IETF maakt van HTTP Strict Transport Security-protocol een webstandaard

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.

Reacties (16)

[Frank-L]

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.

Of gewoon geen externe reclame serveren op sites die beveiligd zijn.
Dan hadden we ook niet die belachelijk gebruikersonvriendelijke vragen van onze browsers gekregen bij mixed-content.

[Reactie gewijzigd door Frank-L op 23 juli 2024 04:18]

[Cameleon73]

Ja, die beveiligingsvraag van sommige browsers is voor de gemiddelde eindgebruiker erg verwarrend. Zie b.v. deze van IE: als je op Yes klikt, krijg je niet de complete site. Zeker veiliger, maar kan wel leiden tot onduidelijke webpagina's. Een fout van de website, maar -zoals bij vele beveiligingsaspecten- wordt er teveel gevraagd aan de eindgebruiker.

[i-chat]

je hebt helemaal gelijk, ik zou ook liever zo gele balk boven het scherm willen. net als bijv bij flash of andere plugins...

[Anoniem: 26447]

Helaas zegt dat nog 9900 van de 10000 gebruikers niets, Er zijn misschien op de 10.000 gebruikers 2 Tweakers of andere mensen die al die vragen snappen die gesteld worden, maar de rest helemaal niet, dus klik - klik - wat een rotsite, je ziet de helft niet, of die site is knudde wat hij werkt niet op deze computer. (ouderen en zelfs erg veel jongeren, denk zelf dat de verhouding op 50% ouderen en 50% jongeren ligt), als ik tenminste de vragen hoor over alles wat met netwerken en windows te maken heeft.

[Nas T]

Die 9900 gebruikers zeggen niets omdat ze nauwelijk bewust zijn van het probleem en dat dit belachelijk slecht vermeldt wordt door websites. Voorbeeld: Fok! vermeldt je met een soort pop-up iets over cookies, maar de link die je als gebruiker wilt zien staat ergens een stuk naar onder (scrollen). Bij het type pop-up is scrollen niet gebruikelijk en zo worddt de gebruiker uitstekend misleidt.

Vervolgens melden de websites dat bijna niemand gebruik van de functie (het zogenoemde "captain obvious" syndroom?) en proberen ze de beleidsmaker te misleiden om zodoende hun zin te krijgen: doen wat de gebruiker haat om zelf beter te worden: tracking cookies plaatsen.

Owja, dit wil je doen.

[Reactie gewijzigd door Nas T op 23 juli 2024 04:18]

[Digital-Punk]

Altijd fijn om aan de ontvangende kant van al die vragen te zitten. Vooral als je toevallig ergens op visitie komt en blijkt dat jij die whizkid bent.
Ontopic: We zullen dit protocol dus gauw terugzien bij bijvoorbeeld paypal, banken en overheidssites? Ben benieuwd!

[Anoniem: 125509]

Ik denk dat je het voorlopig nergens gaat tegenkomen. Voor zover mij bekend wordt het nog niet door Internet Explorer (en Safari) ondersteund. Als je nu zou afdwingen dan ontzeg je opeens een hele hoop klanten de toegang.

Iemand beweerde pas dat Microsoft juist heel vlot was met het implementeren van standaarden. Jammer dat ze hier de bal laten liggen.

[TvL2386]

Das dus niet waar. Als je leest wat het precies inhoud, zie je dat het gewoon een extra HTTP Header is: "Strict-Transport-Security: max-age=31536000". Als je browser deze header niet support, zal hij hem negeren en is het gedrag dus net als bij elke andere site. De Wikipedia pagina is erg informatief: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security.

Wanneer je de website bezoekt op https en bovenstaande header is gezet, dan zullen alle requests die je voor dat domein volgt automatisch via https verlopen zelfs wanneer ergens (al dan niet per ongeluk) http staat. Dit totdat max-age is expired.

Ik vind dit schijnveiligheid. Dit werkt alleen wanneer je de pagina eerder hebt bezocht en je dus weet dat deze site HSTS afdwingt/aangeeft. De preloaded list waarmee Chrome komt is uiteraard niet volledig. Je moet je site zelf aanmelden. Firefox 17 heeft als target ook zo'n list te bevatten: https://wiki.mozilla.org/Privacy/Features/HSTS_Preload_List

