SSTP Explained: The Built-In Windows Protocol That Runs on Port 443

Every major VPN protocol in Windows has a story about what problem it was built to solve. PPTP and L2TP/IPsec each had their moment: the first solved the original remote-access problem and became a security liability; the second solved the encryption gap and was deprecated by Microsoft and retired from Android by Google, with Apple separately removing the legacy cryptographic primitives that most L2TP/IPsec gateway configurations depend on. SSTP solved a different problem, one that neither of its predecessors had addressed: how to make VPN traffic pass through any firewall, on any network, using only software already installed on your machine. Eighteen years later, it is the only Microsoft-designed protocol from that era still standing.

What follows is an explanation of what SSTP is and how it works, what “hiding in HTTPS” actually means technically, where that disguise holds and where it breaks down, and what a cluster of five remote code execution vulnerabilities in its Windows Server implementation tells you about when to use it and when not to. If you are new to VPN protocols in general, VPN Protocols Explained covers the full landscape before you read further here.

SSTP in plain English

SSTP wraps your VPN traffic inside a standard TLS connection on port 443, the same mechanism your browser uses when visiting any HTTPS website. A firewall inspecting the connection sees TLS on port 443 and passes it without question, treating it as ordinary web traffic. Inside that encrypted TLS channel sits a PPP session carrying your actual data, protected further by Crypto Binding that ties the server’s certificate identity to your authentication. The result is a VPN that passes through almost any firewall without special configuration, runs natively on every Windows machine since Vista SP1, and requires no third-party software to connect. SSTP is a remote-access protocol — designed for client-to-server connections — and is not intended or commonly used for site-to-site VPN tunnels between gateways.

What SSTP is not: four protocols it gets confused with

Several protocols share letters or concepts with SSTP, and the confusion is common enough that search engines and AI retrieval systems regularly conflate them.

Protocol	What it actually is	Relationship to SSTP
SSH tunneling	Port forwarding via Secure Shell — forwards specific TCP ports through an encrypted SSH session, typically for remote server access	None. SSH tunneling is not a VPN protocol and does not route all IP traffic. Different transport (port 22), different authentication (key pairs), different architecture. Not interchangeable with SSTP.
SFTP	SSH File Transfer Protocol — a file transfer subsystem running over SSH	None. SFTP is a file transfer tool, not a tunneling or VPN protocol. The acronym overlap is purely coincidental.
SoftEther	A multi-protocol VPN package (University of Tsukuba) that can emulate SSTP, L2TP/IPsec, OpenVPN, and its own protocol	Adjacent. SoftEther can accept SSTP client connections, which is why SSTP Connect for iOS lists SoftEther support alongside SSTP. SoftEther is a separate project from Microsoft’s SSTP specification.
SCTP	Stream Control Transmission Protocol (RFC 4960, updated by RFC 9260) — a transport-layer protocol at OSI Layer 4, alongside TCP and UDP	None. SCTP has no connection to VPNs or tunneling. The three-letter collision is lexical only.

Quick facts

Field	Detail
Protocol type	VPN tunnelling protocol
Developer	Microsoft
First release	Windows Vista SP1 and Windows Server 2008, 2007–2008
Specification	[MS-SSTP] — Microsoft proprietary; no IETF RFC; published at learn.microsoft.com/openspecs
Outer transport	TCP port 443
Security layer	TLS (Transport Layer Security) via Windows Schannel
Inner protocol	PPP (Point-to-Point Protocol)
Server authentication	Mandatory — TLS certificate; no PSK fallback
Client authentication	Optional in TLS phase; mandatory in PPP phase
Recommended PPP auth methods	MS-CHAP v2, PEAP, EAP-TLS
Crypto Binding	Yes — server TLS certificate hash bound to PPP authentication via Compound MAC (HMAC-SHA-256 / SHA-1)
Platform status (2026)	Windows 10/11 and Windows Server: native. Linux: sstp-client (third-party). macOS, iOS, Android: no native client.
Microsoft deprecation status	Not deprecated — named as supported replacement for PPTP and L2TP/IPsec in Microsoft’s October 2024 announcement

Where SSTP came from

The problem PPTP left behind

PPTP was Microsoft’s original VPN protocol, built into Windows and widely deployed through the 1990s and 2000s. Its MS-CHAPv2 authentication was demonstrated to be fundamentally crackable, and its use of GRE — a non-TCP/UDP IP protocol with no port number — made it straightforward for any firewall to block by dropping the GRE protocol number.

L2TP/IPsec addressed PPTP’s security shortcomings but kept the same port-blocking problem in a different form. UDP 500, UDP 4500, and IP Protocol 50 are fixed, well-known values that any firewall administrator can disable in a single rule. Any hotel network, corporate environment, or national firewall that wants to block L2TP/IPsec can do so in seconds, with no collateral damage to web access. SSTP was built to fill that specific gap: a protocol that is secure, Windows-native, and uses a port no network can realistically block without disabling all HTTPS web browsing simultaneously.

Vista SP1 to Windows Server 2025: a protocol that survived its generation

