SSTP e SSL 3.0: a etiqueta fronte á versión negociada

Dúas persoas poden mirar o mesmo despregamento de SSTP e chegar a conclusións opostas. Unha le a documentación do produto, ve as letras SSL e supón que o túnel executa un protocolo retirado hai anos. A outra sinala un apretón de mans moderno e conclúe que a cuestión está pechada. Ambas discuten desde etiquetas e non desde a versión negociada, e só unha desas cousas é proba. A comparación que paga a pena facer é entre o que promete o nome e o que o servizo selecciona realmente.

Dúas respostas á mesma pregunta

O argumento da etiqueta é fácil de enunciar: SSTP descríbese como un protocolo de túnel de sockets seguro, o nome histórico di SSL, polo tanto a conexión ten que ser SSL 3.0. Sobrevive porque o nome si procede desa liñaxe e porque a maioría de quen o repite nunca mirou un apretón de mans. Sobrevive tamén porque a conclusión soa prudente, coma se supoñer o peor fose a opción segura. Supoñer o peor e medir a versión real son actividades distintas, e só unha delas cambia algo.

O argumento da proba fai unha pregunta máis estreita. En que versión de protocolo se puxeron de acordo este cliente e este servidor, neste extremo, neste momento? A resposta vén do servizo que termina TLS, non dunha páxina de mercadotecnia nin dun navegador que chegou a un sitio de nome semellante.

Os dous argumentos difiren no que poden demostrar. A etiqueta non distingue un despregamento antigo dun corrixido, e o apretón de mans non pode dicirlle que fai un servizo alleo no mesmo host. Use a segunda e deixe de usar a primeira.

Lea a versión que o servizo selecciona realmente

Empece por nomear os compoñentes: a implementación cliente, a implementación servidor, o extremo TLS e todo o que hai no medio e termina e restablece TLS. Un balanceador de carga que termina TLS e fala HTTP simple co backend cambia de que dispositivo debe ler a política.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

Anote o extremo e a hora xunto ao resultado, porque un cambio posterior da política fai inútil unha observación sen data. Repita a sonda desde un cliente na mesma ruta de rede que os usuarios que lle importan, xa que un dispositivo de interceptación pode terminar TLS cos seus propios axustes. Se as dúas posicións non coinciden, atopou o compoñente que importa. Se coinciden, ten proba en lugar dun eslogan.

Separe o campo de rexistro da negociación

Un número de versión de aspecto antigo nun campo non é o mesmo feito que unha sesión SSL 3.0. RFC 7568 trata a versión da capa de rexistro e o protocolo negociado como asuntos distintos, e desa distinción veñen exactamente as respostas falsas e seguras. Lea o protocolo negociado, despois o cifrado e só entón saque unha conclusión sobre a sesión.

O mesmo documento é inequívoco sobre o protocolo en si: non debe usarse SSL 3.0, e prohíbese a negociación ou a caída a el. A razón é a construción CBC defectuosa que explotou o ataque POODLE, e iso é unha propiedade do protocolo e non a configuración dunha aplicación.

Por iso «esta carga de traballo probablemente sexa difícil de explotar» non é un argumento para manter SSL 3.0 habilitado. O requisito é eliminar o protocolo, non gañar un debate sobre unha demostración.

Retire SSL 3.0 cunha política que poida soster

En Windows, os axustes de protocolo de Schannel están baixo a clave Protocols e lense por función de cliente e de servidor, polo que un cambio que corrixe unha dirección pode deixar a outra intacta. Microsoft documenta os axustes actuais e os seus requisitos de reinicio, e unha biblioteca TLS de terceiros no mesmo host ignóraos por completo.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

Cambie a política pola vía de administración admitida, confirme que o servizo propietario volve obter a configuración e conserve unha forma aprobada de reverter. Pegar un script de rexistro amplo doutro ambiente é como a corrección dun servizo se converte nunha caída para todos os clientes TLS da máquina. O alcance do reinicio importa aquí: un axuste que parece aplicado pode seguir en memoria dun servizo que non o recargou.

Un par que aínda esixe unha versión obsoleta necesita unha actualización ou un plan de migración. Unha excepción non documentada que restaura o protocolo antigo en silencio non é unha estratexia de compatibilidade e non sobrevivirá á próxima auditoría.

Acepte o cambio con conexións novas

Probe con sesións novas despois do cambio de política, porque unha conexión establecida antes do cambio non demostra nada sobre a configuración vixente agora. Confirme que o protocolo aprobado ten éxito e que o prohibido falla mediante o proceso de validación autorizado, e despois deixe a identidade do certificado e as comprobacións de confianza exactamente como estaban.

Lembre o que o apretón de mans non cobre. SSTP transporta autenticación PPP despois da capa TLS, así que unha versión de protocolo moderna non di nada sobre que usuario foi autorizado nin a que recursos pode chegar a sesión. Son controis separados con probas separadas.

Escriba o resultado como servizo, backend, política permitida e versión observada. Ese rexistro responde con precisión á pregunta de seguridade, algo que nin o argumento da etiqueta nin o da incomodidade logran nunca.