Google brengt Chrome 90 uit en maakt https standaard

Google heeft versie 90 van de Chrome-browser uitgerold. Vanaf deze versie zal Chrome standaard een https-verbinding tot stand proberen te brengen bij elke website. Google voegt bovendien een encoder toe voor de av1-codec en heeft met deze update 37 kwetsbaarheden verholpen.

Het ontwikkelteam achter de browser heeft ervoor gekozen om vanaf versie 90 https als standaard te gebruiken in plaats van het oude http-protocol. Iedere gebruiker kan nog steeds handmatig het http-protocol activeren door een webadres met http in te typen. Het team zou bovendien 37 kwetsbaarheden hebben opgelost waarvan het zes kwetsbaarheden als hoog risico had aangeduid.

Versie 90 van Chrome introduceert ook een av1-encoder. Deze encoder maakt het mogelijk voor Chrome om uitgaande videostreams te coderen met de av1-codec. Eén van de toepassingen waar Google op mikt is videobellen en screensharing. Beide toepassingen zullen via Chrome gebruik kunnen maken van de av1-codec en vervolgens efficiënter draaien. Sinds eind 2017 bevat Chrome al een decoder die het afspelen van av1-content mogelijk maakte. Deze werd in Chrome 70 standaard ingeschakeld.

De av1-codec werd vanaf 2015 ontwikkeld door de Alliance for Open Media, een non-profit consortium bestaande uit Google, Microsoft, Netflix, Mozilla, Cisco, Intel en Amazon dat alternatieven moest ontwikkelen voor de standaardcodecs zoals mpeg4-codering waarvoor dikwijls royalty's moeten worden betaald. Dat is bij de av1-codec niet het geval.

Netflix is vorig jaar begonnen met de implementatie van de av1-codec in haar dienst. Volgens de Amerikaanse streamingdienst Netflix is av1 twintig procent efficiënter in vergelijking met de vp9-codec. Google stelt dat de codec meer dan dertig procent efficiënter is in vergelijking met vp9.

De update zal volgens Google in de loop van de komende dagen beschikbaar zijn voor Chrome op Windows, Mac, Linux en Android. De update voor iOS-apparaten volgt later.

Update, 22u15: Artikel aangepast en aangevuld op basis van de reactie van Balance.

Reacties (62)

[Balance]

Korte tijdlijn over de AV1 ondersteuning in Chrome:

