Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 42 reacties

Microsoft heeft ondersteuning voor http strict transport security naar Internet Explorer 11 op Windows 7 en Windows 8.1 gebracht. De beveiligingsfunctionaliteit was al standaard ingeschakeld bij IE 11 en Edge in de Windows 10-testversie.

Internet Explorer 10 logo (75 pix)De http strict transport-bescherming is naar IE 11 op Windows 7 en 8.1 gekomen als onderdeel van cumulatieve beveiligingsupdates die op patch-dinsdag werden uitgerold, meldt Microsoft. Hsts was al aanwezig in Internet Explorer 11 in de Windows 10-preview en ook de nieuwe Edge-browser bevat de feature.

Http Strict Transport Security is een IETF-protocol dat sites beschermt tegen bepaalde man-in-the-middle- of downgrade-aanvallen, die ervoor zorgen dat de tls-bescherming verwijderd wordt en communicatie tussen server en gebruiker te onderscheppen is. Dankzij hsts geven sites via een http-header aan dat ze alleen nog via https bezocht mogen worden. Onbeschermde verbindingen krijgen een redirect naar https.

Ook garandeert de functionaliteit dat https-sites een valide certificaat gebruiken. Browsers weten welke sites op basis van hsts werken dankzij een lijst die ze bijhouden. Chrome, Safari en Firefox ondersteunen deze preloaded-lijst al.

Moderatie-faq Wijzig weergave

Reacties (42)

Jose Selvi heeft op Black Hat Asia meerdere technieken getoond om HSTS te omzeilen. O.a. het veranderen van de hostname d.m.v een tool dns2proxy.

Hier een tool waar je het mee kunt testen. Er zit o.a. een soortgelijke versie van dns2proxy in.

Vraag me af of hier ook ooit nog fixes voor zullen komen.

Ik heb het veranderen van de hostname een paar dagen geleden nog getest, en dit werkt nog prima :)

[Reactie gewijzigd door VeQVQUCjsxagUCH op 10 juni 2015 22:30]

Meerdere technieken? In die link zie ik alleen een methode om misbruik te maken van de max-age functie van HSTS doormiddel van het uitvoeren van een man in the middle attack op NTP tijd sychronizatie verbinding..

Lijkt mij nu niet echt een practische methode, aangezien ik op Windows 8 de precieze datum en tijd heb staan.
Sorry, ik haal het document door de war met zijn presentatie. Hier zijn presentatie, waar hij wel verteld over het veranderen van de hostnames.
Helaas is dit geen echte omzeiling van HSTS.

Zoals Gijs007 aangeeft, wat gedaan wordt is een zwakheid in bepaalde NTP implementaties te misbruiken om de tijd vooruit te zetten, en dan hopen dat een gebruiker kort genoeg daarna een belangrijke website bezoekt, en dan een SSL-strip uit te voeren.

Maar een goede NTP implementatie heeft diverse beschermingen tegen deze aanval aangezien deze al bekend is. Standaard Windows (en Windows Phone) zijn bijvoorbeeld al niet kwetsbaar. Apple Safari heeft verder ook een bescherming die bij bepaalde websites de expiration gewoon negeert en altijd HTTPS doet.
Met alle respect naar de Linux fans, maar dan hebben we al ruim 99% van de desktop markt die veilig is O-)

Merk tenslotte op dat HSTS net als andere veiligheidsmaatregelen ook nooit eeuwig 100% zal werken. Het voegt ecter wel een grote barriere toe, want men moet nu n NTP hacken n een DNS hack n een SSL-strip. Security is altijd een wapenwedloop.
Volgens mij gaat die presentatie ook alleen over het misbruik maken van de max-age.
Daar gaat zijn presentatie inderdaad over, maar hij heeft het bijvoorbeeld ook over de techniek van Leonardo Nve.

[Reactie gewijzigd door VeQVQUCjsxagUCH op 10 juni 2015 22:35]

HSTS is ook maar een hack. Ik zie het als iets tijdelijks. Op termijn verwacht ik dat we altijd HTTPS gaan gebruiken. Als browsers by default met HTTPS gaan verbinden ipv met HTTP dan is HSTS ook niet meer nodig.
Op termijn verwacht ik dat we altijd HTTPS gaan gebruiken

HTTP 2.0 is inderdaad 100% TLS only.

(De spec staat non-TLS toe ivm lobbywerk van provdiers en advertentiebedrijven, maar alle grote implementerende bedrijven - Apple, Microsot, Google, etc - hebben aangegeven de non-TLS versie gewoon niet te implementeren.)
Leuk hoor, die lijst. Waarom precies? De header is toch afdoende?

Op zich is een preloaded lijst wel leuk. Maar het doet mij wat denken aan CRL (Certificate Revocation Lists). Men leek dat leuk in het begin, todat de lijsten toch wel wat lang begonnen te worden en niet te vaak worden bijgewerkt (zoals hier ook voor wordt gewaarschuwd bij Chrome). En toen kwam het OCSP. Fantastisch, not... Denk je wat aan privacy te winnen door het gebruik van encryptie, gaat je browser doodleuk voor elk verzoek aan een https-website eerst eens even babbelen met de certificate authority om te controleren of het certificaat nog wel geldig is. Gevolg: de certificate authority weet precies welke websites jij bezoekt. Nee, daar wordt het beter van.

Als ze het nou gelijk even goed aanpakken en niet een hardcoded lijst bouwen, en ook geen specifiek protocol ervoor in het leven roepen, maar eerder in de vorm van diffs werken dan is er een veel handelbaarder systeem. De browser doet een verzoek, krijgt een lijst van ingetrokken certificaten binnen en kan naar eigen inzicht regelmatig vragen om wat er gewijzigd is in die lijst sinds de vorige keer dat die opgevraagd is. Er gaat geen info naar buiten over je surfgedrag en je bent wel altijd net zo actueel als je zelf wilt.

Zonder een dergelijke feature is het wat mij betreft direct alweer einde verhaal. De redirect van http naar https heb ik op al mijn servers aanstaan, en dat werkt goed genoeg.
Geen dingen gaan verwarren. HSTS is perfect bruikbaar en privacyvriendelijk. Als je nu al naar HTTPS redirect kan je die headers echt gewoon best meesturen, er zijn nauwelijks nadelen aan (integendeel).

De preloadlist is een extra garantie. Ik vind het wel leuk om te weten dat als ik met Chrome/Firefox/Safari naar Google/Facebook/Twitter/Dropbox surf ik dan altijd 100% encrypted en veilig bezig ben.

CRLs zijn iets totaal verschillend. Volledige CRLs checken zou te zwaar zijn. OCSP is niet ideaal qua privacy, dus veel browsers doen die check niet. De oplossing? OCSP stapling. Alle veiligheid van OCSP, zonder de privacybezwaren. En twee keer niks om in te schakelen.
CRLs zijn iets totaal verschillend. Volledige CRLs checken zou te zwaar zijn. OCSP is niet ideaal qua privacy, dus veel browsers doen die check niet. De oplossing? OCSP stapling. Alle veiligheid van OCSP, zonder de privacybezwaren. En twee keer niks om in te schakelen.

Geheel eens met je post, maar vanwege mijn OCD moet ik even wat puntjes op de i zetten :)

