I livelli di SSTP spiegati: cosa rivela ancora il pacchetto interno

Due fatti su SSTP si fondono nella maggior parte delle spiegazioni, ed è proprio quella fusione a rendere confuse le catture. Il pacchetto dell’applicazione sopravvive dentro il canale protetto, e la connessione TCP che trasporta quel canale conserva i propri indirizzi per tutta la durata. Sul filo viaggia un vettore con il suo carico, mai un sostituto dell’uno o dell’altro. Percorrete la pila dall’esterno verso l’interno ed etichettate ogni confine che attraversate.

Partite dal vettore esterno

La prima cosa sul filo è una normale connessione TCP alla porta 443, con indirizzi reali che i router inoltrano. È quella connessione a sopravvivere alla traduzione degli indirizzi di rete e a poter essere contata da un fornitore di accesso. Proteggere il carico non elimina il vettore, e non nasconde il volume né la cadenza.

Tutto ciò che segue questo punto è trasportato anziché instradato. Il vettore continua a funzionare anche quando lo scambio interno fallisce.

Seguite l’incapsulamento verso l’interno

Dentro il canale protetto si trova uno scambio di controllo SSTP, poi una sessione PPP, poi il pacchetto di rete che il client vuole farsi consegnare. Ogni livello ha la propria negoziazione, i propri messaggi di errore e la propria macchina a stati. Un guasto può quindi sembrare un guasto TLS da un punto di vista e un guasto PPP da un altro. Leggere i livelli in ordine dice quale macchina a stati si è fermata.

Una sola cattura raramente mostra tutta la pila. Le intestazioni esterne sono visibili solo fuori dal punto di terminazione, e quelle interne solo dopo la decapsulazione. Questa asimmetria dipende da dove vi trovate, non dal protocollo.

Lo schema qui sotto raggruppa i livelli perché se ne possa parlare. Non è una disposizione di byte, non promette un record per pacchetto e non dice nulla su quante operazioni crittografiche esegua un’implementazione.

outer IP header
  TCP to port 443
    TLS record layer
      SSTP control and data packets
        PPP frames
          inner IP packet
            application transport and payload

Etichettate l’osservatore prima di leggere una cattura

Due catture della stessa sessione rispondono a domande diverse, e l’interfaccia su cui sono state prese decide quali. Sul percorso di accesso vedete il vettore e i record TLS, e potete misurare dimensioni e intervalli senza vedere un indirizzo interno. Al punto di terminazione, dopo la decapsulazione, il pacchetto interno è traffico ordinario secondo la politica privata di inoltro.

Scrivete l’interfaccia e la direzione su ogni cattura prima di interpretarla. Una traccia presa su un adattatore fisico non mostrerà mai gli indirizzi dell’applicazione interna come normali campi esterni, e leggere questa assenza come un guasto di cifratura è un errore comune. Una traccia presa dall’interno del tunnel non mostra alcun vettore, quindi non può rispondere a una domanda sulla visuale del fornitore. La stessa disciplina vale per i registri del punto di terminazione, che annotano l’ordine della negoziazione e non i contenuti.

Conservate i controlli che lo schema non può dimostrare

L’ordine dei livelli non stabilisce che un’installazione convalidi il certificato del server, negozi una versione di TLS supportata o autorizzi l’account. Ognuno di questi è una decisione di configurazione che fallisce indipendentemente dall’incapsulamento.

Verificateli con un client che riporti ciò che ha negoziato invece di ragionare da un disegno. Iniziate con la stretta di mano TLS, poi lo scambio SSTP, poi PPP, e fermatevi al primo passo che segnala un errore. Il primo comando stampa la catena e la versione negoziata, il secondo elenca le strette di mano presenti in una cattura.

openssl s_client -connect vpn.corp.internal:443 -servername vpn.corp.internal
tshark -r sstp.pcap -Y "tls.handshake.type == 1"