Google Chrome gebruikt nu standaard voor alle verbindingen https
Google heeft besloten om bij alle gebruikers nu standaard https voor alle verbindingen te gebruiken. Wanneer gebruikers op een http-link klikken maakt de browser er automatisch https van. Alleen als de betreffende website geen https ondersteunt wordt er vervolgens op http teruggevallen. Volgens Google werkt de techniek in bijna alle situaties, behalve als de site zoals gezegd geen https aanbiedt.
"Browsers versturen nog steeds onveilige http requests naar websites die https ondersteunen, tenzij de sitebeheerder de nodige configuraties heeft doorgevoerd en hun site aan de HSTS preload list heeft toegevoegd", aldus Google in een uitleg over HTTPS Upgrade, zoals de feature in de browser wordt genoemd. HTTP Strict Transport Security (HSTS) zorgt ervoor dat websites die via HTTPS te bezoeken zijn alleen via HTTPS worden bezocht.
De HSTS preload list die Google noemt bevat hostnames waarvoor de browser automatisch een https-verbinding afdwingt. Het kan echter voorkomen dat een gebruiker iets via http laadt vanaf een website die HSTS ondersteunt, maar nog niet eerder is bezocht en ook niet op de preload list staat. Een ander scenario is wanneer er een website wordt bezocht die de gebruiker van http naar https redirect, maar geen HSTS gebruikt, of een site die zowel http als https ondersteunt, maar geen redirect van http naar https doet.
Via de preload list worden websites meteen via https geladen, maar die lijst is niet allesomvattend. Via HTTPS Upgrade wordt er altijd https gebruikt, en zal http als fallback optie worden gebruikt. Google besloot de feature eerder dit jaar eerst in versie 115 van de browser te testen, maar heeft die begin deze maand onder alle gebruikers uitgerold, zo laat Chris Thompson van Google weten. De feature is één van de maatregelen waar Google mee bezig is om http-verkeer te verminderen.
Ik was het werkelijk kotsbeu om elke keer HSTS te configgen en weer 80 te te moeten hosten omdat browsers nog defaulten naar HTTP.
Hopelijk volgen andere browsers snel!
If you maintain a project that provides HTTPS configuration advice or provides an option to enable HSTS, do not include the preload directive by default.
We get regular emails from site operators who tried out HSTS this way, only to find themselves on the preload list by the time they find they need to remove HSTS to access certain subdomains. Removal tends to be slow and painful for those sites.
Projects that support or advise about HSTS and HSTS preloading should ensure that site operators understand the long-term consequences of preloading before they turn it on for a given domain. They should also be informed that they need to meet additional requirements and submit their site to hstspreload.org to ensure that it is successfully preloaded (i.e. to get the full protection of the intended configuration).
Hoe moeilijk is het voor Google om de adviezen van de mensen te volgen die het project onderhouden.
Hier hebben we de preload header juist voor Google moet zich hier niet mee bemoeien.
Hoe moeilijk is het voor Google om de adviezen van de mensen te volgen die het project onderhouden.
Hier hebben we de preload header juist voor Google moet zich hier niet mee bemoeien.
Ze (Chrome team) doen iets anders nu. Wat ze doen is goed: https by default en als je niet op de preload list staat is terugvallen een optie. Dat voorkomt veel aanvalsmogelijkheden op sites die hsts helemaal niet inzetten (statistieken heb ik niet, maar kan me voorstellen dat dat er heel veel zijn).
Uiteindelijk wil je van HSTS af natuurlijk: gewoon alles https. By default versleutelde verbindingen. Nu nog DANE en betere certificaten erop (die ook worden getoond) dat je ook kunt checken of je echt op de site bent aangekomen waar je naar toe wilde.
Daarnaast is een alternatieve Chromium-gebaseerde browser vaak beter voor uw privacy.
Zet daarbij wel https-everywhere aan als dit nog niet het geval is.
Een Firefox-alternatief zoals de TOR-browser of Librewolf is geweldig op PC's.
En een déjà vu, uit https://blog.chromium.org/2021/03/a-safer-default-for-navigation-https.html:
Tuesday, March 23, 2021
Starting in version 90, Chrome’s address bar will use https:// by default, improving privacy and even loading speed for users visiting websites that support HTTPS.
Zoek in de browser die je gebruikt naar een instelling om altijd https te gebruiken en je te waarschuwen als https niet werkt. Bij elke (ook onopgemerkte) terugval naar http kan de verbinding worden gekaapt, een risico dat vooral groot is op publieke Wi-Fi of andere onvertrouwde netwerken.
ja :
https://www.scmp.com/abacus/tech/article/3103747/google-chrome-remains-chinas-most-popular-web-browser-even-google
google _services_ (search, youtube e.a) worden geblokkeerd - feitelijk "massamedia" .
google code zoals chrome, of Android liggen ze niet wakker van.
Dit verlangt wel een verduidelijking. Werkt het nou WEL of NIET als een website geen https aanbiedt?
Ik denk daarbij niet zozeer aan "websites" maar bijv aan admin interfaces van devices op je interne netwerk.
Gaat dit weer hetzelfde drama worden als met het uitfaseren van Java en Flash, maar nu wellicht op nog meer devices?
er is geen enkele reden om aan te nemen dat wat op poort 80 beschikbaar is, op poort 443 via SSL beschikbaar is.
Ik was het werkelijk kotsbeu om elke keer HSTS te configgen en weer 80 te te moeten hosten omdat browsers nog defaulten naar HTTP.
Hopelijk volgen andere browsers snel!
Hoe moeilijk is het voor Google om de adviezen van de mensen te volgen die het project onderhouden.
Hier hebben we de preload header juist voor Google moet zich hier niet mee bemoeien.
Ze (Chrome team) doen iets anders nu. Wat ze doen is goed: https by default en als je niet op de preload list staat is terugvallen een optie. Dat voorkomt veel aanvalsmogelijkheden op sites die hsts helemaal niet inzetten (statistieken heb ik niet, maar kan me voorstellen dat dat er heel veel zijn).
Uiteindelijk wil je van HSTS af natuurlijk: gewoon alles https. By default versleutelde verbindingen. Nu nog DANE en betere certificaten erop (die ook worden getoond) dat je ook kunt checken of je echt op de site bent aangekomen waar je naar toe wilde.
Tussen oplossing voor iets waar iedereen in de tech industrie al decenia weet dat we mee moeten werken maar sommige simpelweg vertikken hun verantwoordelijkheid te nemen.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
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?