Aggiornamento di Private Network Access: presentazione di una prova di ritiro

Aggiornamenti

• 23 marzo 2023: le tempistiche sono state aggiornate e il ritiro non avverrà prima di Chrome 117.

• 19 gennaio 2023: le tempistiche sono state aggiornate e il ritiro non avverrà fino a Chrome 114.

• 12 agosto 2022: la sequenza temporale è stata aggiornata e il ritiro non avverrà fino a Chrome 109.

• 10 febbraio 2022: è stato pubblicato un articolo aggiornato all'indirizzo Accesso alla rete privata: presentazione dei preflight

• 25 agosto 2021: aggiornamento dell'annuncio delle tempistiche e introduzione di una prova di ritiro.

Nell'ambito della specifica Private Network Access, Chrome ritirerà l'accesso agli endpoint di rete privata da siti web non sicuri. Lo scopo è proteggere gli utenti dagli attacchi di falsificazione delle richieste cross-site (CSRF) che hanno come target router e altri dispositivi su reti private. Questi attacchi hanno colpito centinaia di migliaia di utenti, consentendo a utenti malintenzionati di reindirizzarli a server dannosi.

Chrome introdurrà le seguenti modifiche:

• Blocco delle richieste alle reti private da siti web pubblici non sicuri a partire da Chrome 94.
• Ti presentiamo una prova relativa al ritiro che terminerà in Chrome
  1. Consentirà agli sviluppatori di richiedere un'estensione temporale per le origini scelte, che non saranno interessate durante la prova del ritiro.
• Presentazione di un criterio di Chrome che consentirà ai deployment di Chrome gestiti di bypassare definitivamente il ritiro. Disponibile in Chrome 92.

Se hai bisogno di più tempo per mitigare l'impatto del ritiro, registrati per la prova del ritiro.

Se disponi del controllo amministrativo sugli utenti, puoi riattivare la funzionalità utilizzando i criteri di Chrome.

Per mitigare l'impatto delle nuove limitazioni, utilizza una delle seguenti strategie:

• Esegui l'upgrade del tuo sito web a HTTPS e, se necessario, del server di destinazione.
• Esegui l'upgrade del tuo sito web a HTTPS e utilizza WebTransport.
• Inverti la relazione di incorporamento.

Cronologia

• Novembre 2020: richiesta di feedback sulle modifiche imminenti.
• Marzo 2021: dopo aver esaminato i feedback e aver effettuato attività di informazione, vengono annunciate le modifiche imminenti. La specifica viene rinominata da CORS-RFC1918 in Accesso alla rete privata.
• Aprile 2021: implementazione di Chrome 90 nella versione stabile, con avvisi di ritiro.
• Giugno 2021: Chrome 92 viene implementato nella versione beta, per impedire l'offerta di richieste di rete privata provenienti da contesti non sicuri. In seguito al feedback degli sviluppatori che hanno richiesto più tempo per adattarsi, il ritiro è stato posticipato a Chrome 93 e sarà accompagnato da una prova di ritiro.
• Luglio 2021: a seguito di ulteriori feedback degli sviluppatori, il ritiro e la relativa prova vengono rinviati a Chrome 94. Inoltre, i siti web privati non sono più interessati dal ritiro.
• Agosto 2021: introduzione di Chrome 94 nel canale beta. Gli sviluppatori web possono iniziare a registrarsi per la prova relativa al ritiro.
• Settembre 2021: implementazione di Chrome 94 nella versione stabile. Gli sviluppatori web devono aver eseguito la registrazione per la prova relativa al ritiro e aver implementato i token di prova in produzione.
• Dicembre 2022: sondaggio sulla prova dell'origine inviato e feedback ricevuti. La prova di ritiro è stata estesa a Chrome 113.
• Marzo 2023: la prova del ritiro è estesa a Chrome 116 e dovrebbe terminare in Chrome 117. È in fase di sviluppo un meccanismo alternativo basato sulle autorizzazioni, la cui versione iniziale è prevista per Chrome 114.
• Maggio 2023 (data provvisoria): il meccanismo basato sulle autorizzazioni viene implementato in Chrome 114. I siti web possono utilizzarlo per uscire dalla prova relativa al ritiro.
• Settembre 2023: implementazione di Chrome 117 nella versione stabile, che termina la prova di ritiro. Chrome blocca tutte le richieste di rete privata provenienti da contesti pubblici e non sicuri.

