Gebruikers en organisaties hechten elke dag meer waarde aan veiligheid en privacy. Technologieën zoals HTTPS, een combinatie van HTTP- en SSL/TLS-protocollen, is ontwikkeld om de vertrouwelijkheid en integriteit van het webbrowsen te waarborgen. Veel organisaties hebben maatregelen genomen om de implementatie van HTTPS te bevorderen. Sinds 2014 heeft Google de ranking van websites die HTTPS implementeren verbeterd. Bovendien kunnen websites in Chrome die geen HTTPS implementeren, geen geografische locaties en de applicatiecache gebruiken. Bovendien kunnen gebruikers mogelijk zelfs geen websites bezoeken die HTTPS niet hebben ingeschakeld. Uiteindelijk zullen ze resulteren in een onveilig symbool in de adresbalk van de Chrome-browser. In het verleden zou het verkrijgen en behouden van digitale certificaten veel kosten. Daarom implementeren kleine bedrijven of grote bedrijven met veel domeinnamen mogelijk geen HTTPS vanwege de kosten. Onlangs heeft Let's Encrypt, met zijn ACME-protocol, het verkrijgen ervan gemakkelijker en goedkoper gemaakt SSL / TLS certificaten, en ze bieden gratis Domain Validation (DV)-certificaten aan via een volledig geautomatiseerd proces. Naast Let's Encrypt bieden verschillende contentdistributienetwerken en cloudserviceproviders, waaronder Cloudflare en Amazon, gratis TLS-certificaten aan hun klanten.
Er zijn echter nog steeds veel HTTP-verbindingen op internet. Het naadloos verwerken van de combinatie van HTTP- en HTTPS-verbindingen is lastig voor browsers vanwege de stripping-aanval. HTTPS-stripping-aanvallen hebben tot wijdverbreide bezorgdheid geleid sinds Marlinspike sslstrip presenteerde op de blackhat-conferentie in 2009. Aanvallers kunnen de communicatie tussen de doelwebsite en de client onderscheppen en alle HTTPS-gegevens in de antwoordpakketten van de website omzetten naar HTTP. Hoewel deze aanval de regel schendt die stelt dat TLS/SSL end-to-end beveiliging moet garanderen, kunnen noch de client, noch de server op de hoogte zijn van de aanval, omdat de pakketten die door de server worden verzonden nog steeds versleuteld zijn.
Om zich tegen de stripping-aanval te beschermen, werd in 2012 het HTTP Strict Transport Security (HSTS)-protocol geïntroduceerd. Het definieert een mechanisme waarmee websites zichzelf alleen toegankelijk kunnen maken via beveiligde verbindingen.
Strippende aanval
Een paar jaar geleden werd HTTPS alleen gebruikt op betaalpagina's of inlogpagina's voor financiële of e-commercedoeleinden. Steeds meer sites begonnen echter HTTPS te gebruiken. Een van de redenen hiervoor is dat veel onderzoeken aantonen dat site-eigenaren HTTPS-service op alle pagina's van de site zouden moeten aanbieden, inclusief volledige resourcebestanden, waardoor encryptie van een deel van de sites onveilig is gebleken. Een andere reden is de opkomst van gratis certificaten en de TLS-accelerator. Het onderhouden van een HTTPS-service was erg duur, inclusief de kosten voor het aanvragen van certificaten, de kosten voor het updaten van certificaten en de prestatieoverhead veroorzaakt door extra encryptie or decryptieGelukkig zijn deze problemen de afgelopen jaren opgelost. Veel organisaties zijn begonnen met het aanbieden van gratis TLS/SSL-certificaten en websites hebben enorm geprofiteerd van HTTPS.
Niettemin vormt een HTTPS-strippingaanval een risico voor HTTPS. Wanneer gebruikers een domeinnaam zonder protocoltype (HTTP of HTTPS) typen, is het standaardaanvraagtype HTTP in plaats van HTTPS. Als de server HTTPS-service biedt, geeft de server doorgaans een 302-omleiding na ontvangst van een HTTP-aanvraag. De aanvaller kan het verkeer echter onderscheppen via ARP-spoofing en alle HTTPS-gegevens in het antwoordpakket vervangen door HTTP. De browser zal dus nog steeds een HTTP-website opvragen, ongeacht de 302-omleidingen. Ook hier kan de aanvaller alle HTTP-gegevens in het aanvraagpakket vervangen door HTTPS. De communicatie tussen de aanvaller en de server is versleuteld, maar de communicatie tussen de aanvaller en de browser is in platte tekst. Deze aanval wordt een HTTPS-strippingaanval genoemd en kan niet worden gedetecteerd door browsers of servers, omdat deze het HTTP-communicatieprotocol volgt.
HSTS-protocol
Om de HTTPS-strippingaanval te voorkomen, werd in 2012 het HSTS-beleid ingevoerd. Websites declareren het beleid via het HTTP-responsheaderveld Strict-Transport-Security of via andere middelen, zoals de configuratie van de user-agent. Als de server altijd HTTPS-service wil aanbieden, stuurt deze een HSTS-header naar de browser. Volgens de informatie in de headers onthoudt de browser de domeinen die via HTTPS moeten worden bezocht. En wanneer gebruikers de volgende keer een HTTP-verzoek verzenden, converteert de browser HTTP automatisch naar HTTPS op de achtergrond. Het HSTS-beleid definieert de standaard voor HSTS-headers en de headers bestaan voornamelijk uit drie velden. Het eerste is het veld max-age, wat de vervaldatum aangeeft en verplicht is. Het tweede is het optionele veld includeSubdomains, dat aangeeft of het HSTS-beleid van toepassing is op de subdomeinen van het domein. Het laatste is het veld preload en eveneens optioneel. Dit veld geeft aan of het domein permanent is toegevoegd aan de preloadlijst die door browserproviders wordt beheerd. Het is essentieel dat HTTPS-verzoeken alleen deze headers kunnen verzenden; de aanvaller kan dus niet willekeurig het HSTS-beleid manipuleren om het uit te schakelen.
Conclusie
Het HSTS-protocol biedt een manier om SSL-strippingaanvallen te voorkomen, maar veel website-eigenaren of -ontwikkelaars begrijpen het HSTS-beleid niet goed. Een SSL-strippingaanval biedt aanvallers een manier om een gebruiker die een website bezoekt in platte tekst te lezen. De gegevens tussen de browser en de aanvaller zijn niet versleuteld, waardoor platte tekst toegang geeft tot alle gegevens, inclusief wachtwoorden, creditcardgegevens en meer. Het HSTS-protocol omzeilt deze problemen en dwingt een browser om encryptie te gebruiken tussen de server en de browser.
