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

Aggiornamenti

• 23 marzo 2023: le tempistiche sono state aggiornate e il ritiro non verrà eseguito fino a 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 interessato centinaia di migliaia di utenti, consentendo agli 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.
• Stiamo introducendo una prova di 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.
• Introduzione di un criterio di Chrome che consentirà ai deployment di Chrome gestiti diaggirare il ritiro definitivamente. 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 ridurre 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 ad 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: implementazione di Chrome 92 nella versione beta, che vieta le richieste di rete privata 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: dopo ulteriori feedback degli sviluppatori, il ritiro e la prova associata sono stati 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 del ritiro e aver implementato i token di prova in produzione.
• Dicembre 2022: sondaggio sulla prova dell'origine inviato e feedback ricevuti. La prova del ritiro è stata estesa a Chrome 113.
• Marzo 2023: la prova del ritiro viene 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 da contesti pubblici non sicuri.

Che cos'è l'accesso a rete privata

L'accesso alla rete privata (in precedenza noto come CORS-RFC1918) limita la capacità dei siti web di inviare richieste ai server su reti private. Consente queste richieste solo da contesti sicuri. La specifica estende anche il protocollo Cross-Origin Resource Sharing (CORS) in modo che i siti web debbano ora richiedere esplicitamente una concessione dai 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 di ritiro, le funzionalità ritirate 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 loro origine, Chrome consentirà l'utilizzo della funzionalità ritirata per un periodo di tempo limitato.

Per ulteriori informazioni, consulta la guida introduttiva alle prove delle origini di Chrome e la guida per gli sviluppatori web alle prove delle origini per 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.

È possibile utilizzare una coppia di criteri di Chrome per disattivare il ritiro graduale del tutto o per 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. Inoltre, il corso d'azione 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 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 che potrebbero essere state emesse richieste di risorse secondarie. Questo rappresenta un problema 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 riattivare la funzionalità ritirata 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 vengono bloccate da Contenuti misti, anche se vengono 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 a HTTPS su entrambe le estremità.
• Utilizza WebTransport per connetterti in modo sicuro al server di destinazione.
• Invertire la relazione di incorporamento.

Esegui l'upgrade a HTTPS su entrambe le estremità

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 inviare le richieste come prima.

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

WebTransport

Questa soluzione non richiede il controllo sulla risoluzione DNS degli utenti. Tuttavia, richiede 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 worker di servizio per eseguire il proxy delle richieste HTTP in modo trasparente 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 che sono state oggetto di abusi.

La limitazione del contesto sicuro non verrà implementata fino al raggiungimento di almeno due traguardi dopo il completamento dell'implementazione di WebTransport. Se necessario, il periodo di prova della ritirata verrà esteso.

Incorporamento inverso

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 poi recupera tutte le risorse secondarie (ad esempio script o immagini) da un server pubblico, ad esempio una CDN. L'app web risultante può quindi inviare richieste al server privato, poiché queste sono considerate di 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.

Programmi per il futuro

Limitare le richieste di rete privata a contesti sicuri è solo il primo passo per il lancio dell'accesso alla rete privata. 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 riguardano 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. Anche questi metodi verranno ritirati da Chrome. 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.

Limitare i recuperi di navigazione

Chrome ritira e alla fine blocca 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