CRL wordt vooral te zwaar gevonden in context van browsers. Vandaar dat zowel Firefox als Chrome het standaard niet doen. Als OS is het een ander verhaal, en omdat IE de TLS-bibliotheek van het OS gebruikt doet die wl aan CRL controle. Safari op OS-X om gelijke redenen dus ook. Opera is verder 'dwars' (in positieve zin) en controleert CRL's echter ook gewoon in haar browser.

En OCSP is inderdaad niet ideaal qua privacy, doch verplicht in de standaard voor EV-certificaten dus doen alle browsers op alle platformen het. Microsoft heeft bovendien caching ingebouwd op haar OS zodat het niet elke keer een herverzoek hoeft te doen. Dat komt zowel performance als privacy ten goede. Verder heeft het een slim optimalisatie systeem wat CRL's en OCSP afwisselt afhankelijk van zodat ook als het niet in de cache zit er nog steeds niet altijd een OCSP verzoek gedaan wordt.

OCSP stapling zou ideaal zijn, maar Safari aan de clientkant en bij servers alles behalve Microsoft IIS en CloudFlare ondersteunt het helaas niet. :(
"OCSP stapling zou ideaal zijn, maar Safari aan de clientkant en bij servers alles behalve Microsoft IIS en CloudFlare ondersteunt het helaas niet"

Volgens wikipedia: "Apache HTTP Server supports OCSP stapling since version 2.3.3, the nginx web server since version 1.3.7, LiteSpeed Web Server since version 4.2.4, Microsoft's IIS since Windows Server 2008, HAProxy since version 1.5.0, and F5 Networks BIG-IP since version 11.6.0"

Overigens ondersteunt cloudflare het ook al sinds 2012.


"On the browser side, OCSP stapling was implemented in Firefox 26,[5][16] in Internet Explorer since Windows Vista,[17] and Google Chrome in Linux, Chrome OS, and Windows since Vista."
Je hebt gelijk dat ik slordig was in mijn formulering. Em dat terwijl ik de puntjes op de i zette 8)7

Waar ik naar verwees is dat tot relatief recent in de praktijk enkel IIS servers OCPS stapling ondersteunde. Zomer 2013 bijvoorbeeld nog zo'n 95%.

CloudFlare gebruikt (een aangepaste versie van) ngix dus het is verder inderdaad logisch dat dat platform het ondersteunt. CloudFlare ondersteunde het al langer, doch SSL/TLS was een optionele feature en enkel voor betalende klanten. In 2014 is men het standaard gaan maken en gaan aanbieden voor alle klanten inclusief de gratis abbonementen. Gevolg dat het gebruik van SSL/TLS en daarmee OCPS stapling enorm toenam.

Vandaar dat ik IIS en CloudFlare noemde als enige twee die het (in de praktijk) ondersteunen. Het zou mooi zijn als andere bedrijven dit voorbeeld zouden volgen.
Toch zie ik dat als enigszins zorgwekkend.
Je geeft je private key aan CloudFlare (logisch.) en zet je certificaat daar neer.
In principe kan CloudFlare op het dooie gemakje alles verzamelen, encrypt of niet maakt vrij weinig uit. Dat is toch een false sense of security lijkt me.

Ik geloof dat volgens de laatste ramingen CF intussen zo'n 2 miljoen sites van haar diensten voorziet. En er zijn wel meer van dat soort toko's natuurlijk.
En dat terwijl het totaal geen garanties biedt; waarbij een eigen overflow netwerk; of dat van een provider, toch veiliger is en je je dan ook geen zorgen hoeft te maken als het originele IP wordt gevonden.

Ik bedoel, even de dooddoener erbij halen: de NSA.
CF is een Amerikaans bedrijf. CF heeft de sleutels voor een aantal behoorlijk grote websites. Ook een paar underground (waarvan ik echt niet kan begrijpen dat ze uberhaupt CF gebruiken; leuk je IP verbergen, maar als de US overheid er om vraagt: doei.). En dan zie je mensen die CloudFlare met SSL gebruiken "want dan kan de NSA er niets mee". :')

Natuurlijk is het alsnog een voordeel hoor, begrijp me niet verkeerd. En ook een prima initiatief om gratis SSL aan te bieden; het biedt extra veiligheid, veiligheid die sommigen nu totaal niet hebben. En voor huis, tuin en keuken sites boeit het de overheid niets natuurlijk; maar beschermt SSL je wel tegen ongewenste pottekijkers onderweg.

Aan de andere kant heeft CF wel fijntjes al die sleutels, en gezien steeds meer websites op diensten als CF overstappen, vindt ik dat behoorlijk zorgwekkend.
Ze bieden wel Keyless SSL aan, maar dat gebruiken niet zo heul veul mensen blijkbaar.
Je geeft je private key aan CloudFlare

Nee, CloudFlare biedt encryptie aan van klant tot aan hun servers. Of jij encryptie wilt van CloudFlare tot aan jouw servers staat daar los van. Encryptie biedt ook voordelen betreft het gebruik van SPDY, provdiers jouw klanten niet kunnen tracken, jouw images en content niet kunnen comprimeren/modificeren, etc.

Verder hoef je CloudFlare niet jouw private key te geven. CloudFlare heeft een aantal varianten. In de meest gangbare heeft CloudFlare jouw private key juist geheel niet! Uiteraard heeft CloudFlare wel toegang tot de unencrypted data. Dat is logisch, hoe kan men anders cachen ... :) Het is dus een soort MITM aanval die jij toestaat.

Maar mocht jij bijvoorbeeld dat niet willen kun jij ook bepaalde private zaken niet laten cachen en rechtstreeks naar jouw servers laten lopen, en de publieke bulk content via CloudFlare. Maar ja, per definitie kun jij bij HTTPS niet n caching n encryptie hebben.

Maar dit alles heeft natuurlijk zeer weinig te maken met het onderwerp (certifciaat controle op revocatie) en OCSP stapling ;)
Ja, een header meesturen is natuurlijk niet het probleem. Die lijsten zijn wel problematisch.

OCSP Stapling is een gedeeltelijke oplossing, maar nog steeds niet ultiem. Privacyinbreuk wordt erdoor verminderd, maar je hebt er als bezoeker geen invloed op. Ik kan de server niet dwingen om OCSP stapling toe te passen. En zeer weinig servers passen het toe. Bovendien, wat als de OCSP server niet beschikbaar is? Dan wordt er geen OCSP stapling toegepast, en gaat de client alsnog extra requests doen, die ook zullen falen waardoor de website waarschijnlijk onbereikbaar wordt.

Lokale CRLs checken is geen probleem. Met een fatsoenlijke index erachter is dat in fracties van secondes op te zoeken en neemt niet meer dan enkele megabytes in beslag op de schijf van de bezoeker. Bijwerken aan de hand van changelogs die gepubliceerd worden door de CA's of browserbouwers en je bent altijd up to date.

