Capes de SSTP explicades: què encara revela el paquet intern

Dos fets sobre SSTP es fusionen en la majoria d’explicacions, i és aquesta fusió la que fa confuses les captures. El paquet de l’aplicació sobreviu dins del canal protegit, i la connexió TCP que transporta aquest canal conserva les seves pròpies adreces al llarg de tot el camí. Pel cable viatja un transport més la seva càrrega, mai un substitut de cap dels dos. Recorreu la pila de fora cap endins i etiqueteu cada frontera quan la creueu.

Comenceu pel transport exterior

El primer que hi ha al cable és una connexió TCP ordinària al port 443, amb adreces reals que els encaminadors reenvien. Aquesta connexió és la que sobreviu a la traducció d’adreces de xarxa i la que un proveïdor d’accés pot comptar. Protegir la càrrega útil no elimina el transport, i no amaga el volum ni el moment.

Tot el que ve després d’aquest punt es transporta en lloc d’encaminar-se. El transport continua funcionant fins i tot quan l’intercanvi interior falla.

Seguiu l’encapsulament cap endins

Dins del canal protegit hi ha un intercanvi de control SSTP, després una sessió PPP i després el paquet de xarxa que el client vol que es lliuri. Cada capa té la seva pròpia negociació, els seus propis missatges d’error i la seva pròpia màquina d’estats. Per tant, una fallada pot semblar una fallada de TLS des d’un punt de vista i una fallada de PPP des d’un altre. Llegir les capes en ordre us diu quina màquina d’estats s’ha aturat.

Una sola captura poques vegades mostra tota la pila. Les capçaleres exteriors només són visibles fora del punt final, i les interiors només després de la desencapsulació. Aquesta asimetria ve d’on sou, no del protocol.

El diagrama següent agrupa les capes per tal que se’n pugui parlar. No és una disposició de bytes, no promet un registre per paquet i no diu res sobre quantes operacions criptogràfiques fa una implementació.

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

Etiqueteu l’observador abans de llegir una captura

Dues captures d’una mateixa sessió responen preguntes diferents, i la interfície on es van prendre decideix quina. Al camí d’accés veieu el transport i els registres TLS, i podeu mesurar mides i intervals sense veure cap adreça interior. Al punt final, després de la desencapsulació, el paquet interior és trànsit ordinari sota la política privada de reenviament.

Escriviu la interfície i la direcció a cada captura abans d’interpretar-la. Un rastre pres d’un adaptador físic mai no mostrarà les adreces de l’aplicació interior com a camps exteriors normals, i llegir aquesta absència com una fallada de xifratge és un error habitual. Un rastre pres des de dins del túnel no mostra cap transport, així que no pot respondre una pregunta sobre la visió del proveïdor. La mateixa disciplina s’aplica als registres del punt final, que anoten l’ordre de la negociació i no els continguts.

Conserveu les comprovacions que el diagrama no pot demostrar

L’ordre de les capes no estableix que un desplegament validi el certificat del servidor, negociï una versió de TLS compatible o autoritzi el compte. Cadascuna d’aquestes és una decisió de configuració que falla independentment de l’encapsulament.

Comproveu-les amb un client que informi del que ha negociat en lloc de raonar a partir d’un dibuix. Comenceu amb l’intercanvi de salutació de TLS, després l’intercanvi SSTP, després PPP, i atureu-vos a la primera etapa que informi d’un error. La primera ordre imprimeix la cadena i la versió negociada, i la segona llista les salutacions presents en una captura.

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