Ik was eigenlijk in de veronderstelling dat dit al jaren gebeurde totdat ik laatst voor een certificaat van el-cheapo een webserver online moest brengen op poort 80... Toen kwam ik erachter dat alle browsers standaard 80 proberen en dan pas 443...
Wat ik ergens vreemd vind omdat ze liggen mierenneuken over self-signed certicaten op je eigen UPS, NAS, telco-modem, printer enzovoorts, maar zelf onder water gewoon eerst een onbeveiligde verbinding op zetten..
Dan heb je toch een onzettende plank voor je kop als browser boer?

Vroeger had ik nog een plugin (ook al iets engs) geinstalleerd die standaard https voor me deed, en op een gegeven moment hoefde ik dat niet meer te installeren... ik dacht laatst dat het misschien standaard geherinstalleerd werd, maar dat was niet het geval.

Nu vraag ik me af hoe vaak ik http geproken heb in de veronderstelling dat ik https sprak dankzij deze droedels van browser fabrikanten.

Onlangs bij iemand die net glas gekregen had, een Sagemcom modem van KPN geconfigureerd. Deze had een geldig certificaat voor, als ik me goed herinner, "mijmodem.kpn" - wat natuurlijk helemaal niet zou moeten kunnen, want met welk exemplaar van dat modem communiceert mijn browser?

Absoluut. Bij Firefox staat het standaard uit maar kun je het in elk geval aanzetten, bij Safari op de allerlaatste iPadOS kon ik zo'n instelling niet eens vinden. Bizar.

De lijst die Brave gebruikt lijkt me overbodig. Men valt al terug naar http als https niet werkt. Dan kan simpelweg altijd eerst https geprobeerd worden.

Nooit naar het slotje gekeken?

Nee, bij banken kijk ik er nog naar, maar op mijn eigen netwerken niet zo.


Ik vroeg me dat ook al af... Zo'n lijst heeft alleen nut wanneer HTTPS ondersteund wordt maar niet zou werken... Maar waarom zou je dan HTTPS uberhaupt draaien als je het niet werkend hebt?

Ik weet niet wat er nog op die lijst staat, maar traditioneel was het altijd een probleem om op shared hosting met https
te werken en er zijn dus shared hosting situaties waarbij er per shared IP maar 1 site https gebruikt en de rest alleen met
http kan werken. Bezoek je dit extra sites met https dan krijg je een certificaatfout en als je die negeert krijg je de verkeerde
site te zien. Dat is natuurlijk niet goed.

Gebruik nu dus HTTPS-Only.

Mij ook. En de gesuggereerde lijst met "http-only" sites is helemaal absurd, want http-only "servers" hoor je eigenlijk alleen nog op niet-publieke netwerken te vinden (waar ze ook ongewenst zijn als je van zero-trust uitgaat, maar je kunt geen ijzer met handen breken; er is nog veel legacy spul). Brave kan niet weten om hoeveel "sites" dat gaat.

Elke zichzelf respecterende website aan het publieke internet ondersteunt ondertussen https (met goed geconfigureerde HSTS).

Met dien verstande dat, als https niet werkt, de mogelijkheid voor de browser om http te proberen uitsluitend mag worden geboden indien:

1) De gebruiker géén protocol heeft gespecificeerd of op een http-link heeft geklikt (de browser moet geen http gaan voorstellen, laat staan proberen, als een gebruiker expliciet om https heeft gevraagd);

2) De domeinnaam niet vóórkomt op de HSTS-preload lijst (https://hstspreload.org/);

3) De browser geen geldige HSTS-entry in diens HSTS-database heeft voor de gegeven doneinnaam;

4) Veiligheidshalve zou een browser, zolang deze draait, die via https verbinding heeft (of heeft gehad) met een website (een specifieke domeinnaam) zonder HSTS ondersteuning, http-links naar diezelfde domeinnaam moeten omzetten in https en de gebruiker niet de keuze geven om te downgraden naar http als https ineens niet meer werkt (bijvoorbeeld omdat een Attacker in the Middle https blokkeert en hoopt dat de gebruiker akkoord gaat met http).