Ik vind persoonlijk dan ook eigenlijk niet dat dit echt veel toevoegd aan de bestaande veiligheid die https biedt.
Je kan ook kiezen dat je van de HTTP URL een permanent redirect maakt, dan heb je ook geen initiele HTTP requests meer na het eerste request, net als met deze nieuwe standaard (ik vind het meer een minimale extensie). Uiteraard beschermt een permanent redirect niet tegen "onveilige http links", maar als je geen http links wilt, moet je daarvoor zorgen. Als je ze dan wel op je site hebt staan, zijn dat bugs die gefixed moeten worden.

Aangezien deze header werkt op jouw domein (en optioneel subdomains), vraag ik mij sowieso af hoe de browser zich zal gedragen wanneer je een http link include naar een andere site, of wanneer je een plaatje gebruikt met source naar een andere site. Zonder HSTS zal je browser aangeven dat er onveilige content geinclude wordt, maar wat gebeurd er dan met HSTS? Waarschijnlijk precies hetzelfde omdat het alleen van toepassing is op het huidige domein.

[Mr_Light]

Merk op dat HSTS toegepast wordt op domein niveau, waar een 301 permanent redirect resource niveau werkt.

Ik vind dit schijnveiligheid. Dit werkt alleen wanneer je de pagina eerder hebt bezocht en je dus weet dat deze site HSTS afdwingt/aangeeft.

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'.

Zo als ook al aangegeven op de wiki overigens:

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

zijn dat bugs die gefixed moeten worden.

Bugs zullen zich voordoen, en totdat ze gefixed zijn heb je in dat geval nog altijd wel een gat in jouw beveiliging.

net als met deze nieuwe standaard (ik vind het meer een minimale extensie)

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.

[Reactie gewijzigd door Mr_Light op 23 juli 2024 04:18]

[Anoniem: 125509]

Ik vind dit schijnveiligheid. Dit werkt alleen wanneer je de pagina eerder hebt bezocht ...

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.

[Mr_Light]

"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."

http://www.jtmelton.com/tag/http-strict-transport-security/

aan de server kant word er dus een header geset, als de brower daar niet mee om kan gaan negeert hij deze gewoon. Er zijn dus geen issues voor oudere browsers en iedereen kan gewoon door gaan met browsen. Mensen met een degelijke browser genieten echter van de verbeterde beveiliging.

Heb je liever de spec er bij zie dan 5.1 uit RFC 6797( http://tools.ietf.org/html/rfc6797#section-5.1 ):

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.

UAs = HTTP user agents (zie introduction)

Dat de browser de boel negeert kan je van mij aan nemen of je kan aannemen dat ze zich aan RFC 2616 (http 1.1) houden. zie ook
http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.1

Unrecognized header fields SHOULD be ignored by the recipient and MUST be forwarded by transparent proxies.

Het is voor developers vrij simpel te implementeren, zie wiki voor voorbeelden:
http://en.wikipedia.org/w...t_Security#Implementation

[Reactie gewijzigd door Mr_Light op 23 juli 2024 04:18]

[Anoniem: 125509]

I stand corrected. Bedankt voor de extra info.

Al blijft het mijn mening dat het door alle browsers ondersteund zou moeten worden om een beetje zoden aan de dijk te zetten.

[Anoniem: 125509]

Firefox, Chrome en Opera zou ik toch niet scharen onder enkele browsers. Qua marktaandeel kan je beter stellen dat we al over de helft zitten.

[egnappahz]

En uiteraard ondersteund Opera dit ook al vanaf versie 12.02,

(Mocht die goede browser iemand interesseren)

[Battle Bunny]

"hsts"-protocol komt dus uiteindelijk voor "Hypertext Transfer Protocol Strict Transport Security Protocol"-protocol te staan? Wellicht niet de best gekozen naam ...

[R-J_W]

Het is een hele duidelijke benaming, wanneer je je over het gebruik van de afkorting HTTP kunt zetten.
We gebruiken HTTP zoveel dat we het 'als' een normaal woord gebruiken en het eigenlijk nooit uitschrijven.
Daarbij is het niet een protocol zoals HTTP, maar een protocol voor gebruik met HTTP.

Het is de afkorting die voor verwarring kan zorgen, (al denk ik niet dat deze veel gebruikt gaat worden) en dat er hier gesproken wordt over een 'protocol', waardoor de associatie met HTTP ontstaat.
De header is dan ook gewoon: "Strict-Transport-Security"