Security Professionals
- ipfw add deny all from eindgebruikers to any
Sites moeten .www schrappen!
Inleiding
Naar verluidt [1] gaat Google Chrome, op sites zoals www.security.nl, het voorvoegsel "www." niet meer tonen.
Ik begrijp waarom, want:
1) Op smartphones neemt "www." kostbare schermruimte in (w is ook nog eens de breedste letter bij proportionele fonts);
2) Bijna alle sites doen een redirect naar https://www.example.com/ als je example.com intikt en de Enter toets indrukt, waarmee het geen issue is als je die "www." weglaat bij het openen van een pagina.
M.b.t. punt 2: voor de meeste sites, ook security.nl, is dat echter het onveiligste dat je kunt doen!
Probleem: onjuist geconfigureerde HSTS
Veel https websites, ook security.nl, hebben een incomplete HSTS configuratie. In [2] ben ik daar al eens op in gegaan, maar omdat de beheerders van security.nl dat artikel niet vanzelf hebben aangegrepen om deze site te verbeteren, gaan zij nu op het hakblok ;-)
Als je security.nl intikt in de URL balk van je browser, gevolgd door de enter toets, maakt jouw browser daar http://security.nl/ van, haalt (via DNS) het IP adres op van security.nl en zet een TCP/IP verbinding op met poort 80 van dat IP-adres. Daarna gebeurt het volgende:
Twee configuratiefouten op security.nl
1) Jouw browser maakt zo nooit verbinding met https://security.nl/, en zal daar dus nooit een HTTPS header van ontvangen. Nb. het meesturen van een HSTS header vanaf een http site kan geen kwaad, maar levert ook niks op (browsers evalueren HSTS headers alleen bij https verbindingen).
Het gevolg is dat, elke keer dat je security.nl intikt, een MITM jouw verbinding kan kapen (en dit geldt niet zozeer voor security.nl, maar vooral voor sites waar cybercriminelen meer in geïnteresseerd zijn).
2) De beheerders zijn ook vergeten om https://security.nl/ een HSTS header mee te laten sturen. Het heeft nu dus voor bezoekers geen zin om af en toe https://security.nl/ in te tikken (in plaats van security.nl). En voor de beheerders heeft het geen zin om bezoekende browsers de volgende redirect stappen te laten doorlopen:
De reden dat security.nl intikken het onveiligst is
Van het meest veilig naar het minst veilig:
- Als je altijd https://www.security.nl/ intikt (of daar een snelkoppeling in jouw browser voor aanmaakt en daar op klikt) kan een MITM daar alleen maar tussenkomen met een vals, doch geldig, certificaat. Met een vals ongeldig certificaat komt de aanvaller niet ver, want als jouw browser geldige HSTS informatie van https://www.security.nl/ aan boord heeft, zal dat tot een certificaat-foutmelding (niet weg te klikken) leiden, in plaats van tot een wel weg te klikken) certificaat-waarschuwing.
- Als je altijd www.security.nl intikt en de site regelmatig bezoekt, is de kans groot dat jouw browser nog geldige HSTS informatie van die site aan boord heeft, en jouw browser dus automatisch via https in plaats van http verbindt. Doordat de eerste keer dat je dit doet een MITM kan toeslaan (of nadat je jouw browser hebt opgedragen om alle geschiedenis te vergeten, of na her-installatie van de browser), loop je wat meer risico dan in het vorige scenario;
- Als je altijd https://security.nl/ intikt (waar jouw browser geen HSTS informatie van heeft) en een MITM jouw browser een vals (bijv. self-signed) certificaat voorschotelt, dan krijg je een certificaat-waarschuwing die je weg zou kunnen klikken.
- Als je altijd security.nl intikt, kan een MITM wel heel eenvoudig jouw verbinding kapen, bijvoorbeeld door jou daarna steeds http://security.nl te laten zien (moderne browsers waarschuwen dan wel bij pagina's die om een wachtwoord vragen). Maar de aanvaller kan jouw browser ook redirecten naar sites in zijn beheer, bijvoorbeeld:
Betere oplossing
Maak example.com (in plaats van www.example.com) de main site! Ik bedoel daarmee dat het beter is als alle websites (tenzij al standaard, zoals bij twitter.com en seclists.org) worden aangepast door hun beheerders.
Naast de bovenaan deze bijdrage genoemde twee argumenten, bestaat er allang geen noodzaak meer voor het www. voorvoegsel. Al vele jaren zijn de website en de mailserver de belangrijkste servers die vanaf internet bereikbaar moeten zijn, en door het bestaan van MX records kun je eenvoudig naar één of meer mailservservers met een andere domeinnaam verwijzen. Voor eventuele andere servers kun je dan de uitzonderingen maken (portal., vpn., owa. of webmail., ssh. of shell. etcetera).
Als we dit doen scheelt dat een hoop redirects - met in de praktijk veel voorkomende security risico's door onjuiste configuratie, en "jokken" browsers niet meer als ze het voorvoegsel "www." weglaten!
Uitvoering
Daarvoor moeten twee dingen gebeuren:
1) Niet browsers, maar websites moeten het voorvoegsel www. schrappen. In plaats van www.example.com moet example.com de main site worden. Voor een overgangsperiode kan www.example.com blijven bestaan en redirecten naar de "echte" site, example.com.
2) Zorg dat HSTS goed geconfigureerd is voor de "main site", dus https://example.com/ (of in dit geval: https://security.nl). Indien de beheerders redirect sites als http://www.example.com/ en https://www.example.com/ in stand houden (die uiteindelijk redirecten naar https://example.com/), zorg er dan voor dat de browser ook een HSTS header ontvangt van https://www.example.com/. Dat kan ofwel door via die site te redirecten, of door vanuit de main site iets (bijv. een single pixel GIFje) te downloaden vanaf https://www.example.com/.
Vraag
Zijn de lezers van security.nl het met mij eens, of zie ik hierbij wat over het hoofd?
[1] https://www.security.nl/posting/576436/Google+onder+vuur+over+verbergen+www-subdomein+in+Chrome
[2] https://www.security.nl/posting/566101/NL%3A+veel+brakke+https+sites
Naar verluidt [1] gaat Google Chrome, op sites zoals www.security.nl, het voorvoegsel "www." niet meer tonen.
Ik begrijp waarom, want:
1) Op smartphones neemt "www." kostbare schermruimte in (w is ook nog eens de breedste letter bij proportionele fonts);
2) Bijna alle sites doen een redirect naar https://www.example.com/ als je example.com intikt en de Enter toets indrukt, waarmee het geen issue is als je die "www." weglaat bij het openen van een pagina.
M.b.t. punt 2: voor de meeste sites, ook security.nl, is dat echter het onveiligste dat je kunt doen!
Probleem: onjuist geconfigureerde HSTS
Veel https websites, ook security.nl, hebben een incomplete HSTS configuratie. In [2] ben ik daar al eens op in gegaan, maar omdat de beheerders van security.nl dat artikel niet vanzelf hebben aangegrepen om deze site te verbeteren, gaan zij nu op het hakblok ;-)
Als je security.nl intikt in de URL balk van je browser, gevolgd door de enter toets, maakt jouw browser daar http://security.nl/ van, haalt (via DNS) het IP adres op van security.nl en zet een TCP/IP verbinding op met poort 80 van dat IP-adres. Daarna gebeurt het volgende:
A) http://security.nl/ stuurt een redirect-aanwijzing om naar https://www.security.nl/ te gaan;
B) dat doet jouw browser automatisch;
C) https://www.security.nl/ stuurt een HSTS header mee naar jouw browser.
B) dat doet jouw browser automatisch;
C) https://www.security.nl/ stuurt een HSTS header mee naar jouw browser.
Twee configuratiefouten op security.nl
1) Jouw browser maakt zo nooit verbinding met https://security.nl/, en zal daar dus nooit een HTTPS header van ontvangen. Nb. het meesturen van een HSTS header vanaf een http site kan geen kwaad, maar levert ook niks op (browsers evalueren HSTS headers alleen bij https verbindingen).
Het gevolg is dat, elke keer dat je security.nl intikt, een MITM jouw verbinding kan kapen (en dit geldt niet zozeer voor security.nl, maar vooral voor sites waar cybercriminelen meer in geïnteresseerd zijn).
2) De beheerders zijn ook vergeten om https://security.nl/ een HSTS header mee te laten sturen. Het heeft nu dus voor bezoekers geen zin om af en toe https://security.nl/ in te tikken (in plaats van security.nl). En voor de beheerders heeft het geen zin om bezoekende browsers de volgende redirect stappen te laten doorlopen:
De reden dat security.nl intikken het onveiligst is
Van het meest veilig naar het minst veilig:
- Als je altijd https://www.security.nl/ intikt (of daar een snelkoppeling in jouw browser voor aanmaakt en daar op klikt) kan een MITM daar alleen maar tussenkomen met een vals, doch geldig, certificaat. Met een vals ongeldig certificaat komt de aanvaller niet ver, want als jouw browser geldige HSTS informatie van https://www.security.nl/ aan boord heeft, zal dat tot een certificaat-foutmelding (niet weg te klikken) leiden, in plaats van tot een wel weg te klikken) certificaat-waarschuwing.
- Als je altijd www.security.nl intikt en de site regelmatig bezoekt, is de kans groot dat jouw browser nog geldige HSTS informatie van die site aan boord heeft, en jouw browser dus automatisch via https in plaats van http verbindt. Doordat de eerste keer dat je dit doet een MITM kan toeslaan (of nadat je jouw browser hebt opgedragen om alle geschiedenis te vergeten, of na her-installatie van de browser), loop je wat meer risico dan in het vorige scenario;
- Als je altijd https://security.nl/ intikt (waar jouw browser geen HSTS informatie van heeft) en een MITM jouw browser een vals (bijv. self-signed) certificaat voorschotelt, dan krijg je een certificaat-waarschuwing die je weg zou kunnen klikken.
- Als je altijd security.nl intikt, kan een MITM wel heel eenvoudig jouw verbinding kapen, bijvoorbeeld door jou daarna steeds http://security.nl te laten zien (moderne browsers waarschuwen dan wel bij pagina's die om een wachtwoord vragen). Maar de aanvaller kan jouw browser ook redirecten naar sites in zijn beheer, bijvoorbeeld:
https://securety.nl of https://www.securety.nl (lijkt-op domeinnaam)
https://security.ni of https://www.security.ni (lijkt-op domeinnaam)
https://security.nu of https://www.security.nu (lijkt-op domeinnaam)
https://mijn-security.nl of https://login.opsecurity.nl (valse domeinnaam)
https://security.ni of https://www.security.ni (lijkt-op domeinnaam)
https://security.nu of https://www.security.nu (lijkt-op domeinnaam)
https://mijn-security.nl of https://login.opsecurity.nl (valse domeinnaam)
Betere oplossing
Maak example.com (in plaats van www.example.com) de main site! Ik bedoel daarmee dat het beter is als alle websites (tenzij al standaard, zoals bij twitter.com en seclists.org) worden aangepast door hun beheerders.
Naast de bovenaan deze bijdrage genoemde twee argumenten, bestaat er allang geen noodzaak meer voor het www. voorvoegsel. Al vele jaren zijn de website en de mailserver de belangrijkste servers die vanaf internet bereikbaar moeten zijn, en door het bestaan van MX records kun je eenvoudig naar één of meer mailservservers met een andere domeinnaam verwijzen. Voor eventuele andere servers kun je dan de uitzonderingen maken (portal., vpn., owa. of webmail., ssh. of shell. etcetera).
Als we dit doen scheelt dat een hoop redirects - met in de praktijk veel voorkomende security risico's door onjuiste configuratie, en "jokken" browsers niet meer als ze het voorvoegsel "www." weglaten!
Uitvoering
Daarvoor moeten twee dingen gebeuren:
1) Niet browsers, maar websites moeten het voorvoegsel www. schrappen. In plaats van www.example.com moet example.com de main site worden. Voor een overgangsperiode kan www.example.com blijven bestaan en redirecten naar de "echte" site, example.com.
2) Zorg dat HSTS goed geconfigureerd is voor de "main site", dus https://example.com/ (of in dit geval: https://security.nl). Indien de beheerders redirect sites als http://www.example.com/ en https://www.example.com/ in stand houden (die uiteindelijk redirecten naar https://example.com/), zorg er dan voor dat de browser ook een HSTS header ontvangt van https://www.example.com/. Dat kan ofwel door via die site te redirecten, of door vanuit de main site iets (bijv. een single pixel GIFje) te downloaden vanaf https://www.example.com/.
Vraag
Zijn de lezers van security.nl het met mij eens, of zie ik hierbij wat over het hoofd?
[1] https://www.security.nl/posting/576436/Google+onder+vuur+over+verbergen+www-subdomein+in+Chrome
[2] https://www.security.nl/posting/566101/NL%3A+veel+brakke+https+sites
Reacties (39)
Door Bitwiper: Inleiding
Probleem: onjuist geconfigureerde HSTS
Veel https websites, ook security.nl, hebben een incomplete HSTS configuratie. In [2] ben ik daar al eens op in gegaan, maar omdat de beheerders van security.nl dat artikel niet vanzelf hebben aangegrepen om deze site te verbeteren, gaan zij nu op het hakblok ;-)
Probleem: onjuist geconfigureerde HSTS
Veel https websites, ook security.nl, hebben een incomplete HSTS configuratie. In [2] ben ik daar al eens op in gegaan, maar omdat de beheerders van security.nl dat artikel niet vanzelf hebben aangegrepen om deze site te verbeteren, gaan zij nu op het hakblok ;-)
Ah, u is dus een onbegrepen genie dat thans zijn gram haalt.
11-09-2018, 04:32 door
Bitwiper
Oeps - de titel had natuurlijk moeten luiden "sites moeten www. schrappen!" - mijn excuses!
Google krijgt redelijk wat backlash voor het verwjideren van dat www, en terecht
https://www.security.nl/posting/576436/Google+onder+vuur+over+verbergen+www-subdomein+in+Chrome
HSTS op deze site lijkt inmiddels gefixt.
https://www.security.nl/posting/576436/Google+onder+vuur+over+verbergen+www-subdomein+in+Chrome
HSTS op deze site lijkt inmiddels gefixt.
11-09-2018, 11:08 door
Bitwiper
Door Anoniem: Ah, u is dus een onbegrepen genie dat thans zijn gram haalt.
Ik ben helemaal geen genie, maar door zelf tegen dingen aan te lopen, en door zoveel mogelijk WireShark te draaien op mijn PC's (en o.a. te filteren op http || dns), in m'n browsers op F12 te drukken en die browsers af en toe te resetten, zie ik dit soort dingen. Dat soort onderzoekjes doen kan iedereen die een beetje snapt hoe browsers en WireShark werken - en daar hoef je echt geen genie voor te zijn.Daarbij vind ik het hartstikke zonde als beheerders moeite doen om HSTS te implementeren, maar door onbegrip belangrijke aspecten missen waardoor de site lang niet zo veilig is als (met kleine moeite) had gekund - en zoals vermoedelijk hun bedoeling was. Er valt beheerders overigens ook niet zo heel veel te verwijten als bijna iedereen dit fout doet (vandaar mijn knipoog). Daarnaast gaat het hierbij om een kwetsbaarheid die alleen van toepassing is als een MITM probeert toe te slaan (er is dus m.i. geen "Responsible Disclosure" nodig) - maar dat was nou juist de reden om HSTS te implementeren.
Ten slotte heb ik juist security.nl als voorbeeld gebruikt omdat ik niet verwacht dat veel cybercriminelen credentials van gebruikers op deze site erg waardevol zullen vinden, en dus het risico als zeer laag inschat. Als je dat een probleem vindt, had je dat al onder https://www.security.nl/posting/566101/NL%3A+veel+brakke+https+sites kunnen melden. Om onnodig leed te voorkomen, lijkt het mij echter belangrijker dat zoveel mogelijk beheerders beseffen dat je HSTS goed fout kunt implementeren. Veel literatuur hierover, noch test-sites voor deze issue, heb ik nog niet gevonden - maar dat zou zomaar aan deze niet-genie kunnen liggen.
Heb je aanvullende info, of heb ik het fout (goed mogelijk), deel deze dan i.p.v. negatieve feedback te geven! En kun je wellicht aangeven waarom je niet zou willen dat ik (via deze site) het internet veiliger probeer te maken en/of wat je niet goed vind aan mijn wijze van publiceren? Of ben je gewoon de zoveelste azijnpisser op deze site die graag boodschappers afschiet?
Door Anoniem: Google krijgt redelijk wat backlash voor het verwjideren van dat www, en terecht
https://www.security.nl/posting/576436/Google+onder+vuur+over+verbergen+www-subdomein+in+Chrome
HSTS op deze site lijkt inmiddels gefixt.
https://www.security.nl/posting/576436/Google+onder+vuur+over+verbergen+www-subdomein+in+Chrome
HSTS op deze site lijkt inmiddels gefixt.
Het is niet goed dat Google het doet maar ik hoop dat alle domein houders/website beheerders www en mobile/m weg gooien en er gewoon een responsive website van maken met simpel domein.
Chrome heeft het al teruggedraaid. Even handmatig updaten en je browser opnieuw opstarten...
Er zijn dus twee manieren om het inherente website veiligheidsprobleem op te lossen.
1. Allen, die verantwoordelijk zijn voor de veiligheid van een bepaalde website opvoeden tot beter en veiliger configureren.
Ik denk dat dat absoluut voorlopig niet gaat lukken.
Waarom? Hier alleen al kom je 96 security issues tegen:
https://webhint.io/scanner/a4526d89-6696-4217-a446-5cd6df5f842b
Errors in no-protocol-relative-urls, sri, strict-transport-security, x-content-type-options, no-vulnerable-javascript-libraries.
Dan zijn er nog allerlei fouten mogelijk op websites met certificaten, DNS, server- en naam-server info proliferatie, verkeerd instellen van CMS - gebruikers enumeratie op aan en directory listing op aan, cloaking (site toont verschillende code voor googlebot en google), mal-iFrames etc. etc.
2. We gaan het aan Google overlaten, via hun initiatieven, Google Safe Browsing, Google Web Developers, https everywhere, VirusTotal en wellicht geen adresbar meer maar een zoekbalk, waarna de onveilige site als veilig herschreven zoekresultaat site geladen wordt in de browser (alle browser moeten daarom Google conform worden gemaakt). Zitten we nog wel met het mono-cultuur probleem, net als dat van asp sites in mainland China, maar een kniesoor die daar op let.
De Jip en Janneke klikkers zijn zodoende veilig bezig en tante Mien krijgt zo steeds een veiliger webpagina te zien.
Willen we dit of kunnen we het niet meer voorkomen, dat dit er komt op den duur?
luntrus
1. Allen, die verantwoordelijk zijn voor de veiligheid van een bepaalde website opvoeden tot beter en veiliger configureren.
Ik denk dat dat absoluut voorlopig niet gaat lukken.
Waarom? Hier alleen al kom je 96 security issues tegen:
https://webhint.io/scanner/a4526d89-6696-4217-a446-5cd6df5f842b
Errors in no-protocol-relative-urls, sri, strict-transport-security, x-content-type-options, no-vulnerable-javascript-libraries.
Dan zijn er nog allerlei fouten mogelijk op websites met certificaten, DNS, server- en naam-server info proliferatie, verkeerd instellen van CMS - gebruikers enumeratie op aan en directory listing op aan, cloaking (site toont verschillende code voor googlebot en google), mal-iFrames etc. etc.
2. We gaan het aan Google overlaten, via hun initiatieven, Google Safe Browsing, Google Web Developers, https everywhere, VirusTotal en wellicht geen adresbar meer maar een zoekbalk, waarna de onveilige site als veilig herschreven zoekresultaat site geladen wordt in de browser (alle browser moeten daarom Google conform worden gemaakt). Zitten we nog wel met het mono-cultuur probleem, net als dat van asp sites in mainland China, maar een kniesoor die daar op let.
De Jip en Janneke klikkers zijn zodoende veilig bezig en tante Mien krijgt zo steeds een veiliger webpagina te zien.
Willen we dit of kunnen we het niet meer voorkomen, dat dit er komt op den duur?
luntrus
Ik ken zat mensen die "www." voor alles typen. Het zit gewoon al 20 jaar in hun systeem en ik krijg het er niet uit geramt.
Ik wens je veel succes!
Ik wens je veel succes!
Kunnen die suffe browsers niet gewoon éérst kijken of er onder het hoofddomein een https connectie mogelijk is? En sowieso met elke redirect ergens een piefje zetten wat de gebruiker ziet?
Dan is dat hele HSTS inbakken in databases in browsers ook niet nodig. Want ik wil helemaal niet afhankelijk zijn van dat meneer Koekel mijn domein meebakt in zijn browser of niet! Meneer Koekel is al op alle fronten aan het manipuleren of, en in hoeverre, ik mag "meespelen" op het internep. Ze houden je het liefst achter op alle fronten. Yandex, bijvoorbeeld, laat je snel zien wat je ranking is, als je wat verandert. Koekel niet. Dat is weken wachten. De Search Console loopt steevast twee dagen achter, en soms nog langer. Het heeft alle trekjes die conservatieve partijen hebben in de politiek.
En dat ik dan nu maar moet afwachten wanneer hun nieuwe versie uitkomt om een groen vinkje te krijgen, dat bevalt me helemaal niet. Je kunt toch meteen "zien" dat ik netjes https op mijn hoofddomein heb? Of ben ik nou gek?
Dan is dat hele HSTS inbakken in databases in browsers ook niet nodig. Want ik wil helemaal niet afhankelijk zijn van dat meneer Koekel mijn domein meebakt in zijn browser of niet! Meneer Koekel is al op alle fronten aan het manipuleren of, en in hoeverre, ik mag "meespelen" op het internep. Ze houden je het liefst achter op alle fronten. Yandex, bijvoorbeeld, laat je snel zien wat je ranking is, als je wat verandert. Koekel niet. Dat is weken wachten. De Search Console loopt steevast twee dagen achter, en soms nog langer. Het heeft alle trekjes die conservatieve partijen hebben in de politiek.
En dat ik dan nu maar moet afwachten wanneer hun nieuwe versie uitkomt om een groen vinkje te krijgen, dat bevalt me helemaal niet. Je kunt toch meteen "zien" dat ik netjes https op mijn hoofddomein heb? Of ben ik nou gek?
11-09-2018, 18:01 door
karma4
Door Anoniem: @Bitwiper
Volgens mij heb je het bij het rechte eind.
Voor deze keer geloof ik dat ook.Volgens mij heb je het bij het rechte eind.
Laat ik met een gemeenplaats beginnen. Het wereldwijde web en het internet zijn wel gerelateerd, maar niet hetzelfde. Het DNS is zelfs geeneens onderdeel van het www, al maakt het www er wel grif gebruik van. Iedere professional hoort dit te weten, maar er zullen er vast wel meelezen die het niet wisten. Bij deze, nu weet je het wel.
Eigenlijk maakt het me niet zoveel uit of je een A RR op je domein plakt en daar een webserver op zet. Je zal waarschijnlijk nog steeds een www A RR willen neerzetten mischien zelfs met een http redirect-serverende httpd erachter. Of het veel gaat helpen, nou, browsers zitten vol met halfgare aannames als "oh laten we er speculatief maar www. voor en .com achteraan plakken", als een invoer niet gelijk naar een A RR leidt. Wat dat betreft is chrome met hun "www." verbergen gewoon... nouja, hoe zal ik dat nou eens netjes zeggen? Niet heel constructief bezig.
Maargoed, uit dezelfde bron kennen we "AMP", dat ook al zo briljant is.
En vele, vele websites worden neergeplempt door nietweters die maar gewoon iets doen wat alle anderen ook lijken te doen. Dus daar zitten evenzovele domme aannames tussen. Dus om hier nu algemene best practices te willen declareren voor websites terwijl browsers zojuist alleen maar dommere dingen zijn gaan doen? Ik denk niet dat het veel zoden aan de dijk zet. Daar is zelfs al het idee van een "webnaam" met een "extensie" (is het niet) debet aan.
Dus dan neem je een stapje terug en dan stellen we maar een andere vraag. Ja, www is de meest populaire toepassing van dit moment. Moeten we er dan maar blind vanuitgaan dat alles toch wel www (en dus http, of dan nu https "want dat is veiliger", denken we) zal zijn? Heeft het zin aan te nemen dat al het verkeer tot het einde der internettijd alleen nog maar via poort 443 zal lopen? Wil je daar op gokken en je bruggen verbranden? Lijkt me een beetje overdreven.
Het is ook gewoon niet zo dat dit een fundamenteel technisch probleem is, of dat het op deze manier op te lossen is. Het is arbitrair, en een reactie op google die landjepik speelt met hun browser (ook arbitrair). Het diepere probleem is een mensenprobleem, namelijk dat er veel te veel mensen meedoen die niet alleen niet opletten, maar ook niet de gereedschappen hebben om behoorlijk op te letten op veiligheidsaspecten als "zit er niet een man in mijn browser mee te lezen?"
Het enige zinnige dat je daar over kan zeggen is dat het probleem deels verergerd wordt door slechte tooling (vraag maar eens de inhoud van een certificaat op, in een willekeurige browser), en dat voorgestelde vele "verbeteringen" ook alleen maar verergeringen bleken te zijn, onderwijl wel extra papierwerk (certificaat registreren, dubbelplusextra verificatie bla bla erbijdoen, protocolletje voor dit erbij, headertje voor dat erbij) en dat zelfs de kennelijk-toch-niet-zo-professionals van bijvoorbeeld security.nl er moeite mee hebben het allemaal correct te doen.
Dus nou zeg je, kom, laten we in plaats van example.com -> www.example.com de redirect omdraaien. Hoe gaat dat fundamenteel iets verbeteren?
Eigenlijk maakt het me niet zoveel uit of je een A RR op je domein plakt en daar een webserver op zet. Je zal waarschijnlijk nog steeds een www A RR willen neerzetten mischien zelfs met een http redirect-serverende httpd erachter. Of het veel gaat helpen, nou, browsers zitten vol met halfgare aannames als "oh laten we er speculatief maar www. voor en .com achteraan plakken", als een invoer niet gelijk naar een A RR leidt. Wat dat betreft is chrome met hun "www." verbergen gewoon... nouja, hoe zal ik dat nou eens netjes zeggen? Niet heel constructief bezig.
Maargoed, uit dezelfde bron kennen we "AMP", dat ook al zo briljant is.
En vele, vele websites worden neergeplempt door nietweters die maar gewoon iets doen wat alle anderen ook lijken te doen. Dus daar zitten evenzovele domme aannames tussen. Dus om hier nu algemene best practices te willen declareren voor websites terwijl browsers zojuist alleen maar dommere dingen zijn gaan doen? Ik denk niet dat het veel zoden aan de dijk zet. Daar is zelfs al het idee van een "webnaam" met een "extensie" (is het niet) debet aan.
Dus dan neem je een stapje terug en dan stellen we maar een andere vraag. Ja, www is de meest populaire toepassing van dit moment. Moeten we er dan maar blind vanuitgaan dat alles toch wel www (en dus http, of dan nu https "want dat is veiliger", denken we) zal zijn? Heeft het zin aan te nemen dat al het verkeer tot het einde der internettijd alleen nog maar via poort 443 zal lopen? Wil je daar op gokken en je bruggen verbranden? Lijkt me een beetje overdreven.
Het is ook gewoon niet zo dat dit een fundamenteel technisch probleem is, of dat het op deze manier op te lossen is. Het is arbitrair, en een reactie op google die landjepik speelt met hun browser (ook arbitrair). Het diepere probleem is een mensenprobleem, namelijk dat er veel te veel mensen meedoen die niet alleen niet opletten, maar ook niet de gereedschappen hebben om behoorlijk op te letten op veiligheidsaspecten als "zit er niet een man in mijn browser mee te lezen?"
Het enige zinnige dat je daar over kan zeggen is dat het probleem deels verergerd wordt door slechte tooling (vraag maar eens de inhoud van een certificaat op, in een willekeurige browser), en dat voorgestelde vele "verbeteringen" ook alleen maar verergeringen bleken te zijn, onderwijl wel extra papierwerk (certificaat registreren, dubbelplusextra verificatie bla bla erbijdoen, protocolletje voor dit erbij, headertje voor dat erbij) en dat zelfs de kennelijk-toch-niet-zo-professionals van bijvoorbeeld security.nl er moeite mee hebben het allemaal correct te doen.
Dus nou zeg je, kom, laten we in plaats van example.com -> www.example.com de redirect omdraaien. Hoe gaat dat fundamenteel iets verbeteren?
betekent dit dat het idee van subdomeinen in zijn geheel overbodig wordt?
Er zijn websites die volledig draaien op subdomeinen zoals wordpress.
Gaat dit verdwijnen door Google Chrome?
Er zijn websites die volledig draaien op subdomeinen zoals wordpress.
Gaat dit verdwijnen door Google Chrome?
@ WesleyJ,
Je ziet Google Chrome wordt wel steeds bepalender.
Met 96% proliferatie in Nederland alleen, staat Google hier al ongeveer gelijk aan Interwebz.
Aan de ene kant kun je er bijna niet meer omheen
en aan de andere kant levert het ook wel veel toegevoegde veiligheid op.
Wat het betekent voor privacy en surveillance achter je google account en voor wat je zoekqueries betreft,
is wel weer een groot vraagteken. We gaan het allemaal wel beleven.
luntrus
Je ziet Google Chrome wordt wel steeds bepalender.
Met 96% proliferatie in Nederland alleen, staat Google hier al ongeveer gelijk aan Interwebz.
Aan de ene kant kun je er bijna niet meer omheen
en aan de andere kant levert het ook wel veel toegevoegde veiligheid op.
Wat het betekent voor privacy en surveillance achter je google account en voor wat je zoekqueries betreft,
is wel weer een groot vraagteken. We gaan het allemaal wel beleven.
luntrus
Door Anoniem: Ik ken zat mensen die "www." voor alles typen. Het zit gewoon al 20 jaar in hun systeem en ik krijg het er niet uit geramt.!
Doordat HSTS zelden goed geïmplementeerd is op het root-domein, is dat veiliger. En je kunt https://wws.example.tld/ niet zomaar opdoeken na de site op https://example.tld/ te hebben gezet, want er zijn bijna altijd wel naar jouw site verwijzende links (o.a. Google zoekresultaten en zelfs visitekaartjes) die (nog) met www. beginnen.Zodra je een website naar het root-domein verplaatst en:
- daar HSTS goed op configureert,
- de oude https://www.example.tld/ een redirect laat doen naar https://example.tld/,
- HSTS op www.example.tld intact laat (of toevoegt indien je er niet eerder aan toekwam),
wat is dan het probleem?
Door WesleyJ: betekent dit dat het idee van subdomeinen in zijn geheel overbodig wordt?
Nee, zeker niet! Het gaat uitsluitend om "www." dat veel mensen nooit intypen, tenzij een link dan niet werkt (er zullen ongetwijfeld websites bestaan die uitsluitend via www.*.tld te bereiken zijn, en niet via *.tld). Sterker, je zou heel veel kapot maken, bijv. mijn.overheid.nl is een andere site dan overheid.nl / www.overheid.nl.Door Anoniem: Kunnen die suffe browsers niet gewoon éérst kijken of er onder het hoofddomein een https connectie mogelijk is?
Dat heb ik zelf ook ooit eens geopperd - maar dat is geen goede oplossing om twee redenen:1) Bij goedkope http shared hosting websites (soms honderden op 1 IP-adres) krijg je vaak een certificaatwaarschuwing (of -foutmelding) omdat op poort 443 van dat IP-adres het beheerpanel (met afwijkende domeinnaam) antwoordt. De vraag is wat een browser in zo'n situatie zou moeten doen;
2) Belangrijker: bij een site die wel https ondersteunt, kan een MITM dan een "downgrade attack" uitvoeren door simpelweg netwerkpakketjes bestemd voor poort 443 (https) van jouw browser naar de bedoelde site geheel niet te beantwoorden (of juist met een TCP reset - op deze server luistert niks op poort 443), en zo jouw browser dwingen om het via http te proberen. Waarna de MITM met SSLstrip kan toeslaan of jouw browser naar een site met een "lijkt op" domeinnaam kan doorsturen in de hoop dat je het verschil niet opmerkt (desgewenst via https zodat je een slotje ziet).
Als je in browsers https:// de standaard maakt als de gebruiker niks invoert
Dat lijkt mij inderdaad verstandig, maar gebruikers die niet goed weten dat een site wel degelijk https ondersteunt, maar die door een MITM voor de gek worden gehouden en geleerd hebben dat als iets niet werkt je er http:// voor moet zetten, zijn dan weer een eenvoudig slachtoffer.Een oplossing zou kunnen zijn dat jouw browser voor jou bijvoorbeeld onthoudt:
- dat je die site eerder via https hebt kunnen bereiken
- welk type certificaat werd gebruikt: DV, OV of EV
- wie de uitgever is van het certificaat
- de verloopdatum van het certificaat
en jou -zo duidelijk mogelijk- waarschuwt bij elke verlaging van het betrouwbaarheidsniveau, wijziging van uitgever of voortijdige vervanging van het certificaat. En voor mijn moeder, maar ook in organisaties, zou ik dan graag kunnen instellen dat bepaalde veranderingen (in elk geval https -> http) worden geblokkeerd. En alleen door ingrijpen van een geautoriseerd iemand met verstand van zaken (die bij een bank nooit http zal toestaan) omgedaan kunnen worden gemaakt.
Waterdicht is dit natuurlijk niet, maar het lijkt mij wel een vooruitgang. En sowieso zou dit kunnen, ook als http (nog) het default protocol blijft.
En -bedenk ik mij net- zolang browsers dit niet doen, zou je dit met een proxy server (of op jouw eigen PC draaiende proxy software) kunnen oplossen. Niet zo elegant (lees: veilig) omdat eventuele waarschuwingen dan niet uit de browser zelf komen, maar uit iets waar een netwerkverbinding tussen zit. En dan is het al gauw mogelijk om gebruikers op het verkeerde been te zetten. Maar desalniettemin zou dit best een interessante toevoeging voor bijv. een Pi-hole kunnen zijn.
Is het niet zo dat vanaf het root-domein cookies aan subdomeinen worden meegegeven?
Dus een cookie van example.com komt ook bij static.example.com.
" If you use the naked domain, the cookies get sent to all subdomains (by recent browsers that implement RFC 6265), slowing down access to static content, and possibly causing caching to not work properly. The only way to get around this problem and keep the naked domain is to buy a second domain name just for your static content."
bron: https://www.yes-www.org/why-use-www/
Dus een cookie van example.com komt ook bij static.example.com.
" If you use the naked domain, the cookies get sent to all subdomains (by recent browsers that implement RFC 6265), slowing down access to static content, and possibly causing caching to not work properly. The only way to get around this problem and keep the naked domain is to buy a second domain name just for your static content."
bron: https://www.yes-www.org/why-use-www/
12-09-2018, 10:26 door
sjonniev
+1
Gelukkig weten we inmiddels waarom deze oplossing het meest stomme is wat je kan doen.
Lees elders op deze site en je weet waarom we www. gewoon moeten houden.
www. met of zonder zou gewoon naar de zelfde site moeten verwijzen, zoals het hoort.
Lees elders op deze site en je weet waarom we www. gewoon moeten houden.
www. met of zonder zou gewoon naar de zelfde site moeten verwijzen, zoals het hoort.
Door Bitwiper: Ik begrijp waarom, want:
1) Op smartphones neemt "www." kostbare schermruimte in (w is ook nog eens de breedste letter bij proportionele fonts);
Ik denk niet dat het daarom gaat, dan zou het bij de desktop-versie van Chrome namelijk onzinnig zijn. Ik denk dat dit gaat om de moeite die veel mensen met het lezen van URLs hebben en dat dit een poging is om de verwarring te verminderen door een element weg te nemen.1) Op smartphones neemt "www." kostbare schermruimte in (w is ook nog eens de breedste letter bij proportionele fonts);
Ik heb daar mijn twijfels over. Het is een "oplossing" die maakt dat de weergave soms zus werkt en soms zo, en dat kan op zich weer heel makkelijk een bron van verwarring worden. Eenvoud bereik je niet door magie (of iets wat daarop lijkt) toe te voegen, eenvoud bereik je door dingen recht voor zijn raap te laten zien zoals ze zijn en hetgeen je laat zien zelf zo eenvoudig mogelijk te maken. In die zin ben ik het met je eens dat het beter zou zijn als websites hun URLs zouden vereenvoudigen. Maar zie dat allemaal maar eens op een lijn te krijgen.
Het probleem is dat mensen op onbekende dingen die ze er moeilijk uit vinden zien vaak reageren door dicht te slaan: ik ken dit niet, het ziet er eng uit, dus snap ik dit niet. En als je besloten hebt dat je iets niet snapt dan snap je het ook echt niet.
Alleen kunnen mensen van alles aan als ze ermee opgegroeid zijn.
Kijk naar een datum en tijd: in "12-9-2018 12:54:26" geeft de positie eerst steeds grotere eenheden aan (dag, maand, jaar) en daarna opeens steeds kleinere eenheden (uur, minuut, seconde). Ik denk dat er weinig mensen zijn die dat niet kunnen lezen. Dat patroon zie je ook in URLs ("www", "security'" "nl" staat voor steeds grotere eenheden; "posting", "57552" voor steeds kleinere). In hun huishouden kunnen mensen prima met hiërarchische structuren omgaan (keukenspullen worden in de keuken bewaard, slaapkamerspullen in de slaapkamer, binnen die ruimtes zijn kasten met verschillende doelen, binnen de kasten vakjes en laden met specifieke subdoelen, mogelijk zitten daar weer bakjes en doosjes in met nog kleinere doelen). Het wordt niet zuiver toegepast maar de hiërarchie is zeker ook niet afwezig. Maar directories en subdirectories op een computer zijn onbegrijpelijke abacadabra.
Toen ik opgroeide leerde ik niet alleen over allerlei onderwerpen, ik leerde ook dat ik me over die reactie om dicht te slaan heen moest zetten en dat dingen die moeilijk leken vaak enorm mee bleken te vallen als ik even de tijd en rust nam om het door te laten dringen. Toen mensen in de jaren '80 met computers en software moesten leren omgaan (IBM-pc, Wordstar) was het ook vanzelfsprekend dat het moeite kostte om het te leren en dat dat nodig was om dingen goed te doen. Een beetje doorzettingsvermogen maakt dat je met dezelfde intelligentie veel meer aankan dan zonder dat doorzettingsvermogen lukt. En dat doorzettingsvermogen is voor een deel aan te leren. En af te leren, helaas.
Ik heb het idee dat de "gemak verkoopt"-invulling van commercie ertoe heeft geleid dat veel mensen met hun hakken in de grond gaan staan als niet alles op een presenteerblaadje wordt aangegeven, ze zijn het als recht gaan beschouwen om geen inspanning te hoeven leveren ergens voor, zeker niet als het hi-tech is. Het is goed om dingen zo makkelijk mogelijk te maken, maar niet om het makkelijker te maken dan het nou eenmaal is, dan bereik je echt het punt dat het nodig wordt dat mensen zich gaan inspannen. Het gebrek aan bereidheid daartoe is een cultureel probleem dat denk ik door de focus op marktwerking (want gemak verkoopt) is aangewakkerd.
Dat zou hier wel eens het echte probleem kunnen zijn.
Ah, u is dus een onbegrepen genie dat thans zijn gram haalt.
Nee, hij geeft gewoon een vrij praktisch voorbeeld, voor een discussie op het Security.NL forum. Jammer dat iemand die een goed uitgewerkte forum post plaatst, direkt weer afgezeken moet worden.
Door Anoniem: Ik ken zat mensen die "www." voor alles typen. Het zit gewoon al 20 jaar in hun systeem en ik krijg het er niet uit geramt.
Ik wens je veel succes!
Ik wens je veel succes!
Je vergeet denk ik mij te quoten, CNAME aanmaken + HTTP rewrite rule en dan is het opgelost?
Ben het gedeeltelijk eens: echter zit er verschil tussen site beheerders, site bouwers, server beheerders, DNS beheer. etc etc en die moeten allemaal met elkaar samen werken voor 1 website.
Mijn stelling is: dat DANE geimplementeerd moet zijn voor elke site/server die ssl/tls doet.
Als in het betreffende certificaat dan de juiste SAN's verwerkt zijn, maakt het geen drol uit of de browser www. weg haalt of niet.
Maar een browser moet dat niet doen want: je hebt ook: wiki.example.com of web.example.com of dezesiteislekkerveilig.example.com en ga zo maar door.
Het stuk voor example.com is niet altijd www en refereert naar een A record of CNAME record in de dns van example.com.
DANE is mijn antwoord: het certicifaat is te controleren mbv dns
Mijn stelling is: dat DANE geimplementeerd moet zijn voor elke site/server die ssl/tls doet.
Als in het betreffende certificaat dan de juiste SAN's verwerkt zijn, maakt het geen drol uit of de browser www. weg haalt of niet.
Maar een browser moet dat niet doen want: je hebt ook: wiki.example.com of web.example.com of dezesiteislekkerveilig.example.com en ga zo maar door.
Het stuk voor example.com is niet altijd www en refereert naar een A record of CNAME record in de dns van example.com.
DANE is mijn antwoord: het certicifaat is te controleren mbv dns
Zomaar www. weghalen voor je domeinnaam kan een security-risk opleveren voor je site.
Denk maar eens aan een cookie dat nu wordt gezet op *.www.blaat.com, die is niet geldig voor random.blaat.com.
Zet je hem op *.blaat.com, dan is hij wel geldig voor random.blaat.com.
Dus net zoals altijd: goede risico analyse maken en dan pas doen.
Tweakers.net heeft overigens heel bewust een paar jaar geleden die stap gemaakt.
Denk maar eens aan een cookie dat nu wordt gezet op *.www.blaat.com, die is niet geldig voor random.blaat.com.
Zet je hem op *.blaat.com, dan is hij wel geldig voor random.blaat.com.
Dus net zoals altijd: goede risico analyse maken en dan pas doen.
Tweakers.net heeft overigens heel bewust een paar jaar geleden die stap gemaakt.
Scheelt weer zoeken 11-09-2018, 20:50 door Anoniem --> https://www.webopedia.com/DidYouKnow/Internet/Web_vs_Internet.asp
13-09-2018, 10:51 door
Bitwiper
Door Anoniem: ww3. ww2, ftp ?
11-09-2018, 00:29 door Bitwiper, Laatst bijgewerkt: 11-09-2018, 01:04: Voor eventuele andere servers kun je dan de uitzonderingen maken (portal., vpn., owa. of webmail., ssh. of shell. etcetera).
13-09-2018, 11:08 door
Bitwiper
Door Anoniem: Is het niet zo dat vanaf het root-domein cookies aan subdomeinen worden meegegeven?
Dus een cookie van example.com komt ook bij static.example.com.
" If you use the naked domain, the cookies get sent to all subdomains (by recent browsers that implement RFC 6265), slowing down access to static content, and possibly causing caching to not work properly. The only way to get around this problem and keep the naked domain is to buy a second domain name just for your static content."
bron: https://www.yes-www.org/why-use-www/
enDus een cookie van example.com komt ook bij static.example.com.
" If you use the naked domain, the cookies get sent to all subdomains (by recent browsers that implement RFC 6265), slowing down access to static content, and possibly causing caching to not work properly. The only way to get around this problem and keep the naked domain is to buy a second domain name just for your static content."
bron: https://www.yes-www.org/why-use-www/
Door Anoniem: Zomaar www. weghalen voor je domeinnaam kan een security-risk opleveren voor je site.
Denk maar eens aan een cookie dat nu wordt gezet op *.www.blaat.com, die is niet geldig voor random.blaat.com.
Zet je hem op *.blaat.com, dan is hij wel geldig voor random.blaat.com.
Dus net zoals altijd: goede risico analyse maken en dan pas doen.
Tweakers.net heeft overigens heel bewust een paar jaar geleden die stap gemaakt.
Dank voor de zinvolle reacties!Denk maar eens aan een cookie dat nu wordt gezet op *.www.blaat.com, die is niet geldig voor random.blaat.com.
Zet je hem op *.blaat.com, dan is hij wel geldig voor random.blaat.com.
Dus net zoals altijd: goede risico analyse maken en dan pas doen.
Tweakers.net heeft overigens heel bewust een paar jaar geleden die stap gemaakt.
Ik ben absoluut geen expert op dit gebied.
In https://www.owasp.org/index.php/Session_Management_Cheat_Sheet zie ik:
[...]
Domain and Path Attributes
The “Domain” cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server.
The “Path” cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie.
It is recommended to use a narrow or restricted scope for these two attributes. In this way, the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID.
Setting the “Domain” attribute to a too permissive value, such as “example.com” allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com.
Additionally, it is recommended not to mix web applications of different security levels on the same domain. Vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permissive “Domain” attribute (such as “example.com”) which is a technique that can be used in session fixation attacks [4].
Although the “Path” attribute allows the isolation of session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host. Other methods can be used by these applications to access the session IDs, such as the “document.cookie” object. Also, any web application can set cookies for any path on that host.
Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain.
[...]
[4] "SAP: Session (Fixation) Attacks and Protections (in Web Applications)". Raul Siles. BlackHat EU 2011.
https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-Slides.pdf
https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-WP.pdf
[...]
Domain and Path Attributes
The “Domain” cookie attribute instructs web browsers to only send the cookie to the specified domain and all subdomains. If the attribute is not set, by default the cookie will only be sent to the origin server.
The “Path” cookie attribute instructs web browsers to only send the cookie to the specified directory or subdirectories (or paths or resources) within the web application. If the attribute is not set, by default the cookie will only be sent for the directory (or path) of the resource requested and setting the cookie.
It is recommended to use a narrow or restricted scope for these two attributes. In this way, the “Domain” attribute should not be set (restricting the cookie just to the origin server) and the “Path” attribute should be set as restrictive as possible to the web application path that makes use of the session ID.
Setting the “Domain” attribute to a too permissive value, such as “example.com” allows an attacker to launch attacks on the session IDs between different hosts and web applications belonging to the same domain, known as cross-subdomain cookies. For example, vulnerabilities in www.example.com might allow an attacker to get access to the session IDs from secure.example.com.
Additionally, it is recommended not to mix web applications of different security levels on the same domain. Vulnerabilities in one of the web applications would allow an attacker to set the session ID for a different web application on the same domain by using a permissive “Domain” attribute (such as “example.com”) which is a technique that can be used in session fixation attacks [4].
Although the “Path” attribute allows the isolation of session IDs between different web applications using different paths on the same host, it is highly recommended not to run different web applications (especially from different security levels or scopes) on the same host. Other methods can be used by these applications to access the session IDs, such as the “document.cookie” object. Also, any web application can set cookies for any path on that host.
Cookies are vulnerable to DNS spoofing/hijacking/poisoning attacks, where an attacker can manipulate the DNS resolution to force the web browser to disclose the session ID for a given host or domain.
[...]
[4] "SAP: Session (Fixation) Attacks and Protections (in Web Applications)". Raul Siles. BlackHat EU 2011.
https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-Slides.pdf
https://media.blackhat.com/bh-eu-11/Raul_Siles/BlackHat_EU_2011_Siles_SAP_Session-WP.pdf
[...]
ECHTER: in https://www.owasp.org/images/a/a0/OWASPLondon20171130_Cookie_Security_Myths_Misconceptions_David_Johansson.pdf lees ik:
[...]The ‘Domain’ Attribute
• With domain set, cookies will be sent to that domain and all its subdomains
• The risk with subdomains is lower than when scoped to parent domain, but still relevant
• Remove domain attribute to limit cookie to origin host only
- Important note: IE will always send to subdomains regardless
• With domain set, cookies will be sent to that domain and all its subdomains
• The risk with subdomains is lower than when scoped to parent domain, but still relevant
• Remove domain attribute to limit cookie to origin host only
- Important note: IE will always send to subdomains regardless
Weet iemand of dat laatste klopt (en MSIE nog erger zuigt dan ik al wist)?
Door Anoniem:
Ah, u is dus een onbegrepen genie dat thans zijn gram haalt.
Door Bitwiper: Inleiding
Probleem: onjuist geconfigureerde HSTS
Veel https websites, ook security.nl, hebben een incomplete HSTS configuratie. In [2] ben ik daar al eens op in gegaan, maar omdat de beheerders van security.nl dat artikel niet vanzelf hebben aangegrepen om deze site te verbeteren, gaan zij nu op het hakblok ;-)
Probleem: onjuist geconfigureerde HSTS
Veel https websites, ook security.nl, hebben een incomplete HSTS configuratie. In [2] ben ik daar al eens op in gegaan, maar omdat de beheerders van security.nl dat artikel niet vanzelf hebben aangegrepen om deze site te verbeteren, gaan zij nu op het hakblok ;-)
Ah, u is dus een onbegrepen genie dat thans zijn gram haalt.
HSTS... ik wil graag wat nieuwe skills leren maar iets of iemand zit steeds dwars waardoor ik niet de zekerheid heb om me te focussen op wat belangrijk is. Dit nieuwe 'web' is erg contraproductief en dat is al vaak gezegd maar nog niet openlijk.
Door Anoniem: HSTS... ik wil graag wat nieuwe skills leren [...]
Webservers kunnen via het http protocol "metadata" naar de bezoekende browser sturen in zogenaamde "headers". Deze headers maken geen onderdeel uit van de webpagina zelf en zijn onzichtbaar voor gebruikers (ook als je "view source" doet - maar met F12 kun je ze wel bekijken).Zo'n header is een tekstregel met een "name-value" paar. Die naam is een gestandaardiseerde "identifier" zoals hier beschreven: https://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Standard_response_fields. Omdat https grotendeels gelijk is aan http over TLS, wordt ook bij https gebruik gemaakt van headers.
Eén van die mogelijke headers is de HSTS (Http Strict Transport Security) header, gestandaardiseerd in https://tools.ietf.org/html/rfc6797.
Een voorbeeld van zo'n header regel is:
Strict-Transport-Security: max-age=3600
Bij ontvangst van zo'n header via een https verbinding (browsers negeren HSTS headers indien ontvangen via http), bijvoorbeeld van een URL die begint met https://www.security.nl/, zal elke moderne webbrowser, gedurende 3600 seconden na ontvangst van die header, het volgende doen:
1) Elke URL die begint met http://www.security.nl/, automatisch en ongevraagd wijzigen in httpS://www.security.nl/ nadat je op zo'n link hebt geklikt (of bij een in een pagina ingebouwde verwijzing, bijvoorbeeld naar een plaatje in die pagina), doch voordat de netwerkverbinding daarvoor wordt opgezet;
2) Elke certificaatwaarschuwing (met een "ga toch naar de site" knop) omzetten in een definitieve certificaatfoutmelding die ervoor zorgt dat de gebruiker geheel niet naar de site kan.
Een korte tijd (zoals 3600 seconden = 1 uur in bovenstaand voorbeeld) zorgt er in elk geval (tijdens de huidige sessie) voor dat als je op een eventuele http link naar een pagina op deze site zou klikken, zoals de volgende link naar de pagina die je nu leest:
http://www.security.nl/posting/576552/, die URL automatisch door jouw browser wordt veranderd in:
https://www.security.nl/posting/576552/ - net voordat jouw browser de netwerkverbinding daarvoor opent.
Toen security.nl overschakelde van http naar https hoefden de beheerders dus niet alle http links naar deze site in alle oude pagina's te wijzigen om ervoor te zorgen dat browsers zoveel mogelijk via https met deze site communiceren.
Gebruikelijk en verstandig is een veel langere tijd dan 3600 seconden, bijv. 1 jaar (3600 seconden X 24 uur x 365 dagen = 31536000 seconden). Er is nog iets dat je moet weten: webbrowsers onthouden dit meestal (afhankelijk van instellingen) ook na het stoppen en starten van de webbrowser (ook na herstarten van je PC, tablet of smartphone).
Dus als jij na vandaag, doch binnen 365 dagen, www.security.nl of expliciet http://www.security.nl/ in de URL-balk van jouw browser tikt (of als je nog een oude snelkoppeling naar http://www.security.nl/ hebt en daar op klikt), zal jouw browser daar -normaal gesproken- https://www.security.nl/ van maken, onzichtbaar voor jou, net voor het opzetten van de verbinding.
Een MITM (Man In The Middle) aanvaller kan jouw verbinding alleen kapen als:
- Ofwel zij over een geldig certificaat met bijpassende private key van www.security.nl beschikt;
- Ofwel jouw browser niet (meer) over HSTS informatie voor www.security.nl beschikt.
Dat tweede punt kan onder de volgende onstandigheden:
- Het is de allereerste keer dat je www.security.nl bezoekt (het kip/ei probleem van HSTS);
- Idem met de specifieke browser die je nu gebruikt (herinstallatie, nieuwe smartphone etc.);
- Als jouw browser geen HSTS ondersteunt of de browser zo geconfigureerd is dat niets van de "history" wordt onthouden bij afsluiten, inclusief HSTS informatie.
Is het wat duidelijker zo?
17-09-2018, 00:27 door
Briolet
Mij viel vandaag op dat http://dmarc.org hun www al geschrapt heeft.
In hun publicaties uit 2012 verwijzen ze nog naar de www versie van hun domein. Maar als je dat intikt, krijg je juist een redirect naar de versie zonder www. (-:
In hun publicaties uit 2012 verwijzen ze nog naar de www versie van hun domein. Maar als je dat intikt, krijg je juist een redirect naar de versie zonder www. (-:
Naast de bovenaan deze bijdrage genoemde twee argumenten, bestaat er allang geen noodzaak meer voor het www. voorvoegsel.
Zijn de lezers van security.nl het met mij eens, of zie ik hierbij wat over het hoofd?
Ik stel vast dat omdat anderen HSTS fouten maken (hetgeen ook erg makkelijk is, vooral als je het niet snapt) ik mij nu blijkbaar weer moet aanpassen, terwijl daar bij mij geen noodzaak/argument voor is.
Het www voorvoegsel heeft meer bestaansrecht gekregen met de nTLD's, zoals ink, yoga, company, store en shop
Zonder zal men niet direct aan een URL denken - en andersom; ik zie veel slogans en namen die URL's zouden kunnen zijn maar het niet zijn. www maakt dat dus duidelijk - en i.p.v. http://bedrijf.tld blijft www.bedrijf.tld makkelijker op je briefpapier, visitekaartjes, etc. - maar moet de www dus wel redirecten...
Verder werken CNAMES en DNAMES niet in de zone-apex.
Persoonlijk wil ik die ook absoluut niet, maar talloze gebruikers van remote-hosters (zoals CDN's) wensen dat wel.
Kortom, de techies met kortzichtigheid lopen iets te ver vooruit op wat het digitale tijdperk nog moet gaan brengen.
Of, HSTS is te moeilijk voor hen die het niet begrijpen - een probleem dat je altijd zult houden.
18-09-2018, 01:37 door
Bitwiper
Door Briolet: Mij viel vandaag op dat http://dmarc.org hun www al geschrapt heeft.
In hun publicaties uit 2012 verwijzen ze nog naar de www versie van hun domein. Maar als je dat intikt, krijg je juist een redirect naar de versie zonder www. (-:
Dank voor de vermelding!In hun publicaties uit 2012 verwijzen ze nog naar de www versie van hun domein. Maar als je dat intikt, krijg je juist een redirect naar de versie zonder www. (-:
Door Anoniem:
Naast de bovenaan deze bijdrage genoemde twee argumenten, bestaat er allang geen noodzaak meer voor het www. voorvoegsel.
Zijn de lezers van security.nl het met mij eens, of zie ik hierbij wat over het hoofd?
Ik stel vast dat omdat anderen HSTS fouten maken (hetgeen ook erg makkelijk is, vooral als je het niet snapt) ik mij nu blijkbaar weer moet aanpassen
Dan begrijp je mij verkeerd: natuurlijk leidt het schrappen van www. er niet toe dat HSTS simpeler zou worden, want als je redirect van www.bedrijf.tld naar bedrijf.tld zul je ook beide domeinen moeten beveiligen. Het is toch zonde als je de moeite neemt om HSTS te implementeren, maar door onwetendheid een groot deel van de bezoekers niet beschermt?Naast de bovenaan deze bijdrage genoemde twee argumenten, bestaat er allang geen noodzaak meer voor het www. voorvoegsel.
Zijn de lezers van security.nl het met mij eens, of zie ik hierbij wat over het hoofd?
Ik stel vast dat omdat anderen HSTS fouten maken (hetgeen ook erg makkelijk is, vooral als je het niet snapt) ik mij nu blijkbaar weer moet aanpassen
Nogmaals, de redenen om www. te schrappen zijn wat mij betreft:
1) Marketing eist meestal een zo kort mogelijke domeinnaam ("ga naar security.nl") en gebruikers, die graag zo min mogelijk tikken, is geleerd dat bedrijf.tld in de praktijk altijd werkt voor een site die eigenlijk www.bedrijf.tld heet;
2) Die tekenreeks "www." verspilt schermruimte en maakt het herkennen van de hoofddomeinnaam ietsje lastiger.
Het weglaten van www. terwijl dit wel getoond zou moeten worden, vind ik erger dan dat site-eigenaren zich aanpassen.
28-02-2019, 14:08 door
Briolet
Door Bitwiper: - Als je altijd https://security.nl/ intikt (waar jouw browser geen HSTS informatie van heeft) en een MITM jouw browser een vals (bijv. self-signed) certificaat voorschotelt, dan krijg je een certificaat-waarschuwing die je weg zou kunnen klikken.
Ik werd er gisteren op geattendeerd dat Firefox er tegenwoordig zelf www voor plakt. Heel vervelend als je een site hebt waar geen www versie van bestaat of als de www versie anders is. Tik maar eens "htedrefgh.nl" in en hij probeert de www versie te openen. Nu is dit geen bestaande site, maar bij mij gebeurde het bij een bestaande site zonder www versie. Je kunt dan niet meer bij de site komen via firefox.
Door Briolet: Ik werd er gisteren op geattendeerd dat Firefox er tegenwoordig zelf www voor plakt. Heel vervelend als je een site hebt waar geen www versie van bestaat of als de www versie anders is. Tik maar eens "htedrefgh.nl" in en hij probeert de www versie te openen. Nu is dit geen bestaande site, maar bij mij gebeurde het bij een bestaande site zonder www versie. Je kunt dan niet meer bij de site komen via firefox.
Dat is niet nieuw, zo doet Firefox dat al sinds jaar en dag. En ik heb dat ook al sinds jaar en dag uitgeschakeld (want ik houd daar ook niet van) door in about:config de waarde voor browser.fixup.alternate.enabled op False te zetten.Door Bitwiper:
Ok, jij bent dus eigenlijk de expert die bij nieuwsuur z'n verhaal zou moeten doen, maar niet gevraagd is... :)Door Anoniem: Ah, u is dus een onbegrepen genie dat thans zijn gram haalt.
Ik ben helemaal geen genie, maar... Even een voorbeeld aanhalen: tweakers.net heeft dit en komt soms leuke problemen tegen.
Voorbeeld: https://tweakers.net/plan/319/tweakers-punt-net-uit-google-index-verdwenen-en-weer-terug.html
Voorbeeld: https://tweakers.net/plan/319/tweakers-punt-net-uit-google-index-verdwenen-en-weer-terug.html
Door Anoniem: Even een voorbeeld aanhalen: tweakers.net heeft dit en komt soms leuke problemen tegen.
Voorbeeld: https://tweakers.net/plan/319/tweakers-punt-net-uit-google-index-verdwenen-en-weer-terug.html
Dat was 2006.... zugtVoorbeeld: https://tweakers.net/plan/319/tweakers-punt-net-uit-google-index-verdwenen-en-weer-terug.html
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
