Security Professionals
- ipfw add deny all from eindgebruikers to any
NL: veel brakke https sites
Inleiding
In [1] en [2] is mij door critici duidelijk gemaakt dat mensen echt geen https://www.security.nl/ intikken, maar volstaan met het invoeren van security.nl. En dat is helemaal niet zo gek want overal lees en hoor je "ga naar belastingdienst.nl" in plaats van "ga naar https://www.belastindienst.nl/" - dat veel veiliger is en "HSTS" overbodig maakt.
Omdat de NCTV (Nationaal Coördinator Terrorismebestrijding en Veiligheid) gisteren waarschuwde [3] voor een "continue digitale dreiging voor de nationale veiligheid", neem ik de website daarvan hieronder als voorbeeld - want ook bij hen kan het beter!
Doelen van HSTS
Het hoofddoel van HSTS [4] in de situatie dat je slechts nctv.nl invoert, zou moeten zijn dat MITM (Man in the Middle) aanvallen [5] zo goed als onmogelijk zijn - onder voorwaarde dat de gebruiker eventuele certificaatwaarschuwingen niet negeert.
Een ander doel van HSTS is dat verouderde http links in snelkoppelingen (ook bekend als bookmarks of favorieten), vanuit andere sites of achtergebleven http links in een site die ondertussen https ondersteunt, door de browser automatisch worden omgezet in https - om zo eerdergenoemde MITM aanvallen te voorkomen.
Risico's
Het belangrijkste doel van https is dat je zeker weet met welke webserver jouw browser een verbinding heeft, en daarnaast dat deze verbinding is versleuteld. Daarbij kennen alleen jouw browser en de webserver de unieke sleutel van die sessie, waardoor iemand -waar dan ook tussen jouw webbrowser en de webserver- met toegang tot de verbinding (WiFi, netwerkkabel of netwerkapparatuur), niet kan meekijken en ook geen informatie kan vervangen (denk aan bankrekeningnummers als je geld overmaakt) of verwijderen.
Wellicht het grootste risico hierbij is een downgrade attack, waarbij een MITM een eigen veilige https verbinding heeft met een webserver, maar jij met jouw browser een http verbinding hebt met de server van de MITM - en dat jij NIET (MEER) WEET dat er sprake zou moeten zijn van een https verbinding met de bedoelde server, of DAAR NIET OP LET.
Een tweede risico is dat de MITM jou doorstuurt naar een website met een domeinnaam die sterk lijkt op die van de bedoelde website; de aanvaller kan deze dan eenvoudig van een geldig https certificaat voorzien (bijv. https://www_nctv.nl/, https://nc-tv.nl/ of https://nctenv.nl/). Dit kan allemaal niet als er van het begin af aan sprake is van een https verbinding, mits je de juiste domeinnaam absoluut foutloos hebt ingevoerd en certificaatwaarschuwingen niet wegklikt.
HSTS tracht het risico, dat je loopt door niet expliciet https:// in te tikken, voor een groot deel te mitigeren (beperken). Helemaal lukt dat niet, want HSTS pas werkt nadat je met jouw browser een website, die HSTS ondersteunt, op z'n minst één keer eerder via https hebt bezocht. Jouw webbrowser onthoudt dan voor enige tijd dat elke volgende keer dat je die website bezoekt, dit via https moet gebeuren, ook al tik je geen protocol in, of vraag je expliciet om http.
Als HSTS niet of onvolledig wordt ondersteund door een website heb je een verhoogd risico op MITM aanvallen. Je kunt beargumenteren dat dit risico klein is, maar dan vraag ik me af waarom beheerders HSTS onvolledig implementeren - terwijl het nauwelijks meer moeite kost om dit goed te doen!
Onderzoekje
Gisteravond heb ik een "keukentafelonderzoekje" naar HSTS uitgevoerd; de resultaten daarvan kun je gerust dramatisch noemen. Bij de meeste sites werkt HSTS niet als je slechts nctv.nl invoert, d.w.z. daarbij www. weglaat - vermoedelijk omdat beheerders niet goed begrijpen hoe HSTS werkt - maar ook niet hoe mensen denken (hier maak ik mij ook schuldig aan) en/of hoe marketeers en accountmanagers vereenvoudigen.
Bij de volgende websites werkt HSTS wel als je www.*.nl invoert, maar niet als je slechts *.nl invoert:
Enkele gemeentes (ik was met A begonnen maar ben tussendoor overgestapt op de wat grotere gemeentes): aalburg.nl, aalsmeer.nl, aalten.nl, alblasserdam.nl, alphenaandenrijn.nl, arnhem.nl, apeldoorn.nl, breda.nl, delft.nl, denhaag.nl, heerenveen.nl, helmond.nl, leidschendam.nl, lv.nl, rotterdam.nl, venlo.nl, voorburg.nl, woerden.nl
Enkele andere overheidwebsites: belastingdienst.nl, uwv.nl, tweedekamer.nl, overheid.nl, nctv.nl, bkr.nl, politie.nl
Enkele winkels: wehkamp.nl, zalando.nl, bol.com, ah.nl, anwb.nl, ns.nl, cena.nl
Enkele banken: binck.nl, icscards.nl, knab.nl, rabobank.nl
Enkele certificaatverkopers (die zouden beter moeten weten): argeweb.nl, combell.nl, globalsign.nl, symantec.nl, verisign.nl, versio.nl
Enkele verzekeraars: achmea.nl, cz.nl, nn.nl, zilverenkruis.nl
De volgende websites ondersteunen helemaal geen HSTS:
Enkele gemeentes: assen.nl, www.assen.nl, aaenhunze.nl, www.aaenhunze.nl, alkmaar.nl, www.alkmaar.nl, amsterdam.nl, www.amsterdam.nl, gouda.nl, www.gouda.nl, groningen.nl, www.groningen.nl, portal.groningen.nl, meppel.nl, www.meppel.nl
Een overheidwebsite: afm.nl, www.afm.nl
Een voorbeeld van een verzekeraar: ohra.nl, www.ohra.nl
Enkele andere sites: consumentenbond.nl, www.consumentenbond.nl, marktplaats.nl, www.marktplaats.nl, hema.nl, www.hema.nl
Geen of onvolledige ondersteuning van https (en dus ook geen HSTS): albrandswaard.nl, almelo.nl, almere.nl, maastricht.nl, middelburg.nl, zutphen.nl
Dat het ook goed kan bewijzen de volgende sites (HSTS werkt ook op genoemde domeinnamen, zonder www. dus):
Enkele gemeentes: achtkarspelen.nl, amersfoort.nl, deventer.nl, eindhoven.nl, emmen.nl, gemeentemaastricht.nl, haarlem.nl, tilburg.nl, utrecht.nl, vlissingen.nl, zoetermeer.nl, zwolle.nl
Enkele banken: abnamro.nl, asnbank.nl, ing.nl, sns.nl, snsbank.nl, triodos.nl
Enkele overheidwebsites: aivd.nl, ncsc.nl
Enkele certificaatverkopers: comodo.nl, networking4all.nl, sslcertificaten.nl, transip.nl
Correcte implementatie
Zorg dat jouw site, met elke schrijfwijze van de domeinnaam:
A) Vanuit http een redirect doet naar de https variant met identieke domeinnaam (dus http://nctv.nl/ -> https://nctv.nl/);
B) De https variant (zoals https://nctv.nl/) de HSTS header meestuurt;
C) Pas vanuit https://nctv.nl/ een redirect doet naar https://www.nctv.nl/;
D) Kies, nadat je klaar bent met testen, voor een langere periode dan 1 jaar, bij voorkeur 2 jaar (63072000 secondes);
E) TEST TEST TEST! Check met het "F12" venster van jouw browser of elke https domeinnaam 1 (en niet meer dan 1) HSTS header meestuurt!
Nb. Ik zie beheerders, in een wanhoopspoging, HSTS headers meesturen op http websites, maar Firefox doet daar -m.i. terecht- niets mee, en vermoedelijk andere browsers ook niet.
Bewijs
Bijvoorbeeld voor nctv.nl (of elke andere website waarvan ik claim dat HSTS niet werkt zonder het www. voorvoegsel):
1) In je favoriete browser voer je in als URL: nctv.nl, druk Enter en wacht totdat dit gewijzigd is in https://www.nctv.nl/. Nu zal alle beschikbare HSTS informatie door jouw browser zijn opgeslagen (in een lokale database);
2) Sluit de pagina, clear de browser cache (om te voorkomen dat zometeen cached content wordt getoond) en sluit alle vensters van de browser;
3) Voeg toe aan de hosts file op je PC (het IP-adres is van www.security.nl):
4) Voer uit in een CMD venster (om je erzeker van te zijn dat de hosts file zometeen gelezen wordt, een niet de DNS cache):
5) Start de browser en voer je in als URL: nctv.nl gevolgd door Enter.
Als nctv.nl HSTS had ondersteund, had je nu een certificaatfoutmelding gezien. Die krijg je (op het moment dat ik dit publiceer) niet te zien, maar in plaats daarvan de voorpagina van deze website. In het geval van een echte MITM aanval, had de site natuurlijk als twee druppels water op de echte nctv.nl site kunnen lijken.
Als je het bovenstaande herhaalt voor bijvoorbeeld ing.nl, krijg je wel een certificaatfoutmelding te zien. Daarmee is het onmogelijk voor een MITM om te redirecten naar een andere site, of om een look-alike site te tonen.
Nb. i.p.v. het IP-adres van security.nl kun je natuurlijk ook een ander IP-adres nemen. Het handige van security.nl is echter dat deze de meegestuurde domeinnaam (middels SNI) negeert en altijd de voorpagina laat zien (veel andere servers zullen een foutmelding tonen, en die zou je kunnen verwarren met een certificaatfoutmelding).
Verantwoording
Ik zie dit niet als een echt lek (immers, als je geen HSTS informatie in jouw browser hebt, ben je sowieso niet veilig). Mijn advies is en blijft: tik zelf https:// voor de domeinnaam (zie [1]), dan heb je geen HSTS nodig! Mede daarom heb ik besloten om niet eerst alle sites hiervan op de hoogte te brengen, maar ook omdat ik daar (A) geen tijd voor heb en (B) dan tot Sint Juttemis kan wachten voordat ik beheerders kan waarschuwen met deze bijdrage.
[1] https://www.security.nl/posting/564452/https+voor+leken
[2] https://www.security.nl/posting/564350/nos%3A+duizenden+https+sites+onveilig
[3] https://www.security.nl/posting/565826/NCTV%3A+Continue+digitale+dreiging+voor+nationale+veiligheid
[4] Bijvoorbeeld: https://www.sslcertificaten.nl/support/Terminologie/HTTP_Strict_Transport_Security
[5] Bijvoorbeeld: https://blog.networking4all.com/2016/07/ssl-en-verder-verdediging-tegen-man-in-the-middle-attacks/
In [1] en [2] is mij door critici duidelijk gemaakt dat mensen echt geen https://www.security.nl/ intikken, maar volstaan met het invoeren van security.nl. En dat is helemaal niet zo gek want overal lees en hoor je "ga naar belastingdienst.nl" in plaats van "ga naar https://www.belastindienst.nl/" - dat veel veiliger is en "HSTS" overbodig maakt.
Omdat de NCTV (Nationaal Coördinator Terrorismebestrijding en Veiligheid) gisteren waarschuwde [3] voor een "continue digitale dreiging voor de nationale veiligheid", neem ik de website daarvan hieronder als voorbeeld - want ook bij hen kan het beter!
Doelen van HSTS
Het hoofddoel van HSTS [4] in de situatie dat je slechts nctv.nl invoert, zou moeten zijn dat MITM (Man in the Middle) aanvallen [5] zo goed als onmogelijk zijn - onder voorwaarde dat de gebruiker eventuele certificaatwaarschuwingen niet negeert.
Een ander doel van HSTS is dat verouderde http links in snelkoppelingen (ook bekend als bookmarks of favorieten), vanuit andere sites of achtergebleven http links in een site die ondertussen https ondersteunt, door de browser automatisch worden omgezet in https - om zo eerdergenoemde MITM aanvallen te voorkomen.
Risico's
Het belangrijkste doel van https is dat je zeker weet met welke webserver jouw browser een verbinding heeft, en daarnaast dat deze verbinding is versleuteld. Daarbij kennen alleen jouw browser en de webserver de unieke sleutel van die sessie, waardoor iemand -waar dan ook tussen jouw webbrowser en de webserver- met toegang tot de verbinding (WiFi, netwerkkabel of netwerkapparatuur), niet kan meekijken en ook geen informatie kan vervangen (denk aan bankrekeningnummers als je geld overmaakt) of verwijderen.
Wellicht het grootste risico hierbij is een downgrade attack, waarbij een MITM een eigen veilige https verbinding heeft met een webserver, maar jij met jouw browser een http verbinding hebt met de server van de MITM - en dat jij NIET (MEER) WEET dat er sprake zou moeten zijn van een https verbinding met de bedoelde server, of DAAR NIET OP LET.
Een tweede risico is dat de MITM jou doorstuurt naar een website met een domeinnaam die sterk lijkt op die van de bedoelde website; de aanvaller kan deze dan eenvoudig van een geldig https certificaat voorzien (bijv. https://www_nctv.nl/, https://nc-tv.nl/ of https://nctenv.nl/). Dit kan allemaal niet als er van het begin af aan sprake is van een https verbinding, mits je de juiste domeinnaam absoluut foutloos hebt ingevoerd en certificaatwaarschuwingen niet wegklikt.
HSTS tracht het risico, dat je loopt door niet expliciet https:// in te tikken, voor een groot deel te mitigeren (beperken). Helemaal lukt dat niet, want HSTS pas werkt nadat je met jouw browser een website, die HSTS ondersteunt, op z'n minst één keer eerder via https hebt bezocht. Jouw webbrowser onthoudt dan voor enige tijd dat elke volgende keer dat je die website bezoekt, dit via https moet gebeuren, ook al tik je geen protocol in, of vraag je expliciet om http.
Als HSTS niet of onvolledig wordt ondersteund door een website heb je een verhoogd risico op MITM aanvallen. Je kunt beargumenteren dat dit risico klein is, maar dan vraag ik me af waarom beheerders HSTS onvolledig implementeren - terwijl het nauwelijks meer moeite kost om dit goed te doen!
Onderzoekje
Gisteravond heb ik een "keukentafelonderzoekje" naar HSTS uitgevoerd; de resultaten daarvan kun je gerust dramatisch noemen. Bij de meeste sites werkt HSTS niet als je slechts nctv.nl invoert, d.w.z. daarbij www. weglaat - vermoedelijk omdat beheerders niet goed begrijpen hoe HSTS werkt - maar ook niet hoe mensen denken (hier maak ik mij ook schuldig aan) en/of hoe marketeers en accountmanagers vereenvoudigen.
Bij de volgende websites werkt HSTS wel als je www.*.nl invoert, maar niet als je slechts *.nl invoert:
Enkele gemeentes (ik was met A begonnen maar ben tussendoor overgestapt op de wat grotere gemeentes): aalburg.nl, aalsmeer.nl, aalten.nl, alblasserdam.nl, alphenaandenrijn.nl, arnhem.nl, apeldoorn.nl, breda.nl, delft.nl, denhaag.nl, heerenveen.nl, helmond.nl, leidschendam.nl, lv.nl, rotterdam.nl, venlo.nl, voorburg.nl, woerden.nl
Enkele andere overheidwebsites: belastingdienst.nl, uwv.nl, tweedekamer.nl, overheid.nl, nctv.nl, bkr.nl, politie.nl
Enkele winkels: wehkamp.nl, zalando.nl, bol.com, ah.nl, anwb.nl, ns.nl, cena.nl
Enkele banken: binck.nl, icscards.nl, knab.nl, rabobank.nl
Enkele certificaatverkopers (die zouden beter moeten weten): argeweb.nl, combell.nl, globalsign.nl, symantec.nl, verisign.nl, versio.nl
Enkele verzekeraars: achmea.nl, cz.nl, nn.nl, zilverenkruis.nl
De volgende websites ondersteunen helemaal geen HSTS:
Enkele gemeentes: assen.nl, www.assen.nl, aaenhunze.nl, www.aaenhunze.nl, alkmaar.nl, www.alkmaar.nl, amsterdam.nl, www.amsterdam.nl, gouda.nl, www.gouda.nl, groningen.nl, www.groningen.nl, portal.groningen.nl, meppel.nl, www.meppel.nl
Een overheidwebsite: afm.nl, www.afm.nl
Een voorbeeld van een verzekeraar: ohra.nl, www.ohra.nl
Enkele andere sites: consumentenbond.nl, www.consumentenbond.nl, marktplaats.nl, www.marktplaats.nl, hema.nl, www.hema.nl
Geen of onvolledige ondersteuning van https (en dus ook geen HSTS): albrandswaard.nl, almelo.nl, almere.nl, maastricht.nl, middelburg.nl, zutphen.nl
Dat het ook goed kan bewijzen de volgende sites (HSTS werkt ook op genoemde domeinnamen, zonder www. dus):
Enkele gemeentes: achtkarspelen.nl, amersfoort.nl, deventer.nl, eindhoven.nl, emmen.nl, gemeentemaastricht.nl, haarlem.nl, tilburg.nl, utrecht.nl, vlissingen.nl, zoetermeer.nl, zwolle.nl
Enkele banken: abnamro.nl, asnbank.nl, ing.nl, sns.nl, snsbank.nl, triodos.nl
Enkele overheidwebsites: aivd.nl, ncsc.nl
Enkele certificaatverkopers: comodo.nl, networking4all.nl, sslcertificaten.nl, transip.nl
Correcte implementatie
Zorg dat jouw site, met elke schrijfwijze van de domeinnaam:
A) Vanuit http een redirect doet naar de https variant met identieke domeinnaam (dus http://nctv.nl/ -> https://nctv.nl/);
B) De https variant (zoals https://nctv.nl/) de HSTS header meestuurt;
C) Pas vanuit https://nctv.nl/ een redirect doet naar https://www.nctv.nl/;
D) Kies, nadat je klaar bent met testen, voor een langere periode dan 1 jaar, bij voorkeur 2 jaar (63072000 secondes);
E) TEST TEST TEST! Check met het "F12" venster van jouw browser of elke https domeinnaam 1 (en niet meer dan 1) HSTS header meestuurt!
Nb. Ik zie beheerders, in een wanhoopspoging, HSTS headers meesturen op http websites, maar Firefox doet daar -m.i. terecht- niets mee, en vermoedelijk andere browsers ook niet.
Bewijs
Bijvoorbeeld voor nctv.nl (of elke andere website waarvan ik claim dat HSTS niet werkt zonder het www. voorvoegsel):
1) In je favoriete browser voer je in als URL: nctv.nl, druk Enter en wacht totdat dit gewijzigd is in https://www.nctv.nl/. Nu zal alle beschikbare HSTS informatie door jouw browser zijn opgeslagen (in een lokale database);
2) Sluit de pagina, clear de browser cache (om te voorkomen dat zometeen cached content wordt getoond) en sluit alle vensters van de browser;
3) Voeg toe aan de hosts file op je PC (het IP-adres is van www.security.nl):
82.94.191.109 nctv.nl
ipconfig /flushdns
Als nctv.nl HSTS had ondersteund, had je nu een certificaatfoutmelding gezien. Die krijg je (op het moment dat ik dit publiceer) niet te zien, maar in plaats daarvan de voorpagina van deze website. In het geval van een echte MITM aanval, had de site natuurlijk als twee druppels water op de echte nctv.nl site kunnen lijken.
Als je het bovenstaande herhaalt voor bijvoorbeeld ing.nl, krijg je wel een certificaatfoutmelding te zien. Daarmee is het onmogelijk voor een MITM om te redirecten naar een andere site, of om een look-alike site te tonen.
Nb. i.p.v. het IP-adres van security.nl kun je natuurlijk ook een ander IP-adres nemen. Het handige van security.nl is echter dat deze de meegestuurde domeinnaam (middels SNI) negeert en altijd de voorpagina laat zien (veel andere servers zullen een foutmelding tonen, en die zou je kunnen verwarren met een certificaatfoutmelding).
Verantwoording
Ik zie dit niet als een echt lek (immers, als je geen HSTS informatie in jouw browser hebt, ben je sowieso niet veilig). Mijn advies is en blijft: tik zelf https:// voor de domeinnaam (zie [1]), dan heb je geen HSTS nodig! Mede daarom heb ik besloten om niet eerst alle sites hiervan op de hoogte te brengen, maar ook omdat ik daar (A) geen tijd voor heb en (B) dan tot Sint Juttemis kan wachten voordat ik beheerders kan waarschuwen met deze bijdrage.
[1] https://www.security.nl/posting/564452/https+voor+leken
[2] https://www.security.nl/posting/564350/nos%3A+duizenden+https+sites+onveilig
[3] https://www.security.nl/posting/565826/NCTV%3A+Continue+digitale+dreiging+voor+nationale+veiligheid
[4] Bijvoorbeeld: https://www.sslcertificaten.nl/support/Terminologie/HTTP_Strict_Transport_Security
[5] Bijvoorbeeld: https://blog.networking4all.com/2016/07/ssl-en-verder-verdediging-tegen-man-in-the-middle-attacks/
Reacties (46)
Aanvulling na een nachtje slapen: wat ontbreekt is uitleg wat er precies fout gaat, en ik heb nog wat tips.
Oorzaak
Wat fout gaat zijn sites zonder subdomeinnaam die, vanuit een http verbinding met die site, de gebruiker meteen doorsturen naar https:// gevolgd door een andere domeinnaam.
Dus als een site zoals http://nctv.nl/ jou meteen doorstuurt naar https://www.nctv.nl/, dan registreert de browser geen HSTS header van nctv.nl - en dat maakt de gebruiker elke keer kwetsbaar als zij naar nctv.nl surft.
Zoals duidelijk moge zijn: als www.nctv.nl een HSTS header verstuurt, zal de browser van de gebruiker www.nctv.nl in haar HSTS database opnemen, maar daar schiet nctv.nl niets mee op - daar is immers geen https verbinding mee geweest.
In plaats van de browser via de volgende, wel veilige, route:
te laten redirecten, kun je de middelste stap overslaan als je vanuit https://www.nctv.nl/ de browser iets laat ophalen vanaf https://nctv.nl/ (bijv. een 1x1 pixel of een leeg stukje Javascript) - maar dat heeft natuurlijk alleen zin als https://nctv.nl/ zelf ook een HSTS header meestuurt naar de browser.
includeSubDomains
Er is overigens nog een belangrijke reden om ervoor te zorgen dat de browser https://nctv.nl/ bezoekt. Alleen als dat plaatsvindt, en de HSTS header op https://nctv.nl/ de directive "includeSubDomains" bevat, is in één klap jouw hele huidige site, met alle mogelijke subsites, veilig.
Dit is van belang in situaties waarbij de browser een HSTS instructie voor www.belastingdienst.nl heeft geladen, maar nog niet voor andere subsites zoals mijn.belastingdienst.nl. Ik (en vermoedelijk niet alleen ik) kan gerichte aanvallen bedenken waarbij de gebruiker op het verkeerde been wordt zet (bijv. met een gerichte phishing mail).
Of je gebruik maakt van "includeSubDomains" (vanaf de "root" van jouw site zegt maar) moet een weloverwogen keuze zijn. Immers, je kunt dan op geen enkele sub- of sub-sub- site nog http gebruiken.
Pas toe of leg uit
Beheerders van websites in de publieke sector hoeven hier niet over na te denken, want volgens de "pas toe of leg uit" website is het gebruik van https in combinatie met HSTS verplicht.
Nu we het toch over forumstandaardisatie.nl hebben, stiekem hoopte ik hen erop te betrappen dat ook zij HSTS niet goed zouden hebben geconfigureerd, maar als je forumstandaardisatie.nl opent, word je eerst netjes doorgestuurd naar https://forumstandaardisatie.nl/ met de volgende HSTS header:
en pas daarna naar https://www.forumstandaardisatie.nl/ (met dezelfde header, maar die voegt -mits de gebruiker via de beschreven route binnenkomt- niets meer toe).
Voor die site geldt echter wel dat eventuele andere subdomains niet nu al middels HSTS beschermd zijn, want -als ik HSTS goed begrijp- geldt die aanduiding "subdomains" voor subsites onder de huidige site. Ik bedoel daarmee dat als de browser https://forumstandaardisatie.nl/ nooit bezocht heeft, HSTS alleen geldt voor *.www.forumstandaardisatie.nl en niet voor bijvoorbeeld mijn.forumstandaardisatie.nl of portal.forumstandaardisatie.nl.
Conclusie
Het is, vermoed ik, dus altijd een goed idee om, op z'n minst vanuit de main page van elke site, de browser iets van jouw rootdomain op te laten halen (waarbij die site natuurlijk wel een HSTS header met includeSubDomains moet hebben), om de hele tree van websites te laten beschermen middels HSTS. Dat is geen panacea, maar is beter dan niks of half werk!
Oorzaak
Wat fout gaat zijn sites zonder subdomeinnaam die, vanuit een http verbinding met die site, de gebruiker meteen doorsturen naar https:// gevolgd door een andere domeinnaam.
Dus als een site zoals http://nctv.nl/ jou meteen doorstuurt naar https://www.nctv.nl/, dan registreert de browser geen HSTS header van nctv.nl - en dat maakt de gebruiker elke keer kwetsbaar als zij naar nctv.nl surft.
Zoals duidelijk moge zijn: als www.nctv.nl een HSTS header verstuurt, zal de browser van de gebruiker www.nctv.nl in haar HSTS database opnemen, maar daar schiet nctv.nl niets mee op - daar is immers geen https verbinding mee geweest.
In plaats van de browser via de volgende, wel veilige, route:
http://nctv.nl/ -> https://nctv.nl/ -> https://www.nctv.nl/
includeSubDomains
Er is overigens nog een belangrijke reden om ervoor te zorgen dat de browser https://nctv.nl/ bezoekt. Alleen als dat plaatsvindt, en de HSTS header op https://nctv.nl/ de directive "includeSubDomains" bevat, is in één klap jouw hele huidige site, met alle mogelijke subsites, veilig.
Dit is van belang in situaties waarbij de browser een HSTS instructie voor www.belastingdienst.nl heeft geladen, maar nog niet voor andere subsites zoals mijn.belastingdienst.nl. Ik (en vermoedelijk niet alleen ik) kan gerichte aanvallen bedenken waarbij de gebruiker op het verkeerde been wordt zet (bijv. met een gerichte phishing mail).
Of je gebruik maakt van "includeSubDomains" (vanaf de "root" van jouw site zegt maar) moet een weloverwogen keuze zijn. Immers, je kunt dan op geen enkele sub- of sub-sub- site nog http gebruiken.
Pas toe of leg uit
Beheerders van websites in de publieke sector hoeven hier niet over na te denken, want volgens de "pas toe of leg uit" website is het gebruik van https in combinatie met HSTS verplicht.
Nu we het toch over forumstandaardisatie.nl hebben, stiekem hoopte ik hen erop te betrappen dat ook zij HSTS niet goed zouden hebben geconfigureerd, maar als je forumstandaardisatie.nl opent, word je eerst netjes doorgestuurd naar https://forumstandaardisatie.nl/ met de volgende HSTS header:
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
Voor die site geldt echter wel dat eventuele andere subdomains niet nu al middels HSTS beschermd zijn, want -als ik HSTS goed begrijp- geldt die aanduiding "subdomains" voor subsites onder de huidige site. Ik bedoel daarmee dat als de browser https://forumstandaardisatie.nl/ nooit bezocht heeft, HSTS alleen geldt voor *.www.forumstandaardisatie.nl en niet voor bijvoorbeeld mijn.forumstandaardisatie.nl of portal.forumstandaardisatie.nl.
Conclusie
Het is, vermoed ik, dus altijd een goed idee om, op z'n minst vanuit de main page van elke site, de browser iets van jouw rootdomain op te laten halen (waarbij die site natuurlijk wel een HSTS header met includeSubDomains moet hebben), om de hele tree van websites te laten beschermen middels HSTS. Dat is geen panacea, maar is beter dan niks of half werk!
Bedankt voor je onderzoek en heldere uitleg. Ik maak me eerlijk gezegd bij klanten ook schuldig aan de kortere redirect van:
http://domein.nl/ -> https://www.domein.nl/
Ik zal dit zeker gaan aanpassen, ook al heeft dit het nadeel van een dubbele redirect. De optie om eventueel één resource die altijd op iedere pagina voor komt van https://domein.nl/ te laden is ook interessant om dat te voorkomen.Goed onderzoek en leuk artikel, Bitwiper! Een paar kleine opmerkingen:
Als HSTS actief is voor een website en er vindt een MITM plaats, dan krijgt de gebruiker een melding dat er een mogelijke aanval plaatsvindt (in chrome) maar belangrijker: de melding is niet weg te klikken (in alle browsers die HSTS ondersteunen). De gebruiker kan simpelweg de website niet gebruiken.
Beter advies is: tik het domein in google in. Google zal dan netjes de https link tonen (in een tls sessie die uberhaupt niet de MITMen is) wat vele malen veiliger en gebruiksvriendelijker is dan zelf https in de browser intikken.
Wat ik wel sterk vind is je bevinding dat een verbinding met https://www.voorbeeld.nl waarbij de HSTS header aankomt inclusief de 'includeSubdomains' directive, de includeSubdomains dan ALLEEN geldt voor subdomeinen van het huidige subdomein, bijvoorbeeld een hsts header inclusief de includeSubdomains directive op www.voorbeeld.nl geldt enkel voor bijvoorbeeld asd.www.voorbeeld.nl. De includeSubdomains geldt dus NIET voor andere subdomeinen van hetzelfde niveau, bijvoorbeeld: asdf.voorbeeld.nl zal HSTS niet toegepast worden.
Momenteel ben ik bezig met het ontwikkelen van hsts.me waarbij ik verschillende (Nederlandse) websites wil scannen op hsts. Jouw bevindingen ga ik hierin meenemen! Voeg gerust websites toe via hsts.me/website/add om ze te laten scannen.
Het hoofddoel van HSTS [4] in de situatie dat je slechts nctv.nl invoert, zou moeten zijn dat MITM (Man in the Middle) aanvallen [5] zo goed als onmogelijk zijn - onder voorwaarde dat de gebruiker eventuele certificaatwaarschuwingen niet negeert.
Als HSTS actief is voor een website en er vindt een MITM plaats, dan krijgt de gebruiker een melding dat er een mogelijke aanval plaatsvindt (in chrome) maar belangrijker: de melding is niet weg te klikken (in alle browsers die HSTS ondersteunen). De gebruiker kan simpelweg de website niet gebruiken.
Mijn advies is en blijft: tik zelf https:// voor de domeinnaam (zie [1]), dan heb je geen HSTS nodig
Beter advies is: tik het domein in google in. Google zal dan netjes de https link tonen (in een tls sessie die uberhaupt niet de MITMen is) wat vele malen veiliger en gebruiksvriendelijker is dan zelf https in de browser intikken.
Wat ik wel sterk vind is je bevinding dat een verbinding met https://www.voorbeeld.nl waarbij de HSTS header aankomt inclusief de 'includeSubdomains' directive, de includeSubdomains dan ALLEEN geldt voor subdomeinen van het huidige subdomein, bijvoorbeeld een hsts header inclusief de includeSubdomains directive op www.voorbeeld.nl geldt enkel voor bijvoorbeeld asd.www.voorbeeld.nl. De includeSubdomains geldt dus NIET voor andere subdomeinen van hetzelfde niveau, bijvoorbeeld: asdf.voorbeeld.nl zal HSTS niet toegepast worden.
Momenteel ben ik bezig met het ontwikkelen van hsts.me waarbij ik verschillende (Nederlandse) websites wil scannen op hsts. Jouw bevindingen ga ik hierin meenemen! Voeg gerust websites toe via hsts.me/website/add om ze te laten scannen.
@Bitwiper, ten eerste mijn complimenten voor je uitvoerige bijdragen!
Misschien een aanvulling:
Browsers zouden hier misschien ook een positief aandeel in kunnen hebben door met de opdracht 'new tab' alvast https:// in de url balk te hebben staan. Baat het niet dan schaadt het niet, denk ik zo.
Omdat ik nogal last heb van typefouten - en ik ben zeker niet de enige - gebruik ik liever een zoekopdracht en vandaar uit naar de juiste site om typosquatting in de url balk te voorkomen.
Mij dunkt dat typosquatting minder voorkomt als het adres vooraf wordt gegaan door https:// omdat er om een certificaat wordt gevraagd, of heb ik dat mis?
Misschien een aanvulling:
Browsers zouden hier misschien ook een positief aandeel in kunnen hebben door met de opdracht 'new tab' alvast https:// in de url balk te hebben staan. Baat het niet dan schaadt het niet, denk ik zo.
Omdat ik nogal last heb van typefouten - en ik ben zeker niet de enige - gebruik ik liever een zoekopdracht en vandaar uit naar de juiste site om typosquatting in de url balk te voorkomen.
Mij dunkt dat typosquatting minder voorkomt als het adres vooraf wordt gegaan door https:// omdat er om een certificaat wordt gevraagd, of heb ik dat mis?
Door Aha:
Misschien een aanvulling:
Browsers zouden hier misschien ook een positief aandeel in kunnen hebben door met de opdracht 'new tab' alvast https:// in de url balk te hebben staan. Baat het niet dan schaadt het niet, denk ik zo.
Omdat ik nogal last heb van typefouten - en ik ben zeker niet de enige - gebruik ik liever een zoekopdracht en vandaar uit naar de juiste site om typosquatting in de url balk te voorkomen.
Mij dunkt dat typosquatting minder voorkomt als het adres vooraf wordt gegaan door https:// omdat er om een certificaat wordt gevraagd, of heb ik dat mis?
Zit erinMisschien een aanvulling:
Browsers zouden hier misschien ook een positief aandeel in kunnen hebben door met de opdracht 'new tab' alvast https:// in de url balk te hebben staan. Baat het niet dan schaadt het niet, denk ik zo.
Omdat ik nogal last heb van typefouten - en ik ben zeker niet de enige - gebruik ik liever een zoekopdracht en vandaar uit naar de juiste site om typosquatting in de url balk te voorkomen.
Mij dunkt dat typosquatting minder voorkomt als het adres vooraf wordt gegaan door https:// omdat er om een certificaat wordt gevraagd, of heb ik dat mis?
Mozilla about config
browser.urlbar.trimURLs;true
dubbelklik op de regelbrowser.urlbar.trimURLs;false
Werkt vast ook in de blekebrowser
Enige probleem met de werkwijze http://nctv.nl -> https://nctv.nl -> https://www.nctv.nl is dat je dus 2 certificaten nodig hebt?
Eerst een http redirect doen is natuurlijk ook niet goed...
Eerst een http redirect doen is natuurlijk ook niet goed...
HSTS is gevoelig voor browserfingerprinting en tracking.
Slecht voor je privacy, afhankelijk nog van de soort browser en de configuratie, de ene browser is de andere niet (chrome, tja, chrome).
https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-browser-dilemma-how-hsts-supercookies-make-you-choose-between-privacy-or-security/
Een browserextensie als HTTPS everywhere van EFF lijkt deze privacy problemen te omzeilen met een andere aanpak en standaardisatie mits je dan in een prive modus browst en geen goochelchrome gebruikt.
Vandaar dat een echte privacy browser als Torbrowser, geen gebruik maakt van HSTS maar wel van HTTPS everywhere.
Privacy en security moet je zelf organiseren omdat als je op anderen moet gaan wachten, de jaren die je nog resten ruim tekort schieten.
Hupsacake https://www.eff.org/https-everywhere
Slecht voor je privacy, afhankelijk nog van de soort browser en de configuratie, de ene browser is de andere niet (chrome, tja, chrome).
https://nakedsecurity.sophos.com/2015/02/02/anatomy-of-a-browser-dilemma-how-hsts-supercookies-make-you-choose-between-privacy-or-security/
Een browserextensie als HTTPS everywhere van EFF lijkt deze privacy problemen te omzeilen met een andere aanpak en standaardisatie mits je dan in een prive modus browst en geen goochelchrome gebruikt.
Vandaar dat een echte privacy browser als Torbrowser, geen gebruik maakt van HSTS maar wel van HTTPS everywhere.
Privacy en security moet je zelf organiseren omdat als je op anderen moet gaan wachten, de jaren die je nog resten ruim tekort schieten.
Hupsacake https://www.eff.org/https-everywhere
Om aan te tonen wat Bitwiper meldt een klein voorbeeldje van dit toch vrij grote probleem.
Problemen voor sites die niet automatisch van http naar https redirecten.
Voorbeeld https://urlquery.net/report/6f5decdf-fab5-4adf-9169-4114bf0375fd
Zie: https://aw-snap.info/file-viewer/?protocol=not-secure&tgt=sportvereniging.zeijen.nu&ref_sel=GSP2&ua_sel=ff&fs=1
&
https://aw-snap.info/file-viewer/?tgt=historisch.zeijen.nu&ref_sel=GSP2&ua_sel=ff&fs=0&protocol=not-secure
Kwetsbaar voor MiM aanvallen, X-Powered-By-Header zichtbaar, kwetsbaar voor cross-site aanvallen en versturen van frauduleuze mails.
HEX-geobfusceerde code waarschuwing.
luntrus
Problemen voor sites die niet automatisch van http naar https redirecten.
Voorbeeld https://urlquery.net/report/6f5decdf-fab5-4adf-9169-4114bf0375fd
Zie: https://aw-snap.info/file-viewer/?protocol=not-secure&tgt=sportvereniging.zeijen.nu&ref_sel=GSP2&ua_sel=ff&fs=1
&
https://aw-snap.info/file-viewer/?tgt=historisch.zeijen.nu&ref_sel=GSP2&ua_sel=ff&fs=0&protocol=not-secure
Kwetsbaar voor MiM aanvallen, X-Powered-By-Header zichtbaar, kwetsbaar voor cross-site aanvallen en versturen van frauduleuze mails.
HEX-geobfusceerde code waarschuwing.
luntrus
Stop toch eens met denken voor een ander.
Als iemand naar een http site wil, dan wil hij dat.
Als hij naar http://google.com wil dan wil NIET naar https://www.google.nl
Als iemand naar een http site wil, dan wil hij dat.
Als hij naar http://google.com wil dan wil NIET naar https://www.google.nl
@ anoniem van 17:48
Naar de http://bla de bla dot com versie?
Welk normaal iemand wil dat bij z'n volle verstand als er van een bepaalde site ook nog een veilige verbinding bestaat?
Waarom is het https everywhere initiatief er dan? Voor de kat z'n viool misschien?
Natuurlijk zijn er lieden, die liever een http landschap zien en kunnen bezoeken.
Kun je vaak lekker op rotzooien, want geen veilige c.onnectie, etc.
Voor defacers, scammers aanvaller en mappers van http website servers en dergelijke figuren is het vaak een feest van "Kom maar binnen met je knecht" en daar wil je Tante Truus en Ome Bert, die het verschil tussen http en https niet eens weten en niet weten of een slotje groen of blauw moet zijn, toch niet aan blootstellen?
Kijk eens hier waarom: https://www.eff.org/https-everywhere/atlas/domains/comodo.com.html
Trouwens het niet denken voor of om een ander heeft al een heleboel ellende in de wereld gebracht.
Ben ik mijn broeders hoeder? Volgens velen: "Neen toch natuurlijk ben ik dat niet".
luntrus
Naar de http://bla de bla dot com versie?
Welk normaal iemand wil dat bij z'n volle verstand als er van een bepaalde site ook nog een veilige verbinding bestaat?
Waarom is het https everywhere initiatief er dan? Voor de kat z'n viool misschien?
Natuurlijk zijn er lieden, die liever een http landschap zien en kunnen bezoeken.
Kun je vaak lekker op rotzooien, want geen veilige c.onnectie, etc.
Voor defacers, scammers aanvaller en mappers van http website servers en dergelijke figuren is het vaak een feest van "Kom maar binnen met je knecht" en daar wil je Tante Truus en Ome Bert, die het verschil tussen http en https niet eens weten en niet weten of een slotje groen of blauw moet zijn, toch niet aan blootstellen?
Kijk eens hier waarom: https://www.eff.org/https-everywhere/atlas/domains/comodo.com.html
Trouwens het niet denken voor of om een ander heeft al een heleboel ellende in de wereld gebracht.
Ben ik mijn broeders hoeder? Volgens velen: "Neen toch natuurlijk ben ik dat niet".
luntrus
Waarom zou je voor wat statische informatie wel naar een https site gaan. Omdat er een paar met een alu hoetje opzitten en iedereen maar https proberen op te dringen ?
http en https zijn totaal verschillende dingen behandel ze dan ook als verschillende dingen en stop met het voor een ander denken. STOP IT !!
http en https zijn totaal verschillende dingen behandel ze dan ook als verschillende dingen en stop met het voor een ander denken. STOP IT !!
Door Anoniem: Stop toch eens met denken voor een ander.
Als iemand naar een http site wil, dan wil hij dat.
Als hij naar http://google.com wil dan wil NIET naar https://www.google.nl
Dus als jij je met je auto de sloot in gaat en je dreigt te verzuipen dan hoeft niemand jou te helpen want je zal het wel gewild hebben? En de wegbeheerder had geen vangrail hoeven plaatsen? En zelfs als die wens er dan wel was, heeft de rest dan ook maar te dulden dat jij anderen problemen geeft?Als iemand naar een http site wil, dan wil hij dat.
Als hij naar http://google.com wil dan wil NIET naar https://www.google.nl
Ik maak het met opzet extreem omdat de kern van je boodschap klinkt als die van een egoistisch persoon die denkt alleen op de wereld te zijn.
Ik denk dat we niet te ver moeten doordraven met bekritiseren wat wel en niet goed is. Inderdaad het is uiteindelijk aan de gebruiker en de eigenaar van een website hoe die het systeem inricht of gebruikt binnen de kaders van de wet of andere eisen. Hsts is een hulpmiddel. De TS wil doen geloven dat we niet zonder kunnen en dat zijn manier van denken de juiste is over beveiliging. Je kan het daarmee eens of oneens zijn, maar om te stellen dat we er maar niet over zouden moeten discussieren en iedereen weet wat die doet gaat me te ver. Ik lig er niet wakker van als hsts niet in gebruik is. Het probleem is wel dat het bestaat het niemand lukte om internetters goed te leren wat https is en http historisch als uitgangspunt is genomen omdat men toen nog minder benul had van de risico's van onversleutelde verbindingen, mitm en dat soort dingen.
Waarom zou je voor wat statische informatie wel naar een https site gaan
Een aantal redenen:
- Privacy: misschien je wil niet dat andere kunnen zien dat je artikelen over genitale herpes zit te lezen
- Integriteit: je wilt niet dat een MITM de statische genitale herpes content kan bewerken terwijl naar jou onderweg, waarbij bijvoorbeeld javascript kan worden geïnjecteerd
- Authenticiteit: je wilt zeker weten dat je inderdaad praat met die betrouwbare server die alle info over genitale herpes biedt
stop met het voor een ander denken
Als wij infosec mensen stoppen met voor een ander te denken, zal de 'gewone mens' de dupe zijn aangezien zij gewoon maar verwachten dat alles veilig verloopt.
16-06-2018, 22:04 door
Bitwiper
Dank aan allen voor de reacties!
Dus HSTS heeft, naast nadelen (waaronder vaak onvolledige ondersteuning) t.o.v. https://www.sitenaam.nl/ intikken, ook zeker een voordeel dat ik niet genoemd heb. Nogmaals dank!
Bovendien verschillen Google zoekresultaten per gebruiker. Zelf heb ik, tijdens de tests, alle browser historie (dus ook cookies) weggegooid - waarna Google ineens weer meent dat ik vooral in Nederlandstalige sites geïnteresseerd zal zijn (wat beslist niet zo is), en ik nu zoekresultaten krijg die geheel niet meer door mijn interesses lijken te worden beïnvloed.
Moet je kijken wat er gebeurt als je een keer via op een advertentie-link bovenaan de Google zoekresultaten hebt geklikt - op heel veel pagina's met Google advertenties word je dan aan die eerdere pagina herinnerd - en in mijn zoekresultaten is er dan een duidelijke voorkeur voor vergelijkbare producten.
Kortom, veelbezochte sites buiten beschouwing latend (maar die hebben zelden lastig te onthouden domeinnamen), is het -helaas- noodzakelijk dat je precies weet wat de juiste schijfwijze van een domeinnaam is om te voorkomen dat je op een typosquatting site belandt - overigens steeds vaker met geldig certificaat (maar zelden van het type EV - doordat certificaatuitgevers minder snel geneigd zijn EV certs voor typische typosquattings sites uit te geven, maar vermoedelijk ook omdat de aanvrager veel informatie over zichzelf zal moeten prijsgeven - die wordt gecontroleerd, wat eventuele opsporing natuurlijk aanzienlijk vereenvoudigt).
15-06-2018, 11:11 door Anoniem: Als HSTS actief is voor een website en er vindt een MITM plaats, dan krijgt de gebruiker een melding dat er een mogelijke aanval plaatsvindt (in chrome) maar belangrijker: de melding is niet weg te klikken (in alle browsers die HSTS ondersteunen). De gebruiker kan simpelweg de website niet gebruiken.
Klopt! En hoewel ik dat vast wel eens gezien heb, is dat niet blijven hangen, want ik heb er geen moment aan gedacht en het tot nu toe nergens benoemd :-(Dus HSTS heeft, naast nadelen (waaronder vaak onvolledige ondersteuning) t.o.v. https://www.sitenaam.nl/ intikken, ook zeker een voordeel dat ik niet genoemd heb. Nogmaals dank!
15-06-2018, 11:11 door Anoniem: Beter advies is: tik het domein in google in. Google zal dan netjes de https link tonen (in een tls sessie die uberhaupt niet de MITMen is) wat vele malen veiliger en gebruiksvriendelijker is dan zelf https in de browser intikken.
Daarover verschillen de meningen, want hoewel de meeste banken wel bovenaan de Google zoekresultaten zullen verschijnen, is dat bij kleinere webshops en minder bezochte overheidssites absoluut niet het geval.Bovendien verschillen Google zoekresultaten per gebruiker. Zelf heb ik, tijdens de tests, alle browser historie (dus ook cookies) weggegooid - waarna Google ineens weer meent dat ik vooral in Nederlandstalige sites geïnteresseerd zal zijn (wat beslist niet zo is), en ik nu zoekresultaten krijg die geheel niet meer door mijn interesses lijken te worden beïnvloed.
Moet je kijken wat er gebeurt als je een keer via op een advertentie-link bovenaan de Google zoekresultaten hebt geklikt - op heel veel pagina's met Google advertenties word je dan aan die eerdere pagina herinnerd - en in mijn zoekresultaten is er dan een duidelijke voorkeur voor vergelijkbare producten.
Kortom, veelbezochte sites buiten beschouwing latend (maar die hebben zelden lastig te onthouden domeinnamen), is het -helaas- noodzakelijk dat je precies weet wat de juiste schijfwijze van een domeinnaam is om te voorkomen dat je op een typosquatting site belandt - overigens steeds vaker met geldig certificaat (maar zelden van het type EV - doordat certificaatuitgevers minder snel geneigd zijn EV certs voor typische typosquattings sites uit te geven, maar vermoedelijk ook omdat de aanvrager veel informatie over zichzelf zal moeten prijsgeven - die wordt gecontroleerd, wat eventuele opsporing natuurlijk aanzienlijk vereenvoudigt).
15-06-2018, 11:11 door Anoniem: Wat ik wel sterk vind is je bevinding dat een verbinding met https://www.voorbeeld.nl waarbij de HSTS header aankomt inclusief de 'includeSubdomains' directive, de includeSubdomains dan ALLEEN geldt voor subdomeinen van het huidige subdomein, bijvoorbeeld een hsts header inclusief de includeSubdomains directive op www.voorbeeld.nl geldt enkel voor bijvoorbeeld asd.www.voorbeeld.nl. De includeSubdomains geldt dus NIET voor andere subdomeinen van hetzelfde niveau, bijvoorbeeld: asdf.voorbeeld.nl zal HSTS niet toegepast worden.
Gelukkig zijn lang niet alle oplossingen ingewikkeld en/of prijzig!15-06-2018, 16:23 door Anoniem: Enige probleem met de werkwijze http://nctv.nl -> https://nctv.nl -> https://www.nctv.nl is dat je dus 2 certificaten nodig hebt?
Ja en nee ;-)Ja, het is verstandig om de hoofdsite en elke subsite van een certificaat te voorzien, en dat is een must als je op de hoofsite de directive "includeSubDomains" gebruikt.
Nee, in principe is 1 certificaat genoeg, mits je maar elke domeinnaam erin opneemt. Het certificaat van security.nl is bijvoorbeeld geldig voor zowel "www.security.nl", "secure.security.nl" als "security.nl". Een andere aanpak, zoals bijv. xs4all.nl toepast, is gebruik maken van een wildcard certificaat, namelijk "*.xs4all.nl". Belangrijk om te weten is dat die asterisk slechts voor 1 niveau van subdomains staat, dus "www.xs4all.nl", "service.xs4all.nl" en "webmail.xs4all.nl" kunnen uit de voeten met hetzelfde certificaat, maar het certificaat geldt niet voor bijv. "mijn.service.xs4all.nl".
Een belangrijke overweging hierbij is dat het inzetten van hetzelfde certificaat op meerdere servers (met verschillende domeinnamen) betekent dat op elke server dezelfde private key staat. Als één van die servers gehacked wordt (hoe meer verschillende servers, hoe groter de kans daarop), moet je er waarschijnlijk vanuit gaan dat de private key gestolen is. Tenzij je (grote?) risico's wilt nemen, zul je een nieuw sleutelpaar moeten genereren, een nieuw certificaat moeten aanvragen en op elke server de private key en het certificaat moeten vervangen. Een weloverwogen besluit zou dus kunnen zijn om niet slechts één certificaat in te zetten, maar meerdere.
Je kunt ook overwegen om meerdere wildcard certificaten in te zetten, bijv. van verschillende leveranciers (en met verschillende rootcertificaten). Valt er dan een keer een leverancier om (zoals Diginotar destijds) dan kun je snel schakelen zonder meteen nieuwe sleutelparen te moeten genereren en certificaten te moeten bestellen (een wildcard certificaat is niet per definitie onveilig: dat wordt het pas als je het op meerdere servers inzet, omdat het risico op verlies van de bijbehorende private key toeneemt). Aan de andere kant moet je wel een goede administratie bijhouden welk certificaat waar is geïnstalleerd, want ze lijken allemaal sprekend op elkaar. O.a. fingerprint (meestal een SHA-1 of SHA256 hash over de binaire "ASN.1" versie van het certificaat) verschilt natuurlijk, dus die zou ik als identifier gebruiken.
TERZIJDE: er zijn cloud-hosting-providers die hergebruik van certificaten tot in het extreme doortrekken, zoals ik in augustus vorig jaar meldde in https://isc.sans.edu/forums/diary/Malicious+script+dropping+an+executable+signed+by+Avast/22748/#40100, toen ik ontdekte dat een https server certificaat bleek te zijn uitgegeven voor een enorme reeks sites die helemaal niks met elkaar te maken hadden (behalve, vermoedelijk, een gemeenschappelijk hosting server). Daaronder bevonden zich de counter terrorism site van de Australische overheid (een site met ondertussen een eigen certificaat, maar nog wel mixed content) en een criminele site die malware verspreidde. Aanvankelijk dacht ik dat het om een onterecht uitgegeven certificaat ging, maar dit bleek "volgens de regels" (yeah right) te zijn gebeurd - zie ook het comment van Jana Jurik van CDN77.com onder mijn bijdragen. Een bijzonder trieste zaak dat certificaatuitgevers meewerken aan dit soort praktijken...
Naar aanleiding van jouw vraag vroeg ik mij af hoeveel van de eerder door mij onderzochte servers al een certificaat hebben dat het hoofdomein (zoals nctv.nl) ondersteunt. Dat heb ik vanmiddag en zojuist verder onderzocht, de uitkomsten daarvan zijn als volgt:
Resultaten van mijn tweede onderzoek
Opnieuw uitgevoerd aan de keukentafel, met uitsluitend Firefox ESR - met een "F12 debug window" open. Iedereen kan dit doen lijkt me, en zeker beheerders...
1) Hoofddomeinen met ondersteuning voor https en HSTS
Hier gaat het dus om sites waarbij de beheerders bijna alles goed gedaan hebben, maar een essentieel aspect over het hoofd hebben gezien. Namelijk dat als een bezoeker nctv.nl intikt, en zij daarvandaan meteen naar https://www.nctv.nl/ wordt doorgestuurd, de browser dus nooit https://nctv.nl/ aandoet, en daar dus geen HSTS header van ontvangt. Met als gevolg dat elke volgende keer dat de bezoeker weer nctv.nl intikt, haar verbinding kan worden gekaapt - zonder dat de gebruiker daar foutmeldingen en/of waarschuwingen bij hoeft te ontvangen en de site als twee druppels water op de echte kan lijken. En indien de aanvaller haar doorstuurt naar een erop lijkende domeinnaam, kan deze natuurlijk ook van een geldig certificaat zijn voorzien. Doordat je geldige sites als "gemeentemaastricht.nl" ziet zal het niemand verbazen als je word doorgestuurd naar bijv. https://gemeente_maastricht.nl/ of https://maasticht.nl/ en dat de bezoeker niet weet dat gemeente_maastricht.nl niet van de gemeente Maastricht is resp. over de spelfout in het tweede geval heenkijkt.
Nb. als je als bezoeker de eerste keer (en daarna minstens 2x per jaar) handmatig naar https://sitenaam.nl/ surft, kun je tussendoor redelijk veilig volstaan met het intikken van sitenaam.nl - omdat HSTS daarvan in de HSTS-database van jouw browser is opgeslagen. Wel hartstikke jammer natuurlijk dat bezoekers hier handwerk voor moeten verrichten...
Het gaat hierbij om de volgende sites:
Gemeentes: https://aalsmeer.nl/, https://alblasserdam.nl/, https://breda.nl/, https://delft.nl/, https://denhaag.nl/, https://helmond.nl/, https://lv.nl/, https://woerden.nl/
Overheidwebsites: https://belastingdienst.nl/, https://tweedekamer.nl/, https://overheid.nl/, https://nctv.nl/
Winkels: https://ns.nl/
Beheerders van bovenstaande sites hoeven dus slechts vanuit de https://www.sitenaam.nl/ website de browser op te dragen whatever op te halen vanaf het hoofddomain (https://sitenaam.nl/ dus).
2) Hoofddomeinen met ondersteuning voor https echter zonder HSTS
Deze domeinen sturen (op dit moment) geen HSTS header mee, maar hebben wel een certificaat dat zowel voor minstens www.sitenaam.nl als voor sitenaam.nl geschikt is. Het heeft echter geen zin om af en toe naar https://sitenaam.nl/ te surfen (zoals bij 1 hierboven beschreven), want er wordt niks toegevoegd aan de HSTS database van jouw browser.
Het gaat hierbij om de volgende sites:
Gemeentes: https://alphenaandenrijn.nl/, https://heerenveen.nl/, https://rotterdam.nl/, https://venlo.nl/
Overheidwebsites: https://politie.nl/
Winkels: https://wehkamp.nl/, https://zalando.nl/, https://bol.com/, https://ah.nl/, https://anwb.nl/
Banken: https://binck.nl/, https://icscards.nl/, https://knab.nl/, https://rabobank.nl/
Certificaatverkopers: https://argeweb.nl/, https://combell.nl/, https://globalsign.nl/, https://versio.nl/
Verzekeraars: https://cz.nl/, https://nn.nl/
Om hun sites echt veilig te maken (los van eventuele andere zaken, waar ik nu niet naar gekeken heb), zullen beheerders hetzelfde moeten doen als bij groep 1 hierboven vermeld, maar daarnaast zullen zij het hoofdomein https://sitenaam.nl/ een fatsoenlijke HSTS header moeten laten meesturen (bij voorkeur met "includeSubDomains" daarin).
3) Hoofddomeinen met DEFECTE ondersteuning voor https (een HSTS header krijgt de browser niet te zien)
Deze sites hebben geen geldig certificaat voor het betreffende hoofdomein, maar ondersteunen wel https verbindingen. Daardoor krijg je bij hen (op het moment van schrijven) een certificaatfoutmelding (probeer gerust door erop te klikken):
Gemeentes: https://aalburg.nl/, https://aalten.nl/, https://arnhem.nl/, https://apeldoorn.nl/, https://leidschendam.nl/, https://voorburg.nl/
Overheidwebsites: https://bkr.nl/
Certificaatverkopers: https://symantec.nl/:
symantec.nl uses an invalid security certificate. The certificate is only valid for the following names: symantec.com, norton.com, account.norton.com, careers.symantec.com, customercare.symantec.com, de.norton.mobi, downloads.guardianedge.com, emea.symantec.com, eu.store.pgp.com, jobs.symantec.com, mostdangeroustown.com, mynortonaccount.com, na.store.pgp.com, nortonaccount.com, nortonlearninghub.com, nukona.com, row.store.pgp.com, ssl.symantec.com, store.pgp.com, uk.store.pgp.com, www.account.norton.com, www.emea.symantec.com, www.mostdangeroustown.com, www.nortonaccount.com, www.nortonlearninghub.com, www.nukona.com, www.pgp.com, www.ssl.symantec.com, www.symantec.co.jp, www.symantec.co.uk, www.symantec.fr, www.symantec.de, www.symantec.it, www.symantec.com.au, www.symantec.com.br, www.symantec.mx, www.symantec.es, www.symantec.ca, www.symantec.hk, www.symantec.co.in, www.symantec.tw, www.symantec.sg, lifelock.jobs, www.lifelock.jobs, et.symantec.com Error code: SSL_ERROR_BAD_CERT_DOMAIN
en https://verisign.nl/: verisign.nl uses an invalid security certificate. The certificate is only valid for the following names: verisign.asia, verisign.biz, verisign.ch, verisign.co.in, verisign.co.jp, verisign.co.uk, verisign.com, verisign.com.au, verisign.com.br, verisign.com.cn, verisign.com.es, verisign.com.hk, verisign.com.sg, verisign.com.tw, verisign.com.vn, verisign.de, verisign.dk, verisign.es, verisign.fr, verisign.hk, verisign.in, verisign.info, verisign.jobs, verisign.mobi, verisign.name, verisign.net, verisign.org, verisign.pro, verisign.se, verisign.sg, verisign.tel, verisign.tw, verisign.us, verisign.vn, verisigninc.com, www.verisign.asia, www.verisign.biz, www.verisign.ch, www.verisign.co.in, www.verisign.co.jp, www.verisign.co.uk, www.verisign.com, www.verisign.com.au, www.verisign.com.br, www.verisign.com.cn, www.verisign.com.es, www.verisign.com.hk, www.verisign.com.sg, www.verisign.com.tw, www.verisign.com.vn, www.verisign.dk, www.verisign.es, www.verisign.fr, www.verisign.hk, www.verisign.in, www.verisign.info, www.verisign.jobs, www.verisign.mobi, www.verisign.name, www.verisign.net, www.verisign.org, www.verisign.pro, www.verisign.se, www.verisign.sg, www.verisign.tel, www.verisign.tw, www.verisign.us, www.verisign.vn, www.verisigninc.com Error code: SSL_ERROR_BAD_CERT_DOMAIN
Tot zover het "respect" dat deze laatste twee hebben voor Nederlanders...4) Hoofddomeinen met GEHEEL GEEN ondersteuning voor https, noch voor HSTS (alleen http dus)
Overheidwebsites: https://uwv.nl/: "Unable to connect"
Winkels: https://cena.nl/: "Unable to connect"
Verzekeraars: https://achmea.nl/: "Unable to connect" (terwijl http://achmea.nl/ hoopvol -doch zinloos- meestuurt: "Strict-Transport-Security: max-age=31536000; includeSubDomains")
https://zilverenkruis.nl/: "Unable to connect" (terwijl http://zilverenkruis.nl/ hoopvol -doch zinloos- meestuurt: "Strict-Transport-Security: max-age=31536000; includeSubDomains")
17-06-2018, 00:36 door
Bitwiper
Door Aha: Browsers zouden hier misschien ook een positief aandeel in kunnen hebben door met de opdracht 'new tab' alvast https:// in de url balk te hebben staan.
Vanzelfsprekend (mijn mening) zouden browsers standaard "https moeten praten tenzij anders aangegeven". We zijn hard op weg naar dat moment (en dat kan mij niet snel genoeg gaan).Door Aha: Mij dunkt dat typosquatting minder voorkomt als het adres vooraf wordt gegaan door https:// omdat er om een certificaat wordt gevraagd, of heb ik dat mis?
Cybercriminelen houden er niet zo van om hun identiteit prijs te geven, iets wat in een ver verleden nog nodig was om een certificaat te verkrijgen. Helaas zijn digitale certificaten, over de jaren, enorm in kwaliteit achteruitgegaan - mede als gevolg van prijzenoorlogen.Ten eerste is de betrouwbaarheid waarmee wordt vastgesteld dat de aanvrager geautoriseerd is om dat te doen voor een domeinnaam tot het nulpunt gedaald bij DV certificaten. Ten tweede checken uitgevers van DV certificaten totaal niet of de domeinnaam iets met de, op basis van die domeinnaam, gesuggereerde organisatie te maken heeft. DV certificaatuitgevers vinden dat DNS registrars dat maar moeten doen, maar die hebben dat nooit gedaan (en gaan dat heus niet ineens wel doen). Betrouwbare authenticatie is de primaire taak van certificaatuitgevers, en dat is compleet te grabbel gegooid: door een domeinregistratie te hacken of een BGP hijack uit te voeren, kun je -geheel anoniem- een DV servercertificaat voor een domeinnaam krijgen die helemaal niet van jou is... En om het verhaal compleet te maken, kun je - zowel als eerlijke amateurwebsiteprutser, maar ook als cybercrimineel- certificaten tegenwoordig ook nog eens gratis verkrijgen: geen risico's op "follow the money" dus.
En omdat alleen experts in browsers het verschil kunnen zien tussen DV en OV certificaten, zijn OV (dus ook pre-EV PKI Overheid-) certificaten effectief net zo (on)betrouwbaar.
Kortom, voor zover er typosquatting sites bestaan die nog geen https ondersteunen, verwacht ik dat het aantal daarvan snel zal afnemen. Vooral nu speelgoedcertificaatuitgever Let's Encrypt ook wildcard certificaten ondersteunt: criminelen moeten dan nog wel voor elk typosquatting hoofddomein een certificaat aanvragen, maar kunnen in het subdomein zoveel typosquatten (en/of overtuigende onzin toevoegen) als ze willen. Als ze img.nl weten te registreren, hebben ze maar 1 certiifcaat nodig om ook www.img.nl en mijn.img.nl te ondersteunen. En (geen typosquatting) als ze een domeinnaam als veiligebank.nl zouden registreren, kunnen ze met 1 gratis certifcaat ing.veiligebank.nl, rabobank.veiligebank.nl etc. maken. Joepie (not).
Nerd-puzzle.
In de aanbevolen HTST header configuratie zit een slordige en vooral luie fout. Hint: voor mensen met een echte server, tik in:
cal 1752
Dezelfde fout is namelijk toen ook al gecorrigeerd. En we blijven maar dezelfde fout herhalen! Lui.
In de aanbevolen HTST header configuratie zit een slordige en vooral luie fout. Hint: voor mensen met een echte server, tik in:
cal 1752
Dezelfde fout is namelijk toen ook al gecorrigeerd. En we blijven maar dezelfde fout herhalen! Lui.
Aanvulling voor de mensen die stellen dat je beter kunt Googlen dan zelf domeinnamen intikken: ik wist dat ik nog wel ergens een screenshot van de risico's daarvan moest hebben, deze heb ik zojuist gevonden en geüpload. Zie https://imgur.com/a/HaPEDFy.
Omdat HTTPS everywhere iets vergelijkbaars doet als HSTS (https forceren op sites die jij eerder bezocht hebt, en waarvan HTTPS everywhere heeft "gezien" en onthouden heeft dat zij https ondersteunen), sluit ik niet uit dat dezelfde fingerprinting mogelijk is als je HTTPS everywhere gebruikt (maar daar heb ik geen bewijs voor).
Door Anoniem: HSTS is gevoelig voor browserfingerprinting en tracking.
Ja, en wellicht dat Firefox daarom ook de HSTS database weggooit als je Firefox zo configureert dat deze jouw browsing history weggooit bij afsluiten of handmatig alle historie weggooit. Dus aan privacy winnen - terwijl je tegelijkertijd security - en dus privacy - inlevert...Omdat HTTPS everywhere iets vergelijkbaars doet als HSTS (https forceren op sites die jij eerder bezocht hebt, en waarvan HTTPS everywhere heeft "gezien" en onthouden heeft dat zij https ondersteunen), sluit ik niet uit dat dezelfde fingerprinting mogelijk is als je HTTPS everywhere gebruikt (maar daar heb ik geen bewijs voor).
Door Anoniem:
Door Anoniem: Stop toch eens met denken voor een ander.
Als iemand naar een http site wil, dan wil hij dat.
Als hij naar http://google.com wil dan wil NIET naar https://www.google.nl
Dus als jij je met je auto de sloot in gaat en je dreigt te verzuipen dan hoeft niemand jou te helpen want je zal het wel gewild hebben? En de wegbeheerder had geen vangrail hoeven plaatsen? En zelfs als die wens er dan wel was, heeft de rest dan ook maar te dulden dat jij anderen problemen geeft?Als iemand naar een http site wil, dan wil hij dat.
Als hij naar http://google.com wil dan wil NIET naar https://www.google.nl
Waarom zou het aan jou zijn dat ik geen amfibie voertuig heb en kan zwemmen? En wat voor problemen hebben andere er van als ik naar http://www.google.com wil en niet naar http://www.google.nl , leees helemaaaaaal niets.
Nog stop met denken dat andere problemen hebben en het voor ze oplossen
17-06-2018, 09:59 door
Bitwiper
Door Anoniem: En wat voor problemen hebben andere er van als ik naar http://www.google.com wil en niet naar http://www.google.nl , leees helemaaaaaal niets.
Meestal reageer ik niet op trollen, maar vanwege dit slechte voorbeeld maak ik een uitzondering;-)We leven in een relatief vrij land, maar zelfs Google staat niet toe dat jij het internet afzoekt op http://www.google.nl/ (op die site is namelijk helemaal geen zoekveld te vinden).
Het enige dat die site doet, is jouw browser doorsturen naar https://www.google.nl/. En die site stuurt een HSTS instructie naar jouw webbrowser waarin staat:
Als die hardleerse dwaas jou volgende keer expliciet vraagt om naar http://www.google.nl/ te gaan, moet je dat verzoek negeren en meteen naar https://www.google.nl/ gaan.
De enige reden daarvoor is dat zeer veel eenvoudige geesten de Google zoeksite als startpagina hebben ingesteld (jammer dat niet iedereen dat doet en nog steeds niet iedereen onze browser gebruikt) en/of als ze naar hun bank o.i.d. willen surfen, daar geen bookmark voor hebben maar via Google zoeken naar de link naar hun bank.
Omdat een MITM hen dan heel eenvoudig een valse link kan voorschotelen, zouden wij, Larry Page en zijn medewerkers, niet meer in de spiegel durven kijken als wij hen niet tegen zichzelf zouden beschermen (dat wij dit vooral om economische redenen zouden doen, nl. om te voorkomen dat ISP's -of andere derde partijen- zoekresultaten en/of onze advertenties on-the-fly vervangen door links waar, indien de gebruiker er op klikt, niet wij maar zij geld aan verdienen, is een hardnekkige fabel).
De enige reden daarvoor is dat zeer veel eenvoudige geesten de Google zoeksite als startpagina hebben ingesteld (jammer dat niet iedereen dat doet en nog steeds niet iedereen onze browser gebruikt) en/of als ze naar hun bank o.i.d. willen surfen, daar geen bookmark voor hebben maar via Google zoeken naar de link naar hun bank.
Omdat een MITM hen dan heel eenvoudig een valse link kan voorschotelen, zouden wij, Larry Page en zijn medewerkers, niet meer in de spiegel durven kijken als wij hen niet tegen zichzelf zouden beschermen (dat wij dit vooral om economische redenen zouden doen, nl. om te voorkomen dat ISP's -of andere derde partijen- zoekresultaten en/of onze advertenties on-the-fly vervangen door links waar, indien de gebruiker er op klikt, niet wij maar zij geld aan verdienen, is een hardnekkige fabel).
Veel succes met jouw wens voor een http-gebaseerd web met molochs als Google die daar vanaf willen - om welke reden(en) dan ook!
Is dit wat je wil bij "1) Hoofddomeinen met ondersteuning voor https en HSTS"?
Apache2
000-default.conf:
000-default-le-ssl.conf:
Apache2
000-default.conf:
<VirtualHost *:80>
RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteRule ^/?/(.*) https://%{SERVER_NAME}/$1 [R,L]
</VirtualHost>
RewriteEngine on
RewriteCond %{HTTPS} !=on
RewriteRule ^/?/(.*) https://%{SERVER_NAME}/$1 [R,L]
</VirtualHost>
000-default-le-ssl.conf:
<VirtualHost *:443>
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;"
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/mijnserver/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mijnserver/privkey.pem
</VirtualHost>
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;"
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/mijnserver/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mijnserver/privkey.pem
</VirtualHost>
@de zeer gewaardeerde topic starter, Bitwiper,
Bij de hoofddomein , sub domeinen en tevens voor third party links op hoofd- & subdomein discussie,
kunnen we ook zeker DNS als item niet buiten beschouwing laten.
Het zou op zich al mooi zijn als we een zelfde status zouden kunnen toekennen aan security optimalisatie
in vergelijking tot bijvoorbeeld SEO optimalisatei.
En er is zeker aan solide website security te verdienen.
De Google Safebrowsing en Google's Virus Total inspanningen zijn daar een bewijs van.
Stakeholders en investeerders hebben dus terdege belang bij een zo veilig mogelijke internet website security omgeving.
Dat is beter voor alle partijen inclusief de eindgebruikers, alleen niet wellicht een situatie,
gezocht door scammers, phishers, cloakers.
In het geval van Google ook niet als het hun core business in de weg zit in de non-public cloud.
Doe eens een scan hier: https://dnsdumpster.com/
Overigens symantic.nl is geen certificaatverkoper meer en verwijst op
https://cryptoreport.websecurity.symantec.com/checker/ zelf door naar
https://ssltools.digicert.com/
luntrus
Bij de hoofddomein , sub domeinen en tevens voor third party links op hoofd- & subdomein discussie,
kunnen we ook zeker DNS als item niet buiten beschouwing laten.
Het zou op zich al mooi zijn als we een zelfde status zouden kunnen toekennen aan security optimalisatie
in vergelijking tot bijvoorbeeld SEO optimalisatei.
En er is zeker aan solide website security te verdienen.
De Google Safebrowsing en Google's Virus Total inspanningen zijn daar een bewijs van.
Stakeholders en investeerders hebben dus terdege belang bij een zo veilig mogelijke internet website security omgeving.
Dat is beter voor alle partijen inclusief de eindgebruikers, alleen niet wellicht een situatie,
gezocht door scammers, phishers, cloakers.
In het geval van Google ook niet als het hun core business in de weg zit in de non-public cloud.
Doe eens een scan hier: https://dnsdumpster.com/
Overigens symantic.nl is geen certificaatverkoper meer en verwijst op
https://cryptoreport.websecurity.symantec.com/checker/ zelf door naar
https://ssltools.digicert.com/
luntrus
17-06-2018, 18:14 door
Briolet
Door Bitwiper: Aanvulling voor de mensen die stellen dat je beter kunt Googlen dan zelf domeinnamen intikken: ik wist dat ik nog wel ergens een screenshot van de risico's daarvan moest hebben, deze heb ik zojuist gevonden en geüpload. Zie https://imgur.com/a/HaPEDFy.
Een voorbeeld van een poging om mensen via Google naar een phishing site te sturen stond vorig jaar ook op dit forum (vergelijkbaar met jouw voorbeeld)
https://www.security.nl/posting/540438/Google-advertenties+lokten+Knab-klanten+naar+phishingsite
Door Anoniem: Is dit wat je wil bij "1) Hoofddomeinen met ondersteuning voor https en HSTS"?
Apache2
[...]
Het gaat niet om wat "ik wil", maar om wat de gedachte achter HSTS is: het beschermen van (met name minder ervaren) websurfers tegen MITM aanvallen. Daarbij gaat het overigens niet alleen om cybercriminele activiteiten, in veel landen injecteren ISP's advertenties in http verbindingen (of vervangen ze door andere).Apache2
[...]
Hoe je e.e.a. precies configureert in de door jou gebruikte webserver, ga ik geen uitspraken over doen. Want zoals ik aangaf zijn er meerdere oplossingen mogelijk (redirecten via https://site.nl/ of, in plaats daarvan, vanuit https://www.site.nl/ de browser iets laten ophalen van https://site.nl/), en bovendien ben ik geen Apache/nginx/whatever webserver expert - dus zou ik erin in moeten duiken on aan te geven of een specifieke configuratie verstandig/correct is. En daar wil ik geen tijd in stoppen.
Voor een optimaal veilig domein met subdomeinen v.w.b. HSTS, is het jouw taak on ervoor te zorgen dat de browser van de gebruiker weet dat alle (of evt. een deel van, en dan precies welke) domeinnamen binnen jouw domein https ondersteunen, en het bezoeken daarvan met http onnodige risico's met zich meebrengt voor de gebruiker. Als alternatief kun je zelfs overwegen om jouw site aan te melden op de statische lijst (zie https://hstspreload.org/).
Middels het "F12 venster" van de meeste webbrowsers kun je zien, als je http://site.nl/ opent, of er HSTS headers vanaf https://site.nl/ worden opgehaald. Nb. als MSIE eerder HSTS headers vanaf https://site.nl/ heeft opgehaald, en je opent http://site.nl/, dan liegt MSIE in het netwerktabblad van het F12 venster dat er content van http://site.nl/ wordt opgehaald - terwijl dat onder water vanaf https://site.nl/ gebeurd. Ik raad dan ook niet aan met MSIE te testen (tenzij je tegelijkertijd iets als WireShark draait en kijkt wat er op het niveau van de netwerkinterface gebeurt). Als Firefox (in elk geval de laatste ESR versie) meldt dat iets via http of hsts gebeurt, is dat ook echt zo.
Overigens, als je een verzoek doet voor http://site.nl/ en je die niet in F12 voorbij ziet komen, maar wel https://site.nl/, dan heeft jouw browser vermoedelijk al eerder een HSTS header (van https://site.nl/) ontvangen. Om volledig te kunnen testen (d.w.z. wat er gebeurt als je daadwerkelijk een verzoek voor http://site.nl/ het netwerk opstuurt), zul je alle browserhistorie moeten verwijderen (of tijdelijk HSTS support voor de betreffende webbrowser moeten uitschakelen).
Door Anoniem (luntrus): Bij de hoofddomein , sub domeinen en tevens voor third party links op hoofd- & subdomein discussie, kunnen we ook zeker DNS als item niet buiten beschouwing laten.
Jawel hoor. Het is een wijdverbreid misverstand dat een aanvaller voldoende heeft aan DNS manipulatie om een geslaagde MITM aanval op https te kunnen uitvoeren (hoewel er bij de uitgifte van DV certificaten wel een risico bestaat).Met https zijn er, toplevel, 2 mogelijkheden:
1) Jouw browser heeft verbinding met een server waarvan de domeinnaam in de URL-balk van jouw browser overeenkomt met de (of één van de) domeinnaam (-namen) waar het certificaat geldig voor is en die server toont aan over de juiste private key (nl. degene behorend bij de public key in het certificaat) te beschikken;
2) Niet alles klopt van van wat hierboven staat, waardoor je een certificaatfoutmelding zult zien.
Uitsluitend manipuleren van DNS (of BGP hijacks, of ARP spoofing etc.) betekent geenszins automatisch een geslaagde MITM aanval op een https verbinding naar een webserver met een geldig https server certificaat: daar is gelukkig meer voor nodig!
Een risico bij de uitgifte van DV certificaten is dat de MITM aanval tussen de onderhavige server en de betreffende certificaatverstrekker plaatsvindt. Maar zo'n aanval is lastiger uit te voeren dan eindgebruikers op het verkeerde been zetten, en met deze aanvalstechniek hoor je niet onterecht een EV https servercertificaat te kunnen verkrijgen. Vandaar dat ik DV certificaten speelgoedcertificaten noem.
Door Briolet: Een voorbeeld van een poging om mensen via Google naar een phishing site te sturen stond vorig jaar ook op dit forum (vergelijkbaar met jouw voorbeeld)
https://www.security.nl/posting/540438/Google-advertenties+lokten+Knab-klanten+naar+phishingsite
Dus een niet te verwaarlozen risico. Thanks Briolet!https://www.security.nl/posting/540438/Google-advertenties+lokten+Knab-klanten+naar+phishingsite
@Bitwiper,
Bedankt voor de geruststellende verklaring omtrent de MiM aanvalsmogelijkheden,
die bij nader inzien toch afhankelijk blijken zijn van de mate van solide integriteit van de certificering.
Dit in het geval dat we niet te maken hebben met iets als destijds een DigiNotar fiasco
of staatsactors met een vervalst certificaat (zoals Iran voor zekere *.* google certificaten destijds).
Voor 1 van de voorbeelden, die je hierboven noemt,
zie al de zwakheden hier opgesomd onder het kopje security,
(44 items in totaal daar vermeld): https://sonarwhal.com/scanner/f58ea6e6-675c-4daa-ac8d-5cce295cf2b2
We zijn jammer genoeg helaas nog steeds niet, waar we zijn willen met de "awareness".
luntrus
Bedankt voor de geruststellende verklaring omtrent de MiM aanvalsmogelijkheden,
die bij nader inzien toch afhankelijk blijken zijn van de mate van solide integriteit van de certificering.
Dit in het geval dat we niet te maken hebben met iets als destijds een DigiNotar fiasco
of staatsactors met een vervalst certificaat (zoals Iran voor zekere *.* google certificaten destijds).
Voor 1 van de voorbeelden, die je hierboven noemt,
zie al de zwakheden hier opgesomd onder het kopje security,
(44 items in totaal daar vermeld): https://sonarwhal.com/scanner/f58ea6e6-675c-4daa-ac8d-5cce295cf2b2
We zijn jammer genoeg helaas nog steeds niet, waar we zijn willen met de "awareness".
luntrus
Wat is je dreigings analyse bij het bezoeken van www.security.nl via HTTP - welke vertrouwelijke informatie laat je hier achter ?
Door Anoniem: Wat is je dreigings analyse bij het bezoeken van www.security.nl via HTTP - welke vertrouwelijke informatie laat je hier achter ?
Zie de reactie van 16-06-2018, 15:14 door Anoniem
18-06-2018, 16:56 door
Bitwiper
Door Anoniem: Wat is je dreigings analyse bij het bezoeken van www.security.nl via HTTP - welke vertrouwelijke informatie laat je hier achter ?
Is dat alles wat je kan bedenken na het werk dat ik heb verzet met onderzoekjes en het schrijven van bovenstaande bijdragen? Zijn die werkelijk zo duidelijk dat er geen inhoudelijke vragen over zijn en/of kritiek op bestaat en/of correcties gewenst/noodzakelijk zijn?Maar goed, ik bijt. De kans dat mijn gebruikelijk ISP (xs4all.nl) advertenties of zelfs malware injecteert, lijkt mij klein. Ik schrijf dit echter vanuit het buitenland via een onbekende telefonieprovider (ik heb hier geen WiFi). Ik heb geen idee hoe betrouwbaar die provider is. En zodra ik WiFi heb in dit hotel - hoe betrouwbaar is de beheerder daarvan? Zit ik wel echt op de WiFi van dit hotel -of van iemand die een accesspoint met hetzelfde SSID heeft aangezet? Hoe betrouwbaar is de ISP achter de WiFi?
Een groter risico (vermoedelijk nog steeds beperkt) is dat iemand mijn inloggegevens kaapt. Aangezien ik een uniek wachtwoord gebruik voor security.nl, kunnen ze daarmee nog niet op andere accounts van mij inloggen, dus dat risico beperk ik zelf. Maar ik weet niet of iedereen met een account op deze site even verstandig is.
Sinds je bij security.nl bijdragen van ca. een kwartier oud (helaas) niet meer kunt wijzigen, kan een eventuele kaper van mijn account dat ook nauwelijks. Wel kan een kaper van mijn account namens mij kwetsende en/of (mij of anderen) belachelijk makende nieuwe bijdragen posten of threads beginnen. Ook kan hij mijn wachtwoord wijzigen en wellicht ook (niet gecheckt) mijn e-mail account, waarmee hij (of zij) mijn identiteit op deze site zou kunnen stelen.
En dit is precies waarom het een goede zaak is dat security.nl https gebruikt. En alle andere sites waarvan de beheerders (vaak eindelijk) het licht hebben gezien.
Deze website komt helemaal niet zo slecht uit de bus bij een "quick and dirty" 3rd party cold reconnaissance test:
https://www.htbridge.com/ssl/?id=lmA7WdeP
11 issues qua security best policies -> https://www.htbridge.com/ssl/?id=lmA7WdeP
overeenkomend https://retire.insecurity.today/#!/scan/d7c12753089106518da51f305b8eea865daaa2020e92793a89b4a40a7fdc9ff1
Correlerende kwetsbaarheden volgens Snyk rapport zie:
jQuery@1.7.2 has 2 known vulnerabilities (2 medium).
See https://snyk.io/vuln/npm:jquery for more information.
14 tracking gerelateerde zaken hier (test in beta, overweeg dat): https://privacyscore.org/site/93498/
luntrus
https://www.htbridge.com/ssl/?id=lmA7WdeP
11 issues qua security best policies -> https://www.htbridge.com/ssl/?id=lmA7WdeP
overeenkomend https://retire.insecurity.today/#!/scan/d7c12753089106518da51f305b8eea865daaa2020e92793a89b4a40a7fdc9ff1
Correlerende kwetsbaarheden volgens Snyk rapport zie:
jQuery@1.7.2 has 2 known vulnerabilities (2 medium).
See https://snyk.io/vuln/npm:jquery for more information.
14 tracking gerelateerde zaken hier (test in beta, overweeg dat): https://privacyscore.org/site/93498/
luntrus
Door Anoniem: Wat is je dreigings analyse bij het bezoeken van www.security.nl via HTTP - welke vertrouwelijke informatie laat je hier achter ?
Laat maar, de voorbeelden die je krijgt zijn zover gezocht en niet van deze wereld dat ik me niet kan voorstellen dat men überhaupt nog naar buiten durft zonder invisibility cloak.
Lekker alles via let's encrypt laten lopen.. 1 Hack en 80% van het internet is onveilig.
Enig idee hoeveel procent van de internetters een site bezoeken met bijv. in te geven "nctv.nl" i.p.v. "www.nctv.nl" ?
Voor mij geldt dat ik altijd start met bijv. "www. .....", dus ook: www.nctv.nl
met als enige uitzondering tweakers omdat ik dit toevallig weet.
Ik denk dat het daar ook vandaan komt dat de HSTS header pas wordt meegegeven bij bezoek van www.nctv.nl.
Dit zou ik niet "dramatisch" of "fout" willen noemen. Ik zou liever spreken van beter en minder goed.
Als www.nctv.nl toch het enige subdomein is waar domme bezoekers terecht kunnen.
Want als je een beetje verstand in de kop hebt open je eerst met https en niet met http.
Voor mij geldt dat ik altijd start met bijv. "www. .....", dus ook: www.nctv.nl
met als enige uitzondering tweakers omdat ik dit toevallig weet.
Ik denk dat het daar ook vandaan komt dat de HSTS header pas wordt meegegeven bij bezoek van www.nctv.nl.
Dit zou ik niet "dramatisch" of "fout" willen noemen. Ik zou liever spreken van beter en minder goed.
Als www.nctv.nl toch het enige subdomein is waar domme bezoekers terecht kunnen.
Want als je een beetje verstand in de kop hebt open je eerst met https en niet met http.
Daarom vraagt een website ook voortdurend onderhoud en dienen alle puntjes op de i te worden geplaalst. Is eenmaal verworven code, zoals in dit geval een jQuery bibliotheek, vanwege een bekend geraakte kwetsbaarheid aan vervanging toe, dan moet ie ook worden afgevoerd. In zo'n geval moeten degenen, die verantwoordelijk zijn voor het website onderhoud, dat dan ook doen.
Als er bekende "best policies" bestaan of waar men er weet van heeft, zullen die, in gevallen dat het bij een site noodzakelijk is, ook toegepast moeten worden. Bitwiper haalt daarvan in zijn topic ook wat voorbeelden aan.
Niet omdat de client side security en de server side security elkaar netjes in balans houden, maar gewoon omdat men optimale veiligheid wil leveren, zowel op de server (naamserver/webserver) als met de juiste configuratie en veiligheid op de client.
Maar we werken al binnen een voortdurend steeds groter wordend spanningsveld tussen gewenste security aan de ene kant en de "bijgebogen" methoden ten faveure van bepaalde core business (wat goed is voor Google zien we terug in de chrome browser, denk aan de "diepere"engine toegang, die Giorgio Maone's NoScript niet vanzelf kreeg, NoScript is nog steeds niet portable naar Google Chrome en we moeten ons daar dus behelpen met uMatrix).
Kijk eens eventjes hier: http://www.domxssscanner.com/scan?url=https%3A%2F%2Fwww.security.nl%2Fjs%2Fjquery%2Fjquery.securitynl.js%3F1375791299
Results from scanning URL: https://www.security.nl/js/jquery/jquery.securitynl.js?1375791299
Number of sources found: 117
Number of sinks found: 55
(Deze scanner is wel weer een zeer goed initiatief van Google, ze doen ook goede dingen).
Kijk naar de verdachte looptijd van JavaScript in de code van de af te voeren jQuery bibliotheek:
Het bovenstaande werd gedraaid op een JavaScript unpacker met error rapportage.
Niet "van deze wereld", zou de anoniem van 18:56 zeggen, maar toch goed voor een ticket hier: https://bugs.jquery.com/ticket/11290
Ticket vanwege het algemenere probleem van het "wringen "tussen jQuery selectors en HTML code.
dat via reguliere expressies kan worden opgevangen.
Er is derhalve ook sprake van een xss vulnerability in geval van onverwachte input naar jQuery()
(info credits gaan naar timmywil zie het Bug Tracker commentaar).
Over het algemeen gesproken, al dit soort zaken laten liggen
en niet aanpakken, geeft op den duur een onveiliger internet.
Op het gevaar af om voor een "one trick horse" te worden versleten met het onderzoeken van deze af te voeren jQuery bibliotheken, vind ik dat men dan toch maar purist,moet blijven in zulke gevallen. Vindt je zaken of worden ze gevonden, verhelp die dan.
luntrus
Als er bekende "best policies" bestaan of waar men er weet van heeft, zullen die, in gevallen dat het bij een site noodzakelijk is, ook toegepast moeten worden. Bitwiper haalt daarvan in zijn topic ook wat voorbeelden aan.
Niet omdat de client side security en de server side security elkaar netjes in balans houden, maar gewoon omdat men optimale veiligheid wil leveren, zowel op de server (naamserver/webserver) als met de juiste configuratie en veiligheid op de client.
Maar we werken al binnen een voortdurend steeds groter wordend spanningsveld tussen gewenste security aan de ene kant en de "bijgebogen" methoden ten faveure van bepaalde core business (wat goed is voor Google zien we terug in de chrome browser, denk aan de "diepere"engine toegang, die Giorgio Maone's NoScript niet vanzelf kreeg, NoScript is nog steeds niet portable naar Google Chrome en we moeten ons daar dus behelpen met uMatrix).
Kijk eens eventjes hier: http://www.domxssscanner.com/scan?url=https%3A%2F%2Fwww.security.nl%2Fjs%2Fjquery%2Fjquery.securitynl.js%3F1375791299
Results from scanning URL: https://www.security.nl/js/jquery/jquery.securitynl.js?1375791299
Number of sources found: 117
Number of sinks found: 55
(Deze scanner is wel weer een zeer goed initiatief van Google, ze doen ook goede dingen).
Kijk naar de verdachte looptijd van JavaScript in de code van de af te voeren jQuery bibliotheek:
www.security.nl/js/core.js?1375791299
status: (referer=www.security.nl/js/jquery/jquery.securitynl.js?1375791299)saved 61679 bytes 96d39259b5c00fe90b7668c0e868459f9bc04c4e
info: [script] -www.security.nl/js/jquery/jquery.securitynl.js?1375791299
info: [script] -www.security.nl/js/core.js?1375791299
info: [img]- www.security.nl/image/view/6924/small/spotlight.png
info: [img] -www.security.nl/image/view/7890/small/spotlight.png
info: [img] -www.security.nl/image/view/12498/small/spotlight.png
info: [img] -www.security.nl/images/search.png
info: [img] -www.security.nl/image/view/12493
info: [img] -www.security.nl/image/view/12477
info: [img]- www.security.nl/captcha/captcha.png
info: [decodingLevel=0] found JavaScript
error: undefined variable s
suspicious: maxruntime exceeded 10 seconds (incomplete) 0 bytes
status: (referer=www.security.nl/js/jquery/jquery.securitynl.js?1375791299)saved 61679 bytes 96d39259b5c00fe90b7668c0e868459f9bc04c4e
info: [script] -www.security.nl/js/jquery/jquery.securitynl.js?1375791299
info: [script] -www.security.nl/js/core.js?1375791299
info: [img]- www.security.nl/image/view/6924/small/spotlight.png
info: [img] -www.security.nl/image/view/7890/small/spotlight.png
info: [img] -www.security.nl/image/view/12498/small/spotlight.png
info: [img] -www.security.nl/images/search.png
info: [img] -www.security.nl/image/view/12493
info: [img] -www.security.nl/image/view/12477
info: [img]- www.security.nl/captcha/captcha.png
info: [decodingLevel=0] found JavaScript
error: undefined variable s
suspicious: maxruntime exceeded 10 seconds (incomplete) 0 bytes
Het bovenstaande werd gedraaid op een JavaScript unpacker met error rapportage.
Niet "van deze wereld", zou de anoniem van 18:56 zeggen, maar toch goed voor een ticket hier: https://bugs.jquery.com/ticket/11290
Ticket vanwege het algemenere probleem van het "wringen "tussen jQuery selectors en HTML code.
dat via reguliere expressies kan worden opgevangen.
Er is derhalve ook sprake van een xss vulnerability in geval van onverwachte input naar jQuery()
(info credits gaan naar timmywil zie het Bug Tracker commentaar).
Over het algemeen gesproken, al dit soort zaken laten liggen
en niet aanpakken, geeft op den duur een onveiliger internet.
Op het gevaar af om voor een "one trick horse" te worden versleten met het onderzoeken van deze af te voeren jQuery bibliotheken, vind ik dat men dan toch maar purist,moet blijven in zulke gevallen. Vindt je zaken of worden ze gevonden, verhelp die dan.
luntrus
19-06-2018, 08:41 door
Bitwiper
Door Anoniem: Enig idee hoeveel procent van de internetters een site bezoeken met bijv. in te geven "nctv.nl" i.p.v. "www.nctv.nl" ?
Zelf heb ik daar geen getallen van, maar elke sitebeheerder kan waarschijnlijk in de webserverlogs zien hoeveel mensen via de "zonder www." route binnenkomen. Maar alleen al het feit dat verreweg de meeste sites op www. draaien en daarnaast de moeite hebben genomen om een "zonder www." springkussensite in te richten, geeft m.i. aan dat gebruikers daar kennelijk behoefte aan hebben. Wellicht weten wij, security mensen, marketeers en goedbedoelende systeembeheerders er niet van te overtuigen dat expliciet het protocol meegeven en de domeinnaam van de werkelijke website invoeren het veiligste is.Door Anoniem: Voor mij geldt dat ik altijd start met bijv. "www. .....", dus ook: www.nctv.nl
met als enige uitzondering tweakers omdat ik dit toevallig weet.
Voor mij geldt dat ook. Maar onder mijn bijdrage "https voor leken" hebben critici mij er -volkomen terecht- op gewezen dat de meeste gebruikers dit niet doen. Vandaar mijn onderzoekje en deze draad.met als enige uitzondering tweakers omdat ik dit toevallig weet.
Door Anoniem: Ik denk dat het daar ook vandaan komt dat de HSTS header pas wordt meegegeven bij bezoek van www.nctv.nl.
Dat vermoed ik ook. Maar dan is er wel sprake van een denkfout. Waarom wel HSTS op de main site, maar niet op de jump site?Door Anoniem: Dit zou ik niet "dramatisch" of "fout" willen noemen.
Ik wel. Als je HSTS implementeert doe je dat met een reden. Dat half doen vind ik fout. En veel meer dan de helft van de door mij onderzochte sites doen dit fout, en daarom noem ik de uitkomst van mijn onderzoek dramatisch.Door Anoniem: Als www.nctv.nl toch het enige subdomein is waar domme bezoekers terecht kunnen.
Eens maar marketingmensen vinden dat niet elegant, tikkende mensen zijn lui en het het rootdomein is sowieso van jou. Dus iedereen blij! Helaas heeft een security freak weer wat te zeiken gevonden...Door Anoniem: Want als je een beetje verstand in de kop hebt open je eerst met https en niet met http.
Met verstand heeft dat niets te maken, hooguit met onwetendheid. Als verstand een rol zou spelen, was https de default in webbrowsers en zouden gebruikers expliciet om http moeten vragen voor sites waarvan de naïeve eigenaren en/of beheerders het nut van https nog niet hebben ingezien (en alleen maar hun eigen situatie wegen, niet die van surfers wereldwijd).Bitwiper, je zei eerder dat ncsc.nl hsts wel goed had geïmplementeerd.
Ik zie het beginnen met een http commando 200 GET / (=root) die blijkbaar gelijk is aan (https:)www.ncsc.nl.
En ook lijkt direct de hsts -header mee te worden gestuurd, hoewel deze niet vanaf http behoort te worden verstuurd.
Verder is er geen sprake van een hsts preload site.
Eerlijk gezegd begrijp ik niet helemaal wat daar gebeurt. Is het wel echt in orde volgens wat jij er onder verstaat?
Kun je dit uitleggen?
Ik zie het beginnen met een http commando 200 GET / (=root) die blijkbaar gelijk is aan (https:)www.ncsc.nl.
En ook lijkt direct de hsts -header mee te worden gestuurd, hoewel deze niet vanaf http behoort te worden verstuurd.
Verder is er geen sprake van een hsts preload site.
Eerlijk gezegd begrijp ik niet helemaal wat daar gebeurt. Is het wel echt in orde volgens wat jij er onder verstaat?
Kun je dit uitleggen?
17-06-2018, 19:40 door Bitwiper - Bijgewerkt: 17-06-2018, 20:25 : Voor een optimaal veilig domein met subdomeinen v.w.b. HSTS, is het jouw taak on ervoor te zorgen dat de browser van de gebruiker weet dat alle (of evt. een deel van, en dan precies welke) domeinnamen binnen jouw domein https ondersteunen, en het bezoeken daarvan met http onnodige risico's met zich meebrengt voor de gebruiker. Als alternatief kun je zelfs overwegen om jouw site aan te melden op de statische lijst (zie https://hstspreload.org/).
Zo gemakkelijk werkt dat tegenwoordig niet.
Je moet ten eerste aan een aantal voorwaarden voldoen om op de preload lijst te kunnen komen.
Die voorwaarden worden wel opgesomd in https://hstspreload.org/.
Als je probeert je basisdomein in de preload lijst te zetten, wordt gecontroleerd of je aan de gestelde eisen voldoet.
Zo niet, dan laat hstspreload.org in het rood zien wat er nog niet klopt aan het ingegeven domein om deze in de preloadlijst van browsers op te nemen.
Pas als je aan alle voorwaarden voldoet om in de preloadlijst te kunnen worden opgenomen zal dit worden gehonoreerd in geval je je basisdomein (zonder www e.d.) invult op https://hstspreload.org.
Dat houdt in:
1. je moet een geldig SSL (https) -certificaat hebben geïnstalleerd geldig voor je basisdomein en je subdomeinen.
2. als je bezoeken met http ook accepteert (poort 80) moet je eerst een redirect doen op dezelfde host, dus bijv. van http://domeinnaam.nl naar https://domeinnaam.nl --
3. alle subdomeinen en in het bijzonder het www-subdomein (zoals www.domeinnaam.nl) moet met https werken als er een DNS- record voor bestaat.
4. Plaats een HSTS-header op het basisdomein voor https- verbindingen (voorbeeld: https://domeinnaam.nl) met daarin de volgende variabelen:
a) max-age moet minimaal 31536000 seconden zijn
b) moet includeSubDomains bevatten
c) moet de letterlijke tekst preload bevatten
d) een additionele redirect vanaf je https site moet nog steeds de hsts header bevatten,
en niet de pagina waar je naar toe gaat.
Pas als aan deze voorwaarden is voldaan, kun je op https://hstspreload.org je basisdomein succesvol opgeven voor de preloadlijst die moderne browsers gebruiken.
Hoe ziet dit er dan uit? Bijvoorbeeld zo:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Dit is voor een max-age van 2 jaar die elke keer opieuw in gaat als een bezoeker de betreffende site bezoekt.Je kan je status blijven volgen door nog eens je basisdomein in te vullen op https://hstspreload.org
Dit kan je daar allemaal nalezen in het Engels, maar ik denk dat het goed is er nog eens op te wijzen hoe het werkt
anders leest iemand er wel eens te snel overheen.
Een kleine waarschuwing:
Het is waarschijnlijk dat het een aantal maanden zal duren voordat een nieuwere versie van een browser weet dat je in de preload lijst staat. Dit komt omdat de preload lijst vast in je browser komt te staan, en in chrome moet dit dan ook nog de stable versie zijn. En voordat een nieuwe Chrome browser stable versie uitkomt duurt best even een tijd.
Bovendien moeten de mensen updaten naar de nieuwe stable versie voordat ze de nieuwste preload lijst kunnen gebruiken.
(zie hier weer het belang van updaten)
Maar dan uiteindelijk komt het erin, en heb je het doel bereikt
namelijk dat mensen met up-tp-date browser je bij het allereerst bezoek van je site
niet langer riskant met http kunnen bezoeken, omdat dankzij de hsts preload lijst de browser deze daar automatisch onmiddellijk https van zal maken voordat de verbinding wordt gestart.
Je site correct geconfigureerd in de preload lijst zetten, zet dus de puntjes op de i voor wat betreft bescherming van bezoekers, en met de nieuwe privacy wet houdt "adequaat" beveiligen volgens mij gewoon in dat je hier gebruik van maakt.
Want stel een suffe bezoeker bezoekt de eerste keer je site via wifi of zo met http en treft zonder dat deze dat in de gaten heeft een MITM die naar zijn gegevens vist. Dan kan worden geoordeeld dat een klant dus wel door de nalatigheid van een systeembeheerder er de dupe van is geworden dat hij zijn privee-gegevens aan de verkeerde mensen heeft gegeven.
HSTS is een gangbare security techniek en je site opnemen in de preload lijst volgens mij ook.
Hier kun je vaststellen hoe het https everywhere project zich ontwikkelt: https://www.eff.org/https-everywhere/atlas/
Dus de vraag is zijn er nog "absolute" urls met verwijzingen naar onveilige content (images en scripts)?
luntrus
Dus de vraag is zijn er nog "absolute" urls met verwijzingen naar onveilige content (images en scripts)?
luntrus
19-06-2018, 22:45 door
Bitwiper
Door Anoniem: Bitwiper, je zei eerder dat ncsc.nl hsts wel goed had geïmplementeerd.
Ik zie het beginnen met een http commando 200 GET / (=root) die blijkbaar gelijk is aan (https:)www.ncsc.nl.
En ook lijkt direct de hsts -header mee te worden gestuurd, hoewel deze niet vanaf http behoort te worden verstuurd.
Verder is er geen sprake van een hsts preload site.
Eerlijk gezegd begrijp ik niet helemaal wat daar gebeurt. Is het wel echt in orde volgens wat jij er onder verstaat?
Kun je dit uitleggen?
Zooo jij hebt me even aan het werk gezet zeg! Aanvankelijk had ik wel het bestand "SiteSecurityServiceState.txt" in mijn Firefox profile directory geleegd (dat bestand bevat de HSTS en HPKP security "database" van Firefox), maar ik had niet de cache van Firefox geleegd. Kennelijk had Firefox https://ncsc.nl/ nog in z'n browsercache (en haalt dus niks op van Internet), en kennelijk is dat er aanleiding toe om de HSTS database niet opnieuw bij te werken. Ik dacht dus even dat het tocht niet goed werkte bij NCSC!Ik zie het beginnen met een http commando 200 GET / (=root) die blijkbaar gelijk is aan (https:)www.ncsc.nl.
En ook lijkt direct de hsts -header mee te worden gestuurd, hoewel deze niet vanaf http behoort te worden verstuurd.
Verder is er geen sprake van een hsts preload site.
Eerlijk gezegd begrijp ik niet helemaal wat daar gebeurt. Is het wel echt in orde volgens wat jij er onder verstaat?
Kun je dit uitleggen?
In mijn eerste screenshot https://imgur.com/a/8slMWL6 zie je links in de eerste drie regels dat netjes van http://ncsc.nl/ via httpsncsc.nl/ naar https://www.ncsc.nl/ wordt gesprongen. Rechts zie je ook dat er netjes een HSTS header wordt meegestuurd.
Echter, in de tweede screenshot, https://imgur.com/a/kdeUxHG, zie je dat HSTS disabled zou zijn! Het kostte me wat tijd om daar de oorzaak van te vinden, maar wat mij opviel was dat de tijd achter liep op de ncsc.nl server (vreemd) en dat er rechtsbovenin geen IP-adres te zien was. Deze info kwam dus uit de cache!
Het resultaat in "SiteSecurityServiceState.txt" (na sluiten van Firefox, pas dan wordt dit bestand bijgewerkt) was op dat moment:
www.ncsc.nl:HSTS 0 17701 1560972828797,1,1
cdn.syndication.twimg.com:HSTS 0 17701 2160575347379,1,0
syndication.twitter.com:HSTS 0 17701 2160577512267,1,0
cdn.syndication.twimg.com:HSTS 0 17701 2160575347379,1,0
syndication.twitter.com:HSTS 0 17701 2160577512267,1,0
Mijn denkfout dus, na het legen van de browsercache en van het bestand "SiteSecurityServiceState.txt" werkte alles zoals verwacht, zie mijn derde screenshot: https://imgur.com/a/gGjNkUY en de vierde: https://imgur.com/a/ihrrONs.
De inhoud van "SiteSecurityServiceState.txt" was hierna als volgt:
ncsc.nl:HSTS 0 17701 1560975372824,1,1
www.ncsc.nl:HSTS 0 17701 1560975469126,1,1
cdn.syndication.twimg.com:HSTS 0 17701 2160577893483,1,0
syndication.twitter.com:HSTS 0 17701 2160578190545,1,0
www.ncsc.nl:HSTS 0 17701 1560975469126,1,1
cdn.syndication.twimg.com:HSTS 0 17701 2160577893483,1,0
syndication.twitter.com:HSTS 0 17701 2160578190545,1,0
Toen ik daarna Firefox sloot, weer opende en nogmaals uitsluitend ncsc.nl intikte, werd zoals ik verwachtte geen content meer vanaf de http site geladen, zie https://imgur.com/a/91U2p9w.
Ter vergelijking, in https://imgur.com/a/i7cViRc zie je http://rabobank.nl/ direct naar https://www.rabobank.nl/ springen, https://rabobank.nl/ wordt dus overgeslagen waardoor jouw browser er geen HSTS header van ziet. Aan het bestand "SiteSecurityServiceState.txt" wordt dan ook uitsluitend een regel voor "www.rabobank.nl" toegevoegd, en niet ook een regel voor "rabobank.nl" (voor nctv.nl geldt -helaas- ook nog steeds hetzelfde).
Beantwoordt dat jouw vraag?
PS dank aan Anoniem van 16:35 voor de uitgebreide bijdrage!
Door Anoniem: (luntrus) Hier kun je vaststellen hoe het https everywhere project zich ontwikkelt: https://www.eff.org/https-everywhere/atlas/
Dus de vraag is zijn er nog "absolute" urls met verwijzingen naar onveilige content (images en scripts)?
Ongetwijfeld, maar de meeste (moderne) browsers blokkeren ondertussen (hopelijk) het http deel uit "mixed content", in elk geval zouden er zo geen scripts meer geladen moeten kunnen worden.Dus de vraag is zijn er nog "absolute" urls met verwijzingen naar onveilige content (images en scripts)?
FF
klikklik
https://www.ghacks.net/2018/02/24/firefox-60-https-upgrade-for-mixed-content/
about:config
klikklik
security.mixed_content.block_display_content;true
security.mixed_content.block_active_content;true
security.mixed_content.block_active_content;true
https://www.ghacks.net/2018/02/24/firefox-60-https-upgrade-for-mixed-content/
Ooooo kijk, met die 302 en 301 redirect erbij aan het begin ziet het er ineens veel beter uit.
Dank Bitwiper voor deze verheldering.
En als zijnde anoniem 16:35: graag gedaan hoor.
Mede en vooral door wat er stond op https://hstspreload.org heb ik me meteen bekeerd.
Ik ben nu wel met je eens dat hsts perfect geïmplementeerd moet zijn.
Dank Bitwiper voor deze verheldering.
En als zijnde anoniem 16:35: graag gedaan hoor.
Mede en vooral door wat er stond op https://hstspreload.org heb ik me meteen bekeerd.
Ik ben nu wel met je eens dat hsts perfect geïmplementeerd moet zijn.
@Bitwiper,
Met deze draad, beste Bitwiper, verdien je eigenlijk m.i. een "sticky" hier
en wel als info om af en toe op terug te kunnen grijpen.
Echt een prachtige verhandeling over "hoe heurt het eigenlijk voor https sites".
Dank daarvoor. Zo komt het echt goed "uit de verf".
Ik heb er weer heel wat kennis en inzichten van opgestoken en velen met mij, dunkt me,
luntrus
Met deze draad, beste Bitwiper, verdien je eigenlijk m.i. een "sticky" hier
en wel als info om af en toe op terug te kunnen grijpen.
Echt een prachtige verhandeling over "hoe heurt het eigenlijk voor https sites".
Dank daarvoor. Zo komt het echt goed "uit de verf".
Ik heb er weer heel wat kennis en inzichten van opgestoken en velen met mij, dunkt me,
luntrus
Waarom laadt www.security.nl sneller dan security.nl ?
(als je het extra tikken van www. niet meerekent)
(als je het extra tikken van www. niet meerekent)
21-06-2018, 17:44 door
Bitwiper
Dank aan allen voor de reacties! Ik heb ze niet stuk voor stuk beantwoord; als je het jammer vindt dat ik niet op jouw reactie gereageerd heb, laat dat dan hieronder svp even weten (met datum en tijd van jouw reactie, of herhaal deze desgewenst).
Overigens raad ik iedereen, die meer van web-beveiliging wil weten, aan om met dit F12-venster "te spelen".
Denk er wel aan dat ze soms valkuilen hebben. Firefox laat bijvoorbeeld niet eenduidig zien of content uit de cache komt, zoals ik in deze thread ontdekte. En als HSTS informatie van een site in de HSTS database van MSIE zit, suggereert het F12 venster van MSIE (als je niet expliciet https:// als protocol opgeeft) nog steeds dat er data via http wordt uitgewisseld - terwijl dat niet zo is (te zien in Wireshark, waarvan het ook beslist lonend is -voor gevorderde beveiligers- om je erin te verdiepen).
Welke informatie je precies ziet is afhankelijk van op welk punt tussen zeg maar de netwerkkaart en de HTML renderer wordt afgetapt. Kennelijk zit dat "aftappunt" bij MSIE dichter bij de renderer, dus voordat MSIE in de HSTS database naar de betreffende site heeft gezocht, en op basis daarvan een https- (i.p.v. een http-) verbinding heeft opgezet.
Firefox daarentegen tapt kennelijk ietsje "verderop" af; in het F12 venster daarvan zie je geen http verbindingen als die er in werkelijkheid ook niet zijn.
Door Anoniem: Waarom laadt www.security.nl sneller dan security.nl ?
(als je het extra tikken van www. niet meerekent)
Omdat in het eerste geval een redirect nodig is. Hoeveel tijd het laden van elk onderdeel kost, van welke webservers die content wordt opgehaald en of dat veilig gebeurt, zie je in het F12 "debug" venster (netwerk tabblad) dat de meeste PC webbrowsers standaard aan boord hebben.(als je het extra tikken van www. niet meerekent)
Overigens raad ik iedereen, die meer van web-beveiliging wil weten, aan om met dit F12-venster "te spelen".
Denk er wel aan dat ze soms valkuilen hebben. Firefox laat bijvoorbeeld niet eenduidig zien of content uit de cache komt, zoals ik in deze thread ontdekte. En als HSTS informatie van een site in de HSTS database van MSIE zit, suggereert het F12 venster van MSIE (als je niet expliciet https:// als protocol opgeeft) nog steeds dat er data via http wordt uitgewisseld - terwijl dat niet zo is (te zien in Wireshark, waarvan het ook beslist lonend is -voor gevorderde beveiligers- om je erin te verdiepen).
Welke informatie je precies ziet is afhankelijk van op welk punt tussen zeg maar de netwerkkaart en de HTML renderer wordt afgetapt. Kennelijk zit dat "aftappunt" bij MSIE dichter bij de renderer, dus voordat MSIE in de HSTS database naar de betreffende site heeft gezocht, en op basis daarvan een https- (i.p.v. een http-) verbinding heeft opgezet.
Firefox daarentegen tapt kennelijk ietsje "verderop" af; in het F12 venster daarvan zie je geen http verbindingen als die er in werkelijkheid ook niet zijn.
11-09-2018, 09:59 door
Werkezel
Door Anoniem:
Een aantal redenen:
- Privacy: misschien je wil niet dat andere kunnen zien dat je artikelen over genitale herpes zit te lezen
- Integriteit: je wilt niet dat een MITM de statische genitale herpes content kan bewerken terwijl naar jou onderweg, waarbij bijvoorbeeld javascript kan worden geïnjecteerd
- Authenticiteit: je wilt zeker weten dat je inderdaad praat met die betrouwbare server die alle info over genitale herpes biedt
Als wij infosec mensen stoppen met voor een ander te denken, zal de 'gewone mens' de dupe zijn aangezien zij gewoon maar verwachten dat alles veilig verloopt.
Waarom zou je voor wat statische informatie wel naar een https site gaan
Een aantal redenen:
- Privacy: misschien je wil niet dat andere kunnen zien dat je artikelen over genitale herpes zit te lezen
- Integriteit: je wilt niet dat een MITM de statische genitale herpes content kan bewerken terwijl naar jou onderweg, waarbij bijvoorbeeld javascript kan worden geïnjecteerd
- Authenticiteit: je wilt zeker weten dat je inderdaad praat met die betrouwbare server die alle info over genitale herpes biedt
stop met het voor een ander denken
Als wij infosec mensen stoppen met voor een ander te denken, zal de 'gewone mens' de dupe zijn aangezien zij gewoon maar verwachten dat alles veilig verloopt.
Genietale herpees ? De het tog iedereen ?
02-09-2019, 20:46 door
Bitwiper
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.
