SSTP e SSL 3.0: l’etichetta contro la versione negoziata

Due persone possono guardare lo stesso deployment SSTP e arrivare a conclusioni opposte. Una legge la documentazione del prodotto, vede le lettere SSL e presume che il tunnel stia eseguendo un protocollo ritirato anni fa. L’altra indica un handshake moderno e conclude che la questione è chiusa. Entrambe discutono di etichette anziché della versione negoziata, e solo una di queste cose è una prova. Il confronto che vale la pena fare è tra ciò che il nome promette e ciò che il servizio seleziona davvero.

Due risposte alla stessa domanda

L’argomento dell’etichetta è facile da enunciare: SSTP è descritto come protocollo di tunnelling su socket sicuro, il nome storico dice SSL, quindi la connessione deve essere SSL 3.0. Sopravvive perché il nome viene davvero da quella discendenza e perché quasi tutti quelli che lo ripetono non hanno mai guardato un handshake. Sopravvive anche perché la conclusione suona prudente, come se presumere il peggio fosse la scelta sicura. Presumere il peggio e misurare la versione reale sono attività diverse, e solo una delle due cambia qualcosa.

L’argomento della prova pone una domanda più stretta. Su quale versione di protocollo si sono accordati questo client e questo server, su questo endpoint, in questo momento? La risposta viene dal servizio che termina TLS, non da una pagina di marketing né da un browser che ha raggiunto un sito dal nome simile.

I due argomenti differiscono in ciò che possono dimostrare. L’etichetta non distingue un deployment vecchio da uno aggiornato, e l’handshake non può dirti cosa fa un servizio estraneo sullo stesso host. Usa il secondo e smetti di usare il primo.

Leggi la versione che il servizio seleziona davvero

Comincia a nominare i componenti: l’implementazione client, quella server, l’endpoint TLS e tutto ciò che nel mezzo termina e ristabilisce TLS. Un bilanciatore di carico che termina TLS e parla HTTP in chiaro con il backend cambia il dispositivo di cui devi leggere la politica.

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

Annota endpoint e ora accanto al risultato, perché una modifica successiva della politica rende inutile un’osservazione senza data. Ripeti la sonda da un client sullo stesso percorso di rete degli utenti che ti interessano, dato che un dispositivo di intercettazione può terminare TLS con le proprie impostazioni. Se le due posizioni non concordano, hai trovato il componente che conta. Se concordano, hai una prova invece di uno slogan.

Separa il campo di record dalla negoziazione

Un numero di versione dall’aria antiquata in un campo non è lo stesso fatto di una sessione SSL 3.0. RFC 7568 tratta la versione del record layer e il protocollo negoziato come questioni distinte, ed è esattamente da quella distinzione che nascono le risposte sbagliate e sicure di sé. Leggi il protocollo negoziato, poi la cifratura, e solo allora trai una conclusione sulla sessione.

Lo stesso documento è inequivocabile sul protocollo in sé: SSL 3.0 non deve essere usato, e la negoziazione o il fallback a esso sono proibiti. La ragione è la costruzione CBC difettosa sfruttata dall’attacco POODLE, che è una proprietà del protocollo e non la configurazione di una singola applicazione.

Ecco perché «questo carico di lavoro è probabilmente difficile da sfruttare» non è un argomento per tenere SSL 3.0 abilitato. Il requisito è rimuovere il protocollo, non vincere un dibattito su una singola dimostrazione.

Ritira SSL 3.0 con una politica che puoi sostenere

Su Windows le impostazioni di protocollo di Schannel stanno sotto la chiave Protocols e vengono lette per ruolo client e per ruolo server, ed è per questo che una modifica che sistema una direzione può lasciare intatta l’altra. Le impostazioni attuali e i requisiti di riavvio sono documentati da Microsoft, e una libreria TLS di terze parti sullo stesso host le ignora del tutto.

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

Modifica la politica tramite il percorso di amministrazione supportato, conferma che il servizio proprietario riacquisisca la configurazione e conserva un modo approvato per tornare indietro. Incollare uno script di registro ampio preso da un altro ambiente è il modo in cui la correzione di un singolo servizio diventa un’interruzione per ogni client TLS della macchina. L’ambito del riavvio conta qui: un’impostazione che sembra applicata può essere ancora tenuta in memoria da un servizio che non l’ha ricaricata.

Un peer che richiede ancora una versione obsoleta ha bisogno di un aggiornamento o di un piano di migrazione. Un’eccezione non documentata che ripristina in silenzio il vecchio protocollo non è una strategia di compatibilità e non supererà il prossimo audit.

Accetta la modifica con connessioni nuove

Prova con sessioni nuove dopo la modifica della politica, perché una connessione stabilita prima della modifica non prova nulla sulla configurazione ora in vigore. Conferma che il protocollo approvato riesca e che quello vietato fallisca tramite il processo di validazione autorizzato, poi lascia identità del certificato e controlli di fiducia esattamente come stavano.

Ricorda cosa l’handshake non copre. SSTP trasporta l’autenticazione PPP dopo il livello TLS, quindi una versione di protocollo moderna non dice nulla su quale utente sia stato autorizzato né su quali risorse la sessione possa raggiungere. Sono controlli separati con prove separate.

Scrivi il risultato come servizio, backend, politica consentita e versione osservata. Quel registro risponde con precisione alla domanda di sicurezza, cosa che né l’argomento dell’etichetta né quello del disagio fanno mai.