SSTP shipped with Windows Vista SP1 and Windows Server 2008 and has been native to every subsequent Windows release through Windows 11 and Windows Server 2025. The critical inflection point came in October 2024, when Microsoft published its deprecation announcement for PPTP and L2TP/IPsec on the Windows Server TechCommunity blog. That announcement explicitly named SSTP and IKEv2/IPsec as the supported replacements going forward. SSTP was not deprecated; it survived the same consolidation that retired two of its predecessors. Microsoft’s stated preference is IKEv2 for new deployments; SSTP is the recommended secondary option for environments where TCP 443 is a hard requirement or where IKEv2 infrastructure has not yet been deployed.

Why Microsoft kept SSTP when it retired PPTP and L2TP/IPsec

Four structural differences between SSTP and its deprecated predecessors explain the October 2024 decision.

TCP 443 is irreplaceable in Microsoft’s native protocol stack. IKEv2 uses UDP 500/4500. PPTP uses GRE. L2TP/IPsec uses UDP 500/4500 and IP Protocol 50. SSTP is the only Microsoft-native VPN protocol that uses a port almost universally permitted on the internet. No other protocol on the deprecated list could bypass a port-restrictive network without third-party software. That specific capability had no substitute.

TLS is a stronger security foundation than IKEv1. SSTP’s security layer is provided by TLS, which has benefited from 25-plus years of independent scrutiny and active standardisation through the IETF TLS working group. L2TP/IPsec’s security was anchored to IKEv1, published in 1998, carrying known weaknesses in its PSK authentication modes and historically vulnerable to weak Diffie-Hellman group defaults. SSTP’s TLS layer is immune to both.

Certificate-mandatory design eliminates the PSK failure mode. SSTP requires a server TLS certificate at the protocol level; there is no PSK fallback at the TLS layer. This removes the deployment failure mode that compromised many L2TP/IPsec installations in practice, where publicly documented or shared pre-shared keys reduced effective security to near-zero.

Crypto Binding gave SSTP a documented channel-binding defence. The [MS-SSTP] specification includes the Crypto Binding mechanism — a Compound MAC that ties the server’s TLS certificate hash to the PPP authentication exchange. Neither PPTP nor L2TP/IPsec includes an equivalent channel-binding construction that cryptographically ties the inner PPP authentication to the outer tunnel identity. PPTP has no relay protection at all. L2TP/IPsec provides mutual endpoint authentication through IKE, which does address transport-layer MITM, but it lacks the compound-MAC binding that would prevent an attacker from relaying a legitimately authenticated PPP session into a different outer channel. SSTP arrived with a published defence against that specific attack class that its predecessors lacked.

How SSTP works: PPP inside a TLS tunnel

SSTP establishes a connection in five sequential stages. No user data flows until all five are complete.

Phase 1 — TCP connection on port 443

The client opens a TCP connection to the VPN server on port 443. At the network level this is indistinguishable from an HTTPS connection to any website: a standard TCP three-way handshake on the HTTPS port. No encryption is active yet, no VPN tunnel exists, and no authentication has occurred. What the network observes is a TCP SYN to port 443, which virtually every network allows outbound, because blocking it would simultaneously block all HTTPS web browsing.

Phase 2 — TLS handshake and server certificate validation

With the TCP socket established, the client initiates a TLS handshake. The server presents its TLS certificate; the client validates it against a trusted Certificate Authority. Server certificate authentication is mandatory in SSTP and cannot be replaced with a pre-shared key at the TLS layer — unlike L2TP/IPsec, where PSK is the common deployment and the source of documented IKEv1 vulnerabilities. Once the handshake completes, all subsequent traffic travels inside the encrypted TLS channel. The firewall can observe that a TLS connection on port 443 exists; it cannot read the contents or identify the connection as a VPN tunnel.

TLS version in practice: on current Windows 11 clients connecting to Windows Server 2022 or 2025, TLS 1.3 is available. TLS 1.2 is the practical baseline on older endpoints. SSL 3.0 is disabled by default on Windows Server 2022 and 2025 — the POODLE vulnerability that affects SSL 3.0 is not an active risk on fully updated installations.

Phase 3 — SSTP tunnel negotiation

Inside the established TLS connection, the client sends a request using the custom HTTP verb SSTP_DUPLEX_POST to a specific URI path on the server. The request declares a Content-Length of 2⁶⁴ − 1 — the maximum unsigned 64-bit value — meaning the request body is never completed in the conventional HTTP sense. The connection is held open and SSTP control messages flow through it. From the perspective of an external observer watching the TCP stream, the session resembles a long-running HTTPS upload; the custom verb and the URI path travel inside the TLS encryption and are not readable from the wire without first decrypting the session.

Phase 4 — PPP session and user authentication

With the SSTP tunnel established, a PPP (Point-to-Point Protocol) session is negotiated inside it. PPP handles user-level authentication at this stage. The recommended methods are MS-CHAP v2, PEAP, and EAP-TLS; other PPP authentication methods including PAP and CHAP are technically negotiable but must not be used with SSTP. PAP and CHAP generate no usable keying material, so the Higher-Layer Authentication Key becomes 32 zero bytes and the Compound MAC Key is derived from null input — making the Compound MAC computable by any attacker and effectively nullifying Crypto Binding’s relay protection entirely.