Vooralsnog is voor HSTS de reload-list een hardcoded lijstje in de browser. Niet schaalbaar; meld je je aan dan wordt er handmatig gekeken of je voldoet aan de criteria en wordt de lijst eventueel aangepast. Zodat je maanden later mogelijk bij consumenten terecht komt. Compleet nutteloos dus. Doe het dan gewoon niet; bij de eerste request kan de server mbv de HTST-header ook al aangeven dat hij op de lokaal bijgehouden versie van die lijst moet.
Bijwerken aan de hand van changelogs die gepubliceerd worden door de CA's of browserbouwers en je bent altijd up to date.

Je overdrijft de problemen met CRL's aangezien die uiteindelijk van diezelffde CA's afkomen als de lijsten waar jij naar verwijst. Qua accuraatheid en snelheid ben je dus afhankelijk van diezelfde CA's als die de CRL's publiceren. Loake lijsten lopen dus altijd achter op de CRL's van de CA's zelf.

Overigens de grote 3 (of 4?) doen dat toch al. Microsoft heeft haar CryptoAPI certificaten bibliotheek die ze dynamisch (buiten Windows Update) kunnen wijzigen, Chrome de CRLset en Firefox de OneCRL. (Apple kon ik niet vinden en is volgens mij de enige die dit niet doet.).

Lokale CRL's zijn dus leuk, maar een goede beveiliging is n-n. Alle grote techbedrijven doen een combinatie van zaken. Enkel Chrome doet alleen lokale CRL checks (behalve bij EV-certificaten omdat ze dus moeten van de standaard), iets waarvan ze zo ongeveer van de heel security community door bekritiserd worden. Voor bedrijfsomgevingen kun je het zelfs bij Chrome dus ook weer aanzetten via de policy editor.

Terug naar het topic: de HTST lijst is inderdaad slecht schaalbaar, doch ook vooral een overbrugging tot HTTP 2.0 En bij Safari is het meer dan alleen een preload. Zo zal men bij preloaded sites ook de expiration date negeren zodat een aanval die de systeemklok op jouw Mac zou wijzigen geen zin heeft.

Net zoals CRL lijsten zijn HSTS pre-loads niet perfect, maar dat hoeft ook niet. Het gaat erom de zaak moeilijk genoeg te maken voor een tegenstander.
Https is ernstig overrated. Het garandeert alleen maar dat je praat met wie jij denkt te praten. Maar dat kan ook met de duivel himself zijn. Of met een site die aan de achterkant zijn wachtwoordenbestanden gewoon verkoopt aan de hoogste bieder. Maar dan weet je tenminste wl zeker dat je met die site van doen hebt.
En het feit dat de inhoud van pakketjes waardeloos zijn in het geval iemand je verbinding zit af te luisteren (*kuch*public network*kuch*) is natuurlijk totaal geen voordeel ofzo...
Dat https het mogelijk maakt om gewoon je bankzaken te kunnen doen op een open netwerk (al ben ik zelf paranoide genoeg om dat alsnog niet te doen, maar afijn.) zonder dat iemand kan zitten meelezen is natuurlijk echt absoluut geen voordeel... En dat je gewoon kan inloggen op diensten die HTTPS ondersteunen (bijvoorbeeld je webmail client (inclusief diensten als gmail, outlook, etc.) zonder dat mensen je wachtwoord kunnen onderscheppen uit de lucht, en/of mee kunnen lezen wat jij aan e-mail hebt binnen gekregen of aan het versturen bent, is natuurlijk totaal geen voordeel.

Natuurlijk, de uitbater van de site/dienst waarmee je communiceert moet wel netjes zijn. Al heeft de verkoop van wachtwoorden helemaal niets met SSL te maken, maar dat terzijde.
Dat steeds meer mensen https op hun eigen site zetten, is natuurlijk geen voordeel voor die mensen... Dat mensen met hun eigen servers HTTPS inzetten voor encryptie, is natuurlijk totaal geen voordeel; kunnen ze zichzelf wel vertrouwen dat ze hun eigen wachtwoord niet doorverkopen...? Welnee, allemaal overrated; dat hele SSL verkeer is nutteloos. :')

Hou toch op man. :P
Als je werkelijk denkt dat HTTPS enkel en alleen is om te verifieren met wie je aan 't praten bent, dan mis je toch echt een nogal essentieel puntje van HTTPS waardoor het zo geniaal is: de encryptie tussen jou en de andere partij, waardoor bijvoorbeeld 14 jaar oude eikeltjes prima opgevoede jongeheren met wireshark niet zomaar je wachtwoord kunnen jatten als je ergens inlogt...
Er hoeft maar ergens tussen jou en de andere partij afgeluisterd te worden en ze lezen zo alles mee. HTTPS zorgt ervoor dat dat niet kan/een heel stuk moeilijker is. Als je dat onbelangrijk vindt... Meh.

HTTPS is zeer belangrijk, in toenemende mate zelfs kunnen we wel stellen, en er zijn eigenlijk nog altijd veels te weinig sites die het inzetten.

[Reactie gewijzigd door WhatsappHack op 12 juni 2015 03:55]

Welk deel van "garandeert dat jij praat met wie jij denkt te praten" snap je niet?

Ik zeg toch nergens dat HTTPS niet gecodeerd is? Allicht is het gecodeerd en moeilijk af te luisteren. Daarom weet je praktisch zeker dat je met HTTPS praat met wie jij denkt te praten, en kun je er praktisch van uit gaan dat je niet afgetapt wordt onderweg. Maar het punt dat ik maak is precies dat ene zinnetje dat je wl gebruikt: "de uitbater van de site/dienst moet wel netjes zijn". En dt kan HTTPS nou net niet garanderen. En dr gaat het vaak mis.

Maar goed, die redenatie zal wel iets te hoog gegrepen zijn voor je.
Maar goed, die redenatie zal wel iets te hoog gegrepen zijn voor je.
Ach gossie, iemand is op z'n tenen getrapt omdat ie zelf een verkeerde uitleg post en daarop wordt aangesproken. :')
Doe eens normaal zeg. ;)

Anyway, dat terzijde...
Welk deel van "garandeert dat jij praat met wie jij denkt te praten" snap je niet?
Dat snap ik prima... Maar dat iets garandeert met wie je praat staat totaal niet direct gelijk aan dat dit gesprek dan ook direct encrypt is...
Je kan enkel verifieren dat je gesprekspartner wel de gene is met wie je wilt praten OF je kan enkel encrypten OF je kan beiden tegelijk uitvoeren... Er zijn verschillende technieken beschikbaar.
Ik zeg toch nergens dat HTTPS niet gecodeerd is?
Ja, dat zeg je wel... Je zegt:
Https is ernstig overrated. Het garandeert alleen maar dat je praat met wie jij denkt te praten
Dat is dus niet waar. Het garandeert helemaal niet alleen maar dat je praat met wie jij denkt te praten. Het garandeert dat PLUS het encrypt het verkeer. En dat is nu juist het grote voordeel van HTTPS.
Maar het punt dat ik maak is precies dat ene zinnetje dat je wl gebruikt: "de uitbater van de site/dienst moet wel netjes zijn". En dt kan HTTPS nou net niet garanderen. En dr gaat het vaak mis.
En laat dat nou net een open deur intrappen zijn...
Daarnaast heb je ook geen enkel argument gegeven waarom HTTPS te allen tijde overrated zou zijn, puur omdat een enkeling een rotte appel kan zijn... Dat er iets mis kan gaan doordat de ontvanger niet te vertrouwen is, wil niet zeggen dat daardoor de gehele techniek waardeloos/overrated is; die redenatie slaat nergens op.

