Google Chrome gaat websites volgend jaar standaard via Https laden

Google Chrome gaat websites vanaf oktober 2026 standaard via Https laden. Google zet vanaf versie 154 de instelling om altijd beveiligde verbindingen te gebruiken aan. Gebruikers worden gewaarschuwd als zij een niet-beveiligde website proberen te bezoeken.

Google introduceerde de instelling om altijd beveiligde verbindingen te gebruiken in 2021 en schrijft nu dat het tijd is om deze standaard in te schakelen. Door deze instelling laadt Chrome websites altijd standaard via Https. Wanneer er geen Https-versie beschikbaar is, waarschuwt Chrome gebruikers via een melding.

Google waarschuwt dat hackers HTTP-verbindingen kunnen onderscheppen om zo aanvallen uit te voeren met onder meer malware en social engineering. Bovendien krijgen veel gebruikers volgens Google geen melding van onbeveiligde HTTP-verbindingen, omdat HTTP-websites direct doorverwijzen naar Https-websites. Daardoor krijgen gebruikers geen waarschuwing te zien en kunnen ze zich niet beschermen.

Volgens Google is de adoptie van Https de laatste jaren gestagneerd. In 2015, toen Google begon met het bijhouden van het gebruik van Https, was 30 tot 45 procent van de verzoeken binnen Chrome via Https. Sinds 2020 ligt dat op 95 tot 99 procent.

Reacties (112)

[supersnathan94]

Als je in 2025 nog geen HTTPS gebruikt, met alle gratis en geautomatiseerde oplossingen zoals Let's Encrypt, dan leef je eigenlijk onder een digitale steen. Deze stap van Google is op zich meer dan terecht.

Ik ben echt niet de grootste fan van Chrome’s dominantie, maar hier hebben ze gewoon gelijk. HTTP is anno nu gewoon niet meer te verantwoorden, tenzij het om lokaal development of een volledig afgesloten testomgeving gaat. Voor de rest: versleutelen of verdwijnen.

[Alxndr]

Ik leef blijkbaar onder een steen, ik dacht dat alles tegenwoordig al automatisch over https ging.

De campagne dat je naar het slotje in de adresbalk moet kijken is toch al bijna 10 jaar oud?

Dit bericht bevat me dan ook heel erg, of ik snap het gewoon niet?

[supersnathan94]

Ik leef blijkbaar onder een steen, ik dacht dat alles tegenwoordig al automatisch over https ging.

Dat is een heel logische reactie eigenlijk, want voor de meeste gebruikers lijkt alles inderdaad al via HTTPS te lopen. En in de praktijk is dat ook grotendeels zo: meer dan 95% van alle Chrome-verkeer gebruikt inmiddels HTTPS volgens Google.

Wat Google nu doet, is het laatste stukje “default security” afdwingen:

• Tot nu toe probeerde Chrome HTTP eerst, en werd je pas doorgestuurd naar HTTPS als de site dat zelf aangaf via redirects (HTTP 302).
• Vanaf versie 154 (oktober 2026) probeert Chrome altijd eerst HTTPS, en toont een waarschuwing als er geen beveiligde versie beschikbaar is.

Dat slotje waar je het over hebt (tegenwoordig vervangen door een pictogram van een instelling of globe) was onderdeel van die bewustwordingscampagne ja, maar browsers vertrouwden nog steeds op de site zelf om HTTPS te forceren via zogeheten HSTS (HTTP Strict Transport Security).

Met deze wijziging neemt Chrome dat stukje veiligheid dus over aan de browserzijde. Je hoeft straks niet meer te hopen dat de sitebeheerder alles goed heeft ingesteld: Chrome gaat er standaard vanuit dat de beveiligde variant de bedoeling is.

Je heb grotendeels gelijk, bijna alles gaat al via HTTPS, maar dit is de stap die ervoor zorgt dat ook config fouten en nalatigheid eruit worden gehaald. Default HTTPS eerst

[Gbuz]

Er is ook zoiets als een HSTS preload list. Websites kunnen hiermee aangeven dat ze alleen over https mogen geladen worden.

In dat geval gaat Chrome, ook vandaag al, de website onmiddellijk over https laden. Dus Chrome gaat niet altijd HTTP eerst proberen.

[supersnathan94]

Dat klopt, maar dat is nu dus overbodig doordat het by default gebeurt. Scheelt weer een waslijst aan data die je wel gewoon op je lokale apparaat moet hebben, voor websites die je waarschijnlijk nooit bezoekt.

edit:
overigens is die lijst echt heel klein in verhouding met de miljoenen websites er op het web zijn en is het eigenlijk een wassen neus mbt veiligheid:

I want to call out a couple of things. Only eight of the top twenty domains are on the Chrome HSTS preload list. Half aren’t using HSTS at their apex domain at all. Yahoo and OpenAI are using the HSTS headers, but they aren’t on the preload list.

HSTS preload adoption and challenges | APNIC Blog

het doet iets, maar deze HTTPS als eis doet veel meer.

[Reactie gewijzigd door supersnathan94 op 29 oktober 2025 22:39]

[!GN!T!ON]

Dat ze zelf overigens ontmoedigen quote van je gelinkte pagina:

While HSTS is recommended, HSTS preloading is not recommended

[Alxndr]

top uitleg, thnx.

Ik had alleen verwacht dat 'eerst https proberen' al jaren de standaard was, dat klinkt zo makkelijk/logisch - afhankelijk zijn van webmasters die goede 302's instellen lijkt me iets wat je niet zou moeten willen.

[supersnathan94]

Nouja. Volgens mij is chrome nu de laatste die het doet. Maar wel de grootste. Safari en FF hebben het al sinds eind vorig jaar dacht ik.

[_Pussycat_]

Ik krijg volgens mij ook al sinds jaren enorme waarschuwingen met héél kleine knopjes "more options -> I understand the risk" of zoiets bij non-https sites.

[Mijzelf]

Volgens mij is dat bij een https site met een invalide of self-signed certificaat.

[SillieWous]

Dat vind ik prima te verantwoorden voor bijv. persoonlijke websites die alleen content serveren.

[bzzzt]

Zelfs dan is het geen goed idee. Iedere tussenpartij (ISP, fake wifi hotspot, gecompromitteerde router) kan je traffic onderscheppen en manipuleren en daarmee bijvoorbeeld injection aanvallen op je browser doen zonder dat je het door hebt.
En als je ook maar iets van access control op die persoonlijke website wil hebben is het helemaal geen goed idee je traffic inclusief password of token zichtbaar is.

[_Pussycat_]

Mwah, ik gebruikte bij een soort buienradar lange tijd http omdat https langzamer was. Het risico dat iemand de plaatjes op de buienradar manipuleert valt wel mee denk ik.

[R_Zwart]

Bijzonder, zo'n reactie op Tweakers. Zodra een bedrijf in het nieuws komt die om wat voor reden dan ook last hebben van een vulnerability worden ze voor van alles en nog wat uitgemaakt tot aan dat er veel zwaarder gestraft moet worden.

En tweakers zelf gebruiken vrijwillig onveilige systemen.

[_Pussycat_]

Door mij worden ze voor niks uitgemaakt. Ik weet niet wat er gebeurd is en moet zelf vaak genoeg kiezen tussen een te dure en een te slechte oplossing. Ik begrijp ook dat oneindig veel geld uitgeven aan één probleem geen manier is om een bedrijf te runnen.

Andere tweakers hebben daar idd andere meningen over.

[Reactie gewijzigd door _Pussycat_ op 29 oktober 2025 14:19]

[DJ Henk]

