Come funziona la crittografia nei protocolli PON?

Xx-point · 17 apr 2023

ciao,
visto che tutto il traffico downstream di tutti i clienti di un albero GPON viene broadcastato a tutti gli ONT (quindi fino a 64) vorrei capire un po' come è gestita la riservatezza delle comunicazioni su ftth in italia;

leggo dalla documentazione (poca) che si trova in giro che i protocolli *PON supportano la cifratura con aes-128 in downstream (l'OLT e l'ONT negoziano una chiave simmetrica, generata sull'ONT e trasmessa in upstream).

la cifratura in upstream è invece considerata meno importante (visto che il traffico upstream arriva solo all'OLT e non a tutti gli altri ONT dell'albero. quindi serve un TAP hw installato sulla fibra per vedere il traffico upstream.

Esiste qualche documento dove si spiega quale tipo di cifratura sia attiva sugli OLT (nessuna, solo downstream, entrambe) e quando vengono rinegoziate le chiavi per i vari operatori italiani che gestisono reti attive?

simonebortolin · 17 apr 2023

in GPON solo downstream e facoltativa

in XGS-PON downstream obbligatoria e upstream facoltativa (all'epoca della definizione degli standard era richiesta da tim, ma non la usa)

In qualsiasi caso ITU-T Rec. G.984.3 paragrafo 12.1 e seguenti

Aggiungo che Only the GEM frame/fragment payload is encrypted. The GEM header is not encrypted.

Xx-point · 17 apr 2023

simonebortolin in GPON solo downstream e facoltativa

in XGS-PON downstream obbligatoria e upstream facoltativa (all'epoca della definizione degli standard era richiesta da tim, ma non la usa)

ok, qundi l'italia è quasi, del tutto, nel campo GPON: "solo downstream e facoltativa" e da quanto dici di tim, mi pare di capire che abbiano optato per la semplicità e non per la sicurezza :-(
anche gli altri 'proprietari di OLT sulle varie reti hanno preso la strada di TIM per la non cifratura?

PS ho trovato un paper di telecomitalia di un po' più di un decennio fa (quando ancora insistevano con la protezione del loro rame da usare per ADSL e FTTC, potrebbe pensare il malfidente) in cui erano molto critici sulla sicurezza di GPON .... devono aver cambiato idea nel frattempo, se non attivano la cifratura nemmeno dove si potrebbe ;-)

simonebortolin In qualsiasi caso ITU-T Rec. G.984.3 paragrafo 12.1 e seguenti

questo è interessante e risponde anche alla mia domanda sulla rinegoziazione delle chiavi (è pilotata dall'OLT, non ci sono vincoli sulla frequenza, ma lo fa ALMENO ogni volta che l'ONT (ONU) torna online.

simonebortolin Aggiungo che Only the GEM frame/fragment payload is encrypted. The GEM header is not encrypted.

se cifrassero almeno il payload, questo non sarebbe un grosso problema, tutto sommato l'header dei frame GEM mi pare di capire non contenga dati sensibili e/o interessanti per lo spione... potrebbe giusto capire con precisione quanto traffico fa il singolo cliente (e forse dai pattern dei pacchetti riconoscere il tipo di traffico, ma non il sorgente).

Ma solo a me questa mancanza di riservatezza crea un certo fastidio, forse indefinito, ma sicuramente poco gradevole?

Xxblitz · 17 apr 2023

x-point Ma solo a me questa mancanza di riservatezza crea un certo fastidio, forse indefinito, ma sicuramente poco gradevole?

A me poco importa se gli header sono in chiaro: quello che conta è che ci sia la crittografia a livello applicativo - ovviamente mica voglio che "il primo sniffer che passa" mi veda i dati.

Ma magari sono io ignorante. Considera che in fase di diagnostica\throubleshoting la crittografia potrebbe essere pure una seccatura.

Discorso diverso se avessi un dispositivo direttamente connesso a internet allora si mi darebbe fastidio anche il sapere che il suo mac può potenzialmente andare in giro per il mondo. Però mi immagino che la tipica rete sia quella dietro router casalingo senza particolari sofisticazioni.

MMarco25 · 17 apr 2023

x-point Ma solo a me questa mancanza di riservatezza crea un certo fastidio, forse indefinito, ma sicuramente poco gradevole?

Un po’ si ma ormai i protocolli di livello superiore sono quasi tutti criptati e autenticati client-server o client-client, eccetto che per metadati. Il problema serio a mio parere sono le telefonate 100% in chiaro sia signaling che voce.

simonebortolin · 17 apr 2023

x-point ok, qundi l'italia è quasi, del tutto, nel campo GPON: "solo downstream e facoltativa" e da quanto dici di tim, mi pare di capire che abbiano optato per la semplicità e non per la sicurezza :-(
anche gli altri 'proprietari di OLT sulle varie reti hanno preso la strada di TIM per la non cifratura?

PS ho trovato un paper di telecomitalia di un po' più di un decennio fa (quando ancora insistevano con la protezione del loro rame da usare per ADSL e FTTC, potrebbe pensare il malfidente) in cui erano molto critici sulla sicurezza di GPON .... devono aver cambiato idea nel frattempo, se non attivano la cifratura nemmeno dove si potrebbe ;-)

Spetta non ho detto ciò, se non erro tutto o quasi tutto l'attuale GPON ha la crittografia abilitata in downstream, però non ho la certezza ecco.

Teoricamente c'è pure il mib per beccare se è crittografato o meno (forse 256 o 257) ed è proprio per questo che in xgs-pon è obbligatorio, tutti lo usano crittografato.

x-point Ma solo a me questa mancanza di riservatezza crea un certo fastidio, forse indefinito, ma sicuramente poco gradevole?

Se il tuo traffico è principalmente https/ssh che ti interessa? l'unico problema sono le chiamate come dice @Marco25 o i siti http

x-point se cifrassero almeno il payload, questo non sarebbe un grosso problema, tutto sommato l'header dei frame GEM mi pare di capire non contenga dati sensibili e/o interessanti per lo spione... potrebbe giusto capire con precisione quanto traffico fa il singolo cliente (e forse dai pattern dei pacchetti riconoscere il tipo di traffico, ma non il sorgente).

Teoricamente lo fanno.

xblitz A me poco importa se gli header sono in chiaro: quello che conta è che ci sia la crittografia a livello applicativo - ovviamente mica voglio che "il primo sniffer che passa" mi veda i dati.

Quì non si stava parlando degli eader ma del resto dei dati, gli header è giusto che siano crittografati.

Xx-point · 18 apr 2023

simonebortolin Spetta non ho detto ciò, se non erro tutto o quasi tutto l'attuale GPON ha la crittografia abilitata in downstream, però non ho la certezza ecco.

sorry, avevo inteso male, questo è confortante.
mi sconforta un po' il fatto che il dato sulla cifratura o meno delle comunicazioni non sia pubblicamente disponibile agli utenti, ma solo una voce di corridoio (e che ciò non sia una cosa prevista da agcom nei suoi regolamenti).

simonebortolin Teoricamente c'è pure il mib per beccare se è crittografato o meno (forse 256 o 257)

il cliente può fare query snmp all'ont e questo risponde 'lato client'?!?!?!
questo sarebbe interessante (anche per monitorare l'attenuazione della linea nel tempo

simonebortolin Se il tuo traffico è principalmente https/ssh che ti interessa? l'unico problema sono le chiamate come dice @Marco25 o i siti http

non è così semplice, ad esempio di default il dns passa in chiaro (no, l'utente medio non usa DoH/DoT per tutti i suoi client) e da li puoi capire tante cose, poi ci sono mille mila altri protocolli che non cifrano o non lo fanno del tutto [es in https l'hostname passa in chiaro, per poter utilizzare SNI], ovvio che poi la cifratura applicativa è una cosa doverosa da aggiungere, ma uno strato di aes-128 per garantire un po' di riservatezza di base non guasterebbe averlo garantito.

Marco25 Il problema serio a mio parere sono le telefonate 100% in chiaro sia signaling che voce

non avevo pensato all'rtp. però, si, è vero se dovesse mancare la cifratura in downstream potremmo ascoltare l'audio (solo in ingresso) di tutte le chiamate dei vicini connessi sulla stessa porta dell'OLT e questo potrebbe essere sufficiente a convincere un operatore ad attivare aes come mandatorio sulla rete!

simonebortolin · 18 apr 2023

x-point sorry, avevo inteso male, questo è confortante.
mi sconforta un po' il fatto che il dato sulla cifratura o meno delle comunicazioni non sia pubblicamente disponibile agli utenti, ma solo una voce di corridoio (e che ciò non sia una cosa prevista da agcom nei suoi regolamenti).

Sisi mi sono anche io espresso male, perché avevo il terrore che ci fosse qualche ISP non lo avesse attivo e quindi per precauzione non ho detto nulla.

x-point il cliente può fare query snmp all'ont e questo risponde 'lato client'?!?!?!

Beh l'ont in genere è accessibile lato client. https://hack-gpon.github.io/ ci ha una wiki con coi dati di accesso agli ont. poi una volta che sei entrato cerchi come fare il mib ed ottieni un sacco di dati.

x-point questo sarebbe interessante (anche per monitorare l'attenuazione della linea nel tempo

Sisi, questo si faceva già dal 2017 https://www.linux.it/~md/text/gpon-sha2017.pdf

x-point non è così semplice, ad esempio di default il dns passa in chiaro (no, l'utente medio non usa DoH/DoT per tutti i suoi client)

però tu sì immagino....

MMarco25 · 18 apr 2023

x-point di default il dns passa in chiaro (no, l'utente medio non usa DoH/DoT per tutti i suoi client) e da li puoi capire tante cose, poi ci sono mille mila altri protocolli che non cifrano o non lo fanno del tutto [es in https l'hostname passa in chiaro, per poter utilizzare SNI]

Come detto sopra, preferisco la cifratura a livello applicativo. DoH e DoT possono essere implementati di default a livello di OS o rete (ad esempio Android utilizza automaticamente DoT se il resolver configurato lo supporta). TLS rivela SNI ma con la transizione del web a QUIC e TLS 1.3 anche il nome del sito potrà essere criptato.

x-point questo potrebbe essere sufficiente a convincere un operatore ad attivare aes come mandatorio sulla rete!

Non mi aspetto che gli ISP implementino questo tipo di cifratura. Gli utenti non ne sono al corrente, non capirebbero le implicazioni, quindi non è un valore aggiunto per l'offerta. E anche se la implementassero, non ci sarebbe un whitepaper da valutare sui cifrari e la gestione delle chiavi.