Indien 1) t/m 4) n.v.t. zijn, moet duidelijk aan die gebruiker worden uitgelegd wat de risico's zijn (met name op public WiFi), waarna aan de gebruiker moet worden gevraagd of deze ermee akkoord gaat om http te proberen.

Dat is lang geleden, de meeste browsers ondersteunen SNI (https://en.wikipedia.org/wiki/Server_Name_Indication). Bij TLS v1.3 is dat een beetje een kip-ei-probleem omdat de bedenkers van die standaard willen voorkómen dat een passieve afluisteraar van de netwerkverbinding, vóórdat de verbinding versleuteld is, kan nagaan met welke domeinnaam je probeert te verbinden. Maar het nut daarvan is beperkt omdat de afluisteraar wel altijd het (mogelijk shared) IP-adres van de server ziet.

Dat had, als ik me goed herinner, ermee te maken dat het SSL-protocol (of oudere versies ervan) geen voorziening hadden om de hostnaam als onderdeel van het protocol door te geven. Meerdere hostnamen op hetzelfde IP-adres konden daardoor niet ondersteund worden. Die beperking is op een gegeven moment ondervangen. Dit kan allang het probleem niet meer zijn.

Niet mee eens, het weerbericht kan prima over een http verbinding net als het nieuws, pas als er gevoelige data over de lijn gaat zou je naar https hoeven te gaan.

Het grootste probleem van "terugval op http of slechts via http" een connectie aangeboden krijgen,
(opzettelijk?) vindt m.i. plaats bij gebruik van de Tor-browser.
Dit terwijl Mozilla-Firefox dat toch wel goed geregeld zou moeten hebben.
Ik kan het niet aan Marlinspike vragen. ;)

Hoe zou het daar het beste opgelost moeten kunnen worden?

Vergeet even niet dat Brave ook een 'secondaire' Tor-modus (onveilig en vaak achter de feitelijkheid aanlopend)
aanbiedt en je er ook Torry.io zoekmachine op kan draaien.

Maar dan kun je m.i. ook wel direct je data aan Big Tech afstaan (verkeerde code opgegeven?).

Wie legt het eens even duidelijk uit hoe het in elkaar steekt?

Hoe overtuigen we de meerderheid van de mensheid op Interwebz ervan,
dat men er uitdrukkelijk voor heeft gezorgd, dat anonimiteit en privacy niet meer bestaan
(in een groot deel van deze wereld dan wel te verstaan).

#obserwator

Jaren geleden begonnen sommige internetproviders advertenties toe te voegen aan HTTP-websites. Niet de websites die werden aangepast verdienden aan die advertenties maar die providers. Als ik me goed herinner gebeurde dit onder meer in het Verenigd Koninkrijk. Voor zover mij bekend is dit in Nederland niet gebeurd. Maar over de grens gebeurde het wel degelijk.

Het gaat hier (als het goed is) niet om gevoelige data, en toch is dit een goede reden om HTTPS te gaan gebruiken. Ik denk dat elke website-eigenaar, particulier of zakelijk, pisnijdig wordt van zoiets, het is puur parasitair gedrag.

Mij staat bij dat deze ontwikkeling een van de redenen was om te concluderen dat HTTP niet meer voldoet en om Let's Encrypt op te zetten.

Ik vraag me steeds vaker af wie waarom security.nl bezoekt en, na zoveel jaren https, kennelijk volledig overtuigd van zichzelf, mythes in stand probeert te blijven houden.

Mocht je geen troll zijn maar een nitwit (ook ik ben ooit begonnen), lees dan https://www.security.nl/posting/564452/https+voor+leken (door Bitwiper in 2018).

Doe eens niet zo hooghartig en vertel gewoon waarom het een probleem zou zijn.

Doe eens niet zo op je tenen getrapt en lees de tekst waar ik naar verwees.