De echte Tweaker snapt dat het niet dom zwart-wit is. Het is niet dat alles met HTTPS goed is en al het andere slecht. Het nadeel van HTTPS is dat je macht overdraagt aan een andere partij, of dat je zelf een certificaat in elkaar moet gaan knutselen, wat vervolgens ook niet zomaar door alle clients geaccepteerd wordt.

Simpel voorbeeld: ik heb hier op mijn NAS Miniflux draaien, een RSS-reader. Gewoon over HTTP en dat is veilig genoeg, want zonder Wireguard VPN kom je überhaupt mijn interne netwerk niet op.

Stel nu dat mijn browser dat niet accepteert, dan wordt het opeens een stuk moeilijker. Want Let's Encrypt biedt wel gratis certificaten, maar om die te krijgen zal ik die Miniflux (of een proxy) eerst van buiten toegankelijk moeten maken en een domeinnaam moeten koppelen. Los van dat ik er geen zin in heb, maakt dat de boel zeker niet veiliger.

En dan hebben we het nog niet over dat ik de toegang van mijn eigen laptop naar mijn eigen NAS nu afhankelijk heb gemaakt van de goedkeuring van een vage buitenlandse partij die niet per se het beste met mij voor heeft. Op dit moment hebben ze natuurlijk een prima reputatie, maar we hebben gezien hoe snel dat kan omslaan als een of andere mafketel in het Witte Huis zijn hamburgers te laat geserveerd krijgt.

En dat alles omdat een paar pipo's van een ander bedrijf dat niet per se het beste met mij voor heeft besloten hebben dat het ene 'veilig' is en het andere 'onveilig'.

[supersnathan94]

Je kunt dit allemaal vrij “eenvoudig” zelf in eigen beheer draaien met iets als CaddyServer. Kost niks en qua tijd is het ook verwaarloosbaar.

[Yggdrasil]

Caddyserver gebruikt toch ook Let's Encrypt? Ja, het aanvragen en vernieuwen van certificaten is eenvoudig daarmee maar je bent nog steeds afhankelijk van een externe partij (LE) en moet nog steeds je webserver open zetten voor de buitenwereld (voor het serveren van de LE challenge/response van HTTP01 validatie) of je moet Caddyserver koppelen aan een externe DNS-server met een door Caddyserver ondersteunde API voor DNS01 validatie. Het is niet super moeilijk allemaal, maar je bent gedwongen afhankelijk van een of meer externe partijen omdat je browser dat eist. Dat is denk ik waar @R_Zwart op doelt.

[lenwar]

Klopt, maar malafide drukken code injecteren des te meer.

Het is een ding om iemand te pesten met een verkeerde site. Maar die tijd is lang geleden.

Het is al jaren zo, dat malware een businessmodel voor fraude en oplichting is.

[supersnathan94]

Als je Comcast, Airtel of BT als provider hebt dan zullen ze daar gewoon ads en JavaScript op injecteren. De inhoud van je pagina doet er niet toe.

Ook tracking cookies worden daar op toegevoegd zonder dat je daar wat aan kunt doen.

[supersnathan94]

Dat argument hoor je vaker, maar ook alleen content serveren is geen vrijbrief meer voor HTTP.
Zelfs een eenvoudige blogpagina kan via een onbeveiligde verbinding worden onderschept of aangepast door derden. Denk aan injectie van advertenties, tracking scripts of zelfs malware door tussenliggende partijen (wifi-netwerken, proxies, ISP’s).

HTTPS gaat allang niet meer alleen over “gevoelige data”, maar over integriteit en vertrouwen. Het zorgt ervoor dat wat jij publiceert, ook echt zo bij de bezoeker aankomt. En dat kost letterlijk niks meer om te implementeren. Als het nou ingewikkelde processen en dure certifcaten zou kosten had ik je nog gelijk gegeven, maar het is gewoon vrijwel gratis te doen. Veel hostingpartijen bieden het zelfs al aan voor nop.

[DdeM]

Kleine caveat dat je dan ook wel een HSTS policy moet hebben en echt geen http verkeer moet toestaan, anders is een MITM nog steeds mogelijk.

[supersnathan94]

HSTS hoeft niet meer als je default altijd HTTPS doet als browser. Vanaf versie 154 probeert de browser altijd eerst HTTPS en toont hij een waarschuwing bij HTTP, waardoor de klassieke downgrade attack eigenlijk niet meer lukt tenzij de gebruiker het negeert of handmatig doorklikt.

HSTS blijft uiteraard best practice voor compatibiliteit met andere browsers (zeker voor sites met inlog of gevoelige data), maar het doel van deze wijziging is juist om die bescherming standaard te benaderen, ook voor sites die zelf geen HSTS-header hebben ingesteld.

[!GN!T!ON]

Klein verschil met de default HTTPS eerst, en HSTS, is dat Chrome (et al.) bij die eerste wel een waarschuwing tonen, maar je als gebruiker nog wel op ''negeer dit, ga verder' kan klikken, en bij HSTS de browser zegt bekijk het maar. Dus niet alleen voor compatibiliteit is HSTS nog aan te raden, het biedt ook nog een extra security mechanisme.

[Aloy]

Ook met HSTS kan je er nog door als gebruiker, je hebt er alleen geen knop voor. Als je “thisisunsafe” intypt (er is geen invoerveld voor, gewoon intypen met de focus op de pagina) dan gaat de browser ook door de waarschuwing heen.

[!GN!T!ON]

Dat is een leuke die ik niet wist :)

[necessaryevil]

HSTS hoeft niet meer als je default altijd HTTPS doet als browser. Vanaf versie 154 probeert de browser altijd eerst HTTPS en toont hij een waarschuwing bij HTTP, waardoor de klassieke downgrade attack eigenlijk niet meer lukt tenzij de gebruiker het negeert of handmatig doorklikt.

AJe kunt niet op de gebruiker vertrouwen, dus het is nog mogelijk! DZe gemiddelde gebruiker snapt hier de ballen niet van, en zeg nou eerlijk, we worden met z'n allen zo hard oversopeld met onleesbare overeenkomsten en andere vage waarschuwingen dat ik denk dat veel tweakers ook gewoon welleens perongeluk op ja drukken.

[supersnathan94]

we worden met z'n allen zo hard oversopeld met onleesbare overeenkomsten en andere vage waarschuwingen dat ik denk dat veel tweakers ook gewoon welleens perongeluk op ja drukken.

Ik durf te wedden dat wij significant vaker zomaar op ja drukken omdat wij "denken" wel de risico's in te kunnen schatten.

[Paul]

Met MITM kan je server nog zo weinig doen met HTTPS, die man in the middle heeft jouw server niet nodig, die vangt het request op en geeft antwoord. Dat request hoeft helemaal niet bij jouw server te komen om de hacker de kans te geven antwoord te geven.

HSTS dwingt HTTPS af op vervolgbezoeken, niet op het eerste verzoek (tenzij je HSTS Preload gebruikt, en daar staat LANG niet alles in), dus zolang je browser HTTP probeert heeft de MITM de optie het antwoord te bewerken.

Dit moet echt aan de kant van de browser opgepakt worden, om het risico van MITM uit te sluiten moet de browser gewoon geen HTTP meer doen.

[TheVivaldi]

Ik ook. Voor een simpele persoonlijke website is dat niet echt nodig. En bovendien zijn er nog genoeg oude (persoonlijke) websites in de lucht die allang niet meer worden bijgewerkt (of kunnen worden bijgewerkt), maar wel waardevol zijn.

[supersnathan94]

of kunnen worden bijgewerkt