At the completion of Phase 4, SSTP performs Crypto Binding. The SSTP Call Connected message carries two binding elements: the server’s TLS certificate hash (a 32-byte SHA-256 value, or 20-byte SHA-1 for older implementations) and the Compound MAC, a keyed HMAC computed over the entire message with the MAC field zeroed. The HMAC key is the Compound MAC Key (CMK), derived via the IKEv2 PRF+ construction from the Higher-Layer Authentication Key contributed by the PPP authentication method. Because the certificate hash is included in the message being MAC’d, the Compound MAC cryptographically binds that specific server certificate to the PPP session. An attacker who intercepts the TLS session and attempts to relay the PPP authentication to a different TLS context will produce a mismatched certificate hash, and authentication fails. Crypto Binding is documented in the [MS-SSTP] specification.

Phase 5 — Data flow

User traffic is framed as PPP packets, encapsulated inside the SSTP layer, encrypted by TLS, and transmitted over TCP 443. The complete packet stack from outside in: TCP/IP header, TLS record, SSTP header, PPP frame, user payload. Every packet traverses this full stack in both directions for the life of the connection.

Port 443: what “looking like HTTPS” actually means — and where it stops

Why stateless firewalls pass SSTP traffic

SSTP traffic passes through virtually any stateless firewall because it arrives on TCP port 443 with a valid TLS record structure, the same observable properties as an HTTPS connection to any website. A stateless firewall makes its allow/block decision based on port number and protocol — it does not inspect payload content. Port 443, TLS record: the firewall allows it without further examination. This is why SSTP works on hotel networks, corporate environments with basic access control rules, and many national networks that block standard VPN ports: blocking TCP 443 would disable all HTTPS web access simultaneously, which is not a realistic option for any network that wants to remain functional.

The one exception: authenticated web proxies

Authenticated web proxies are the documented case where SSTP is blocked even on TCP 443. These are proxy servers that require users to authenticate before forwarding traffic and that validate the content of what they forward. An authenticated proxy can inspect the SSTP control messages during Phase 3 and identify the connection as a VPN tunnel rather than a genuine HTTPS web request. This limitation is documented in connection with the [MS-SSTP] specification. Most consumer networks and corporate environments with basic firewall rules do not deploy authenticated web proxies; enterprise environments with dedicated internet security appliances sometimes do.

Where the disguise ends: deep packet inspection

SSTP provides stateless firewall bypass, not true obfuscation. The distinction matters for how far the disguise holds under more sophisticated inspection.

Passive deep packet inspection sitting on the wire cannot read the SSTP URI path or the SSTP_DUPLEX_POST verb, because both travel inside the encrypted TLS tunnel. What passive DPI can use for identification are TLS handshake fingerprints (JA3 or JA4 signatures), the characteristic long-lived single-connection pattern resulting from the Phase 3 held-open request, and certificate or SNI heuristics. These are probabilistic signals rather than definitive identification.

Active probing produces definitive results: the Nmap sstp-discover script constructs a valid SSTP_DUPLEX_POST request and confirms whether the server responds with SSTP control messages. TLS-terminating middleboxes — SSL inspection appliances that decrypt and re-encrypt sessions — can read the SSTP URI after decryption and block SSTP distinctly from other HTTPS traffic. Commercial next-generation firewalls from vendors including Palo Alto Networks and Fortinet maintain SSTP application signatures that operate in this way, provided SSL inspection is enabled.

SSTP is meaningfully more firewall-friendly than IKEv2/IPsec (UDP 500/4500, easily blocked) or WireGuard (non-standard UDP, no port-443 fallback). Against networks running active SSL inspection, it provides less protection than a purpose-built obfuscation protocol — for those options, see What Is an Obfuscated VPN?

SSTP vs HTTPS and SSL VPN: clarifying two common comparisons

SSTP vs HTTPS. SSTP uses HTTPS’s transport — TCP port 443 with TLS — but is a tunneling protocol, not a web protocol. An HTTPS connection carries web content between a browser and a web server using HTTP request/response semantics; the session ends when the response is delivered. An SSTP connection carries an encrypted PPP session between a VPN client and a VPN server, held open indefinitely via the SSTP_DUPLEX_POST mechanism. The port and TLS layer are shared; the application layer is entirely different. To a stateless firewall, SSTP and HTTPS are indistinguishable. To any system that decrypts and inspects the session content, they are distinct in purpose, structure, and behaviour.

SSTP vs SSL VPN. “SSL VPN” is a broad industry category covering any VPN product that uses SSL/TLS as its security layer — which technically includes SSTP. The term more commonly refers to clientless browser-portal VPN products such as Cisco Secure Client (formerly AnyConnect) clientless mode, Ivanti Connect Secure (formerly Pulse Connect Secure), and Fortinet Agentless VPN (formerly SSL VPN portal, renamed in FortiOS 7.6.3), which provide browser-based access to web applications and file shares without a dedicated VPN protocol client installed on the device. These operate at the application layer, reverse-proxying specific resources rather than routing all IP traffic. SSTP is a full-tunnel PPP-based VPN. When enterprise procurement documentation or vendor comparison sheets list “SSL VPN,” they typically mean the portal-based category; SSTP belongs to the full-tunnel VPN category and is not equivalent to those products.

The TCP Meltdown phenomenon

