TLS viaxa dentro da canle de control, non por todo o túnel

Ver a palabra TLS nunha descrición de VPN e concluír que un proxy web entenderá o tráfico é un atallo habitual. Dentro deste protocolo os pares intercambian os seus propios paquetes, e TLS funciona como parte dunha canle dentro dese intercambio. A carga útil que lle importa ao usuario viaxa nun formato de mensaxe distinto, e por iso os dous nunca coinciden cunha sesión HTTPS ordinaria.

O sobre chega primeiro

Cada paquete do túnel comeza coa cabeceira propia do protocolo: un tipo de mensaxe, un identificador de chave e, sobre un transporte de fluxo de bytes, un prefixo de lonxitude que marca onde remata o paquete. Un lector que non analiza ese sobre non pode saber onde comeza o seguinte campo.

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)

Ese esquema é un mapa e non unha táboa de bytes, porque os campos exactos dependen do tipo de mensaxe, aínda que o primeiro octeto sempre empaqueta o opcode e o identificador de chave xuntos. Adiviñar o tipo de mensaxe polo número de porto é como os descodificadores acaban etiquetando mal o que ven. A orde é o que importa para o diagnóstico: transporte, despois o sobre do protocolo, despois un dos dous tipos de traballo. Le o sobre antes de formares calquera opinión sobre o que segue. Un descodificador que comeza no lugar equivocado produce desatinos con moita confianza.

A capa de fiabilidade pertence ao protocolo

As mensaxes de control necesitan unha entrega ordenada e confirmada, e o protocolo proporciónao el mesmo con confirmacións e retransmisións. Unha confirmación pode chegar como mensaxe propia ou viaxar con outra mensaxe de control, o que fai que as trazas parezan irregulares a quen espera un intercambio limpo.

A vantaxe é que o handshake TLS recibe un portador fiable mesmo cando o transporte exterior é UDP. O custo é que un só datagrama pode conter só parte desa conversa, así que tratalo como un rexistro TLS autónomo produce desatinos. A reensamblaxe ten que ocorrer na capa do protocolo. Por iso un paquete capturado raramente parece un paso completo do handshake.

Cambiar o transporte exterior a TCP non elimina esta capa. Un transporte fiable significa menos retransmisións a nivel de protocolo, non que desapareza o enmarcado nin que o tráfico se converta en HTTP.

Os paquetes de datos usan un formato distinto

Unha vez existe a sesión, a carga útil chega como mensaxes de datos que transportan paquetes IP internos ou tramas Ethernet. Están protexidos coas súas propias chaves e o seu propio procesamento, e non son rexistros de aplicación TLS en ningún sentido que aceptaría unha biblioteca TLS.

Esa separación é visible na configuración: a canle de control e a canle de datos teñen axustes de cifrado separados, así que unha liña de rexistro que nomea unha non di nada da outra. Ler un cifrado de control forte como proba dun cifrado de datos forte é un erro de informe habitual.

Mantén tamén fóra da explicación unha idea equivocada relacionada. TLS non é unha canle de chave pública xunto a unha canle de datos simétrica, porque TLS mesmo protexe os seus rexistros de forma simétrica unha vez establecidas as chaves. A distinción real é o rol e o formato do paquete, non que tipo de criptografía usa cada lado.

Por que un proxy HTTPS non pode axudar

Un proxy que termina TLS espera un fluxo de rexistros TLS e despois un protocolo de aplicación dentro del. A canle de control deste protocolo transpórtase dentro do seu propio enmarcado cunha capa de fiabilidade arredor, así que un proxy que termina le ese enmarcado como entrada corrupta.

Un reenviador transparente que deixa pasar bytes ou datagramas sen interpretalos pode funcionar, sempre que non reescriba nin reensamble o fluxo. A pregunta que hai que facer sobre calquera intermediario é se reenvía o transporte e o enmarcado reais, non se admite TLS nalgún sitio. Pregúntao antes de pasar unha noite con regras de proxy. A maioría dos fallos aquí son arquitectónicos e non un axuste que falta.

Ler unha traza correctamente

Espera primeiro un intercambio de control, despois un número moito maior de mensaxes de datos, ambos compartindo un transporte. Se a fase de control se completa e a fase de datos se atasca, o fallo afecta a chaves, encamiñamento ou filtrado da ruta de datos e non ao handshake. Captura unhas cantas mensaxes de datos e comproba se saen do cliente. Esa soa observación parte a busca pola metade.

As descricións históricas dos métodos de chave na documentación do protocolo non implican que unha versión determinada siga admitindo todos os formatos antigos. Comproba a versión que executas antes de construír unha expectativa sobre un parágrafo que describe como funcionaban as cousas antes.