• In december 2017 werd er een patch toegevoegd waarmee libaom, de AV1 referentie en- en decoder standaard met Chrome werd gecompiled. In de dev-branch was deze toen een tijd beschikbaar.
• Met Chrome 70, in oktober 2018, werd de beslissing genomen om AV1 decoding standaard aan te zetten. Daarvoor zat deze nog verstopt achter een flag (status | tracking bug)
• De snellere dav1d av1 decoder is toegevoegd in februari 2019 en standaard aangezet in Chrome 74.
• Ondersteuning voor het AVIF formaat voor afbeeldingen is toegevoegd april 2020 en ging standaard aan in Chrome 85 voor de desktop. In Chrome 89 werd dit ook voor de Android app aangezet (status | tracking bug.

Chrome 90 introduceert nu een AV1 encoder. In de webbrowser kan dus AV1 content geëncodeerd worden, wat vele malen intensiever is dan het ontvangen en decoderen ervan. Dit is met name bedoelt voor video-conferencing met bijvoorbeeld WebRTC, zodat jij niet alleen AV1 video kant ontvangen maar die ook kan versturen. De AV1 codec is niet alleen efficiënter voor reguliere video, maar doet het ook erg goed op screen-content, voor het delen van je scherm.

[JayStout]

@Balance Artikel aangepast en aangevuld op basis van je reactie. Bedankt voor de comment! Jay

[djwice]

Ah ... daarom kan ik nu screen recording doen met de nieuwste update op m'n Chromebook!

Is wel goed geoptimaliseerd, 't werkt ook op m'n ARM-based Chromebook.

En daarom released AWS nu net webcam support voor hun workspace, ook via Chrome zonder plugin

Valt allemaal mooi samen binnen een dag of wat van elkaar.

[Reactie gewijzigd door djwice op 24 juli 2024 16:22]

[Jerie]

Wordt AV1 al toegepast voor remote desktop zoals Citrix, NX, RDP?

[P1nGu1n]

Is het mogelijk om al het HTTP verkeer te blokkeren in Chrome of Firefox, en alleen nog maar HTTPS toe te staan? Ik kreeg geen relevante zoekresultaten, toen ik ernaar zocht.

[Reactie gewijzigd door P1nGu1n op 24 juli 2024 16:22]

[n9iels]

Het is mij niet helemaal duidelijk hoe Chrome dit nu gaat doen, maar Firefox heeft sinds een tijd HTTPS-only mode: https://blog.mozilla.org/...troduces-https-only-mode/

[dec0de]

About:config -> dom.security.https_only_mode op true zetten?

Verder niet naar gekeken, dit zag ik gewoon na 1 min in about:config zoeken

En verder staat het gewoon in about:preferences#privacy helemaal onderaan, mits je een recente firefox versie hebt. De about:config zal ook bij (iets) oudere versies bestaan.

[Reactie gewijzigd door dec0de op 24 juli 2024 16:22]

[djwice]

Voor je eigen website kun je de HSTS preload header gebruiken: https://hstspreload.org/

Zo regel je dat bezoekers zelfs als ze http intypen altijd via https verbinden, ook bij het aller eerste bezoek.

Lijkt me goed idee voor alle websites die je bezoekt dat ze dat implementeren. :-)

[IIsnickerII]

Is het niet beter om je server dit gewoon af te laten handelen. Voor zover ik weet kan nginx gewoon automatisch verkeer redirecten naar https. Lijkt mij cleaner.

[Stoelpoot]

Nee, dat is juist niet cleaner. Als je dit door de server laat regelen, moet je namelijk eerst een volledig onveilig HTTP-request sturen en ontvangen om geredirect te worden. Deze redirect kan al worden onderschept.

Door jezelf op de HSTS preload list te laten plaatsen zorg je er voor dat die onveilige redirect niet meer nodig is en gebruikers altijd naar je HTTPS-website gaan.

[IIsnickerII]

Ah, top! Weer wat geleerd vandaag!

[menzo]

In Firefox wel, bij Security opties

[Marctraider]

TCP Port 80 outgoing in firewall blokkeren.

Of wat ik doe, helemaal niks behalve core networking doorlaten en via zelf gemaakt context menutje handmatig per executable ports doorlaten (In dit geval dus TCP 443) :-)

Ben je gelijk van Microsoft phone home af.

[Reactie gewijzigd door Marctraider op 24 juli 2024 16:22]

[2020Media]

Betekent dat ook voor website eigenaren dat je niet meer hoeft te redirecten naar de https versie in bijvoorbeeld je .htaccess bestand (apache)?

[djwice]

https://hstspreload.org/

Deze aanzetten op je http-header en je domein submitten, ongeveer 2 maanden later krijg je geen http verkeer meer.

Werkt al een paar jaar


Nog meer security tips?
https://observatory.mozilla.com/ alle tips uitvoeren tot je 135/100 score hebt.
Zorg voor modern configuratie:
https://ssl-config.mozill...nssl=1.1.1d&guideline=5.6
En voeg ook DNS CAA toe.

Betere conversie en minder server load?
Zorg dat alle issues uit deze test verhopen zijn en alle vinkjes groen:
https://developers.google.com/web/tools/lighthouse

Verdien je terug in no-time.


Tip: maak je content-security-policy eerst -report-only totdat je alle kinderziektes er uit heb. Maar spreek met jezelf een fixed deadline af wanneer die 'report-only' uit gaat. Zet een limiter en cache op de reporting API (alleen nieuwe rapporten wegschrijven)... of gebruik één fixed price SaaS voor het ontvangen van je rapporten.
https://report-uri.com/home/generate