SSTP always tunnels traffic inside a TCP connection. TCP is a reliable delivery protocol that retransmits any packet that is lost in transit. When a TCP stream runs inside another TCP connection, both layers operate their own independent retransmission logic. On a stable network the overhead is negligible. On a lossy network — congested mobile data, satellite links, high-latency international paths — the two retransmission stacks interact destructively. The outer TCP detects packet loss and retransmits; the inner TCP independently detects the same loss and also retransmits; the compounding cycles progressively saturate available bandwidth and collapse throughput. This is called TCP Meltdown, documented formally by Olaf Titz in “Why TCP Over TCP Is A Bad Idea” (2001). It is structural to SSTP, not configurable away.

On reliable broadband, SSTP delivers throughput broadly comparable to OpenVPN in TCP mode. On unreliable connections, performance degrades significantly relative to UDP-based protocols such as WireGuard and IKEv2/IPsec, which are unaffected by TCP Meltdown. This is a meaningful consideration in the contexts where SSTP is most commonly deployed — travel, hotel networks, restrictive environments — because those are precisely the situations where underlying connection reliability is lowest.

For comparison: OpenVPN defaults to UDP and switches to TCP 443 only as a fallback for restrictive networks, paying the TCP Meltdown cost only when necessary. WireGuard and IKEv2 use UDP exclusively and never incur it. SSTP is structurally subject to TCP Meltdown on every connection, because TCP 443 is its only transport — though the realized throughput penalty only manifests under packet loss or high latency, and is negligible on a stable link.

Security: TLS, certificates, and what the CVE record reveals

1. What TLS-based security avoids

SSTP’s TLS foundation sidesteps two specific vulnerabilities that define the security risk profile of IKEv1-based protocols. First, there is no PSK exposure: server authentication in SSTP requires a certificate, so the offline dictionary attack demonstrated in CVE-2018-5389 against IKEv1 pre-shared keys does not apply. Second, TLS key exchange uses ECDHE with modern curves including X25519 and P-256 on current Windows implementations, not the 1024-bit MODP Diffie-Hellman groups whose vulnerability in IKEv1 deployments was documented in “Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice” (Adrian et al., ACM CCS 2015). SSTP’s TLS architecture avoids both.

SSTP does not mandate a specific bulk encryption algorithm. The cipher used is whatever TLS negotiates between client and server via Windows Schannel. The common claim that “SSTP uses AES-256” describes a typical configuration outcome, not a protocol requirement. Schannel defaults on Windows Server 2022 and 2025 prioritise ECDHE-based AEAD suites, making AES-256-GCM the likely negotiated cipher on current systems — but the actual cipher depends on the server’s Schannel configuration. For a full explanation of what AEAD encryption means in practice, see VPN Encryption Explained.

2. Crypto Binding: the MITM relay defence

SSTP includes a mechanism called Crypto Binding that is absent from both PPTP and L2TP/IPsec. In a TLS-over-PPP architecture without binding, a man-in-the-middle attacker who intercepts the TLS session could relay the PPP authentication exchange to a different TLS context, effectively separating the channel from the identity that authenticated it. Crypto Binding closes that gap.

The SSTP Call Connected message carries two binding elements: the server’s TLS certificate hash (SHA-256, or SHA-1 as a compatibility fallback) and the Compound MAC, a keyed HMAC computed over the entire message with the MAC field zeroed. The HMAC key is the Compound MAC Key (CMK), derived via the IKEv2 PRF+ construction from the Higher-Layer Authentication Key contributed by the PPP authentication method. Because the server’s certificate hash is included in the message being MAC’d, the Compound MAC cryptographically binds that specific certificate identity to the PPP session. An attacker relaying the session through a different TLS context will present a mismatched certificate hash; Compound MAC verification fails and the connection is rejected. The full specification is in [MS-SSTP], published under Microsoft’s Open Specifications programme at learn.microsoft.com.

3. The CVE record: five RCEs across six months

The Windows SSTP component — specifically the SSTP service (sstpsvc) within the Routing and Remote Access Service, which is shared between Windows Server RRAS and the Windows VPN client stack — accumulated five remote code execution vulnerabilities between December 2022 and May 2023. All five carry a CVSS base score of 8.1 (High) and are exploitable by an unauthenticated remote attacker sending a crafted packet to the SSTP listener on TCP 443. Each involves a concurrency or memory-safety defect in the sstpsvc implementation; none represents a break in the MS-SSTP protocol design itself.

CVE	Weakness class	CVSS	Patched
CVE-2022-44670	CWE-367 TOCTOU race condition	8.1 HIGH	December 2022 Patch Tuesday
CVE-2022-44676	RCE in SSTP handler	8.1 HIGH	December 2022 Patch Tuesday
CVE-2023-21535	CWE-362 race condition / CWE-591 improper memory locking	8.1 HIGH	January 2023 Patch Tuesday
CVE-2023-21548	RCE in SSTP handler	8.1 HIGH	January 2023 Patch Tuesday
CVE-2023-24903	CWE-362 race condition / CWE-415 double free	8.1 HIGH	May 2023 Patch Tuesday

Attack complexity for each is rated High (AC:H): the underlying defects are race conditions that require winning a timing window, so exploitation is not trivially reliable. None of the five requires authentication. The SSTP listener on TCP 443 is the sufficient attack surface when the server is internet-exposed, which is exactly the deployment scenario SSTP is used for.

