De Internet Engineering Task Force heeft het HTTP Strict Transport Security-protocol tot webstandaard verheven. Het hsts-protocol, een mechanisme dat de betrouwbaarheid van versleutelde ssl-verbindingen moet verbeteren, wordt echter nog weinig toegepast.
Via het hsts-protocol kunnen websites in de http response header aangeven dat zij uitsluitend toegankelijk zijn via versleutelde https-verbindingen. Reguliere onversleutelde http-verbindingen worden daarbij geweigerd. Het protocol moet een aantal aanvalsmethoden verhinderen op websites die ssl gebruiken. Zo voorkomt hsts-protocol dat zogenaamde mixed content wordt ingeladen door een webbrowser. Het mixed content-probleem treedt op wanneer een webserver bijvoorbeeld scripts van een niet beveiligde server van een derde partij ophaalt en aan de eindgebruiker serveert. Hierdoor ontstaat het risico dat een aanvaller een zogeheten session cookie weet te bemachtigen.
Hsts kan ook een middel zijn om man-in-the-middle-aanvallen te verhinderen. Browsers die contact leggen met websites die hsts ondersteunen en dus een https-verbinding vereisen, slaan deze informatie tijdelijk in een cache op. Als de gebruiker opnieuw verbinding maakt met dezelfde site, zal uit de browsercache blijken dat de website een https-verbinding nodig heeft. Zolang de houdbaarheidsdatum van deze informatie in de browsercache niet is verlopen, zal het uitvoeren van een man-in-the-middle-aanval aanzienlijk bemoeilijkt worden.
Inmiddels heeft het Internet Engineering Task Force het HTTP Strict Transport Security-protocol als webstandaard gepubliceerd. Enkele browsers, waaronder Chrome en Firefox, kunnen met hsts overweg, maar er zijn nog relatief weinig websites die gebruik maken van het protocol. Zo heeft SSL Pulse, een project dat het gebruik van ssl op het web in kaart brengt, becijferd dat van de 180.000 populairste websites met https-ondersteuning slechts een kleine 1700 hsts geactiveerd heeft. Daarnaast zouden veel van deze sites de hsts-implementatie niet goed geconfigureerd hebben, bijvoorbeeld door een te korte caching-periode via de time to live-instelling, zo schrijft NetworkWorld.
Het is de vraag in hoeverre hsts breder geïmplementeerd zal gaan worden nu het protocol een officiële IETF-standaard is. Diverse sites van Google ondersteunen het veiligheidsmechanisme, evenals PayPal en Twitter. Facebook is bezig om dataverkeer via https te laten verlopen, maar de sociale-netwerksite biedt nog geen hsts-ondersteuning.
Of gewoon geen externe reclame serveren op sites die beveiligd zijn.Zo voorkomt hsts-protocol dat zogenaamde mixed content wordt ingeladen door een webbrowser. Het mixed content-probleem treedt op wanneer een webserver bijvoorbeeld scripts van een niet beveiligde server van een derde partij ophaalt en aan de eindgebruiker serveert.
[Reactie gewijzigd door Frank-L op zondag 25 november 2012 13:44]
[Reactie gewijzigd door Nas T op zondag 25 november 2012 21:00]
http://www.jtmelton.com/tag/http-strict-transport-security/"There are no backwards compatibility issues and it only enhances your security posture. By adding the header, you give your users greater security with very little effort on your part."
UAs = HTTP user agents (zie introduction)5.1. HSTS Host Declaration
An HTTP host declares itself an HSTS Host by issuing to UAs an HSTS
Policy, which is represented by and conveyed via the
Strict-Transport-Security HTTP response header field over secure
transport (e.g., TLS). Upon error-free receipt and processing of
this header by a conformant UA, the UA regards the host as a Known
HSTS Host.
Het is voor developers vrij simpel te implementeren, zie wiki voor voorbeelden:Unrecognized header fields SHOULD be ignored by the recipient and MUST be forwarded by transparent proxies.
[Reactie gewijzigd door Mr_Light op zondag 25 november 2012 21:09]
bootstrappen is belangrijk. Nu beperk je het tot eerste http request. In de toekomst wordt het waarschijnlijk nog eerder in het proces, namelijk eerste dns request icm met dnssec en een dns server die je wel vertrouwd kom je een heel eind zeker in combinatie met The DNS-Based Authentication of Named Entities http://tools.ietf.org/html/rfc6698 Preloaded lists scalen niet en worden snel 'oud'.Ik vind dit schijnveiligheid. Dit werkt alleen wanneer je de pagina eerder hebt bezocht en je dus weet dat deze site HSTS afdwingt/aangeeft.
The Chrome browser attempts to limit this problem by including a "pre-loaded" list of HSTS sites.[16] Unfortunately this solution cannot scale to include all websites on the internet; a potential solution might be achieved by using DNS records to declare HSTS Policy, and accessing them securely via Secure DNS, optionally with certificate fingerprints to ensure validity (although Secure DNS will have secure last mile issues for the foreseeable future
Bugs zullen zich voordoen, en totdat ze gefixed zijn heb je in dat geval nog altijd wel een gat in jouw beveiliging.zijn dat bugs die gefixed moeten worden.
het is een open deur maar extensies moeten ook worden gestandaardiseerd. Een rondje langs de RFC's leert dat de meesten niet echt 'groot' zijn.net als met deze nieuwe standaard (ik vind het meer een minimale extensie)
[Reactie gewijzigd door Mr_Light op maandag 26 november 2012 12:41]
Wat bij je bank ook meestal wel het geval zal zijn. En dat is volgens mij juist waarvoor het bedoelt is. Man in the middle aanvallen moeilijker maken.Ik vind dit schijnveiligheid. Dit werkt alleen wanneer je de pagina eerder hebt bezocht ...
Op dit item kan niet meer gereageerd worden.
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True