Die moet je even uitleggen. TLS bovenop je infra heeft niks te maken met de website zelf.

En bovendien zijn er nog genoeg oude (persoonlijke) websites in de lucht die allang niet meer worden bijgewerkt (of kunnen worden bijgewerkt), maar wel waardevol zijn.

misschien tijd ze dan maar te archiveren bij web archive en dan de stekker er uit? Als er toch niks nieuws meer bij komt kan dat wel op een centrale manier veilig geregeld worden toch?

[sambalbaj]

Je bent ook via archive stukken beter vindbaar als de originele site nog bestaat.

Anders moet je het echt weten en daarop zoeken.


Maar prima stap natuurlijk van Google anno nu.

Naast een waarschuwing zouden ze de optie mogen geven om een archiefpagina te laden.

[ToolBee]

Zoals firefox al jaren doet...

[lenwar]

YouTube: Here's Why Your Static Website Needs HTTPS

Troy Hunt (ik weet het, maar hij heeft hier wel gelijk 😄), laat hier het simpel zien, waarom je dan wel moet doen.

[Cyberpuppy]

Natuurlijk. Voor een groot gedeelte klopt dit. Echter beheren wij ook switches en IOT apparatuur. Die is lang niet altijd in staat een HTTPS te leveren. Danwel is er geen geldig certificaat. Moet natuurlijk wel mogelijk blijven ook dit soort webinterfaces te bezoeken.

[Jordy141]

Je krijgt in dat geval van chrome een waarwchuwing dat het geen https is, maar wel nog de optie om door te gaan.

Het is niet zo dat Chrome het bezoeken van http-sites nu onmogelijk maakt, alleen dat het standaard https probeert en als dat niet kan een waarschuwing geeft dat het een onbeveiligde verbinding is, met de optie om alsnog door te gaan.

[supersnathan94]

Nee precies, maar die hangen hoop ik ook niet direct aan het internet?

Maar dat is dus wel wat ik versta onder lokaal "development" en beheer

[R_Zwart]

Of het direct aan het internet hangt is helemaal niet meer relevant mbt security. Als je bijvoorbeeld naar een 5G netwerk kijkt: daarvan hangt niets aan internet, maar alle interne interfaces zijn op basis van https.

[supersnathan94]

Of het direct aan het internet hangt is helemaal niet meer relevant mbt security

Nouja het is wel relevant voor de attack vector, maar je bedoel meer dat het geen vereiste meer is om wel gewoon TLS toe te voegen op je interfaces?

[Jeoh]

Reverse proxy er voor.

[Cyberpuppy]

Tuurlijk. Iedere MKB klant met 1 switch gaan we dit voor inzetten.

[Brummetje]

Zou ik ook niet zo snel doen maar het is ook niet alsof dat uren werk is.

[p0linskie]

Maar je kunt ala ITer toch gewoon naar je IP en dan :80 erachter?

[himlims_]

begrijp oprecht niet waarom het een harde eis is - zolang er geen user-input is, of scriptjes die toegankelijk zijn, is risico praktisch 0

[supersnathan94]

Nou dat is het dus absoluut niet. Iedere speler op de lijn kan het verkeer onderscheppen en aanpassen. Kinderlijk eenvoudig te doen met een raspberry PI bijvoorbeeld.

bzzzt in 'Google Chrome gaat websites volgend jaar standaard via Https laden'

supersnathan94 in 'Google Chrome gaat websites volgend jaar standaard via Https laden'

Het is echt niet slim.

[SoftwareGert]

Praktisch risico is nog steeds nul voor veel persoonlijke sites.

Theoretisch heb je gelijk, en is het niet aan te raden, maar net als met risico management binnen bedrijven is het een “it depends”.

Daarnaast is er een gelaagdheid die op orde moet zijn, en je kan wel HTTPS forceren, maar er zijn genoeg andere wegen om alsnog een corrupte CA te installeren op diverse systemen, of om mensen op akkoord te laten klikken.

[supersnathan94]

Praktisch risico is nog steeds nul voor veel persoonlijke sites.

Tsja dat zeggen mensen ook van het gebruik van windows XP/7/8/10 na de EOL datum. Ga jij het er op gokken? Klopt dat het praktisch risico voor veel persoonlijke sites klein kan lijken, maar dat is vooral omdat de kans en de impact laag lijken, niet omdat het technisch veilig is. HTTPS kost tegenwoordig praktisch niks (Let’s Encrypt + automatische renewal) en voorkomt niet alleen dat gegevens worden afgeluisterd maar vooral dat jouw site door derden wordt aangepast (injecties, malvertising, trackers).

Ja, “it depends”: als je bezoekers in een streng beheerde omgeving zitten (company laptops met locked-down CA-stores) of het om puur lokaal devwerk gaat, zijn uitzonderingen verdedigbaar. Maar veel aanvalspaden die je noemt (corrupte CAs, social engineering om beveiligingswaarschuwingen te negeren), zijn precies waarom je liever wél HTTPS + HSTS gebruikt: het verhoogt de drempel voor aanvallers en vermindert menselijke fouten.

Praktisch risico ≠ acceptabel risico. Voor persoonlijke sites is de investering verwaarloosbaar; de mogelijke benefit (integriteit + vertrouwen) maakt het de moeite waard.

[SoftwareGert]

De mogelijke voordelen zijn verwaarloosbaar bij een persoonlijke site. Integriteit en vertrouwen? Op een persoonlijke recepten blog? Daarmee is het praktische risico meer dan acceptabel.

maar blijf vechten voor het begrip. Ik zou alleen adviseren om zout in te slaan. Het kan glad worden, her en der heb je nog wat slakken te gaan, en sommige dingen die je zegt mogen ook met een korreltje genomen worden.

En een stukje advies; je gaat jezelf opbranden in het bedrijfsleven/publiek internet met deze houding. Je bent meer en meer aannames en zij sprongen aan het nemen om je gelijk te bewijzen.

[supersnathan94]

Even terugkomend op het risico. De afgelopen 15 jaar zijn er tig service providers betrapt op het injecteren van Javascript en ads in HTTP verzoeken van klanten. Het risico is dus niet 0 en eigenlijk veel realistischer een stuk hoger dan dat.

1. Comcast (VS, 2014-2015)

Comcast injecteerde advertenties en “bandbreedte-waarschuwingen” in onbeveiligd HTTP-verkeer van klanten. Technisch gezien gebeurde dit via hun proxy’s of wifi-gateways, die HTML aanpasten vóórdat het de browser bereikte. Het leidde tot veel kritiek omdat het gedrag identiek was aan dat van klassieke MITM-aanvallen. Comcast still uses MITM javascript injection to serve unwanted ads and messages
Are you aware? Comcast is injecting 400+ lines of JavaScript into web pages. : r/technology

2. Marriott Hotels (VS, 2014)

Marriott blokkeerde gasten-wifi en gebruikte spoofed certificates om eigen captive-portalpagina’s te tonen, waarmee bezoekers werden gedwongen tot betaalde internettoegang. Ze kregen hiervoor een boete van de FCC. Marriott Hotels fined $600,000 by FCC for jamming Wi-Fi hotspots [pdf] (xpost from HN) : r/technology FCC document

3. BT en Phorm (VK, 2006-2008)

British Telecom werkte samen met advertentiebedrijf Phorm om HTTP-verkeer van gebruikers te analyseren en te herschrijven voor gerichte advertenties, zonder toestemming. Dit was een van de eerste grootschalige Europese voorbeelden van “ISP-injected ads”.

BT escapes prosecution over web snooping - BBC News

4. Verizon “Supercookie” (2012-2014)