Ik weet het niet zeker, maar moet ik nu ook nog afsluiten met een ad hominem aanval? ;)

[Reactie gewijzigd door WhatsappHack op 12 juni 2015 13:38]

Ik weet het niet zeker, maar moet ik nu ook nog afsluiten met een ad hominem aanval?
Nee, doe maar niet, daarmee zet je jezelf alleen maar mr voor schut. Sorry.

Natuurlijk garandeert het alleen maar dat je praat met wie je denkt te praten. Als het niet encrypted zou zijn, en daarmee eenvoudig af te luisteren - of liever, te manipuleren - valt, dan praat jij niet direct met wie jij denkt te praten. Maar, for the sake of discussion, laat ik dan toevoegen "zonder een groot risico te lopen afgeluisterd te worden". Want k die encryptie is niet waterdicht, en ook SSL-certificaten kunnen vervalst worden.

Mijn uitleg deugt, jouw interpretatie niet. Zo simpel is het. En je zegt zelf dat het een open deur is. Maar ja... voor jou misschien wel, voor anderen misschien niet. Welkom op Tweakers! Misschien kun je er gemakshalve wel even van uit gaan dat niet iedereen dezelfde kennis heeft en niet alle deuren voor iedereen open zijn, en sommige cht nog wel eens ingetrapt mogen worden.. waarvan akte.

Het is, buiten jouw belevingswereld om, namelijk nogal eens de gewoonte dat mensen denken dat een bepaalde website https gebruikt, 'dus' zal het veilig en betrouwbaar zijn.

En nee, dat is het niet per definitie. HTTPS garandeert in hoge (maar niet volledige) mate dat jij praat met wie jij denkt te praten -door encryptie en het ondertekenen van de echtheid van de site* - maar dat zegt nog niets over de eigenaar van de site of wat die eigenaar met de gegevens doet die jij aanlevert of afneemt. Dat was mijn punt en dat was duidelijk omschreven.

Maar ja, als je een punt wil maken hier moet je blijkbaar alle randvoorwaarden noemen, anders zijn er blijkbaar mensen die niet helemaal snappen wat je bedoelt. En dat geeft niks; maar om hun onvermogen om iets van de materie te begrijpen gelijk te projecteren op een ander is een tikkeltje.. hoe zeg je dat.. sneu.

* Voorwaarden voor een SSL-certificaat zijn bijvoorbeeld, maar niet beperkt tot, NAW-gegevens en telefonische controles van de echtheid van de domeinnaamhouder door de certficerende instantie(s).

Trouwens, misschien dat je er even een Engels woordenboek op na moet slaan, maar 'overrated' is niet hetzelfde als 'waardeloos'. Overrated, zeker in deze context, betekent dat er onterecht tevl waarde aan wordt gehecht, precies om de reden die ik aangeef. De techniek is prima. Waar het vaak aan schort is de implementatie en consumenten die blind vertrouwen op dat groene adresbalkje. Ook bij sites die https gebruiken moet je blijven opletten wat er met je data gebeurd, da's alles..

[Reactie gewijzigd door DigitalExcorcist op 12 juni 2015 15:06]

Nee, doe maar niet, daarmee zet je jezelf alleen maar mr voor schut. Sorry.
Gelukkig heb ik tot dusver enkel feiten gepost, dus met dat voor schut staan zal het wel meevallen. :)
Excuses aanvaard!

-edit-
Nu ten eerste even iets anders; ff iets helder maken voordat mensen dit alles verkeerd gaan begrijpen... Ik ben bang dat ons gebruik van de term "met wie je praat" verwarring kan veroorzaken.
Aan een ieder die deze discussie leest zonder verstand van encryptie:

De termen "garandeert met wie je praat" die in deze discussie voorbij komen slaan constant enkel op client-server communicatie, dus in situaties als: "ik wil inloggen bij internetbankieren op rabobank.nl. Ben ik wel echt verbonden met rabobank.nl??". Daar garandeert HTTPS dat je verbonden met Rabobank.nl. (En garandeert tevens dat de verbinding versleuteld is, en dus niet af te luisteren valt.)

Echter, bij diensten waarmee je via een server communiceert met iemand anders (eg: chatdienst, e-mail diensten, etc.); dan ongeacht of de verbinding HTTPS beveiligd is of niet heb je geen garantie dat je werkelijk praat met je gesprekspartner.
Daar kan je enkel zeker van zijn als jij en je gesprekspartner los van de server digitale handtekeningen, andere vormen van hashes of volledige end-to-end encryptie gebruiken. (Met bewezen technieken... Anders is het nog niet controleerbaar. Neem Telegram als voorbeeld hoe het dus niet moet als je veilig wilt zijn met end-to-end encryptie.)

"Praten" slaat hier dus op HTTPS communicatie tussen je browser en een server (jouw browser "praat" met de server), niet op praten met een persoon terwijl er nog een server tussenzit. ;)
-/edit-

Dan, back to the discussion at hand:
Natuurlijk garandeert het alleen maar dat je praat met wie je denkt te praten. Als het niet encrypted zou zijn, en daarmee eenvoudig af te luisteren - of liever, te manipuleren - valt, dan praat jij niet direct met wie jij denkt te praten.
Neen. Het garandeert dat je praat met wie je denkt te praten, en encrypt het verkeer. Je krijgt dus "confidentiality", iets dat je niet hebt als je enkel controleert met wie je praat...
Daar zit echt een extreem groot verschil in!

Een wat makkelijker voorbeeld:
Als ik met jou praat in volle trein, dan kunnen anderen dat horen. Maar omdat ik jou zie, weet ik dat ik met jou praat. Ik heb dus absoluut de garantie dat ik daadwerkelijk met jou aan het praten ben; en hoewel er veel mensen zijn is er niemand die de woorden die ik uitpsreek kan veranderen dus is ook de integriteit gewaarborgd. Ik heb echter niet de garantie dat het gesprek vertrouwelijk is!
Dit is vergelijkbaar met een Digital Signature.

Nu anders:
Ik zit alleen met jou in een kamer, er is niemand anders en ook geen afsluiterappartuur oid.
Nu heb ik de garantie dat ik met jou praat, niemand kan mijn woorden wijzigen dus hebben we ook integriteit, en weet ik zeker dat het veilig is omdat niemand ander kan meeluisteren.
... Of we spreken in die volle trein in codetaal die alleen jij en ik kunnen omzetten naar echte taal, dan zitten we wat dichter bij "encryption" in plaats van "secrecy". :P


Ergo: het feit dat ik de garantie heb met jou te praten, garandeert nog niet dat het ook een vertrouwelijk gesprek is.

Is dat niet even een groot verschil?
In beide situaties heb ik de garantie dat ik met jou praat, maar in de ene situatie is het vertrouwelijk; in de andere niet.
Hetzelfde geldt op het internet; ik kan enkel de garantie hebben met jou te praten, of ik kan de garantie hebben met jou te praten maar dat niemand met ons mee kan luisteren. Dat is een super belangrijk verschil.


