SSTP és PPP sobre HTTPS, no una pàgina web al port 443

SSTP transporta PPP dins d’una connexió HTTPS, i per això sembla trànsit web per a qualsevol cosa que hi hagi al mig. TLS i HTTP estableixen el canal exterior, després els missatges de control d’SSTP preparen el túnel i PPP aporta el comportament de la sessió. Un navegador que carrega una pàgina a la mateixa adreça només ha completat una part de la primera etapa. Tractar-ho com una prova de VPN és com es culpa un proxy que funciona d’una discrepància de protocol.

Recorre les quatre etapes en ordre, i la fallada que veus caurà en una d’elles.

Etapa 1: TCP i TLS

El client obre una connexió TCP al port 443 i fa un handshake TLS. La cadena de certificats ha de coincidir amb el nom d’amfitrió amb què es va configurar el client. Una discrepància de nom aquí produeix una fallada abans que s’intercanviï cap missatge SSTP, i la especificació d’SSTP assumeix que aquest canal HTTPS exterior ja existeix. Res de les etapes posteriors no pot compensar una fallada de confiança aquí.

Un servidor web genèric pot completar aquesta etapa perfectament i tot i així fallar la següent. L’èxit de TLS és una evidència sobre el certificat, no sobre el protocol que hi ha darrere.

Etapa 2: la petició HTTPS

SSTP fa la seva petició amb un mètode específic, SSTP_DUPLEX_POST, i manté l’intercanvi obert en lloc de retornar un document. Un servidor o proxy configurat per a peticions de pàgina ordinàries pot acceptar la connexió i després rebutjar el mètode. Aquest rebuig és el problema de compatibilitat que la gent sol descriure com que el port 443 està bloquejat.

Llegeix el codi de resposta i el mètode al registre del servidor. Un rebuig en aquesta etapa és un problema diferent d’un temps d’espera TCP, i tots dos porten a correccions diferents.

Etapa 3: missatges de control

Un cop acceptada la petició, SSTP intercanvia missatges de control que negocien i preparen el túnel. Són missatges de protocol dins del cos HTTPS, no peticions HTTP, així que un proxy que inspecciona i reescriu cossos els pot trencar mentre deixa les peticions de pàgina intactes.

Aquí és on un dispositiu d’inspecció profunda guanya la seva reputació. Si les pàgines carreguen i la VPN falla, comprova si el cos es modifica en lloc de si el port és obert.

Etapa 4: PPP pren el relleu

PPP aporta després el comportament de la sessió: negociació de l’enllaç, autenticació i la configuració de la capa de xarxa que segueix. L’autenticació PPP és separada de la comprovació TLS que el client ja ha superat. Un certificat de servidor que el client accepta no diu res sobre si les credencials de l’usuari són vàlides o si el compte està autoritzat.

Un certificat acceptat i un inici de sessió rebutjat no són contradictoris. Són etapes consecutives amb resultats independents.

L’autenticació té diversos papers

El client valida la identitat del servidor TLS contra el seu magatzem de confiança i el nom configurat. PPP autentica després l’usuari o la màquina, segons el desplegament. El servidor pot afegir la seva pròpia política sobre qui es pot connectar i a què pot arribar. Mantén el nom d’amfitrió coherent amb la identitat del certificat, perquè substituir-lo per una adreça crua converteix una configuració que funciona en una fallada de comprovació de nom.

Anota quina etapa ha reportat la fallada. Certificat, mètode, missatge de control, autenticació PPP, després rutes: cinc llocs, cinc reparacions.

Què pot i què no pot mostrar una prova al navegador

Carregar una pàgina a l’adreça demostra resolució DNS, abastabilitat TCP i que hi ha alguna cosa escoltant que parla HTTP. No demostra que el mètode s’accepti, que l’intercanvi de control sobrevisqui o que l’autenticació PPP estigui configurada. Fes servir un client que implementi SSTP en lloc de convertir un altre perfil canviant el port.

Un cop la sessió està en marxa, les rutes, el DNS i el reenviament del costat del servidor encara decideixen a què pot arribar l’usuari. El túnel és un camí, no una autorització.