SSTP and SSL 3.0: the Label Versus the Negotiated Version

Two people can look at the same SSTP deployment and reach opposite conclusions. One reads the product documentation, sees the letters SSL, and assumes the tunnel is running a protocol retired years ago. The other points at a modern handshake and concludes the question is closed. Both are arguing from labels rather than from the negotiated version, and only one of those is evidence. The comparison worth making is between what the name promises and what the service actually selects.

Two answers to the same question

The label argument is easy to state: SSTP is described as a secure socket tunnelling protocol, the historical name says SSL, therefore the connection must be SSL 3.0. It survives because the name genuinely does come from that lineage, and because most people who repeat it have never looked at a handshake. It also survives because the conclusion sounds conservative, as if assuming the worst were the safe choice. Assuming the worst and measuring the actual version are different activities, and only one of them changes anything.

The evidence argument asks a narrower question. Which protocol version did this client and this server agree on, at this endpoint, at this time? That answer comes from the service that terminates TLS, not from a marketing page or a browser that reached a similarly named website.

The two arguments differ in what they can prove. The label cannot distinguish an old deployment from a patched one, and the handshake cannot tell you what an unrelated service on the same host is doing. Use the second and stop using the first.

Read the version the service actually selects

Start by naming the components: the client implementation, the server implementation, the TLS endpoint, and anything in between that terminates and re-establishes TLS. A load balancer that ends TLS and speaks plain HTTP to the backend changes which device's policy you need to read.

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

Record the endpoint and the time alongside the result, because a later change to the policy makes an undated observation useless. Repeat the probe from a client on the same network path as the users you care about, since an interception device can terminate TLS with its own settings. If the two positions disagree, you have found the component that matters. If they agree, you have evidence rather than a slogan.

Separate the record field from the negotiation

A legacy-looking version number in one field is not the same fact as an SSL 3.0 session. RFC 7568 treats the record-layer version and the negotiated protocol as distinct concerns, and that distinction is exactly where confident wrong answers come from. Read the negotiated protocol, then read the cipher, and only then draw a conclusion about the session.

The same document is unambiguous about the protocol itself: SSL 3.0 must not be used, and negotiation or fallback to it is prohibited. The rationale is the broken CBC construction that the POODLE attack exploited, which is a property of the protocol rather than of one application's configuration.

That is why "this workload is probably hard to exploit" is not an argument for keeping SSL 3.0 enabled. The requirement is to remove the protocol, not to win a debate about one demonstration.

Retire SSL 3.0 with a policy you can support

On Windows, Schannel protocol settings live under the Protocols key and are read per client and per server role, which is why a change that fixes one direction can leave the other untouched. The current settings and their restart requirements are documented by Microsoft, and a third-party TLS library on the same host ignores them entirely.

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

Change the policy through the supported administration path, confirm the owning service reacquires its configuration, and keep an approved way back. Pasting a broad registry script from another environment is how a single service fix becomes an outage across every TLS client on the machine. Restart scope matters here: a setting that looks applied may still be held in memory by a service that has not reloaded it.

A peer that still requires an obsolete version needs an update or a migration plan. An undocumented exception that quietly restores the old protocol is not a compatibility strategy, and it will not survive the next audit.

Accept the change with fresh connections

Test with new sessions after the policy change, because a connection established before the change proves nothing about the configuration now in force. Confirm that the approved protocol succeeds and that the prohibited one fails through the authorized validation process, then leave certificate identity and trust checks exactly as they were.

Remember what the handshake does not cover. SSTP carries PPP authentication after the TLS layer, so a modern protocol version says nothing about which user was authorized or which resources the session may reach. Those are separate controls with separate evidence.

Write the result down as service, backend, allowed policy and observed version. That record answers the security question precisely, which neither the label argument nor an argument from inconvenience ever does.