Je kan nog altijd praten met wie je denkt te praten terwijl de content zelf niet encrypt is. Dan praat je alsnog met wie je wilt praten en kun je dat prima verifieren, maar kunnen anderen eventueel meeluisteren naar "het gesprek"; cq: de data inzien die jij verstuurd hebt. (Zij kunnen het dan echter niet wijzigen.)
Er zijn andere methoden om dit te controleren zonder dat hier ook encryptie op toegepast wordt... En dat is een zeer belangrijk nuance verschil, zeker als je net wilt doen alsof je uitleg voor de leek is, dan moet je wel zorgen dat het klopt.
Welkom op Tweakers, toch? ;)

Hier, wat leesmateriaal voor je, dan snap je misschien wat ik bedoel. Het verschil tussen encryptie en handtekeningen:
https://en.wikipedia.org/wiki/Digital_signature
http://stackoverflow.com/...-in-asymmetric-encryption

-----
Enkel authenticated = wel de garantie dat het afkomt van de persoon met wie je wilt praten, maar geen garantie dat die persoon het ook direct aan jou verstuurd heeft (al boeit dat vrij weinig...), geen garantie dat het bericht is aangepast, en ook geen garantie dat niemand anders het kan lezen! Je hebt hier dus de garantie dat het bericht daadwerkelijk van de persoon/server afkomt; ongeacht of daar nog iemand tusseninzit of niet.

Voorbeeld situatie:
Ik log in op Tweakers.net en post een reactie. Ik ben authenticated.
Nu wijzigt een Moderator mijn bericht. Maar omdat er geen integriteit controle is, weet niemand zeker of ik wel geschreven heb wat er in die post staat. ;) En omdat het publiek is, is er ook duidelijk geen encryptie.

Dit is in principe dus wat jij beweert als je zegt dat HTTPS enkel "garandeert met wie je praat"...

Enkel encrypted = wel de garantie dat het niet af te luisteren valt (tot op zekere hoogte, ja.), maar geen garantie dat je "praat" met wie jij wilt praten! (En dus ook geen garantie op integriteit, dus geen garantie dat er niet met de data geknoeid is. "Als het encrypted is, dan valt het niet te manipuleren" is dus absoluut niet waar!

Voorbeeld: twee mensen encrypten een bericht met dezelfde sleutel. Jij hebt de decryptiesleutel. De encryptiemethode draagt geen zorg voor authenticatie noch voor integriteit. Jij kan het bericht nu wel ontcijferen, maar je weet niet van wie het afkomt, noch of de inhoud van het bericht wel is wat er verstuurd werd. Misschien is er namelijk nog wel een derde persoon die de sleutel ook heeft, en heeft die het bericht tussendoor aangepast! (Noot: met moderne ciphers werkt dat zo niet meer natuurlijk, maar dit is puur even als voorbeeld.)
Eechter: een ieder die de sleutel niet heeft, kan het niet lezen. Wat dat betreft heb je dus wel vertrouwelijkheid!
Bonus link: http://blog.atmel.com/201...ption-and-authentication/

Enkel integriteit = Geen garantie met wie je praat en geen garantie dat het versleuteld is, maar wel garantie dat de data die aan jou verstuurd is ook daadwerkelijk de data is die verstuurd moest worden.

Voorbeeld: Een random persoon maakt een stukje software, en publiceert hier een SHA hash van. De software is niet encrypt, iedereen kan het downloaden. Jij kan het downloaden. Je kan nu enkel zien of de software die je binnen hebt gekregen daadwerkelijk de software is die aangeboden werd, maar je hebt geen bewijs wie het gemaakt heeft noch is het stukje code waar de software uit bestaat vertrouwelijk.
-----

HTTPS gebruikt een combinatie van die drie, (authenticatie + encryptie + integriteit) dus niet enkel authenticatie zoals jij wilt beweren: maar zowel authenticatie als encryptie. En daarnaast ook nog eens integriteit van de HTTPS pakketjes zelf. :) (Doch niet van de data die je verstuurd binnen die pakketjes!! Dat is ook nog ff een puntje dat opgemerkt moet worden. :P)

Authenticated en Integrity los van elkaar zien bij cryptografie is trouwens behoorlijk academisch en zou in de praktijk eigenlijk belachelijk zijn omdat je dan geen werkelijk vertrouwen kan hebben; als je de integriteit niet kan controleren, wat heeft de authenticatie dan nog voor zin? Maar ze zijn wel degelijk los van elkaar te zien en het zijn twee aparte zaken. :)
In de praktijk komen Authentication + Integrity dus vrijwel altijd bij elkaar.
Maar Authentication + Integrity (controleren wie het verstuurd heeft, en of de inhoud wel klopt) komen absoluut niet altijd samen met encryptie! (zorgen dat niemand het kan lezen.)
En dat is nou het fundamentele probleem waarom ik jou "het garandeert enkel met wie je praat" opmerking onjuist vind.
Het is echt: "het garandeert met wie je praat, en het garandeert dat je enkel met die persoon/server praat en niemand anders het kan lezen.".


HTTPS blijft dus toch echt "de garantie dat je praat met wie je praat, en de garantie dat het verkeer versleuteld is." :) Alhoewel daar ook weer een haakje en oogje aan zit: namelijk de integriteitscontrole die hier niet standaard bijzit in alle situaties; maar die enkel van toepassing is op de pakketjes zelf. (Kolere wat een hoop uitzonderingen. :))

Je kan prima verifieren met wie je praat, zonder dat de data zelf encrypt is... Het is jammer dat je net doet alsof die technieken totaal niet bestaan. Dat er iemand tussen gaat zitten, neemt in dat soort gevallen niet weg dat je alsnog praat met wie je wilt praten: immers valt de inhoud totaal niet te manipuleren. ;) En dus praat je alsnog met wie je wilt praten, en kan je zien dat dat zo is; ongeacht dat er iemand tussen zit of dat meer mensen mee kunnen luisteren/lezen. :) Snapje?

Ik bedoel, bij een HTTPS verbinding zitten er ook tig routers tussen; dus eigenlijk is enkel *authenticatie en integriteit* (eg: via signature), en dus niet encryptie!, van belang om te controleren of wat jij binnenkrijgt wel is van de persoon/server met wie jij wilt praten. Het *encryptie* gedeelte is enkel van belang om te zorgen dat anderen het niet kunnen lezen: maar het is *authenticatie* dat ervoor zorgt dat jij zeker weet met wie jij praat. ;)
(En "*direct* praten met" is bij HTTPS dus bijna nooit het geval. Eerder "*enkel* praten met"; dus dat niemand het kan lezen ongeacht wie er allemaal tussen zitten. Kan je mierenneuken vinden, ik vind het een belangrijk nuance verschil...)

HTTPS is wel: garantie dat je praat met met de juiste server, dat de data die uitgewisseld wordt encrypt is en dat de integriteit van de verstuurde pakketjes an sich correct is.
HTTPS is dus niet: enkel garantie dat je praat met de juiste server, maar geen garantie dat de data encrypt is.
Dat laatste is echter wel wat jij steeds zegt.