The mitigation is keeping Windows Server current. All five CVEs were addressed through Patch Tuesday updates, and the interim measure where SSTP is not needed is to disable the SSTP listener in RRAS to eliminate the exposed attack surface. The pattern of five CVSS 8.1 unauthenticated RCEs in sstpsvc within a six-month window reflects recurring memory-safety issues in a specific closed-source implementation; it is not evidence of a protocol-level break.

4. POODLE and SSL 3.0: a configuration concern, not a protocol break

Several sources claim SSTP is vulnerable to the POODLE attack (CVE-2014-3566) because it uses SSL 3.0. This requires a correction. SSTP uses TLS, not SSL 3.0. POODLE is a padding-oracle attack specific to the SSL 3.0 CBC construction; it is only reachable if SSL 3.0 remains enabled in the underlying TLS stack and a protocol downgrade can be negotiated.

On Windows Server 2022 and 2025, and on modern Windows 10/11, SSL 3.0 is disabled by default in Schannel. POODLE is not an active risk on any default modern Windows installation. It becomes a concern only on older or manually misconfigured deployments where an administrator has explicitly re-enabled SSL 3.0. If your RRAS server is running on a current, fully patched Windows Server release, no SSL 3.0 remediation is required.

5. TunnelCrack: routing table leaks that affect all Windows VPN clients

TunnelCrack (USENIX Security 2023, Xue, Malla, Xia, Pöpper, and Vanhoef) describes two named routing table attack patterns that can divert some traffic outside an active VPN tunnel. The LocalNet attack exploits the direct route Windows automatically adds to the local network segment; the ServerIP attack exploits the route Windows adds to reach the VPN server itself. Both are assigned CVEs at different severity levels (the most serious, CVE-2023-36673, carries CVSS 7.4).

These attacks are not specific to SSTP. They affect Windows VPN clients broadly, regardless of the protocol in use, and were also demonstrated against macOS and iOS VPN clients. Microsoft treats this as a configuration matter to be addressed through forced tunnelling rather than a patching issue; no security update has been issued for the built-in Windows VPN client behaviour. The practical mitigation is a forced tunnel configuration that routes all traffic, including DNS, through the VPN, leaving no local routes for the attacks to exploit. If your deployment already uses full-tunnel routing — standard for most enterprise and privacy-focused configurations — TunnelCrack presents no additional risk.

6. The closed-source concern: [MS-SSTP] and the audit gap

SSTP’s specification is [MS-SSTP], published under Microsoft’s Open Specifications programme at learn.microsoft.com. It is not an IETF RFC, and SSTP has never been submitted to the IETF standardisation process. The protocol has not received the kind of independent cryptographic scrutiny that OpenVPN (roughly 25 years of community audit and multiple named third-party assessments) or WireGuard (formal NDSS 2017 academic paper, Linux kernel inclusion review process) have accumulated. The Windows implementation is closed-source, observable only by examining network traffic rather than reviewing code. These five CVEs were discovered through security research and Microsoft’s vulnerability disclosure programme, not through open code review.

For users whose threat model includes specific concern about Microsoft — SSTP traffic transits Microsoft’s TLS implementation on Microsoft’s OS, connecting to a Windows Server RRAS instance — this is a material consideration. The protocol has an 18-year operational history without a fundamental design break, but that record rests on deployment history rather than verified independent analysis.

Platform support

Platform	Status	Notes
Windows 10 / 11 (client)	✅ Native	Settings → Network & Internet → VPN → Add a VPN connection. Select SSTP as the VPN type. No third-party software required.
Windows Server (RRAS)	✅ Supported	Client and server roles. Confirmed available in Windows Server 2025. Named in Microsoft’s October 2024 deprecation announcement as a supported replacement for PPTP and L2TP/IPsec.
Linux	⚠️ Third-party	sstp-client (open-source) is available via standard package managers on major distributions. NetworkManager-sstp provides desktop GUI integration. Installation required; not built in.
macOS	⚠️ Third-party only	No native macOS SSTP client. sstp-client is available via Homebrew and MacPorts. IKEv2 and WireGuard are the practical native-quality alternatives on macOS.
iOS	⚠️ Third-party only	No native iOS SSTP client. SSTP Connect is a third-party App Store app supporting SSTP/MS-SSTP and SoftEther VPN. Limited and not recommended for general use.
Android	⚠️ Third-party only	No native Android SSTP client. Open SSTP Client (open-source, by kittoku, on Google Play) provides SSTP access. Limited and not recommended for general use.
RouterOS (MikroTik)	✅ Supported	Supported since RouterOS v5.0 in both client and server modes. Note: certificate-less SSTP mode (introduced in v5.0beta2) is MikroTik-to-MikroTik only and is not Windows-compatible.

Windows native: what “no installer required” means in practice

On Windows 10 and 11, SSTP is accessible directly from Settings without downloading any application. A connection requires three values: the server address, the VPN type (SSTP), and the user credentials. Windows validates the server’s TLS certificate automatically against its built-in trust store. In managed enterprise environments where software installation is governed by Group Policy, SSTP is the only TCP-443 protocol that works within those constraints without requiring a software deployment exception. IKEv2 is also native to Windows, but its UDP ports (500 and 4500) are blocked by many of the same restrictive networks where SSTP is needed. SSTP on TCP 443 is the native option that persists where IKEv2 cannot connect.

