SSTP i SSL 3.0: l’etiqueta davant la versió negociada

Dues persones poden mirar el mateix desplegament d’SSTP i arribar a conclusions oposades. Una llegeix la documentació del producte, veu les lletres SSL i suposa que el túnel executa un protocol retirat fa anys. L’altra assenyala una encaixada de mans moderna i conclou que la qüestió està tancada. Totes dues discuteixen des d’etiquetes i no des de la versió negociada, i només una d’aquestes coses és una prova. La comparació que val la pena fer és entre el que promet el nom i el que el servei selecciona realment.

Dues respostes a la mateixa pregunta

L’argument de l’etiqueta és fàcil d’enunciar: SSTP es descriu com un protocol de túnel de sockets segur, el nom històric diu SSL, per tant la connexió ha de ser SSL 3.0. Se sosté perquè el nom prové realment d’aquella línia i perquè la majoria de qui ho repeteix no ha mirat mai una encaixada de mans. També se sosté perquè la conclusió sona prudent, com si suposar el pitjor fos l’opció segura. Suposar el pitjor i mesurar la versió real són dues activitats diferents, i només una d’elles canvia alguna cosa.

L’argument de la prova fa una pregunta més estreta. En quina versió de protocol es van posar d’acord aquest client i aquest servidor, en aquest extrem, en aquest moment? La resposta ve del servei que acaba TLS, no d’una pàgina de màrqueting ni d’un navegador que va arribar a un lloc amb un nom semblant.

Els dos arguments difereixen en què poden demostrar. L’etiqueta no distingeix un desplegament antic d’un de corregit, i l’encaixada de mans no pot dir què fa un servei aliè al mateix amfitrió. Useu la segona i deixeu d’usar la primera.

Llegiu la versió que el servei selecciona realment

Comenceu per anomenar els components: la implementació client, la implementació servidor, l’extrem TLS i tot el que hi ha al mig i acaba i restableix TLS. Un balancejador de càrrega que acaba TLS i parla HTTP pla amb el backend canvia de quin dispositiu heu de llegir la 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

Anoteu l’extrem i l’hora al costat del resultat, perquè un canvi posterior de la política fa inútil una observació sense data. Repetiu la sonda des d’un client a la mateixa ruta de xarxa que els usuaris que us importen, ja que un dispositiu d’intercepció pot acabar TLS amb els seus propis ajustos. Si les dues posicions no coincideixen, heu trobat el component que importa. Si coincideixen, teniu una prova en lloc d’un eslògan.

Separeu el camp de registre de la negociació

Un número de versió d’aspecte antic en un camp no és el mateix fet que una sessió SSL 3.0. RFC 7568 tracta la versió de la capa de registre i el protocol negociat com a assumptes diferents, i d’aquesta distinció ve exactament les respostes falses i segures. Llegiu el protocol negociat, després el xifratge i només llavors traieu una conclusió sobre la sessió.

El mateix document és inequívoc sobre el protocol en si: no s’ha d’usar SSL 3.0, i es prohibeix la negociació o la caiguda a ell. La raó és la construcció CBC defectuosa que va explotar l’atac POODLE, i això és una propietat del protocol i no la configuració d’una aplicació.

Per això «aquesta càrrega de treball probablement és difícil d’explotar» no és un argument per mantenir SSL 3.0 habilitat. El requisit és eliminar el protocol, no guanyar un debat sobre una demostració.

Retireu SSL 3.0 amb una política que pugueu sostenir

A Windows, els ajustos de protocol de Schannel són sota la clau Protocols i es llegeixen per funció de client i de servidor, per la qual cosa un canvi que corregeix una direcció pot deixar l’altra intacta. Microsoft documenta els ajustos actuals i els seus requisits de reinici, i una biblioteca TLS de tercers al mateix amfitrió els ignora completament.

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

Canvieu la política per la via d’administració admesa, confirmeu que el servei propietari torna a obtenir la configuració i conserveu una manera aprovada de revertir. Enganxar un script de registre ampli d’un altre entorn és com la correcció d’un servei es converteix en una caiguda per a tots els clients TLS de la màquina. L’abast del reinici importa aquí: un ajust que sembla aplicat pot seguir en memòria d’un servei que no l’ha recarregat.

Un parell que encara exigeix una versió obsoleta necessita una actualització o un pla de migració. Una excepció no documentada que restaura el protocol antic en silenci no és una estratègia de compatibilitat i no sobreviurà a la propera auditoria.

Accepteu el canvi amb connexions noves

Proveu amb sessions noves després del canvi de política, perquè una connexió establerta abans del canvi no demostra res sobre la configuració vigent ara. Confirmeu que el protocol aprovat té èxit i que el prohibit falla mitjançant el procés de validació autoritzat, i després deixeu la identitat del certificat i les comprovacions de confiança exactament com estaven.

Recordeu què no cobreix l’encaixada de mans. SSTP transporta autenticació PPP després de la capa TLS, així que una versió de protocol moderna no diu res sobre quin usuari va ser autoritzat ni a quins recursos pot arribar la sessió. Són controls separats amb proves separades.

Escriviu el resultat com a servei, backend, política permesa i versió observada. Aquest registre respon amb precisió la pregunta de seguretat, cosa que ni l’argument de l’etiqueta ni el de la incomoditat aconsegueixen mai.