Verizon voegde unieke tracking-headers toe aan al het mobiele HTTP-verkeer, waardoor adverteerders gebruikers konden volgen, zelfs over verschillende sites heen. Dit gebeurde op netwerklaag, volledig buiten de browser om.

FCC fines Verizon $1.35 million over ‘supercookie’ tracking | The Verge

5. Chinese Great Cannon (2015)

De Chinese overheid gebruikte HTTP-injectie via ISP’s om verkeer om te leiden naar DDoS-aanvallen op GitHub en GreatFire.org. Ook hier werd legitiem HTTP-verkeer aangepast onderweg.

Great Cannon - Wikipedia

6. Airtel (India, 2017)

Airtel injecteerde JavaScript in HTTP-pagina’s om reclamebanners voor eigen diensten te tonen. Zodra HTTPS verplicht werd bij veel Indiase nieuwssites, stopte dit abrupt, omdat TLS-versleuteling het technisch onmogelijk maakte.

Shady Business: Airtel & MTNL injecting advertisements / js into websites you visit! - Team-BHP

Dus wat zien we dan? HTTPS maakt daadwerkelijk een directe impact op de veiligheid van een groot deel van de wereld. Mensen die niet ineens meer een hoop ads voor hun neus krijgen waar ze niet op zitten te wachten en die ook nog eens schadelijke code toe kunnen voegen.

Dat is wat mij betreft geen acceptabel risico. Want dit is qua impact onafhankelijk van of het en grote site is die jij bezoekt of niet. Dus de receptenblog van oma Ina is net zo vatbaar als de bankwebsite van ING (als dezet geen HTTPS gehad zou hebben). Iedere HTTP website waar jij dan naartoe gaat wordt immers door de mitm aangepast.

[SoftwareGert]

Oh, wauw, je bedoelt te zeggen dat omdat het basis protocol en het internet op vertrouwen aan elkaar hangt, dat als een tussenpartij de fout in gaat dat er dan problemen zijn?

Maar als er ‘tig’ zijn, zie ik graag de lijst tot minimaal 20, want dan zit er ‘tig’ in het woord. Aangezien je graag correct wilt zijn.

Je vergeet ook de artikels dat een Nederlandse partij verantwoordelijk voor CA’s een klein foutje had gemaakt. En vergeet stuxnet ook niet.

leef je uit, maar wat ik eerder zei; hosting partijen moeten dit forceren, als je dit probleem wilt oplossen. Als eigenaar van een site is de algehele staat van het internet niet jouw probleem.

Hopelijk heb je nog wel kunnen slapen.

[supersnathan94]

De mogelijke voordelen zijn verwaarloosbaar bij een persoonlijke site.

De mogelijke voordelen van die hele site zijn verwaarloosbaar. Ik snap niet zo goed waarom dit überhaupt een discussiepunt is. Het is letterlijk een vinkje zetten in de meeste webhosting panels.

Daarmee is het praktische risico meer dan acceptabel.

Voor jou. Dat is een afweging die je als gebruiker moet maken en daarom staat er ook een vette waarschuwing in beeld, maar kun je er wel omheen. Ik vind het het niet waard om dat risico te lopen op een willekeurige website (die advertenties serveren bijvoorbeeld, dus adblock) laat staan een receptenblogje van Ingrid uit schubbekutteveen die geen idee heeft wat internet security inhoud.

En een stukje advies; je gaat jezelf opbranden in het bedrijfsleven/publiek internet met deze houding. Je bent meer en meer aannames en zij sprongen aan het nemen om je gelijk te bewijzen.

Tsja als er telkens nieuwe argumenten worden aangeleverd moet ik die wel in de overweging meenemen toch?

en sommige dingen die je zegt mogen ook met een korreltje genomen worden.

Oh dat zal zeker.

[R_Zwart]

Sites worden voor 99% gebruikt door leken. Dan moet het gewoon zo uniform mogelijk zijn. Geen slotje,site niet bezoeken. Hoe ga je de doorsnee gebruiker uitleggen dat het voor de ene site niet erg is als het geen https is en voor de andere site wel?

Je kijkt er naar met een IT-pet op. Maar het is de rol van onze beroepsgroep om IT zo veilig mogelijk te maken voor iedereen. Stel je voor dat auto's of keukenapparatuur zo gemaakt zou worden dat alleen mensen met veel kennis van zaken er veilig mee overweg kunnen. Dat zal niemand accepteren. Waarom zouden we dat in onze branche wel moeten accepteren?

[DataGhost]

Het is niet zo dat iemand "jouw persoonlijke site" gaat aanvallen om malware te serveren aan gebruikers ervan. De aanvalsvector is heel anders, en dat gaat veel automatischer en breder dan dat. Als je ergens een wifi-hotspot opzet met bijvoorbeeld als naam "Wifi in de trein", "Albert Heijn", "Jumbo-Hotspot", "Public" of iets dergelijks waar hele hordes mensen automatisch mee verbinden, kan je gewoon volautomatisch elke http-verbinding afvangen en jouw malware serveren. Dan maakt het helemaal niet uit naar wat voor site je verbindt, of het nou een persoonlijke site is of iets "belangrijks". Gewoon al het http-verkeer krijgt malware geïnjecteerd. Compleet zonder enige actie van de gebruiker. Dát is waarom je ook voor je persoonlijke en "onbelangrijke" sites HTTPS wilt gebruiken. En het is tegenwoordig gratis, automatisch en praktisch triviaal dus een echt excuus heb je niet.

Een dergelijke aanval is van een heel ander kaliber dan iemand social engineeren om een CA te laten installeren en te laten vertrouwen alvorens verbinding te maken met een site. Dus goeie actie van Chrome en je hebt maar pech met je "persoonlijke site". Stel maar een uitzondering in ofzo, of installeer gewoon een gratis certificaat.

[SoftwareGert]

Dus, omdat iemand niet mijn site aanvalt, maar gedeelde infra, moet ik beveiliging toepassen die geen directe impact heeft op mijn site zelf. Punt 2 uit de OWASP top 10 begint ook over het bepalen van de data classificatie, en niet met de tekst "alle data".

Dan is het logischer en in lijn met jullie redenatie dat elke hosting partij HTTP volledig moet gaan blokkeren. Dan leg je het probleem waar hij hoort, want de eigenaar van de site kan volgens de bestaande risico frameworks en de teksten uit de OWASP top 10 tot de volgende conclusie komen: Niet relevant voor mijn site.

Wat dan ook een terechte conclusie kan zijn.

Dat door een gebrekkige infrastructuur en technologie in het midden dan tot andere problemen kan leiden buiten mijn wetenschap en controle om, is niet iets waar ik voor verantwoordelijk ben als ik een simpele persoonlijke site host.

O. En ik ben niet tegen HTTPS, en je zou verwachten dat Chrome het gedrag al langer had, het ging vooral om de "te strak door de bocht" reactie over de proportionaliteit van de maatregelen.

[GeroldM]

Met je stellingen ben ik het geheel mee eens.

Mijn baas wil alle interne services zelf gehost hebben. Als in on-prem. Want hier in dit Zuid-Amerikaanse land is het elektrische grid lang niet zo betrouwbaar als in Nederland. Is er een probleem, dan zijn er zonnepanelen en een generator voor als de prik helemaal wegvalt.