Che cos'è l'accesso a rete privata

L'accesso alla rete privata (precedentemente noto come CORS-RFC1918) limita la possibilità dei siti web di inviare richieste ai server su reti private. Consente queste richieste solo da contesti sicuri. La specifica estende anche il protocollo CORS (Cross-Origin Resource Sharing), in modo che i siti web ora debbano richiedere esplicitamente una concessione ai server su reti private prima di poter inviare richieste arbitrarie.

Le richieste di rete privata sono richieste il cui indirizzo IP del server di destinazione è più privato di quello da cui è stato recuperato l'iniziatore della richiesta. Ad esempio, una richiesta da un sito web pubblico (https://example.com) a un sito web privato (http://router.local) o una richiesta da un sito web privato a localhost.

Scopri di più all'indirizzo Feedback richiesto: CORS per reti private (RFC1918).

Che cos'è una prova relativa al ritiro

Le prove di ritiro (in precedenza prove di origine inversa) sono una forma di prove di origine utilizzate per semplificare il ritiro delle funzionalità web. Le prove di ritiro consentono a Chrome di ritirare determinate funzionalità web e di impedire ai siti web di creare nuove dipendenze, offrendo al contempo ai siti web attualmente dipendenti più tempo per eseguire la migrazione.

Durante una prova relativa al ritiro, le funzionalità deprecate non sono disponibili per tutti i siti web per impostazione predefinita. Gli sviluppatori che devono ancora utilizzare le funzionalità interessate devono registrarsi per la prova del ritiro e ottenere token per le origini web specificate, quindi modificare i propri siti web in modo da pubblicare questi token nelle intestazioni HTTP o nei meta tag (tranne in questo caso). Se un sito web pubblica token validi corrispondenti alla sua origine, Chrome consentirà l'utilizzo della funzionalità deprecata per un periodo di tempo limitato.

Per ulteriori informazioni, consulta la guida introduttiva alle prove dell'origine di Chrome e la guida alle prove dell'origine per sviluppatori web per ulteriori istruzioni.

Che cosa cambia in Chrome

Chrome 94

A partire da Chrome 94, i contesti pubblici non sicuri (in generale, i siti web non pubblicati tramite HTTPS o da un indirizzo IP privato) non possono effettuare richieste alla rete privata. In precedenza era prevista per Chrome 92, pertanto i messaggi di ritiro potrebbero ancora fare riferimento al traguardo precedente.

Questo ritiro è accompagnato da una prova relativa al ritiro, che consente agli sviluppatori web cuyos siti web utilizzano la funzionalità ritirata di continuare a utilizzarla fino a Chrome 116 registrandosi per i token. Leggi di seguito per istruzioni su come registrarti e attivare la prova sul tuo sito web.

Puoi utilizzare un paio di criteri di Chrome per disattivare il ritiro completamente o su origini specifiche a tempo indeterminato. In questo modo, le installazioni di Chrome gestite, ad esempio quelle nelle impostazioni aziendali, possono evitare interruzioni.

Chrome 117

Il periodo di prova del ritiro termina. È necessario eseguire la migrazione di tutti i siti web dalla funzionalità ritirata o configurare i criteri degli utenti per continuare a abilitarla.

Azioni consigliate per gli sviluppatori

Il primo passaggio per i siti web interessati è acquistare tempo fino a quando non sarà possibile implementare una correzione adeguata: registrandosi per la prova del ritiro o utilizzando i criteri. Successivamente, il procedimento consigliato varia a seconda delle circostanze di ciascun sito web interessato.

Registrati per la prova relativa al ritiro

1. Fai clic su Registrati per la sperimentazione dell'accesso alla rete privata da origini in contesti non sicuri per ottenere un token di prova per l'origine partecipante.
2. Aggiungi il valore Origin-Trial: $token specifico per l'origine all'intestazione della risposta. Questo intestazione di risposta deve essere impostato solo sulle risposte della risorsa principale e di navigazione quando il documento risultante utilizza la funzionalità ritirata. È inutile (anche se innocuo) associare questa intestazione alle risposte delle risorse secondarie.