Linux, MikroTik, and mobile: what to expect in practice

Linux. sstp-client is available in the package repositories of major distributions — sstp-client on Debian and Ubuntu-based systems, with equivalent packages on Fedora (and on RHEL-family distributions via EPEL). NetworkManager-sstp integrates SSTP into NetworkManager, with a GNOME/GTK front-end provided by the accompanying NetworkManager-sstp-gnome package. The server certificate must either come from a publicly trusted CA already present in the system’s CA bundle, or you must place the CA root into /usr/local/share/ca-certificates/ and run update-ca-certificates to register it with the system store. Alternatively, pass the certificate directly to the sstpc binary via --ca-cert <path>. Once configured, sstp-client produces a connection functionally equivalent to the Windows native client against a standard Windows Server RRAS endpoint.

MikroTik RouterOS. When RouterOS acts as an SSTP server accepting connections from Windows clients, the server certificate must be issued by a CA that Windows trusts. RouterOS’s built-in self-signed CA is not trusted by Windows by default; using it requires manually importing the RouterOS CA root into the Windows trust store on each client machine, or replacing it with a certificate from a publicly trusted CA. The certificate-less SSTP mode available since RouterOS v5.0beta2 bypasses this requirement but works only for MikroTik-to-MikroTik connections — Windows SSTP clients will reject a certificate-less endpoint and display a certificate verification error.

macOS, iOS, and Android. No native client exists on any of the three. The options are sstp-client via Homebrew or MacPorts on macOS, SSTP Connect (a third-party App Store app that also supports SoftEther) on iOS, and Open SSTP Client (free, open-source, on Google Play) on Android. Support on all three is functional but limited compared to the Windows native experience; certificate trust issues and configuration complexity are more common. For these platforms, IKEv2/IPsec — native on macOS and iOS — or WireGuard — with official apps on all three — are more consistent choices.

SSTP vs the alternatives

SSTP occupies a narrow position in the protocol landscape — not the fastest, not the most widely supported, and not the most audited. The comparison focuses on the dimensions where that distinction matters most.

	SSTP	IKEv2/IPsec	OpenVPN (TCP 443)	WireGuard
Firewall bypass via port 443	✅ Always	❌ Never — UDP 500/4500	✅ When configured in TCP mode	❌ Never — UDP only
Windows-native, no installer	✅ Yes	✅ Yes	❌ No	❌ No
Open-source / independently audited	❌ No — [MS-SSTP] proprietary	✅ IETF RFC 7296; implementations vary	✅ Yes	✅ Yes
Transport protocol	TCP only	UDP only	TCP or UDP	UDP only
TCP Meltdown exposure	Structural — realized under packet loss	None	Only in TCP mode	None
Cross-platform native support	Windows only	Windows, iOS, macOS, Android	All platforms (with app)	All platforms (with app)

Should you use SSTP? A verdict by user type

IT administrator on Windows Server infrastructure

Verdict: Viable for Windows-centric environments; IKEv2 remains Microsoft’s stated preference.

SSTP is a legitimate upgrade from L2TP/IPsec for Windows Server RRAS administrators who need a supported migration path before a future deprecation cycle forces a move. It is available in Windows Server 2025, requires no third-party client for Windows machines, and avoids the PSK and Diffie-Hellman group vulnerabilities that define L2TP/IPsec’s security risk profile.

Two operational items require planning. First, the CVE record: exposing an unpatched SSTP listener on TCP 443 to the internet is not acceptable given the history of unauthenticated RCEs in sstpsvc. Keeping Windows Server current is a hard requirement, not a best practice. Second, the SSTP server certificate requires a public CA-issued certificate renewed on a shorter cycle than many administrators expect: the CA/Browser Forum reduced the maximum TLS certificate validity to 200 days from 15 March 2026, falling further to 100 days in March 2027 and 47 days in March 2029. Certificate renewal is no longer an annual task — plan for roughly every six months on current timelines, and shorter still as the schedule advances.

For deployment topology: if SSTP terminates behind a load balancer, that appliance must pass through TCP 443 without SSL inspection. SSL offloading breaks SSTP because Crypto Binding depends on the TLS session being end-to-end between client and RRAS server. For diagnosing connection failures, a packet capture at the server confirms whether TCP 443 packets are arriving — a TCP SYN with no corresponding SYN-ACK from the server indicates the connection is not reaching the RRAS process. SSTP control messages travel inside TLS and cannot be inspected from a wire capture without decrypting the session.

Microsoft’s stated preference is IKEv2 as the primary migration target from L2TP/IPsec.

Windows user who needs to bypass a restrictive firewall

Verdict: The one scenario where SSTP’s native Windows position is the right choice.

A Windows user connecting from a hotel network, a corporate environment with strict UDP blocking, or a country that restricts non-HTTPS traffic — who cannot or prefers not to install third-party VPN software — has no other protocol that satisfies both constraints simultaneously. IKEv2 is also native to Windows but uses UDP 500/4500, blocked by many of the same restrictive networks. OpenVPN on TCP 443 achieves equivalent firewall bypass but requires an app installation. WireGuard is UDP-only with no port-443 fallback. SSTP is the only option in the intersection of Windows-native and TCP 443.

