Gebruikers en organisaties hechten steeds meer waarde aan beveiliging en privacy. Technologieën zoals HTTPS , een combinatie van HTTP- en SSL/TLS-protocollen, zijn ontwikkeld om de vertrouwelijkheid en integriteit van webbrowsing te waarborgen. Veel organisaties hebben maatregelen genomen om de implementatie van HTTPS te stimuleren. Sinds 2014 heeft Google de ranking van websites die HTTPS gebruiken verbeterd. Bovendien kunnen websites zonder HTTPS in Chrome geen gebruik maken van geografische locatiegegevens en de applicatiecache. Gebruikers kunnen websites zonder HTTPS mogelijk zelfs helemaal niet bezoeken. Uiteindelijk verschijnt er een onveilig symbool in de adresbalk van de Chrome-browser. In het verleden waren digitale certificaten erg duur. Daarom kozen kleine bedrijven of grote bedrijven met veel domeinnamen er vaak niet voor om HTTPS te implementeren vanwege de kosten. Recentelijk heeft Let's Encrypt, met zijn ACME-protocol, het verkrijgen van SSL/TLS -certificaten eenvoudiger en goedkoper gemaakt. Ze bieden ook 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
Enkele jaren geleden werd HTTPS alleen gebruikt op betaalpagina's of inlogpagina's van financiële of e-commercewebsites. Steeds meer websites zijn echter HTTPS gaan implementeren. Een van de redenen hiervoor is dat veel studies aantonen dat website-eigenaren HTTPS op alle pagina's van hun website zouden moeten aanbieden, inclusief alle bronbestanden. Het versleutelen van slechts een deel van de website is immers onveilig gebleken. Een andere reden is de opkomst van gratis certificaten en TLS-accelerators. Het onderhouden van een HTTPS-service was voorheen erg duur, vanwege de kosten voor het aanvragen en bijwerken van certificaten en de prestatievermindering door extra versleuteling of ontsleuteling . Gelukkig zijn deze problemen de afgelopen jaren opgelost. Veel organisaties zijn begonnen met het aanbieden van gratis TLS/SSL-certificaten, waardoor websites enorm hebben 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.
