Updates
23 maart 2023 : de tijdlijn is bijgewerkt en de beëindiging zal pas plaatsvinden in Chrome 117.
19 januari 2023 : de tijdlijn is bijgewerkt en de beëindiging zal pas plaatsvinden in Chrome 114.
12 augustus 2022 : de tijdlijn is bijgewerkt en de beëindiging zal pas plaatsvinden in Chrome 109.
10 februari 2022 : Er is een bijgewerkt artikel gepubliceerd op Private Network Access: introductie van preflights
25 augustus 2021 : bijgewerkte tijdlijnaankondiging en introductie van een beëindigingsproef.
Chrome beëindigt de toegang tot particuliere netwerkeindpunten vanaf niet-beveiligde websites als onderdeel van de Private Network Access- specificatie. Het doel is om gebruikers te beschermen tegen cross-site request forgery (CSRF)-aanvallen gericht op routers en andere apparaten op particuliere netwerken. Deze aanvallen hebben honderdduizenden gebruikers getroffen , waardoor aanvallers hen naar kwaadaardige servers konden omleiden.
Chrome introduceert de volgende wijzigingen:
- Blokkeer verzoeken aan privénetwerken van onveilige openbare websites vanaf Chrome 94.
- Introductie van een beëindigingsproef die eindigt in Chrome
- Hierdoor kunnen ontwikkelaars een tijdsverlenging aanvragen voor de gekozen oorsprong, wat niet zal veranderen tijdens de beëindigingsproef.
- Er wordt een Chrome-beleid geïntroduceerd waarmee beheerde Chrome-implementaties de beëindiging permanent kunnen omzeilen. Verkrijgbaar in Chroom 92.
Als u meer tijd nodig heeft om de impact van het beëindigingsregister voor de beëindigingsproef te beperken.
Als u beheerderscontrole heeft over uw gebruikers, kunt u de functie opnieuw inschakelen met behulp van het Chrome-beleid.
Gebruik een van de volgende strategieën om de impact van de nieuwe beperkingen te verzachten:
- Upgrade uw website naar HTTPS en indien nodig de doelserver .
- Upgrade uw website naar HTTPS en gebruik WebTransport .
- Keer de inbeddingsrelatie om .
Tijdlijn
- November 2020: Oproep voor feedback over de komende wijzigingen.
- Maart 2021: Na het beoordelen van de feedback en het doen van outreach worden komende wijzigingen aangekondigd. De specificatie is hernoemd van CORS-RFC1918 naar Private Network Access.
- April 2021: Chrome 90 wordt uitgerold naar Stabiel, waardoor er waarschuwingen over beëindiging verschijnen.
- Juni 2021: Chrome 92 wordt uitgerold naar bèta en verbiedt privénetwerkverzoeken vanuit onveilige contexten. Na feedback van ontwikkelaars die meer tijd hebben gevraagd om zich aan te passen, wordt de beëindiging uitgesteld naar Chrome 93, vergezeld van een beëindigingsproef.
- Juli 2021: Na verdere feedback van ontwikkelaars worden de beëindiging en de bijbehorende proefperiode uitgesteld naar Chrome 94. Bovendien hebben privéwebsites geen last meer van de beëindiging.
- Augustus 2021: Chrome 94 wordt uitgerold naar bèta. Webontwikkelaars kunnen zich aanmelden voor de beëindigingsproef.
- September 2021: Chrome 94 wordt uitgerold naar Stable. Webontwikkelaars hadden zich moeten aanmelden voor de beëindigingsproef en proeftokens in productie moeten nemen.
- December 2022: Origin-proefenquête verzonden en feedback ontvangen. De beëindigingsproefperiode wordt uitgebreid naar Chrome 113.
- Maart 2023: De beëindigingsproef wordt uitgebreid naar Chrome 116 en eindigt in Chrome 117. Er wordt gewerkt aan een op toestemming gebaseerd alternatief mechanisme , gericht op de eerste release in Chrome 114.
- Mei 2023 (voorlopig): het op toestemming gebaseerde mechanisme wordt uitgerold in Chrome 114. Websites kunnen het gebruiken om de beëindigingsproef te beëindigen.
- September 2023: Chrome 117 wordt uitgerold naar Stabiel, waarmee de beëindigingsproef wordt beëindigd. Chrome blokkeert alle privénetwerkverzoeken vanuit openbare, niet-beveiligde contexten.
Wat is particuliere netwerktoegang
Private Network Access (voorheen bekend als CORS-RFC1918) beperkt de mogelijkheid van websites om verzoeken te verzenden naar servers op particuliere netwerken. Het staat dergelijke verzoeken alleen toe vanuit beveiligde contexten. De specificatie breidt ook het Cross-Origin Resource Sharing (CORS)-protocol uit, zodat websites nu expliciet een subsidie moeten aanvragen bij servers op particuliere netwerken voordat ze willekeurige verzoeken mogen verzenden.
Privénetwerkverzoeken zijn verzoeken waarvan het IP-adres van de doelserver meer privé is dan dat waarvan de verzoekinitiator is opgehaald. Bijvoorbeeld een verzoek van een openbare website ( https://example.com ) aan een privéwebsite ( http://router.local ), of een verzoek van een privéwebsite aan localhost.
Meer informatie vindt u op Feedback gezocht: CORS voor particuliere netwerken (RFC1918) .
Wat is een beëindigingsproef?
Beëindigingsproeven (voorheen bekend als reverse origin-proeven) zijn een vorm van oorsprongsproeven die worden gebruikt om de beëindiging van webfuncties te vergemakkelijken. Met beëindigingsproeven kan Chrome bepaalde webfuncties afschaffen en voorkomen dat websites er nieuwe afhankelijkheden van vormen, terwijl de huidige afhankelijke websites tegelijkertijd extra tijd krijgen om daarvan af te migreren.
Tijdens een beëindigingsproefperiode zijn de beëindigde functies standaard niet beschikbaar voor alle websites. Ontwikkelaars die de getroffen functies nog steeds moeten gebruiken, moeten zich aanmelden voor de beëindigingsproef en tokens verkrijgen voor specifieke weboorsprongen, en vervolgens hun websites aanpassen om die tokens weer te geven in HTTP-headers of metatags (behalve in dit geval). Als een website geldige tokens aanbiedt die overeenkomen met hun oorsprong, staat Chrome het gebruik van de verouderde functie gedurende een beperkte tijd toe.
Voor meer informatie raadpleegt u Aan de slag met de origin-proefversies van Chrome en de handleiding voor webontwikkelaars over origin-proefversies voor instructies.
Wat verandert er in Chrome
Chroom 94
Vanaf Chrome 94 is het voor openbare, niet-beveiligde contexten (in het algemeen websites die niet via HTTPS of vanaf een privé-IP-adres worden geleverd) verboden om verzoeken in te dienen bij het particuliere netwerk. Dit was eerder gepland voor Chrome 92, waardoor beëindigingsberichten mogelijk nog steeds de eerdere mijlpaal vermelden.
Deze beëindiging gaat gepaard met een beëindigingsproef, waardoor webontwikkelaars waarvan de websites gebruik maken van de verouderde functie deze kunnen blijven gebruiken tot Chrome 116 door zich te registreren voor tokens. Zie hieronder voor instructies over hoe u zich kunt registreren en de proefversie op uw website kunt inschakelen.
Er kan gebruik worden gemaakt van een paar Chrome-beleidsregels om de beëindiging voor onbepaalde tijd geheel of voor specifieke bronnen uit te schakelen. Hierdoor zijn beheerde Chrome-installaties mogelijk, bijvoorbeeld in bedrijfsomgevingen, om breuk te voorkomen.
Chroom 117
De beëindigingsperiode eindigt. Alle websites moeten worden gemigreerd van de beëindigde functie, of het beleid van hun gebruikers moet worden geconfigureerd om de functie te blijven inschakelen.
Aanbevolen ontwikkelaarsacties
De eerste stap voor getroffen websites zal hoogstwaarschijnlijk enige tijd duren voordat een goede oplossing kan worden geïmplementeerd: door zich te registreren voor de beëindigingsproef of door beleid te gebruiken. Vervolgens varieert de aanbevolen handelwijze afhankelijk van de omstandigheden van elke betrokken website.
Registreer u voor de beëindigingsproef
- Klik op Register for the Private Network Access from non-secure contexts origin proefversie om een proeftoken voor de deelnemende oorsprong te verkrijgen.
- Voeg de oorsprongspecifieke
Origin-Trial: $tokenaan uw antwoordheader . Deze antwoordkop hoeft alleen te worden ingesteld op hoofdbron- en navigatiereacties wanneer het resulterende document gebruik maakt van de verouderde functie. Het is nutteloos (hoewel onschadelijk) om deze header aan subresource-reacties toe te voegen.
Omdat deze proefversie moet worden in- of uitgeschakeld voordat een document verzoeken mag doen, kan deze niet worden ingeschakeld via een <meta> -tag. Dergelijke tags worden alleen uit de antwoordtekst geparseerd nadat mogelijk subresourceverzoeken zijn uitgegeven. Dit vormt een uitdaging voor websites die geen controle hebben over responsheaders, zoals statische websites van github.io die worden bediend door een derde partij.
Voor meer details, zie de Webontwikkelaarshandleiding voor origin-proefversies .
Beleid inschakelen
Als u beheerderscontrole heeft over uw gebruikers, kunt u de beëindigde functie opnieuw inschakelen met behulp van een van de volgende beleidsregels:
Raadpleeg dit Helpcentrum-artikel voor meer informatie over het beheren van beleid voor uw gebruikers.
Toegang tot localhost
Als uw website verzoeken moet indienen bij localhost, hoeft u alleen maar uw website te upgraden naar HTTPS .
Verzoeken die gericht zijn op http://localhost (of http://127.*.*.* , http://[::1] ) worden niet geblokkeerd door gemengde inhoud, zelfs niet als ze vanuit een beveiligde context worden verzonden.
Houd er rekening mee dat de WebKit-engine en de daarop gebaseerde browsers (met name Safari) hier afwijken van de W3C Mixed Content-specificatie en deze verzoeken verbieden als Mixed Content . Ze implementeren ook geen Private Network Access, dus websites willen klanten die dergelijke browsers gebruiken mogelijk omleiden naar een HTTP-versie van de website in platte tekst, die door dergelijke browsers nog steeds wordt toegestaan om verzoeken aan localhost te doen.
Toegang tot privé-IP-adressen
Als uw website verzoeken moet versturen naar een doelserver op een privé-IP-adres, dan werkt het eenvoudigweg upgraden van de initiatorwebsite naar HTTPS niet. Gemengde inhoud voorkomt dat beveiligde contexten verzoeken indienen via HTTP in platte tekst, zodat de nieuw beveiligde website nog steeds niet in staat zal zijn de verzoeken uit te voeren. Er zijn een paar manieren om dit probleem op te lossen:
- Upgrade beide uiteinden naar HTTPS.
- Gebruik WebTransport om veilig verbinding te maken met de doelserver.
- Keer de inbeddingsrelatie om.
Upgrade beide uiteinden naar HTTPS
Deze oplossing vereist controle over de DNS-resolutie van gebruikers, zoals het geval kan zijn in intranetcontexten, of als gebruikers de adressen van hun naamservers verkrijgen van een DHCP-server die u beheert. Het vereist ook dat u over een publieke domeinnaam beschikt.
Het grootste probleem bij het aanbieden van particuliere websites via HTTPS is dat certificeringsinstanties voor openbare sleutelinfrastructuur (PKI CA) alleen TLS-certificaten verstrekken aan websites met publieke domeinnamen. Om dit te omzeilen:
- Registreer een openbare domeinnaam (bijvoorbeeld
intranet.example) en publiceer DNS-records die die domeinnaam naar een openbare server van uw keuze verwijzen. - Verkrijg een TLS-certificaat voor
intranet.example. - Configureer binnen uw privénetwerk DNS om
intranet.exampleom te zetten in het privé-IP-adres van de doelserver. - Configureer uw privéserver om het TLS-certificaat voor
intranet.examplete gebruiken. Hierdoor hebben uw gebruikers toegang tot de privéserver ophttps://intranet.example.
Vervolgens kunt u de website die de verzoeken initieert upgraden naar HTTPS en doorgaan met het indienen van de verzoeken zoals voorheen.
Deze oplossing is toekomstbestendig en vermindert het vertrouwen dat u in uw netwerk stelt, waardoor het gebruik van end-to-end-encryptie binnen uw privénetwerk wordt uitgebreid.
WebTransport
Deze oplossing vereist geen controle over de DNS-resolutie van uw gebruikers. Het vereist wel dat de doelserver een minimale WebTransport-server draait (HTTP/3-server met enkele aanpassingen).
U kunt het ontbreken van een geldig TLS-certificaat, ondertekend door een vertrouwde CA, omzeilen door WebTransport en het bijbehorende mechanisme voor het vastzetten van certificaten te gebruiken. Hierdoor kunt u veilige verbindingen tot stand brengen met privéapparaten die bijvoorbeeld een zelfondertekend certificaat hebben. WebTransport-verbindingen maken bidirectionele gegevensoverdracht mogelijk, maar kunnen geen verzoeken ophalen. U kunt deze aanpak combineren met een servicemedewerker om op transparante wijze HTTP-verzoeken via de verbinding te proxyen, vanuit het oogpunt van uw webapplicatie. Aan de serverzijde kan een overeenkomstige vertaallaag de WebTransport-berichten omzetten in HTTP-verzoeken.
We erkennen dat dit een behoorlijke hoeveelheid werk met zich meebrengt, maar het zou aanzienlijk eenvoudiger moeten zijn dan bouwen bovenop WebRTC; onze hoop is ook dat een deel van de noodzakelijke investeringen wordt geïmplementeerd in de vorm van herbruikbare bibliotheken. Wij zijn ook van mening dat dit vooral de moeite waard is, gezien het feit dat niet-beveiligde contexten waarschijnlijk de toegang tot steeds meer webplatformfuncties zullen verliezen naarmate het platform in de loop van de tijd steeds meer HTTPS-gebruik op sterkere manieren aanmoedigt. Ongeacht de particuliere netwerktoegang zou dit waarschijnlijk sowieso een verstandige investering zijn.
We verwachten dat WebTransport via HTTP/3 wordt geleverd in Chrome 96 (er is een origin-proefversie gestart) met maatregelen ter bescherming tegen het delen van sleutels en andere ondermaatse beveiligingspraktijken, waaronder:
- Een korte maximale vervaltijd voor vastgezette certificaten.
- Een browserspecifiek mechanisme voor het intrekken van bepaalde sleutels die onderhevig zijn aan misbruik.
We zullen de veilige contextbeperking pas verzenden ten minste twee mijlpalen nadat WebTransport volledig is uitgerold. Indien nodig wordt de beëindigingsproef verlengd.
Omgekeerde inbedding
Deze oplossing vereist geen administratieve controle over het netwerk en kan worden gebruikt wanneer de doelserver niet krachtig genoeg is om HTTPS uit te voeren.
In plaats van privé-subbronnen op te halen van een openbare web-app, kan een skelet van de app worden geserveerd vanaf de privé-server, die vervolgens alle subbronnen (zoals scripts of afbeeldingen) ophaalt van een openbare server, zoals een CDN. De resulterende web-app kan vervolgens verzoeken indienen bij de privéserver, omdat deze als dezelfde oorsprong worden beschouwd. Het kan zelfs verzoeken doen aan andere servers met privé-IP's (maar niet aan localhost), hoewel dit op de lange termijn kan veranderen.
Door alleen een skelet op de privéserver te hosten, kunt u de webapp bijwerken door nieuwe bronnen naar de openbare server te pushen, net zoals u een openbare webapp zou bijwerken. Aan de andere kant is de resulterende webapp geen veilige context en heeft dus geen toegang tot enkele van de krachtigere functies van internet.
Plannen voor de toekomst
Het beperken van particuliere netwerkverzoeken om contexten te beveiligen is slechts de eerste stap bij het lanceren van Private Network Access. Chrome werkt eraan om de rest van de specificatie de komende maanden te implementeren. Blijf op de hoogte voor updates!
Beperking van localhost-toegang vanaf privéwebsites
De wijzigingen in Chrome 94 zijn alleen van invloed op openbare websites die toegang hebben tot privé-IP-adressen of localhost. De Private Network Access-specificatie classificeert verzoeken van particuliere websites aan localhost ook als problematisch. Chrome zal deze uiteindelijk ook afschaffen. Dit brengt echter een iets andere reeks uitdagingen met zich mee, aangezien veel particuliere websites geen domeinnamen hebben, wat het gebruik van proefversietokens bemoeilijkt.
CORS-preflightverzoeken
Het tweede deel van Private Network Access is het afschermen van particuliere netwerkverzoeken die vanuit een beveiligde context worden geïnitieerd met CORS-preflightverzoeken . Het idee is dat zelfs als het verzoek vanuit een veilige context is geïnitieerd, de doelserver wordt gevraagd om expliciet toestemming te geven aan de initiator. Het verzoek wordt alleen verzonden als de subsidie succesvol is.
Kortom, een CORS-preflightverzoek is een HTTP OPTIONS verzoek met enkele Access-Control-Request-* headers die de aard van het daaropvolgende verzoek aangeven. De server kan vervolgens beslissen of er al dan niet fijnmazige toegang wordt verleend door 200 OK te reageren met Access-Control-Allow-* headers.
Meer details hierover vindt u in de specificatie .
Beperk navigatie-ophaalacties
Chrome beëindigt en blokkeert uiteindelijk verzoeken om subresources aan privénetwerken. Dit heeft geen invloed op de navigatie naar particuliere netwerken, die ook kunnen worden gebruikt bij CSRF- aanvallen.
De Private Network Access-specificatie maakt geen onderscheid tussen de twee soorten ophaalacties, die uiteindelijk aan dezelfde beperkingen onderworpen zullen zijn.
Omslagfoto door Markus Spiske op Unsplash