"Hola, hola, maar wacht eens eventjes". Velen hebben nog niet meegekregen, dat dit in feite niets zegt over de veiligheid van de websites achter deze veiliger https verbinding.

Scan maar eens hier: https://www.htmlyse.com/htmlyse en hier: https://webhint.io/scanner/ De waarschuwingen en fouten vliegen je vervolgens dan letterlijk aan alle kanten om de oren.

Interwebs stays a dangerous place for the security aware. De overigen staan er waarschijnlijk niet zo erg bij stil en laten zich een toegenomen veiligheidsverhaal graag op de mouw spelden. Ik hoop dat men hier wel beter weet inmiddels.

Deze campagne heeft dus gezorgd voor veiligere verbindingen, maar in zekere zin ook minder transparentie op achterliggende onveiligheid veroorzaakt door slechte configuraties en fouten door web-admins, hosters, cloud-transporteurs.

Ook zal het wel zo zijn dat het Google met een marktaandeel van 97% wel zo goed uitkomt, maar met veilige connecties blijft er nog voldoende security through obscurity over. Ze hebben immers deze https everywhere campagne groot gevoerd
(samen met andere partijen overigens)

luntrus

Maar met HSTS is het een drama, in elk geval bij de top 50 (https://www.alexa.com/topsites).

HSTS is riskant. Eén configuratie foutje op een (sub-)domein, en je kunt gelijk een nieuwe domeinnaam gaan zoeken. Wat bij de betere en waardevollere domeinen niet iets is wat je snel wilt riskeren.

Het ligt aan de browsers. Die bakken in een nieuwe versie mee welke sites https zijn. Het is dus ook een kunstje om ons meer afhankelijk te maken van browsers als Chrome. Die op hun beurt dan weer een "account" vereisen en alles wat je doet in die browser doorgeven aan hun baas.

Het is een machtsmiddel waarom niet voor de grote firma's buigende sites spoedig is gevaarlijk of zelfs geblokkeerd kunnen worden weergegeven. Terwijl je op je server oon gewoon poort 80 dicht kan zetten en geen http connecties meer biedt. Net zoals ik ook al 20 jaar geen telnet service meer heb die luistert. Maar ook dat mijn ssh connectie door niemand geblokkeerd kan worden die op gekleurde fietsjes rijdt.

@ Bitwiper,

Valt inderdaad tegen, zie hier https://w3techs.com/technologies/details/ce-hsts/all/all
Je komt niet hoger dan ca. 8 % uit.

Maar in dit geval zien we ook geen gezamenlijke inspanningen van google met EFF e.d.

luntrus

FUD. Niemand verplicht je om de directive IncludeSubDomains te gebruiken, en bij twijfel of je alles voor elkaar heb kun je met een korte TTL (Time To Live) van bijv. 86400 seconden (24 uur) of nog korter beginnen.

Gewoon niet waar. Je moet zelf jouw site opgeven voor de "HSTS preload list" en je schijnt er best moeite voor te moeten doen om op die lijst te komen. Als je de "preload" directive weglaat in jouw HSTS headers, kom je echt niet spontaan op die lijst.

HSTS heeft wel een ander nadeel: het maakt tracking van gebruikers mogelijk. Maar ik denk dat dit nadeel niet opweegt tegen het voordeel, nl. dat het SSL-strip (AKA TLS-strip) aanvallen meestal lastiger maakt.

Voorwaarde daarbij is dat je ook redirects goed configureert (iets dat ook bij veel top-Alexa sites fout gaat). Ik beschrijf eerst het http verleden:

Gegeven: de meeste website domeinnamen beginnen met www. (of een ander voorvoegsel) zoals www.example.com.

Probleem: iedereen adverteert met "example.com" dus dat is wat 99,9% (gokje, overdreven wellicht) van de surfers in hun URL balk invoert. De browser zal dan een DNS lookup doen van "example.com" en, als er een IP-adres als antwoord ontvangen wordt, een TCP verbinding opzetten naar poort 80 (http) op dat IP-adres, onder vermelding van "verbind mij met http://example.com/".

Fix: maak (naast http://www.example.com/) een tweede webserver, http://example.com/, die de browser van de bezoeker doorstuurt naar http://www.example.com/ (middels een redirect, aangegeven met "->"):
Dus: http://example.com/ -> http://www.example.com/

Toen kwam het https tijdperk.

Probleem: browsers gaan er -helaas- nog steeds vanuit dat je http bedoelt als je geen andere protocol identifier intikt. En van http wilden we nou juist af omdat het zo kwetsbaar is voor afluisteren en manipulatie door MITM (Man In The Middle) aanvallers - een koud kunstje op bijv. public WiFi of als jouw router gehacked is (voorbeeld: https://www.security.nl/posting/575748/Gehackte+MikroTik-routers+sturen+verkeer+door+naar+aanvallers). En 99.9% van de gebruikers tikt geen https:// vóór de afgekorte URL's die zij intikken (zie https://www.security.nl/posting/564452/https+voor+leken). Kortom, gebruikers tikken nog steeds "example.com" en browsers maken daar nog steeds http://example.com/ van.

Een deel van de site admins die op https overstappen, implementeert helemaal geen HSTS headers (m.i. onverstandig). Verreweg de meeste site admins die hun sites wel HSTS headers laten meezenden, gebruiken hun hersens niet en vergeten een cruciaal aspect (Alexa top 50, maar ook belangrijke/veelbezochte sites in NL, zie https://www.security.nl/posting/566101/NL%3A+veel+brakke+https+sites). Want hun setup is meestal zo dat de browser geen HSTS header ontvangt van de site waar zij de domeinnaam van intikken, waardoor zij elke keer opnieuw kwetsbaar zijn voor MITM aanvallen (zie de laatstgenoemde URL voor meer info).

TLDR:
FOUT: http://example.com/ -> https://www.example.com/ [+ HSTS header]
De browser ontvangt zo geen HSTS header van example.com. Beide volgende oplossingen zijn goed:
1) http://example.com/ -> https://example.com/ [+ HSTS hdr] -> https://www.example.com/ [+ HSTS hdr]
2) http://example.com/ -> https://www.example.com/ [+ HSTS hdr] + get https://example.com/1x1.gif [+ HSTS hdr]

P.S. een HSTS header die je meestuurt vanaf een http site wordt door de browser genegeerd (omdat deze voor een ander protocol bedoeld is, en omdat een MITM aanvaller zo'n header eenvoudig on-the-fly kan verwijderen uit een http antwoord, maar niet uit een https antwoord - dat versleuteld is en wijzigingen in de "stream" hoort te detecteren en melden).

@ Bitwiper, +1 - dank voor je uiteenzetting.

Wat vind je van de nieuwe google chrome setting zonder https// en www? Nu slechts nog donker slotje met domein naam.
Is dit weer niet nog meer "security through obscurity" of weer opnieuw een concessie aan de "domme onwetende klikmassa"?

Ook luntrus snapt het niet, eerst vol inzetten op https-everywhere en dan volledige adressen in browser niet meer tonen. In de balk verschijnt https:// nog wel, namelijk op de tab als die laadt.

Voor controle op het certificaat (en wie van de browser-gebruikers doen dat allemaal?), moet je eerst via Ctrl + Shift+I naar "inspecteren" en dan naar "security" (en daar naar "security overview") en later eventueel naar tabje "https everywhere" om de pagina te herladen in HTTPS Switch Planner modus om zo veel mogelijk mixed content herschreven te kunnen laden. Check eventueel hier https://www.eff.org/https-everywhere/atlas/

Ten slotte merk ik op: "Wil je ergens op kunnen rekenen, reken dan vooral op jezelf". Maar ja, we blijven roependen in de woestijn, vooral wat betreft HSTS en HSTS-pre-loading. Check hier https://hstspreload.org
Met dank aan Scott Helme voor zijn campagne ter bevordering van HSTS.

luntrus