Mega groot verschil!
Ik hoop dat je dat wel begrijpt nadat je m'n linkjes hebt gelezen en de uitleg hebt gelezen, en derhalve ook snap waarom ik je op dat punt corrigeer. Misschien kan je zelf ook nog eens zoeken naar het verschil tussen authenticatie en encryptie. :)

HTTPS is echt niet enkel authenticatie zoals jij beweert, maar zowel authenticatie als encryptie. En dan heb je dus ook nog integriteit, maar dat wordt niet per se gegarandeerd door HTTPS zelf bij het uitwisselen van data! Enkel de authenticiteit, integriteit en encryptie van de pakketjes zelf wordt gegarandeerd: maar de *inhoud* van de pakketjes; bijvoorbeeld een e-mail, PDFje of een stuk software, daar wordt de integriteit (authenticiteit ook niet perse, trouwens.) niet van gegarandeerd natuurlijk.
Dat wordt juist wel weer gegarandeerd door een keyed Digital Signature toe te passen op de data die je verstuurd. ;) (... of door een andere vorm van integriteitscontrole, zoals via MD5/SHA hashes.) Als je bijvoorbeeld software gaat downloaden, dan gebruik je in de ideale situatie: authenticatie + encryptie + integriteitcontrole. De eerste twee vinden plaats dankzij HTTPS (ben ik wel verbonden met die mirror, en is de verbinding versleuteld?), de laatste controleer je via een hash. (En de pakketjes van HTTPS zelf worden automatisch ook al op integriteit gecontroleerd.)
Echter, bij het inloggen bij de bank kan je er natuurlijk wel vanuit gaan dat de data die je binnenkrijgt ook is wat je bank je heeft gestuurd, je zit immers client-server verbonden en dat is verifieerbaar; dus zou het op de server al aangepast moeten zijn. (Doch: dat is mogelijk...! Maar zeer onwaarschijnlijk. Toch zou een extra signature niet mis zijn voor die data, voor bepaalde accounts en het maken van overboekingen. :))

En die extra authenticate + integrity doe je het liefst natuurlijk ook als je in een client-server-client opzet terecht komt! :) (Bijv.: ik verbind via HTTPS met de server, Pietje doet dit ook. Maar het document wat ik naar Pietje via deze verbinding stuur: daar voeg ik een Digital Signature aan toe, zodat Pietje zeker weet dat het van mij is *en* dat de inhoud onderweg niet gewijzigd is door de server!)

Snap je de grote verschillen tussen deze zaken nu? :)

Bonus link:
https://www.owasp.org/ind...er_Protection_Cheat_Sheet
Maar, for the sake of discussion, laat ik dan toevoegen "zonder een groot risico te lopen afgeluisterd te worden". Want k die encryptie is niet waterdicht, en ook SSL-certificaten kunnen vervalst worden.
Dat is niet enkel for the sake of discussion, dat is om je uitspraak accuraat te maken.
Zo klopt het namelijk een stuk beter, met dat zinnetje erbij. :)

SSL Certificaten vervalsen is trouwens makkelijker gezegd dan gedaan... Zeker zonder toegang tot de netwerken en sleutels. Na de hack bij diginotar bijvoorbeeld was het wel prima mogelijk voor certificaten die door hen uitgegeven waren; daarom werden ze ook linea recta ongeldig verklaard. Over het algemeen kun je er met een zeer hoge mate van zekerheid vanuitgaan dat een SSL certificaat dat een OK status krijgt, ook daadwerkelijk correct is en niet vervalst is.

Maar sure; als je iets echt extreem belangrijks overstuurt: dan moet je er vanuit gaan dat het niet zondermeer veilig is, en extra stappen ondernemen.
Bijvoorbeeld de data apart encrypten van de encryptie van de verbinding zelf...
Mijn uitleg deugt, jouw interpretatie niet. Zo simpel is het.
Neen, je uitleg was onjuist. Punt.
Het is, buiten jouw belevingswereld om, namelijk nogal eens de gewoonte dat mensen denken dat een bepaalde website https gebruikt, 'dus' zal het veilig en betrouwbaar zijn.
En daar kun je over het algmeen ook prima vanuit gaan, tenzij je op shady websites komt.
Als je bijvoorbeeld bij je bank inlogt, bij PayPal, hier op Tweakers of waar dan ook wat respectable sites zijn: dan kan je er prima vanuit gaan dat de verbinding veilig en betrouwbaar is, en dat de ontvangende partij geen misbruik zal maken van de door jou verstuurde data. Dat geeft wel zo'n veilig gevoel!
Het is tegenwoordig ook redelijk de uitzondering dat de beter bezochte websites de wachtwoorden niet perfect encrypten, in plaats van plain-text op te slaan.

Ja, je kan heel paranoide gaan zitten doen; maar zet dan gewoon je PC uit.
Veiligheid staat boven alles, laat dat voorop staan: maar er moet ook nog een stukje usability en vertrouwen zijn. En als jij gewoon sites met een goed aanzien bezoekt, dan kun je er prima vanuit gaan dat SSL de data die je verstuurt beveiligd; en dat de website/dienst die je gebruikt jou wachtwoord veilig opslaat en bewaart.
Echter, de ontvangende partij kan natuurlijk gehacked worden. Hier op Tweakers bijvoorbeeld zou de database gejat kunnen worden, hoe betrouwbaar de staff hier ook is. (En ik acht ze zeer betrouwbaar... Heb ze nu een paar keer mogen ontmoeten, en er zijn niet veel mensen met zulke diepe kennis en een gevoel voor veiligheid en privacy waarboring.) Daarom is het ook van levensbelang om bijvoorbeeld niet aan "password recycling" te doen, of de wachtwoorden nou gehashed worden of niet. Dat is echter richting offtopic, dus daar zal ik verder niet al te diep op ingaan.

Het misbruiken van data bij de ontvangende kant, doet echter niets af aan de nuttigheid van SSL.
SSL/TLS is gewoon van levensbelang op internet, it's that simple. Er is niets "overrated" aan.
Maar ja, als je een punt wil maken hier moet je blijkbaar alle randvoorwaarden noemen, anders zijn er blijkbaar mensen die niet helemaal snappen wat je bedoelt. En dat geeft niks; maar om hun onvermogen om iets van de materie te begrijpen gelijk te projecteren op een ander is een tikkeltje.. hoe zeg je dat.. sneu.
Haha, over sneu gesproken... Kan je nou echt geen enkele post maken zonder op de man te gaan spelen? :)
Nogmaals: doe eens normaal man. Ik val jou ook niet op de man aan omdat je kennelijk nog nooit gehoord had van signature verification. Maar omdat je daar nog nooit van gehoord hebt, vind ik niet dat dit meteen "onvermogen" is... Je hoeft niet alles te weten.
Ik was sarcatisch, maar heb je algehele intellegentie niet in twijfel getrokken. Als je bezig blijft met Ad Hominem aanvallen, zal ik daar denk ik langzaamaan echter wel aan gaan twijfelen.

Je uitleg is gortig en gewoon onjuist als we het over HTTPS hebben. Dat geeft helemaal niets, dat kan gebeuren. Als mensen het "niet snappen", dan moet je misschien even bij jezelf gaan afvragen of je uitleg wel zo goed was. :) Er viel niets verkeerd te snappen aan je uitleg: de uitleg zelf was gewoon incorrect.
Daarnaast kan je, mits je vond dat je uitleg goed was, ook gewoon je mening opnieuw onderbouwen zonder hierbij op te man te spelen. Dat je kennelijk niet zonder kan, is een beetje jammer...

