TLS viaggia dentro il canale di controllo, non in tutto il tunnel

Vedere la parola TLS in una descrizione VPN e concludere che un proxy web capirà il traffico è una scorciatoia comune. Dentro questo protocollo i peer scambiano i propri pacchetti, e TLS gira come parte di un canale all’interno di quello scambio. Il payload che interessa all’utente viaggia in un formato di messaggio diverso, ed è per questo che i due non coincidono mai con una sessione HTTPS ordinaria.

La busta arriva per prima

Ogni pacchetto del tunnel inizia con l’intestazione del protocollo stesso: un tipo di messaggio, un identificatore di chiave e, su un trasporto a flusso di byte, un prefisso di lunghezza che segna dove finisce il pacchetto. Un lettore che non analizza quella busta non può sapere dove inizia il campo successivo.

outer transport (UDP datagram or TCP stream)
  -> OpenVPN header (opcode, key id, length where needed)
    -> control message (reliability wrapper, TLS exchange)
    -> data message (protected inner packet)

Quello schizzo è una mappa e non una tabella di byte, perché i campi esatti dipendono dal tipo di messaggio, anche se il primo ottetto impacchetta sempre l’opcode e l’identificatore di chiave insieme. Indovinare il tipo di messaggio dal numero di porta è il modo in cui i decoder finiscono per etichettare male ciò che vedono. L’ordine è ciò che conta per la diagnosi: trasporto, poi la busta del protocollo, poi uno dei due tipi di lavoro. Leggi la busta prima di formarti un’opinione su ciò che segue. Un decoder che parte nel posto sbagliato produce assurdità sicure di sé.

Lo strato di affidabilità appartiene al protocollo

I messaggi di controllo richiedono una consegna ordinata e confermata, e il protocollo lo fornisce da sé con conferme e ritrasmissioni. Una conferma può arrivare come messaggio proprio o viaggiare con un altro messaggio di controllo, il che rende le tracce irregolari per chi si aspetta un unico scambio pulito.

Il vantaggio è che l’handshake TLS ottiene un vettore affidabile anche quando il trasporto esterno è UDP. Il costo è che un singolo datagramma può contenere solo una parte di quella conversazione, quindi trattarlo come un record TLS autonomo produce assurdità. Il riassemblaggio deve avvenire al livello del protocollo. Per questo un pacchetto catturato raramente sembra un passo completo dell’handshake.

Passare il trasporto esterno a TCP non elimina questo strato. Un trasporto affidabile significa meno ritrasmissioni a livello di protocollo, non che l’incorniciatura scompaia o che il traffico diventi HTTP.

I pacchetti dati usano un formato diverso

Una volta che la sessione esiste, il payload utile arriva come messaggi dati che trasportano pacchetti IP interni o frame Ethernet. Sono protetti con le proprie chiavi e la propria elaborazione, e non sono record applicativi TLS in alcun senso che una libreria TLS accetterebbe.

Questa separazione è visibile nella configurazione: il canale di controllo e il canale dati hanno impostazioni di cifratura separate, quindi una riga di log che nomina uno non dice nulla sull’altro. Leggere una cifratura di controllo forte come prova di una cifratura dati forte è un comune errore di reportistica.

Tieni anche fuori dalla spiegazione un equivoco correlato. TLS non è un canale a chiave pubblica accanto a un canale dati simmetrico, perché TLS stesso protegge i propri record in modo simmetrico una volta stabilite le chiavi. La distinzione reale è ruolo e formato del pacchetto, non che tipo di crittografia usa ciascun lato.

Perché un proxy HTTPS non può aiutare

Un proxy che termina TLS si aspetta un flusso di record TLS e poi un protocollo applicativo al suo interno. Il canale di controllo di questo protocollo è trasportato dentro la propria incorniciatura con uno strato di affidabilità attorno, quindi un proxy che termina legge quell’incorniciatura come input corrotto.

Un inoltro trasparente che lascia passare byte o datagrammi senza interpretarli può funzionare, purché non riscriva o riassembli il flusso. La domanda da porre su qualsiasi intermediario è se inoltra il trasporto e l’incorniciatura reali, non se supporta TLS da qualche parte. Chiedilo prima di passare una serata sulle regole del proxy. La maggior parte dei fallimenti qui è architetturale e non un’impostazione mancante.

Leggere correttamente una traccia

Aspettati prima uno scambio di controllo, poi un numero molto maggiore di messaggi dati, entrambi sullo stesso trasporto. Se la fase di controllo si completa e la fase dati si blocca, il guasto riguarda chiavi, instradamento o filtraggio del percorso dati e non l’handshake. Cattura alcuni messaggi dati e verifica se lasciano davvero il client. Quella singola osservazione dimezza la ricerca.

Le descrizioni storiche dei metodi di chiave nella documentazione del protocollo non implicano che una data versione supporti ancora ogni vecchio formato. Controlla la versione che esegui prima di costruire un’aspettativa su un paragrafo che descrive come funzionavano le cose in passato.