Daarnaast zijn de ISPs hier niet erg prettig in de omgang en schrikken niet niet terug voor gebruikertje pesten. Hier liggen 2 lijnen, 1 fiber, 1 coax. De ISP met de coax lijn is de enige ISP die op deze kantoorlocatie een statisch IP adres wil toekennen. De rest verdomd het."Leuke" bijkomstigheid, als er een probleem is met 1 van de lijnen, en de monteur komt langs, daarna moeten we fysiek controleren of die monteur de verbinding van de andere ISP niet "expres" heeft beschadigd.

Deze ISP die wel met het IP adres over de brug komt, maakt van DNS expres een potje, waardoor Let's Encrypt compleet over de emmer gaat. Maakt niet uit welke methode je instelt bij de Let's Encrypt procedure. Heb ze allemaal uitgeprobeert en allemaal vallen ze om.

Oh, dan maar een betaald certificaat....in deze globale regio zijn er niet veel verstrekkers en de tarieven liggen flink hoger dan in NL. Ruim 2000 Euro per jaar (omgerekend).

Hier heb ik dus te maken met een moedwillig gesaboteerde infrastructuur. Voor interne services werkt HTTP normaal, HTTPS voor interne services is hier veel duurder.

@de overige tweakers:
Dat HTTPS veruit te preferen valt, dat hoef je mij niet uit te leggen. En via slinkse weg heb ik wel een oplossing gevonden om HTTPS voor sommige services te activeren. De enige reden waarom ik dat vermeld is om aan te geven dat ik HTTPS ook daadwerkelijk wil implementeren waar ik het aan de gang kan slingeren.

Maar met commentaar als: "eventjes dit, eventjes dat", dat zal vast allemaal goed werken in een land als Nederland en/of de EU, waar ISPs op prijs en goede services moeten concurreren. Dat is in dit deel van de wereld dus niet het geval, er zijn er maar heel weinig en hoeven zich daardoor niet zo goed of wellwillend te gedragen, want je kan nergens anders naar toe.

Door deze ervaringen in een ander continent kan ik de overige Tweakers meldden dat Tweakers in Nederland zijn verwend.

[supersnathan94]

Voor interne services werkt HTTP normaal, HTTPS voor interne services is hier veel duurder.

Je kunt volledig offline certificaten uitgeven voor interne services:

• Gratis en open source: Smallstep CA, HashiCorp Vault PKI, of CFSSL (die kan wel duur worden).
• Je genereert een eigen rootcertificaat, distribueert dat naar je interne systemen (of browsers), en gebruikt het om interne HTTPS-certificaten uit te geven.
• Dit voorkomt afhankelijkheid van externe validatie en werkt zelfs zonder internet.

Voordeel: Volledig onder eigen controle, maar je moet het rootcertificaat beheren en op clients vertrouwen.

Deze ISP die wel met het IP adres over de brug komt, maakt van DNS expres een potje, waardoor Let's Encrypt compleet over de emmer gaat. Maakt niet uit welke methode je instelt bij de Let's Encrypt procedure. Heb ze allemaal uitgeprobeert en allemaal vallen ze om.

Oh, dan maar een betaald certificaat....in deze globale regio zijn er niet veel verstrekkers en de tarieven liggen flink hoger dan in NL. Ruim 2000 Euro per jaar (omgerekend).

Let’s Encrypt is niet de enige die het ACME-protocol ondersteunt.
Je kunt een lokale ACME-server draaien die automatisch certificaten uitgeeft, bijvoorbeeld via Step CA (van Smallstep). Again, gratis, eenvoudig te integreren met nginx, Traefik of Caddy.

Voordeel: Volledig geautomatiseerd zoals Let’s Encrypt, maar zonder afhankelijkheid van publieke DNS.

Als het gaat om webhosting dan is Caddy Server nog wel aan te raden. Caddy is een open source webserver die automatisch HTTPS configureert met ingebouwde ACME-client, ook voor interne domeinen met een eigen CA.

• Je hoeft nauwelijks iets te configureren: caddy reverse-proxy :443 localhost:8080 is vaak genoeg.
• Werkt zelfs met een interne CA of self-signed setup.

Als lokale ISP’s DNS saboteren, kun je soms alsnog via alternatieve resolvers werken:

• Cloudflare DNS (1.1.1.1) of Google DNS (8.8.8.8) via DoH (DNS over HTTPS).
• Of een lokale Unbound-resolver die upstream queries via DoH of DoT doorstuurt.
  Dat voorkomt dat de lokale ISP kan injecteren of blokkeren.

De situatie die je schetst is frustrerend en niet vergelijkbaar met hoe “makkelijk” het hier gaat, maar het probleem ligt niet bij HTTPS als concept.
Het gaat om de afhankelijkheid van onbetrouwbare infrastructuur. Door lokale CAs, alternatieve ACME-servers en DoH te gebruiken, kun je grotendeels onafhankelijk worden van die beperkingen, en tóch veilige verbindingen opzetten zonder duizenden euro’s per jaar uit te geven.

[supersnathan94]

Dat door een gebrekkige infrastructuur en technologie in het midden dan tot andere problemen kan leiden buiten mijn wetenschap en controle om, is niet iets waar ik voor verantwoordelijk ben als ik een simpele persoonlijke site host.

Maar je hebt er wel controle over. Door HTTPS te gebruiken zadel je je gebruikers niet met de problematiek op dat het kan. JIJ bepaalt namelijk of HTTPS kan of niet. Niet de gebruiker.

Als webhoster is het absoluut jouw verantwoordelijkheid om je gebruiker veilig content te serveren. Jij bent de enige die er voor kan zorgen dat de gebruiker namelijk niet door een simpele MITM opzet vatbaar is.

Dus, omdat iemand niet mijn site aanvalt, maar gedeelde infra, moet ik beveiliging toepassen die geen directe impact heeft op mijn site zelf

Ja. want jij bent de enige die er wat aan kunt doen. De gebruiker kan niet zeggen, "ik wil HTTPS" als jij het niet aanbied.

Je bent de enige die de kan doen en de enige die er voor verantwoordelijk kan zijn dat dit goed werkt. de gebruiker kan hier niks tegen doen, want zolang jij niet de mogelijkheid bied dat een gebruiker kan controleren dat jij het wel echt bent (wat TLS doet) dan kan ie er ook niks van zeggen.

[Steven]

Het zorgt er ook voor dat als je DNS compromoised is; dat je dan door hebt dat je met de verkeerde website aan het praten bent. Ook op jouw persoonlijke site kan het onhandig zijn als er ineens een malafide 'koop nu een iPhone voor €300'-advertentie geinjecteerd is.

[MadEgg]

Er is ook nog een privacy aspect aan. Je request is ook encrypted met (moderne) https. Dankzij SNI is zelfs de hostname encrypted. Dat betekent dat je ISP of elke partij met traffic tot je verkeer alleen nog kan zien met welk IP adres je verbinding maakt,
niet welke website je opvraagt, en ook niet welke pagina.

Met http kan dat wel en kan basically iedereen zin wat voor informatie je leest. Qua privacy is daar het een en ander op aan te merken.

Al met al wat mij betreft een goede stap dus.

[blinchik]

HTTP is nog niet volledig dood in 2025 hoor, in specifieke use-cases zijn er echter nog wel redenen om http te gebruiken.

- Dingen cachen. Bv. bij apt repository's gebruikt men nog steeds http, omdat dit dan makkelijk geredirect en gecached kan worden. authenticiteit, integriteit en verificatie van de packages worden bij apt gecontroleerd door gpg.

- bij captive portals kan https niet zomaar geredirected worden, omdat TLS de inhoud en hostnaam versleutelt en dan de gebruiker krijgt dan een SSL error in plaats van een loginpagina.