[Reactie gewijzigd door djwice op 24 juli 2024 16:22]

[MrMarcie]

https://observatory.mozilla.org/ ipv com

[djwice]

tnx & correct! 'k Kan hem helaas niet meer aanpassen.

[Reactie gewijzigd door djwice op 24 juli 2024 16:22]

[Paul]

Heb je een voorbeeld van zo'n fixed price SaaS (report-uri.com ziet er erg goed uit, maar is niet fixed price) of reporting API?

Wij zijn ook bezig met CSPs en ik krijg online alleen per-report SaaS-oplossingen gevonden, of een paar regels PHP die de gePOSTte JSON omzet naar een mailtje Helaas zijn we geen ontwikkelaars, en de bedrijven die de sites wel ontwikkelen zijn niet heel snel (of genegen) in het maken van CSPs.

[djwice]

Je kunt https://report-uri.com/ of https://www.cloudflare.com/ gebruiken.

(Zie documentatie Rocket Loader) https://support.cloudflar...olicy-CSP-with-Cloudflare

Zijn niet wellicht niet 100% fixed price, maar als het uit de klauwen loopt, haal je de http-header even weg, fix je alle bevindingen die je tot dan toe hebt en zet je hem weer aan.
Hoe eerder je de bevinding aanpast (domein toevoegen aan csp http-header, script/css in een apart bestand op eigen server zetten of SHA256 van het script in de csp header opnemen) hoe minder CSP rapporten je krijgt.

Dus als je hem aanzet, zorg dat je tijd hebt om hem weer even uit te zetten en de bevindingen aan te passen - en weer aan te zetten.

Begin met https://developer.mozilla...curity-Policy-Report-Only zodat je de werking van je website niet verstoord terwijl je de CSP aan het optimaliseren bent. Als je geen meldingen meer krijgt van content die je zelf op je website hebt laten zetten, dan kun je hem omzetten naar https://developer.mozilla...s/Content-Security-Policy

Het voordeel van report-uri.com is dat deze persoon gespecialiseerd is en CSP echt op de kaart heeft gezet; dus de rapporten en tools zijn denk ik de beste op dit gebiedt. Het voordeel van cloudflare is dat je nog veel meer veiligheidstools en ook website versnelling tot je beschikking krijgt: dat kan ook overweldigend zijn, hangt er een beetje van af.

[Reactie gewijzigd door djwice op 24 juli 2024 16:22]

[n9iels]