Daarnaast zeg je het zelf al, dit is Tweakers; Er komen zowel leken als experts, dus moet er wel de juiste informatie staan met een uitleg die voor iedereen begrijpelijk is. Jij geeft die niet. Beetje hypocriet om dan te gaan klagen als iemand je verbeterd. :/ Je kan ook gewoon vriendelijk eventjes bedanken voor de verbetering en er iets van leren, you know... Er is helemaal *niets* mis met fouten maken of een techniek verkeerd snappen. In plaats van boos te worden, kan je ook gewoon weer wat opsteken; en dat is dan ook waarom ik op je reageer; en op je blijf reageren om de zaak recht te zetten.

Niet zo boos joh. ;)
* Voorwaarden voor een SSL-certificaat zijn bijvoorbeeld, maar niet beperkt tot, NAW-gegevens en telefonische controles van de echtheid van de domeinnaamhouder door de certficerende instantie(s).
Dat ligt aan het type certificaat.
Het gros van particuliere websites zijn gewoon Domain Validated. Daar komen totaal geen NAW gegevens of telefonische controle aan te pas. Steker nog: daar wordt totaal niet naar gekeken. Het enige dat gecontroleerd wordt, is of jij wel toegang hebt tot de mailbox in de whois gegevens van dat domein; of een van de andere "common mailboxes" binnen dat domein (eg: postmaster, admin, etc.)... De CA weet dan totaal niet wie jij bent, noch wie het aanvraagt. Als ik toegang heb tot de mailbox in jou whois gegevens, of 1 van de common mailboxes binnen jou domein (aldanniet illegaal), dan kan ik prima voor jou een SSL certificaatje aanvragen.

Bij SSL certificaten op basis van Extended Validation (waarbij je zo'n compleet groene balk in je browser bar krijgt) zijn weer een heel ander verhaal, daar moet je een zee aan informatie aanleveren en door allerlei controles heengaan. De veiligheid en verzekering is dan ook sterk verhoogd.
Trouwens, misschien dat je er even een Engels woordenboek op na moet slaan, maar 'overrated' is niet hetzelfde als 'waardeloos'. Overrated, zeker in deze context, betekent dat er onterecht tevl waarde aan wordt gehecht, precies om de reden die ik aangeef. De techniek is prima. Waar het vaak aan schort is de implementatie en consumenten die blind vertrouwen op dat groene adresbalkje. Ook bij sites die https gebruiken moet je blijven opletten wat er met je data gebeurd, da's alles.
Ik weet wat het betekend, maar ben het gewoon niet met je eens. Er wordt niet klakkeloos teveel waarde aan gehecht, het een maakt het ander niet minder namelijk.
Het laat onverlet dat HTTPS nog altijd geen "overrated" techniek is, maar een extreem belangrijke techniek voor communicatie die over het internet heenvliegt.
Dat je moet opletten of de ontvanger wel netjes met je data omgaat: uiteraard. Maar dat doet niets af aan HTTPS, en dat leg je naar mijn mening totaal niet goed uit; jou eerste post maakte de suggestie dat HTTPS an sich overrated is: en dat is het absoluut niet.

Ik ben het dus niet met je oneens dat je wel zeker moet zijn dat de ontvanger betrouwbaar is, maar het doet gewoon niets af aan HTTPS zelf.
Derhalve is HTTPS geen overrated techniek. Voor het gros van de mensen die het internet gebruiken, maakt het sowieso weinig uit; maar is het wel van belang dat hun wachtwoord niet in transit achterhaald kan worden.

Mensen versturen hun data ook gewoon in plain-text als er geen SSL is, ook naar shady sites. (Phising, anyone?) Dat klakkeloos versturen en er vanuit gaan dat de site betrouwbaar is, gebeurt dus ook zonder SSL. ;)
Wat dat betreft kan je daar beter eerst aan werken, dan over HTTPS te klagen. :) Veel mensen weten niet eens wat HTTPS is of dat het uberhaupt bestaat.

Als jij om die reden HTTPS overrated vindt: so be it, dan zullen we het wat dat betreft helaas wel oneens moeten blijven. ;)
Bottom line: Ja, je moet altijd opletten aan wie je je data verstuurt; en of die wel te vertrouwen is/zijn. Neen, dat maakt HTTPS niet overrated of een gevaar vanwege "schijnveiligheid".

[Reactie gewijzigd door WhatsappHack op 13 juni 2015 04:49]

2de deel van die feature is eigenlijk het nuttige want je kan met gemak je hosting zo inrichten dat je geen http requests toe staat en automatisch http redirect naar https.
Dat gaat niet werken. Een MITM aanval om HSTS te omzeilen werkt zoals getoond op dit plaatje: http://www.ilmuhacking.co...009/05/sslstrip_flow1.png
Een aanval zoals in dat plaatje werkt niet zodra de site al een keer bezocht is. Een browser die HTST ondersteunt zal niet eens meer proberen de http versie te benaderen, maar direct een https-sessie opzetten. Alleen voor de eerste request zal deze aanval werken, en als de site niet in de STS preloaded list van de browser staat.
The initial request remains unprotected from active attacks if it uses an insecure protocol such as plain HTTP or if the URI for the initial request was obtained over an insecure channel. The same applies to the first request after the activity period specified in the advertised HSTS Policy max-age (sites should set a period of several days or months depending on user activity and behavior). Google Chrome, Mozilla Firefox and Internet Explorer/Microsoft Edge address this limitation by implementing a "STS preloaded list", which is a list that contains known sites supporting HSTS
Behalve als je als MITM ook de hostname veranderd. Dan hebben de preloaded list & de header geen zin meer. De gebruiker moet zijn connectie dan wel als http connectie initialiseren.
Behalve als je als MITM ook de hostname veranderd

Dat kan niet, aangezien de client de hostname specficeert en het SSL/TLS protocol expliciet beschermt tegen hostname wijzigingen.

Wat wl kan is een phishing site die ipv https://www.ing.nl bjvooebeeld http://www.ingg.nl probeert.
Dat bedoelde ik ook eigenlijk, maar ik vind het alleen niet echt phishing, aangezien je alleen als proxy fungeert (en natuurlijk gegevens aftapt :9).

Met phishing denk ik meer aan specifieke websites die je nabouwt, en daar slachtoffers naar toe laat gaan.
Maar dat is dan ook wat moet gebeuren wil zo'n aanval slagen. Jij moet de gebruiker zlf zo ver krijgen naar http://www.ingg.nl te laten gaan.

De MITM aanvaller kan dat niet doen dankzij HSTS en TLS zelf. Immers indien die een re-direct (via DNS poisoning of zo) uitvoert zal de browser weigeren ingg.nl over HTTP (zonder s) te bezoeken dankzij HSTS. Immers de browser denkt dat hij naar ing.nl gaat.