Poiché questa prova deve essere attivata o disattivata prima che a un documento sia consentito effettuare richieste, non può essere attivata tramite un tag <meta>. Questi tag vengono analizzati dal corpo della risposta solo dopo l'emissione di richieste di sottorisorse. Questo rappresenta una sfida per i siti web che non hanno il controllo degli intestazioni di risposta, come i siti web statici github.io pubblicati da terze parti.

Per ulteriori dettagli, consulta la Guida per gli sviluppatori web alle prove delle origini.

Abilita criteri

Se disponi del controllo amministrativo sugli utenti, puoi riabilitare la funzionalità deprecata utilizzando uno dei seguenti criteri:

• InsecurePrivateNetworkRequestsAllowed
• InsecurePrivateNetworkRequestsAllowedForUrls

Per ulteriori dettagli sulla gestione delle norme per gli utenti, consulta questo articolo del Centro assistenza.

Accesso a localhost

Se il tuo sito web deve inviare richieste a localhost, devi solo eseguire l'upgrade a HTTPS.

Le richieste che hanno come target http://localhost (o http://127.*.*.*, http://[::1]) non sono bloccate dai contenuti misti, anche se inviate da contesti sicuri.

Tieni presente che il motore WebKit e i browser basati su questo (in particolare Safari) deviano dalla specifica dei contenuti misti del W3C qui e vietano queste richieste come contenuti misti. Inoltre, non implementano l'accesso alla rete privata, pertanto i siti web potrebbero voler reindirizzare i client che utilizzano questi browser a una versione HTTP non protetta del sito web, che consentirebbe comunque a questi browser di effettuare richieste a localhost.

Accesso agli indirizzi IP privati

Se il tuo sito web deve inviare richieste a un server di destinazione su un indirizzo IP privato, l'upgrade del sito web di iniziativa a HTTPS non funziona. I contenuti misti impediscono ai contesti sicuri di effettuare richieste tramite HTTP in testo normale, pertanto il sito web appena reso sicuro non potrà comunque effettuare le richieste. Esistono alcuni modi per risolvere il problema:

• Esegui l'upgrade di entrambe le estremità a HTTPS.
• Utilizza WebTransport per connetterti in modo sicuro al server di destinazione.
• Invertire la relazione di incorporamento.

Esegui l'upgrade di entrambe le estremità a HTTPS

Questa soluzione richiede il controllo sulla risoluzione DNS degli utenti, ad esempio nei contesti intranet o se gli utenti ottengono gli indirizzi dei propri server dei nomi da un server DHCP sotto il tuo controllo. Inoltre, è necessario disporre di un nome di dominio pubblico.

Il problema principale della pubblicazione di siti web privati tramite HTTPS è che le autorità di certificazione dell'infrastruttura a chiave pubblica (PKI CA) forniscono certificati TLS solo ai siti web con nomi di dominio pubblici. Per risolvere il problema:

1. Registra un nome di dominio pubblico (ad esempio intranet.example) e pubblica i record DNS che indirizzano il nome di dominio a un server pubblico di tua scelta.
2. Ottieni un certificato TLS per intranet.example.
3. All'interno della tua rete privata, configura il DNS in modo che risolva intranet.example nell'indirizzo IP privato del server di destinazione.
4. Configura il server privato in modo che utilizzi il certificato TLS per intranet.example. In questo modo, i tuoi utenti potranno accedere al server privato all'indirizzo https://intranet.example.

Puoi quindi eseguire l'upgrade del sito web che avvia le richieste a HTTPS e continuare a effettuare le richieste come prima.

Questa soluzione è a prova di futuro e riduce la fiducia che riponi nella tua rete, aumentando l'uso della crittografia end-to-end all'interno della tua rete privata.

WebTransport

Questa soluzione non richiede il controllo sulla risoluzione DNS degli utenti. Richiedono che il server di destinazione esegua un server WebTransport minimo (server HTTP/3 con alcune modifiche).

Puoi aggirare la mancanza di un certificato TLS valido firmato da un'autorità di certificazione attendibile utilizzando WebTransport e il relativo meccanismo di pinning dei certificati. In questo modo è possibile stabilire connessioni sicure a dispositivi privati che potrebbero avere, ad esempio, un certificato autofirmato. Le connessioni WebTransport consentono il trasferimento di dati bidirezionale, ma non le richieste di recupero. Puoi combinare questo approccio con un service worker per eseguire il proxy in modo trasparente delle richieste HTTP sulla connessione, dal punto di vista della tua applicazione web. Sul lato server, un livello di traduzione corrispondente può convertire i messaggi WebTransport in richieste HTTP.