SSTP defeats port-based blocking reliably, but networks that perform active probing or TLS fingerprinting can identify and block it. In those environments, a purpose-built obfuscation protocol is required regardless of which base VPN protocol is used.

If installing a VPN client is an option, OpenVPN on TCP 443 through a provider with a verified no-log policy is the more auditable alternative and works consistently across all platforms. The choice between SSTP and OpenVPN TCP 443 in this scenario comes down to whether a software installation is practical.

Everyone else

Verdict: Use WireGuard or IKEv2 instead.

For everyday VPN use — privacy, performance, and general browsing — SSTP’s closed-source specification, Windows-centricity, and structural TCP Meltdown exposure make it the wrong default. WireGuard delivers better performance, a compact and auditable codebase, and cross-platform native support without any installer. IKEv2 is faster on mobile, handles network transitions through MOBIKE, and is natively supported across Windows, iOS, macOS, and Android. OpenVPN provides roughly 25 years of independent audit and works on every platform. SSTP’s advantages are situational. Without a specific port-443-only or no-installer requirement, there is no performance, privacy, or security reason to choose it over these alternatives.

Common SSTP errors and what they mean

Error / Symptom	Most likely cause	Fix
“The certificate received from the remote server does not pass the verification procedure”	The server’s TLS certificate is not trusted by the client: expired, self-signed, issued by a CA not in the Windows trust store, or the server address entered in the VPN connection does not match the certificate CN or SAN.	Confirm the server certificate is issued by a publicly trusted CA and is not expired. Verify that the server address in the VPN connection matches the certificate CN or SAN exactly — a mismatch of even one character causes this error. For internal PKI deployments, install the CA root certificate in the Windows trust store on each client before connecting.
Windows Error 809 — “The network connection between your computer and the VPN server could not be established because the remote server is not responding”	In the SSTP context, TCP port 443 is blocked between client and server, or the Windows Server host firewall is not allowing TCP 443 to reach the RRAS process. Unlike IKEv2 Error 809 (blocked UDP 500/4500), SSTP Error 809 points to a TCP 443 blockage — uncommon given how universally TCP 443 is allowed, but possible if the server’s host firewall is filtering the specific destination IP, or if a corporate proxy is stripping the SSTP_DUPLEX_POST request.	Confirm the Windows Server firewall rules allow inbound TCP 443 to the RRAS process. Run a packet capture at the server interface and look for TCP SYN packets on port 443 — their absence confirms the connection is blocked upstream before reaching RRAS. SSTP control messages travel inside TLS and cannot be inspected from the wire without decrypting the session. If the client is behind an SSL-inspecting corporate proxy, the proxy may be terminating the TLS session and breaking the end-to-end Crypto Binding requirement.
TLS handshake failure — connection drops immediately after TCP connects	TLS version or cipher suite mismatch between client and server. Most commonly seen when connecting to an older RRAS server that has not been updated, or when SSL 3.0 has been manually re-enabled on the server and the client refuses to negotiate below TLS 1.2.	Ensure the RRAS server is fully updated via Patch Tuesday. If SSL 3.0 was manually enabled on the server, disable it in Windows Server Schannel settings via registry or Group Policy. Confirm TLS 1.2 is enabled on the server side.
“Authentication failed” or credentials rejected after the tunnel connects	PPP authentication failure in Phase 4. The TLS tunnel established correctly but the username, password, or authentication method does not match the server’s RRAS configuration. This is distinct from a TLS certificate failure: the tunnel is up and the inner PPP session is failing independently.	Verify the username and password. Confirm the authentication method selected in the Windows VPN client (MS-CHAP v2, EAP-TLS, or PEAP) matches what the RRAS server is configured to accept. For EAP-TLS, verify the client certificate is valid and present in the Windows certificate store.
Tunnel connects but performance collapses on poor connections	TCP Meltdown. The tunnel is working, but lossy underlying conditions trigger independent retransmission loops in both the inner and outer TCP stacks, compounding latency and degrading throughput. Small pings and low-bandwidth traffic may appear fine while file transfers and video stall or time out.	TCP Meltdown is structural to SSTP and has no configuration fix. On unreliable links — mobile data, satellite, or high-latency paths — switch to IKEv2 or WireGuard if port-443 bypass is not a hard requirement for that connection.

Frequently asked questions

What is SSTP?

SSTP (Secure Socket Tunneling Protocol) is a VPN protocol developed by Microsoft that transports PPP traffic inside a TLS channel on TCP port 443. Because port 443 is the standard HTTPS port, SSTP traffic appears as ordinary web traffic to stateless firewalls and most proxy servers. It was first released with Windows Vista SP1 and Windows Server 2008 and has been native to every Windows version since.

What does SSTP stand for?

Secure Socket Tunneling Protocol. The “socket” refers to the TCP socket on port 443 over which the TLS channel operates. The name describes the mechanism: the protocol tunnels PPP traffic through that TLS-secured socket.

What port does SSTP use, and why does it matter?

SSTP uses TCP port 443, the HTTPS port. Blocking TCP 443 would disable all HTTPS browsing, so virtually every network allows it outbound — the one exception is authenticated web proxies that inspect HTTPS session content, which can identify and block SSTP specifically.

Is SSTP still supported by Microsoft in 2026?