Nee dat moet je absoluut nog steeds doen. Ten eerste uiteraard omdat niet iedereen op de wereld de laatste versie van Google Chrome gebruikt (godzijdank niet). Maar ook van wege SEO redenen moet je dat zeker blijven doen. Zoekmachines vinden het namelijk niet leuk als jou website op meerdere manieren benaderbaar is (http, https, http://www, https://www).

[Reactie gewijzigd door n9iels op 24 juli 2024 16:22]

[Vibonacci]

Daarvoor bestaat het concept: canonical links.

[ultimasnake]

Zeker wel, google geeft al aan datn je http:// typed je niet geforceerd (door chrome) naar https gaat. Iemand die dit nog blind typed of een bookmark zo heeft staan zal dan dus op de http versie draaien

(En natuurlijk alle argumenten hierboven van anderen)

[mjz2cool]

Search Engine Optimization.
De vindbaarheid van je website is onder andere afhankelijk van hoe je .htaccess bestand eruit ziet.

[xFeverr]

Alleen ziet Google dat bestand niet. En draait niet iedereen een Apache webserver.

Je bedoelt waarschijnlijk hoe je URL's er uit zien.

[Strebor]

Apache leest de .htaccess. Niet Google (of Chrome).
Dus als jij in de .htaccess directives zet om verkeer te redirecten naar https of verkeer vanaf een IP te blokkeren, of whatever, dan is het Apache die dat doet, en niet Chrome.

[xFeverr]

dat zeg ik toch Google ziet de bestanden niet, waarmee ik bedoel te zeggen dat niemand die bestanden kan zien.

[Strebor]

Ah, ik begreep je verkeerd... ook goedemorgen

[Ablaze]

Zou dat nog echt zo zijn? Ik denk dat Google toch wel zo slim is om de https versie te pakken. En je geeft je website (plus sitemap) waarschijnlijk toch op via de Search Console.

Het voordeel is dat je weer een poort dicht kunt zetten en je configuratie makkelijker wordt. Ook heb je nooit het risico dat je per ongeluk inloggegevens stuurt via een http verbinding.

[n9iels]

Mwah ja oke dat zou bij nieuwere websites of websites die lang en breed zijn gemigreerd naar HTTPS zeker een optie zijn. Als zou ik zelf niet direct weten waarom je dat perse zou willen Het is niet dat er via port 443 minder troep binnen komt.

[VTOLfreak]

Poortnummer is niet gelijk aan protocol. http://mijnsite.nl:443/ en https://mijnsite.nl:80/ zijn perfect valide URL's. Je moet de configuratie aanpassen in je webserver zodat deze in zijn geheel geen HTTP meer accepteert of op zijn minst strikte port bindings zodat HTTP requests enkel op poort 80 zijn toegelaten.

Poorten blokkeren is zeker noodzakelijk maar het is verkeerd om te denken als je een default port dicht hebt gezet dat je dan een bepaald protocol hebt geblokkeerd.

[Paul]

Naar mijn mening is dat veel te vroeg. Chome is niet de enige browser, en zelfs als dat wel zo was dan nog heeft niet iedereen de laatste versie.

Waar ik wel absoluut voorstander van ben (en wat ik overal waar ik dat voor het zeggen heb ook heb ingesteld) is via HTTP niets anders te sturen dan redirects naar HTTPS.

[Michaelr1]

Ik wil mijn attack surface altijd zo klein mogelijk houden. Een redirect naar HTTPS stel ik om die reden oik al jaren niet meer in. HTTP & Poort 80 staan waar ik werk ook al een jaar of 10 dicht.

[Paul]

Ik ga er vanuit dat je weet wat je doet (of daar zelf de gevolgen van moet dragen), maar als je dat doet op websites waarvan mensen het adres in de browser intypen, dan loop je een heleboel (potentiële) klanten mis.

Daarnaast, als je die redirect laat afhandelen door dezelfde Netscaler / F5 / NGINX / Apache / IIS als de rest van het verkeer is het geen additioneel attack surface; gaat allemaal door dezelfde engine.

[Verwijderd]

Niet alleen een .htaccess file draagt daar aan bij. Maar ook zou je je site moeten opzetten en insturen voor HSTS.
https://hstspreload.org/

[Tadango]

Kan je dat https first ook uitzetten? Ik werk voornamelijk met dev / interne sites op http en heb geen zin om overal http voor te moeten typen. Eens zoeken of er een flag is daarvoor....

[Primuszoon]

In de blogpost https://blog.chromium.org...for-navigation-https.html

For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails (including when there are certificate errors, such as name mismatch or untrusted self-signed certificate, or connection errors, such as DNS resolution failure)

en ook:

IP addresses, single label domains, and reserved hostnames such as test/ or localhost/ will continue defaulting to HTTP.

[Tadango]

Top, dat maakt het een stuk bruikbaarder.

[GeroldM]

Inderdaad, zal hier ook moeten gebeuren ben ik bang. Gevalletje noodgedwongen.

Ben woonachtig in Paraguay. op een mooie locatie, vind ik zelf. Probleem 1 is dat er maar ISP internet levert op dit adres. Beheer zelf een mail server, website, Nextcloud, wiki, DNS enz. Maar omdat ik alles zelf moet hosten (contractuele verplichtingen waar klanten expliciet aangeven hun data (voor het fixen van issues) niet in de Cloud willen), heb ik dus een IP adres bij deze ene ISP moeten aanschaffen. Domeinen regelen ze niet, dus deze geregeld via de club die domeinen beheert voor dit hele land.

Ging zo'n 14 jaar prima. Maar de laatste tijd is men dus aan het focussen op HTTPS. Nu is mijn DNS server goed ingeregeld voor forward and reverse DNS requests. Alleen gooit de DNS server van de ISP roet in het eten bij reverse DNS requests.

Hen daarop aangesproken en krijg het antwoord: wij beheren DNS niet. Het probleem ook aangekaart bij de nationale domein beheerder. Daar krijg ik het antwoord: moet je ISP regelen. Wacht eens even, dat spelletje ken ik al. Kastje naar de muur en weer terug. Sorry, gabinete para muro y volver....alles gaat in de Zuid-Amerikaanse variant van Spaans.

Kan dus nergens een certificaat aanvragen, want de reverse DNS klopt niet. Hierdoor krijgt mijn mailserver een maximale reputatie score van 95 uit 100 punten sinds men alsmaar meer en meet op HTTPS en beveiligde mail is gaan focussen. Daarvoor had de server jarenlang een reputatiescore van 100. Want het ding is wel degelijk goed en zo veilig mogelijk ingeregeld.

Toch is die relatief kleine deuk in de score voldoende voor Google, Microsoft en andere grote mailbeheerders om mail van mijn server te negeren. Op zich wel begrijpelijk, daar niet van. Het is echter geen onwil vanuit mijn kant dat er tot op heden geen mogelijkheden zijn om extra beveiliging zoals HTTPS toe te passen, puur vanwege dit ff-ing "kastje - muur" spel waar ik onvrijwillig deelnemer ben.

Chrome is hier in dit werelddeel ook een heel populaire browser, dus verwacht een boel ellende van deze Google strapatsen. De bedinging dat ik hier op eigen servers data heb staan voor het fixen van issues (en daarna ook via voorafgesproken procedures verwijder nadat de fix door de klant is geaccepteerd) heeft al een hoop voeten in de aarde gehad. Ga daar niet weer doorheen voor een server in een datacenter.

HTTPS is in mijn geval meer een vloek dan een zegen. Bovenstaand verhaal zou duidelijk moeten maken dat ik wel een voorstander van HTTPS ben, maar het dus ook vrees vanwege idioterij van derden.

[OruBLMsFrl]

Gegeven:
- Ga daar niet weer doorheen voor een server in een datacenter.
- Alleen gooit de DNS server van de ISP roet in het eten bij reverse DNS requests. Hen daarop aangesproken en krijg het antwoord: wij beheren DNS niet.

Blijft over
-> andere ISP

Het is trouwens ofwel de ISP die het moet regelen, of een nog grotere ISP waar die van jou inkoopt (nog altijd niet jouw probleem, maar goed, de wereld kan eens weerbarstig zijn). Je kunt ook altijd nagaan bij welk bedrijf jouw IP netblock geregistreerd is vanuit de IANA en onderliggende number registries, zal LACNIC zijn in jouw geval?
https://www.iana.org/numbers

Op basis daarvan zal die reserve DNS toch ook legit moeten verlopen. De authoritive DNS server voor jouw number block zo vinden geeft je dan hopelijk meteen een hint wie dat zou moeten instellen ook. Succes

[Reactie gewijzigd door OruBLMsFrl op 24 juli 2024 16:22]

[deadinspace]

Kan dus nergens een certificaat aanvragen, want de reverse DNS klopt niet.

Welke CA doet een reverse DNS check? Ik ben dat nog nooit tegengekomen eigenlijk...

[Tadango]

Let's encrypt ook niet toch? Kwestie van je bewijs op het domein plaatsen en het valideert.

[computerbart]

Volgens mij heeft Let's Encrypt geen reverse DNS nodig. En ook nog lekker goedkoop

[Koffie]

De bemoeizucht van Google weer. Eerst www verbergen, nu default naar https wat geen standaard is.
Als ik een readonly site bezoek, zal het mij jeuken dat het plaintext is.

[Verwijderd]

Dat zou je wel moeten jeuken:
https://www.troyhunt.com/...atic-website-needs-https/

[luuk34]

En nu gewoon in 1 paragraaf zonder dat 'geneuzel' dat he makkelijk is om te configureren. Want dat heeft toch NIETS te maken met dat HTTP onveilig zou zijn?

Waarom moet ik nu HTTPS doen? Voor een readonly site waar geen wachtwoorden worden verstuurd, zoals bijvoorbeeld tweakers.net (als je hier alleen die onzinnige reactie leest onder veel artikelen) dan lijkt mij HTTPS nog steeds overkill..

[Henk Poley]

Hier heb je 'm:

Alles tussen de webserver en jouw computer kan HTTP verkeer ongezien aanpassen. Er kan bijvoorbeeld malware of reclame toegevoegd worden. Dit is ook al gebeurt/gedaan. Je brengt al je bezoekers in gevaar door nog HTTP te gebruiken.

[Verwijderd]

Je kunt artikel lezen toch, of niet? Omdat zelfs statische websites last kunnen krijgen van een MITM, door geïnfecteerde routers en computers.

Aangezien je op Tweakers (persoonlijke) informatie verstuurd, is HTTPS wel degelijk wenselijk. HTTP is onveilig, omdat alle data in transit op elk punt onderschept of aangepast kan worden.

[BeosBeing]

Je kunt artikel lezen toch, of niet?

Er valt heel weinig te lezen op die site. Vrijwel alle info zit in een 24min durende video.

Omdat zelfs statische websites last kunnen krijgen van een MITM, door geïnfecteerde routers en computers.

Kijk daar geef jij een geldige reden. Die website van @Verwijderd zet dat in vaag verhaal over dat https opzetten zo simpel is en waarbij je dus die 24 minuten kutvideo moet luisteren wil je dit horen.

Aangezien je op Tweakers (persoonlijke) informatie verstuurd, is HTTPS wel degelijk wenselijk. HTTP is onveilig, omdat alle data in transit op elk punt onderschept of aangepast kan worden.

Als je op tweakers persoonlijke informatieverstuurd, dan ben je ingelogd. Dan is https zeker zinvol, al hecht ik daar minder waarde aan, als aan encryptie op de sites voor webmail en bankzaken.

[Verwijderd]

Diegene op wie je reageert en die het linkje postte ben ik ;-)