Siamo consapevoli che si tratta di un lavoro considerevole, ma dovrebbe essere molto più semplice rispetto alla creazione su WebRTC. Ci auguriamo inoltre che parte dell'investimento necessario venga implementata come librerie riutilizzabili. Riteniamo inoltre che sia particolarmente utile considerare il fatto che i contesti non sicuri potrebbero perdere l'accesso a un numero sempre maggiore di funzionalità della piattaforma web man mano che la piattaforma si orienta verso l'utilizzo di HTTPS in modo più deciso nel tempo. Indipendentemente dall'accesso a rete privata, si tratterebbe comunque di un investimento saggio.

Prevediamo che WebTransport su HTTP/3 venga rilasciato in Chrome 96 (è iniziata una prova dell'origine) con misure di mitigazione per proteggersi dalla condivisione delle chiavi e da altre pratiche di sicurezza non conformi, tra cui:

• Una scadenza massima breve per i certificati bloccati.
• Un meccanismo specifico del browser per revocare determinate chiavi oggetto di abusi.

Non invieremo la limitazione relativa al contesto sicuro fino ad almeno due traguardi dopo l'implementazione completa di WebTransport. Se necessario, il periodo di prova per il ritiro verrà esteso.

Inverti incorporamento

Questa soluzione non richiede alcun controllo amministrativo sulla rete e può essere utilizzata quando il server di destinazione non è abbastanza potente per eseguire HTTPS.

Anziché recuperare le risorse secondarie private da un'app web pubblica, è possibile pubblicare uno scheletro dell'app dal server privato, che recupera poi tutte le risorse secondarie (ad esempio script o immagini) da un server pubblico, ad esempio una CDN. L'app web risultante può quindi effettuare richieste al server privato, che sono considerate della stessa origine. Può anche inviare richieste ad altri server con IP privati (ma non a localhost), anche se questo potrebbe cambiare nel lungo periodo.

Se ospiti solo uno scheletro sul server privato, puoi aggiornare l'app web spingendo nuove risorse sul server pubblico, proprio come faresti con un'app web pubblica. D'altra parte, l'app web risultante non è un contesto sicuro, pertanto non ha accesso ad alcune delle funzionalità più potenti del web.

Piani per il futuro

La limitazione delle richieste di rete privata a contesti sicuri è solo il primo passo per avviare l'accesso privato alla rete. Chrome si sta adoperando per implementare il resto della specifica nei prossimi mesi. Continua a seguirci per non perderti gli aggiornamenti.

Limitare l'accesso a localhost da siti web privati

Le modifiche in Chrome 94 interessano solo i siti web pubblici che accedono a indirizzi IP privati o a localhost. La specifica Private Network Access classifica inoltre come problematiche le richieste da siti web privati a localhost. Prima o poi Chrome ritirerà anche queste. Tuttavia, questo presenta una serie di sfide leggermente diverse, poiché molti siti web privati non hanno nomi di dominio, il che complica l'utilizzo dei token di prova per il ritiro.

Richieste di preflight CORS

La seconda parte di Accesso alla rete privata è il controllo delle richieste di rete privata avviate da contesti sicuri con le richieste di preflight CORS. L'idea è che, anche se la richiesta è stata avviata da un contesto sicuro, al server di destinazione viene chiesto di fornire una concessione esplicita all'iniziatore. La richiesta viene inviata solo se la concessione va a buon fine.

In breve, una richiesta preflight CORS è una richiesta OPTIONS HTTP che trasporta alcune intestazioni Access-Control-Request-* che indicano la natura della richiesta successiva. Il server può quindi decidere se concedere o meno l'accesso granulare rispondendo con 200 OK e le intestazioni Access-Control-Allow-*.

Scopri di più nella specifica.

Limita i recuperi tramite navigazione

Chrome ritira e alla fine bloccherà le richieste di risorse secondarie alle reti private. Ciò non influirà sulla navigazione verso reti private, che possono essere utilizzate anche negli attacchi CSRF.

La specifica di accesso alla rete privata non fa distinzione tra i due tipi di recupero, che alla fine saranno soggetti alle stesse limitazioni.

Foto di copertina di Markus Spiske su Unsplash