- PXE boot, booten via netwerk heeft de computer nog geen CA's, dit gaat via http. Het kan tegenwoordig wel via https maar is redelijk ingewikkeld. Zelfde eigenlijk met mDNS of Zeroconf.

[supersnathan94]

Klopt helemaal hoor, maar dat zijn inderdaad use-cases buiten de browser om.
APT-repositories, PXE-boot en captive portals vallen allemaal onder infrastructuur- of systeemniveau, niet onder regulier webverkeer, APT heeft zijn eigen verificatie (idd PGP) om geknoei te detecteren en iets als PXE boot is natuurlijk altijd vanaf een vertrouwede server binnen in je netwerk. Chrome’s wijziging richt zich puur op publieke webpagina’s die via de browser worden bezocht, niet op interne netwerkservices of low-level protocollen.

Voor browsers is er eigenlijk geen enkele legitieme reden meer om nog HTTP te gebruiken. Alles wat via een menselijke gebruiker op het web gaat, hoort gewoon via HTTPS te lopen. De uitzonderingen die jij noemt zijn technisch interessant, maar niet relevant voor deze context.

[Z80]

Chrome gaat pas oktober 2026 over naar https eerst. Dus pas over een jaar. Firefox doet het nu al.

En versleutelen of ander verdwijnen? WAAROM? En de wereld is groot heel groot. Niet alles is gevoelig en modern.

[Reactie gewijzigd door Z80 op 29 oktober 2025 12:52]

[supersnathan94]

Safari en Edge ook. Maar FF heeft een marktaandeel van hoogstens 2%, Chrome van 80-85%. Dat is wel even een verschil.

En versleutelen of ander verdwijnen? WAAROM?

Het gaat niet zozeer om geheimhouding, maar om integriteit en vertrouwen. Zelfs als je site alleen maar statische content serveert, wil je dat bezoekers zeker weten dat wat ze zien ook echt van jou komt, en niet onderweg is aangepast door een MITM, ISP of tussenliggende proxy.

De wereld is inderdaad groot, maar juist daarom wil je een betrouwbare onderlaag. HTTP is niet “ouderwets”, het is simpelweg onbetrouwbaar geworden in een tijd waarin verkeer voortdurend door allerlei lagen heen gaat. HTTPS is vandaag de dag gewoon de minimale baseline, niet omdat alles gevoelig is, maar omdat je niet wilt dat iemand anders ermee kan knoeien.

[bvdberg76]

Ik heb een aantal eenvoudige websites, zonder interactie. Waarom zou ik dan veel geld gaan betalen per maand voor belachelijke bedragen die ze vragen voor keys?

[zanza006]

Opzich zijn er mogelijkheden om dit gratis te doen.

[supersnathan94]

Dat zeg ik dus. Het is praktisch gratis. Beetje hoster heeft het als een vinkje een vraagt er niks voor.

Ik heb een site bin transip, is ook gewoon HTTPS voor een projectje waar ooit 15 mensen wat mee hebben gedaan. Kost niks. Inschrijfpagina voor een weekendje weg. 0 recurring usage en op de lijst om gewoon te schrappen.

[xzaz]

Laatst voor iemand een website moeten overzetten naar https. Bleek dus niet voor te zijn geregeld bij de provider dus een mailtje moeten sturen en 45 euro moeten af tikken. Voor een gratis certificaat. Dat weerhoudt mensen wel van om https te gebruiken.

[zanza006]

Zelf host ik thuis een statische html pagina. Sinds enkele maanden via https.

Maar is er is voor mij geen enkele meerwaarde dit te doen, dan enkel af te zijn van de meldingen dat dit mogelijks onveilige website is.

Of zie ik dit verkeerd.

[lucade2210]

Het zal je verbazen hoeveel oude conventionele IT'ers onder gigantische keien leven.

Ik had laatst een website (een online tuinspullen bedrijf) waar ik een account had aangemaakt. Een minuut later kreeg ik een email terug om m'n account te activeren. Die mail bevatte dus gewoon mijn wachtwoord in plain tekst... Naast het feit dat dat dus al onveilig over email verstuurd is, betekent het ook dat het niet gesalt vanuit mijn browser verstuurd is en daarmee gewoon leesbaar door de website eigenaar. Groot is de kans dat die gewoon nog in plain tekst is opgeslagen ook.

Afijn, ik dat bedrijf op een nette manier gemaild en hiervoor gewaarschuwd. Krijg ik het antwoord terug dat ze met hun IT leverancier gesproken hadden en die hen sterk verzekerde dat alles super veilig was en dat niemand de wachtwoorden kon lezen...

Tja. Leugens? Kop in het zand? Luiheid? 'T zal een combinatie van allen zijn.

[supersnathan94]

Het zal je verbazen hoeveel oude conventionele IT'ers onder gigantische keien leven.

Dat verbaasd me helemaal niks.

Daarom is het juist goed dat grote partijen met veel markt invloed af en toe wel eens een goed idee hebben zoals dit. Alleen jammer dat het zolang heeft moeten duren. Maar andere browsers hebben aangetoond dat het in ieder geval prima kan zonder teveel issues voor de gebruiker.

[Lrrr]

Eh, salten gebeurt toch aan de serverkant? Dus je browser stuurt je WW naar de server -> salten + hashen -> salt & hash worden opgeslagen in de DB.

Tussen die eerste en tweede stap is je WW dan ook nog in plaintext, dus kan de server hem dan nog in plaintext naar je mailen (niet dat dat een good practice is, maar het betekent dus niet noodzakelijkerwijs dat het WW dan ook in plaintext wordt opgeslagen).

Of ben ik nu juist degene die onder een steen leeft?

[uiltje]

Op zich klopt dit (hoewel je ook het wachtwoord kan pre-salten, maar dat gebeurd meestal niet). Echter, je verwacht dat de server meteen een password hash met salt uitrekent, en niet dat het ding je wachtwoord aan allerlei andere systemen zoals mail servers overhandigd.

[cricque]

Tsja de "wp webspecialist" heeft hier dikwijls geen kaas van gegeten maar rekent wel serieuze prijzen voor wat te klikken. Heb genoeg klanten waar de website alleen via http is (meestal wp of zowat click gedoe) ... Die hebben zelf zeker geen kaas van gegeten. Als je hun daar op wijst ... tsja zullen we doorgeven en daar blijft het bij.


Zou het moeten absoluut, echter realiteit is anders

[nzall]

Er is nog een reden voor een publiek beschikbare webpagina zonder HTTPS: captive portals op openbare wifi netwerken. Kan zijn dat dit ondertussen veranderd is, maar mijn ervaring met die portalen is altijd geweest dat de redirect naar die portalen eigenlijk enkel goed werkt als je een onbeveiligde pagina probeert open te doen. Bij beveiligde pagina's werkt dat niet zo goed...

[moonlander]

Als ik inlog op de odido Klik en klaar router, dan gaat dat via een onbeveiligde verbinding....

Als ik inlog op de beheer pagina van mijn brother laserprinter, is dat zonder certificaat...

Er zijn nog genoeg voorbeelden waar http gebruikt wordt..

[Tim_bots]