Er valt heel weinig te lezen op die site. Vrijwel alle info zit in een 24min durende video.

Goed, ik post een informatiebron omdat iemand misinformatie aan het posten is, als het formaat iemand niet aanstaat is dat zijn/haar probleem. Paar minuten een educatieve video kijken is een goede investering van tijd :-) die "kutvideo" is overigens een demo over hoe dat in z'n werk gaat en waar je voor moet uitkijken. Lijkt me prima passen in dit gesprek.

Als je op tweakers persoonlijke informatieverstuurd, dan ben je ingelogd.

Nou, niet precies. Reclame en andere tracking tools halen ook informatie over je op uit je browser. Ook je browse-gedrag is persoonlijke informatie. Tenzij de hele wereld je browser-historie mag zien natuurlijk.

[BeosBeing]

Paar minuten een educatieve video kijken is een goede investering van tijd :-)

Voor iemand die een website gaat opzetten absoluut. Voor iemand die alleen browst is het een grove verspilling van tijd, en wie tussendoor even op tweakers kijkt, en geen anderen wilt storen met videio-geluid (zeker als het collega's zijn) is een video absoluut not done.
Alles wat er over te zeggen is, is samen te vatten in een paar zinnetjes:
1) Omdat zelfs statische websites last kunnen krijgen van een MITM, door geïnfecteerde routers en computers.
2) Alles tussen de webserver en jouw computer kan HTTP verkeer ongezien aanpassen. Er kan bijvoorbeeld malware of reclame toegevoegd worden. Dit is ook al gebeurt/gedaan. Je brengt al je bezoekers in gevaar door nog HTTP te gebruiken.
3) Tegenwoordig weet je zonder https, dus niet meer zeker of je bezoeker wel te zien krijgt wat jij wilt laten zien.
4) De tekst die de bezoeker ziet kan veranderd zijn en een andere boodschap overbrengen dan wat jij wilt, er kan zelfs malware aan zijn toegevoegd.