Yes. Microsoft’s October 2024 announcement deprecated PPTP and L2TP/IPsec from Windows Server RRAS, naming SSTP and IKEv2 as the supported replacements. SSTP remains available natively in Windows Server 2025 and Windows 10 and 11 clients.

Can SSTP bypass deep packet inspection?

SSTP bypasses stateless firewalls reliably. Against deeper inspection the picture is mixed: passive DPI cannot read the SSTP-specific content (the custom verb and URI travel inside TLS), but commercial firewalls with SSL inspection enabled can identify SSTP after decrypting the session, and TLS fingerprinting provides probabilistic identification without decryption. SSTP is not a substitute for a purpose-built obfuscation protocol.

Is SSTP open source?

No. SSTP’s specification is [MS-SSTP], a Microsoft proprietary document published under the Open Specifications programme at learn.microsoft.com. There is no IETF RFC for SSTP. The Windows implementation is closed-source. Third-party clients such as sstp-client for Linux and Open SSTP Client for Android are open-source implementations of a closed specification.

What is Crypto Binding in SSTP?

Crypto Binding ties the server’s TLS certificate hash to the PPP authentication exchange, preventing a man-in-the-middle from relaying a legitimately authenticated PPP session into a different TLS context. It works by computing a keyed HMAC — the Compound MAC — over the SSTP Call Connected message with the server’s certificate hash included; any hash mismatch causes authentication to fail. The mechanism is absent from both PPTP and L2TP/IPsec.

How does SSTP differ from L2TP/IPsec?

The two protocols share the PPP inner session but differ in most other respects. L2TP/IPsec uses IKEv1 and IPsec ESP for security, was deprecated by Microsoft in October 2024, is commonly deployed with a pre-shared key vulnerable to offline dictionary attacks, and uses fixed UDP ports that restrictive firewalls block easily. SSTP uses TLS for security, is still supported, requires a server certificate by design, implements Crypto Binding, and uses TCP 443.

SSTP vs OpenVPN: which is better?

SSTP is built into Windows and requires no software installation; OpenVPN is cross-platform, open-source, and has a longer independent audit history — but requires a client app. Both can use TCP port 443 for firewall bypass. If installing a VPN client is an option, OpenVPN; if not, SSTP is the only native Windows protocol that reaches port 443.

Does SSTP work on macOS, iOS, or Android?

Not natively. On macOS, sstp-client is available via Homebrew and MacPorts. On iOS, SSTP Connect is a third-party App Store app supporting SSTP and SoftEther. On Android, Open SSTP Client is a free open-source app on Google Play.

What is the TCP Meltdown problem with SSTP?

TCP Meltdown occurs when TCP runs inside another TCP connection: both layers independently detect packet loss and retransmit, the cycles compound, and throughput collapses. Because SSTP’s only transport is TCP, it is structurally subject to this on every connection. On stable broadband the effect is negligible; on lossy links — mobile data, satellite, congested paths — performance degrades significantly compared to UDP-based protocols like WireGuard and IKEv2.

What TLS certificate does SSTP require, and how often does it need renewing?

The SSTP server must present a certificate issued by a publicly trusted Certificate Authority, with a CN or SAN that matches the server address clients use to connect. Self-signed certificates work but require manually installing the CA root in every client’s Windows trust store. The CA/Browser Forum reduced the maximum TLS certificate validity to 200 days from 15 March 2026 (down from the previous 398-day cap), with further reductions to 100 days in March 2027 and 47 days in March 2029. SSTP RRAS administrators should plan for renewal approximately every six months under the current cap, and build automation or reminders around the upcoming reductions. Allowing the certificate to expire breaks all SSTP client connections until renewal is complete.

Is SSTP the same as SSH tunneling?

No. SSH tunneling forwards specific TCP ports through an encrypted Secure Shell session — it is not a VPN protocol and does not route all IP traffic. SSTP is a full-tunnel VPN that routes every packet through an encrypted PPP session on TCP 443; the two are architecturally unrelated.

Does SSTP work without administrator rights on Windows?

Connecting to an existing SSTP VPN profile on Windows 10 and 11 does not require administrator rights. Creating the VPN profile in Settings → Network & Internet → VPN → Add a VPN connection is available to standard user accounts. The exception is certificate trust: if the SSTP server uses a private CA rather than a publicly trusted one, installing the CA root certificate into the Windows system trust store requires administrator privileges. On managed enterprise devices where IT has pre-provisioned both the VPN profile and the CA certificate via Group Policy or Intune, end users connect to SSTP without elevated rights.

How do I set up an SSTP VPN server on Windows Server?

The four core requirements are: install the Remote Access server role (DirectAccess and VPN role service) with RRAS enabled, bind a publicly trusted TLS certificate to the SSTP listener via the RRAS Management Console (server Properties → Security → SSL Certificate Binding) or PowerShell (Set-RemoteAccess -SslCertificate), open inbound TCP 443 in the Windows Server firewall, and configure the RRAS authentication policy to accept MS-CHAP v2, PEAP, or EAP-TLS. If SSTP terminates behind a load balancer, SSL inspection must be disabled on that appliance to preserve end-to-end Crypto Binding. The IT administrator verdict covers the key operational considerations, including certificate renewal cadence, load balancer topology, and a TCP-layer packet capture at the server for diagnosing connection failures.