Heb ik alleen 2 uitdagingen met HTTPS (don't get me wrong, ik ben zeker voorstander ervan, maar soms...)

De 1e uitdaging zijn embedded devices (ESP32). Ik negeer dan even voor het gemak de extra processorkracht die benodigd is voor de HTTPS berekeningen. Deze apparaten benader je vaak middels mDNS of het IP adres. Hoe moet je daar een HTTPS certificaat voor regelen? Note: omdat het hier om embedded apparaten gaat is het hernieuwen van een certificaat ook lastig.

De 2e uitdaging zijn lokale servers. Ook die zijn alleen via een lokaal IP adres of (als je geluk hebt) via een DNS naam te benaderen. Maar hoe zorg ik er dan voor dat deze ook remote benaderbaar zijn zodat ik een correct certificaat kan krijgen.

Een self signed certificaat is hierin ook niet handig omdat je dan toch de hele ondertekening keten negeert. Dus een man in the middle attack werkt dan ook net zo goed (plus chrome vind dit ook niet leuk om te doen)

[Niemand_Anders]

Snap al jaren niet waarom Chrome (of andere browsers) niet standaard eerst HTTPS proberen en pas als deze niet thuis geeft, dan pas terugschakeld naar HTTP.

De AES instruction-set zit in zo'n beetje alle 64-bit processoren, dus de overhead om eerst HTTPS is minimaal...

[bzzzt]

Dat doet Chrome ook, maar vereist dat er een HTTP header gezet is (HTTP Strict-Transport-Security, oftewel HSTS). Enige wat je daarmee niet afvangt is het eerste request naar een nieuwe website (wat in theorie via HTTP kan worden gedaan). Daarom hebben de browser makers een 'preload' lijst gemaakt waar je een website in op kan laten nemen: https://hstspreload.org
Als je daar een keer op staat wordt HTTP niet meer geprobeerd en zal je site altijd een geldig certificaat moeten presenteren.

[supersnathan94]

Dat doet Chrome ook

nee dat doet chrome dus niet. De default was nog steeds HTTP tenzij je op de HSTS pre-load stond.

Nu is dus HSTS niet meer nodig omdat je het dus bij default doet. Ik snap ook niet zo goed waarom ze het niet alsnog gewoon probeerden en bij een foutcode http als fallback. HSTS is als protocol gemaakt om er voor te zorgen dat je SSL/TLS kunt forceren, maar als de browser dat gewoon bij default doet heb je HSTS helemaal niet nodig.

[bzzzt]

nee dat doet chrome dus niet. De default was nog steeds HTTP tenzij je op de HSTS pre-load stond.

Alleen voor het eerste request. Daarna cached je browser de HSTS header en wordt er geen HTTP meer gebruikt.

Ik snap ook niet zo goed waarom ze het niet alsnog gewoon probeerden en bij een foutcode http als fallback. HSTS is als protocol gemaakt om er voor te zorgen dat je SSL/TLS kunt forceren, maar als de browser dat gewoon bij default doet heb je HSTS helemaal niet nodig.

Omdat een fallback niet secure is? Als je als attacker TLS kan blokkeren of verstoren en een browser terugvalt op onbeveiligd kan je alsnog meeluisteren.

[supersnathan94]

Omdat een fallback niet secure is? Als je als attacker TLS kan blokkeren of verstoren en een browser terugvalt op onbeveiligd kan je alsnog meeluisteren.

Maar de situatie is nu default http. Dus dat is per definitie onveiliger dan het alleen als fallback gebruiken, wat ze nu daadwerkelijk gaan doen.

[bzzzt]

Het verschil is dat er nu rustig een waarschuwing getoond kan worden als een site terugvalt naar HTTP. Dat kon een aantal jaar geleden nog niet omdat je dan kapot gespammed zou worden en gebruikers waarschuwingen zouden negeren.

[supersnathan94]

Nee oke maar ze hadden die waarschuwing niet hoeven tonen. Dat doen ze namelijk nu ook niet voor http.

Chrome had prima intern kunnen kijken of er een HTTPS versie was en zo niet dan HTTP gebruiken dat doen ze straks namelijk ook, alleen dan met een waarschuwing.

[GertMenkel]

Dat doen sommige browsers, maar dat maakt nogal wat intranets met verkeerd ingestelde HTTPS-servers kapot. neverssl.com heeft om die reden ook een HTTPS-certificaat genomen, omdat anders neverssl.com het eigenlijk niet deed zoals bedoeld.

In een perfecte wereld waarin iedere server met HTTPS aan ook daadwerkelijk de HTTPS-versie van de dienst die op de HTTP-poort draait aanbiedt, had die instelling al lang omgekund.

In Firefox zit die instelling dan ook al een paar jaar. In privémodus staat die standaard aan en ik heb hem al tijden aangezet voor niet-privémodus, maar regelmatig kom ik nog op websites waar HTTPS kapot is.

[supersnathan94]

maar dat maakt nogal wat intranets met verkeerd ingestelde HTTPS-servers kapot

Maakt de verkeerde instelling niet gewoon het intranet kapot? Configuratiefout neerleggen bij de browser die security afdwingt is wel een aparte manier.

[GertMenkel]

Tja, datzelfde zou ik ook zeggen over het beperken van third party cookies, het plaatsen van API's achter secure origins, het weghalen van de user agent, en ander gedrag dat de veiligheid en privacy verbeterd ten koste van compatibiliteit.

Ik ben groot voorstander; ik draai zelf al bijna twee jaar HTTPS-only in Firefox. De IT-beheerder die 50 legacy-servers beheert waarop HTTPS kapot is door brakke firmware zal daar anders over denken . Ik ben zelf ook hardware tegengekomen die wel een HTTPS-poort aanbood, en zelfs een zelfgekozen certificaat accepteerde, maar daar andere diensten op draaide als de web-UI (een of andere "veilig" API). Ik zou zelf niet de >1000 euro neerleggen om zo'n ding te vervangen als een compatibility flag in Chrome gratis is, al is het wel een reminder om naar andere merken te kijken zodra dat apparaat aan vervanging toe is.

[Reactie gewijzigd door GertMenkel op 29 oktober 2025 15:16]

[RobertMe]

HSTS blijft wel nodig. Aangezien zoals je zelf aangeeft HSTS het gebruik van HTTPS forceert. Als HTTPS alleen de standaard is kun je wel nog terug naar HTTP, bij HSTS kan dat niet. En HSTS vereist ook dat er een geldig certificaat wordt gebruikt, terwijl je zonder HSTS bij een ongeldig certificaat nog kunt "door klikken" om verder te gaan ondanks het ongeldige certificaat.

HSTS blijft in zoverre dus wel een use case hebben: het forceren dat HTTPS wordt gebruikt, incl een geldig certificaat. Daar waar je zonder HSTS alleen een waarschuwing krijgt als er niet aan deze zaken wordt voldaan, maar je wel deze waarschuwing kunt negeren.

Effectief veranderd er v.w.b. HSTS dus ook niet eens zo veel. Het enige verschil is dat als de site niet op de HSTS preload staat nu nog de eerste request naar de http:// variant gaat en die eerste request vatbaar is voor een MITM. (En HSTS geset door de site heeft een levensduur die kan vervallen waardoor volgende requests dagen / weken / maanden (/ jaren?) later ook weer vatbaar zijn voor een MITM de eerste request).

Wat meer "past" bij een mogelijke uitfasering van HSTS is dat er nieuwe tlds zijn die HTTPS vereisen. Dit geldt bv voor het .dev domein. Geen enkele browser staat je toe om .dev te bezoeken zonder dat er een geldig certificaat is. (Mogelijk doordat gewoon .dev gepreload is in HSTS, of een ander mechanisme, dat weet ik niet. In ieder geval hoef je er als website eigenaar niks voor te doen).

[DDX]

Ookal heb je HSTS ingesteld, kan je nogsteeds verder door thisisunsafe in te tikken als je de hsts error ziet. (of misschien hebben ze dit zinnetje weer aangepast, doen ze eens in de zoveel jaar)

[supersnathan94]

Als HTTPS alleen de standaard is kun je wel nog terug naar HTTP

Maar welk nut heeft dat dan nog?

Een downgrade van de connectie is niet per se handig.

De vraag is dus in hoeverre Chrome dan niet gewoon kan zeggen, dat staan we gewoon helemaal niet meer toe. Daarmee vervalt de behoefte van pre-load en HTTPS force.

Uiteraard wel alleen als alle andere browsers dit ook gaan doen.

Wat meer "past" bij een mogelijke uitfasering van HSTS is dat er nieuwe tlds zijn die HTTPS vereisen. Dit geldt bv voor het .dev domein. Geen enkele browser staat je toe om .dev te bezoeken zonder dat er een geldig certificaat is. (Mogelijk doordat gewoon .dev gepreload is in HSTS, of een ander mechanisme, dat weet ik niet. In ieder geval hoef je er als website eigenaar niks voor te doen).

Oh interessant. was me nog niet opgevallen.

[qless]

Connectie maken gaat eerst met asymmetric versleuteling, daar doet AES nog niks. Op moderne systemen is de overhead minimaal, dus ik vindt dit een goede maatregel, zolang http maar wel mogelijk blijft voor specifieke dingen/noodgevallen.

[Z80]

Firefox probeert al vanaf versie 136 (begin dit jaar) https first. Chrome loopt ruim een jaar achter.

[Travelan]

Wat, doet Chrome dat nu nog steeds niet? Safari (op iOS in elk geval) gelukkig wél. Dit is echt wel stap 1 in veilig internetgebruik...

[_eLMo_]

Sinds eind 2024. Al veel langer (jaren) waarschuwt Safari, maar "default" was nog steeds http, met een automatische upgrade (HSTS) als HTTPS available was (tenzij je specifiek zelf http:// typt).

Helemaal eens voor de rest.

[MrHarry]

zolang je nog maar wel http://localhost dingen kan doen is het prima, want vaak als dev test je dingen lokaal en dat hoeft niet altijd via https te lopen.

[Louw Post]

Ik heb dit al een tijdje aanstaan in Edge en daar heb je de optie dat het alleen verplicht is voor publieke websites en niet lokaal/intranet. In mijn ervaring krijg je dan alsnog gewoon een waarschuwingspagina waar je kan doorklikken naar de 'onveilige' website.

[bzzzt]

Nadeel is dat je dan een aparte lokale configuratie moet aanleveren. Dingen als 'secure cookies' werken dan ook niet dus je test dan feitelijk anders dan op je productie omgeving.

[gimbal]

Je lokale dev omgeving is nooit gelijk aan prod, als je al iets met https gaat testen dan zet je wel iets van een mock omgeving op met nginx in een docker image of iets dergelijks. Je gaat echt geen virtual machine met een 1:1 kopie van prod draaien.

Meestal ook niet nodig want als het eenmaal ingericht is dan gaat het echt niet zomaar kapot; dat is dan een flinke regressie. Je richt het 1 keer in en daarna zou je toch echt wel een uat/pre-prod omgeving moeten hebben om testen op uit te voeren voordat het naar prod gaat. Als het kapot is dan merk je het daar wel.

[Gwaihir]

Kunnen we dan ook een eenvoudige oplossing krijgen voor waarschuwingsvrij https binnen het LAN?

Ik heb best wat eenvoudige zaken binnenshuis, stevig achter de firewal, die geen https ondersteunen en simpelweg op IP benaderd worden. (Ook net nieuw aangeschaft, nu op de markt.) Ik snap dat eigenlijk ook wel, want voor die apparaten (zoals switch beheer) waar https wél ondersteund wordt, is het gebruik ervan ook verre van elegant: je hebt geen (geldig) certificaat en dus een bak foutmeldingen weg te klikken. En de 'oplossingen' die daarvoor bestaan blijken helaas buitengewoon ingewikkeld.

Mijn browser rapporteert dus vast ook zo'n percentage http requests terug aan mama Google (en ook nog 'ns zo'n percentage certificaatfouten). Maar het aantal noodzakelijke kliks om die sites nog te bereiken verder ophogen, zie ik niet als beveiligingsupgrade, maar een push om mee te gaan met de 'alles via de cloud (abonnementen)' manie.

[Bathing Aap]

In principe zouden ze .local - Wikipedia dan moeten herkennen en daarmee Link-local address - Wikipedia uitzonderen, ik weet niet of ze dat (gaan) doen...

[Gwaihir]

Je post klonk interessant. Maar dat Wikipedia artikel geeft allerminst de indruk dat het een uitgemaakte zaak is.

Op zich lijkt het idee mij niet verkeerd. Liefst zou ik dan nog iets verder gaan: enkele 'tld's' gereserveerd voor LAN (net als sommige IP ranges), waarop bijzondere regels gelden. Bijvoorbeeld eentje die slechts 'LAN' betekent, eentje waarop https certificaten niet verwacht worden of nodig zijn*, en eentje waarop het vertrouwensniveau nog hoger ligt (zodat ook http verbindingen ok blijven).

En dan op de verschillende routers (die toch meestal al lokaal gebruikt worden in de DNS keten) de mogelijkheid een lijstje bij te houden.

*Of misschien nog beter: doe er (ook nog) eentje waar https certificaten wel gecontroleerd worden, maar dan self-signed, d.w.z. dat de lokale router als eindpunt van de certificeringsketen mag fungeren zonder dat daarvoor weer per pc van alles verbouwd hoeft te worden.

[Olaf van der Spek]

Is er een 'oplossing' voor bijvoorbeeld printers en routers, die geen normaal certificaat hebben?

[Sleepkever]

Op "Continue to site" klikken van de waarschuwing?

[Exception]

Proxy

[Marctraider]

Ik blokeer standaard alle porten behalve 443.

[Pilovali]

Dus ook geen 53 voor DNS? En 123 voor NTP?

[Marctraider]

Jawel. Die staan in mijn custom core networking rules.

Ik bedoelde uiteraard voor mijn browser(s) ;)

[Reactie gewijzigd door Marctraider op 29 oktober 2025 12:56]

[Rabb]

Volgens het artikel uit 2021 deden ze dit toen al. Wat veranderd er dan in dit geval?

[GarBaGe]

Google waarschuwt dat hackers HTTP-verbindingen kunnen onderscheppen om zo aanvallen uit te voeren met onder meer malware en social engineering

Dit zijn dan toch ook hackers die onder een steen leven?
Het is vrij normaal dat hackers tegenwoordig beschikking hebben over HTTPS phising sites met geldige TLS certificaat, maar dan een domeinnaam wat heel veel lijkt op wat de gebruiker verwacht.

[Stroper]

Das een andere manier van hakken.

Https zorgt ervoor dat je enkel met de eigenaar van de site praat. Dat wil uiteraard niet zeggen dat https://www.ingbankierennederland.com ook van ING is.


Als echter ING nog http://ing.nl zou gebruiken, kan een hacker binnen je ISP, publieke WIFI,... ervoor zorgen dat je echt met een andere site praat ipv. ing.nl

[gimbal]

Zeker. HTTPS gaat je niet helpen met het feit dat ze hebben kunnen inbreken echter om uberhaupt dat soort wijzigingen te kunnen doen. Het is een beetje mosterd na de maaltijd op dat moment.

[Teun!]

Is er iemand hier die nog regelmatig plain http websites tegenkomt?

Ik heb er zelf eentje die publiekelijk is en geen https support heeft, en ik irriteer me daar mateloos aan en heb dit ook gemeld bij het bedrijf (lokale bordspellen winkel) maar die willen er niks aan doen helaas.