Daarvoor hoef ik geen 24-minuten video te kijken.

[Verwijderd]

Voor iemand die alleen browst is het een grove verspilling van tijd

Er mag best wel meer educatie over dit soort onderwerpen. Het grootste deel van ons werk en vrije tijd hangt samen met het internet en mensen die in allerlei onzin trappen of online slachtoffer zijn, wordt steeds groter. Zo'n instelling als die van Koffie en luuk34 helpt daar totaal niet bij, die in hun onwetendheid als kinderen "boeien" roepen op het internet.

[Keypunchie]

@koffie
Hoezo geen standaard?

Genoeg sites die https-only zijn (en terecht)

Je bedoelt misschien dat het niet gebruikelijk was. Maar https is een standaard.

[Koffie]

https is een standaard ja, maar niet dé default standaard voor een website. Dat is namelijk plain http

[Zackito]

Ben benieuwd hoeveel klanten er weer gaan bellen, website doet het niet

[MrAndy9797]

Ben benieuwd hoeveel klanten er weer gaan bellen, website doet het niet

Welke klanten? Want als ( -als ze je daar al echt voor zouden bellen- ) ze daarvoor bellen, heb je na jaren van aankondiging je website nog steeds niet in orde lijkt me.

Los van het feit dat de overgrote meerderheid gewoon verder gaat met hun zoektocht naar een wel-werkende website