En zou je een certificaat aanbieden voor ingg.nl beschermt TLS zelf je omdat het certifciaat ongeldig zal zijn vanwege een hostname mismatch met het verwachte domein ing.nl.
Met SSLSTRIP+ kan dit wel gewoon hoor.
Nee dat kan niet.

Leg anders maar eens uit hoe dat zou moeten. :)
HSTS becshermt nu juist expliciet tegen tools zoals SSLStrip.
Zoals op die Github pagina staat kan SSLSTRIP+ deels HSTS omzeilen door de hostname te veranderen. Dit doen ze d.m.v. dns2proxy en een redirect via een header. De gebruiker dient dan wel zijn connectie via http te initialiseren, zoals ik in een van mijn vorige comments al zei.

SSLSTRIP+ fungeert dan als proxy en geeft alles door, zoals ik hiermee al een keer heb aangegeven.
De gebruiker dient dan wel zijn connectie via http te initialiseren, zoals ik in een van mijn vorige comments al zei.

Precies wat ik zei dus: Wat wl kan is een phishing site die ipv https://www.ing.nl bjvooebeeld [siq] http://www.ingg.nl probeert.

Echter indien jij als gebruiker http://www.ing.nl (dus zonder s!) intypt, zal de browser zelf dit veranderen naar https://www.ing.nl dankzij HSTS. Er wordt dus geen initiatie gedaan over HTTP.

Ofwel een HTTP request naar ing.nl zal gewoon nooit gebeuren indien de client reeds een HSTS header ontvangen heeft of op de preload lijst staat.

Blijft over klassieke phishing als enige methode om een client zover te krijgen een HTTP request te doen.
Ik heb het net even getest, en je hebt gelijk. Ik krijg een "307 Internal Redirect" terug.

Maar wat ik me nu wel afvraag is waarom SSLSTRIP+ de hostname veranderd. SSLSTRIP+ zou alleen werken als het niet in de preloaded list staat. Maar als het ook alleen werkt als het de eerste keer is dat de gebruiker naar de site gaat, kunnen ze net zo goed alleen die HSTS header strippen (dus niet de hostname veranderen), dan zou het ook moeten werken.
Ik moet daar even over nadenken, maar kan me voorstellen dat de aanval werkt bij situaties waar een website zelf redirects doet n zelf niet HTST beschermt is.

Ik weet niet of ING dat doet trouwens, maar gebruik ING maar als een hypothetisch voorbeeld: Stel dat www.ing.nl een redirect doet (denk aan een login-knop) naar https://secure.ing.nl, dan kan SSLStrip een redirect naar http://secure.ingg.nl doen.

Als www.ing.nl niet HSTS beschermt is kan SSLStrip werken, of nog erger als www.ing.nl plain-HTTP zou toestaan. Op dat moment doet de client wel degelijk een HTTP-initiatie.

Dus ik moet mijzelf ook corrigeren :) De oorspronkelijke aanval is nog steeds niet mogelijk (HTST werkt), maar behalve phishing is er nog een tweede aanval mogelijk (denk ik), mits de root-website geen HSTS ondersteunt of erger plain-HTTP toestaan.

Om die reden overigens doet gelukkig bijna elke zichzelf respecterende site die financiele gegevens hanteert daarom de home-page ook HTTPS/HSTS maken. Maar er zijn altijd zwarte schapen.
Ik heb het vandaag even na gevraagd aan de maker van de tool. Het werkt blijkbaar als volgt (ook als de gebruiker de HSTS header al een keer ontvangen heeft):

Pre-condition: De gebruiker moet het DNS request niet gecached hebben.

SSLSTRIP+ werkt bijna hetzelfde als SSLSTRIP. Er zijn twee verschillen.

HSTS header
Bij SSLSTRIP+ wordt ook de HSTS header gestript van alle requests, zodat deze niet nogmaals de gebruiker bereikt.

Dns2proxy
Dns2proxy wordt gebruikt om de DNS requests the onderscheppen (network layer). Deze worden aangepast zodat www.google.com naar www.gooogle.com (3 o's) gaat. De hostname wwww.gooogle.com staat niet in de preloaded lijst, en kan daarom gewoon over http.
Dat kan zijn, maar gaat nog steeds niet werken igv HTST.

Immers de DNS request kan wel ondertschept worden en aangepast naar een andere IP (exacte domeinnaam is niet relevant), maar jouw browser wil nog steeds een TLS verbinding maken naar google.com, en de bezitters van gooogle.com zullen geen geldig certificaat hebben voor google.com. Dus een dik rood schild zal in beeld komen.

Dit kan wl werken bij een niet HSTS beschermde verbinding (mits de gebruiker uiteraard het ontbreken van een slotje niet opmerkt). Immers dan vind potentieel een redirect plaats naar een ander domein. Maar HSTS beschermt nu net expliciet tegen deze aanval.

Het strippen van de header is verder enkel relevant voor non-preload gevallen om te voorkomen dat halverwege de aanval de browser alsnog over gaat op HTTPS en HTTP weigert.

Merk tenslotte op dat het enkel werkt indien geen DNSSEC of een andere vorm van DNS protectie aanwezig is. Zo zal Windows Phone altijd de DNS van de provider gebruiken en niet die van het malafide accesspoint.
Ik ga het zometeen nog even testen. Als ik de maker van de tool moet geloven, wordt de gebruiker gewoon netjes naar http://gooooogle.com geredirect zonder een rood kruis (ook als google.com hsts gebruikt). Wel gewoon over http uiteraard.

Er is natuurlijk een kans dat de gebruiker dit opmerkt. Maar ik denk niet dat die kans groot is bij de 'normale' internet gebruiker.
Als het non-preloaded HSTS is en de gebruiker ook nooit naar google.com gegaan is, kan dat inderdaad werken. Er komt dan immers http://www.google.com in beeld want de browser denkt nog steed dat hij de chte Google bezoekt. Dat is een klassieke SSL-strip met ARP-poisoning aanval.

Maar bij HSTS site gaat dit du sniet werken, daar HSTS ontwikkeld is specifieek voor deze aanval. SSLSTRIP+ doet precies de aanval waar HSTS tegen beschermt.

Het feite dat de persoon telkens spreekt over gooogle.com (met extra o's) doet mij vermoeden dat hij een andere soort aanval uitvoert. Immers de domeinnaam is volstrekt irrelevant bij een klassieke MITM met RAP-poisoning aanval, en de server in kwestie hoeft zelfs niet eens een domeinnaam te hebben. Immers de browser denkt toch dat bij de echte google.com bezoekt.

Wat ik vermoed is dat hij gebruikers probeert te vangen die http://www.google.com intypen (dus zonder expliciete s) op een platform dat gn HSTS ondersteund. Dan werkt deze aanval namelijk precies zoals geadverteerd.

Wel ben ik het geheel eens dat een gewone gebruiker dit vaak niet zal opmerken inderdaad.
Dus hoe meer sites, hoe langer de lijst, en dus ook hoe langer bepaalde controles gaan duren... Een lijst bijhouden noem ik nou echt niet een goeie zaak..
Het is overigens wel opmerkelijk hoe kort de lijst tot nu toe is. Terwijl hij inmiddels al 2 jaar en 3 maanden bestaat.

[Reactie gewijzigd door VeQVQUCjsxagUCH op 10 juni 2015 21:30]

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True