[Reactie gewijzigd door MrAndy9797 op 24 juli 2024 16:22]

[gwartena]

Ik gok dat Zackito niet op zijn eigen website doelt, maar dat hij eindgebruikers (klanten) aan de lijn gaat krijgen die met Chrome niet meer naar bepaalde sites kunnen surften (sites niet beheerd door Zackito). Maar goed, dat is een gok...

[Zackito]

Klopt inderdaad, ik zit gelukkig al jaren niet meer op een servicedesk functie maar kan me voorstellen wat er gaat gebeuren.

[sjenkie97]

Ik heb in de instellingen van Firefox ingesteld dat alle adressen htpps verplicht moeten zijn. Voorheen (heb het nog steeds geinstalleerd als browser plugin) had ik HTTPSeverywhere

[Strebor]

Ik ben benieuwd wat dit gaan doen door simpele DNS webredirects aangeboden door diverse DNS diensten.

In diverse DNS systemen kun je bijvoorbeeld heel simpel een webredirect zetten. Je kunt dan bijvoorbeeld http://oudehostnaam.domein.nl doorsturen naar https://nieuwehostnaam.anderdomein.nl.

Maar dat werkt niet met HTTPS (zojuist gechecked bij een tweetal diensten).

Uiteraard is redirecten geen DNS functie en zit er in de werkelijkheid een webserver tussen. Dus de hostnaam is in werkelijk een A record naar een webserver van de DNS dienst, die weet waar hij bezoekers naar jouw hostnaam naartoe moet sturen.

De DNS providers zullen dus een TLS certificaat moeten gaan bijhouden per hostnaam. Op zich moet dat volautomatisch kunnen met letsencrypt.

[Keypunchie]

[dubbelpost]

[Reactie gewijzigd door Keypunchie op 24 juli 2024 16:22]

[holoduke51]

Goed om te weten dat Chrome privacy niet respecteert. Advies om Chrome niet meer te gebruiken. https://www.floc-away-from-chrome.com/