How VPN is arranged through SSTP
I found just a few references to SSTP on Habré, and therefore I want to tell you about the device of this protocol. The Secure Socket Tunneling Protocol (SSTP) is Microsoft's VPN protocol, based on SSL and included in their operating systems since Windows 2008 and Windows Vista SP1. The connection is made using HTTPS on port 443. SSL is used for encryption, SSL and PPP are used for authentication. More about the device - under the cut.
The server part of the protocol is included in Windows Server 2008, 2008 R2, 2012, 2012 R2. The following describes the current (and, it seems, the only) version - 1.0.
It is mainly used to connect node-node or network-node. The default connection is port 443, but it can be configured on other ports.
Conventionally, the protocol stack when transferring data looks like this (only VPN-related headers are shown, without the underlying levels):
The structure of the SSTP package itself:
Flag C = 0 if the packet is with data, and C = 1 if the packet is control.
SSTP is pretty simple due to the fact that it uses the functionality of other cryptographic protocols. Actually, the only cryptographic function implemented by SSTP itself is the “cryptographic binding”, which is described below.
All data encryption is carried out by the SSL protocol. All packets of SSTP, PPP and higher protocols are transmitted only in encrypted form.
Authorization takes place immediately by three protocols: SSL, PPP and, in fact, SSTP itself.
When an SSL connection is established, the server is authorized by the client using an SSL certificate. Client authentication by the server is allowed, but not supported by any of the server Windows.
At the PPP level, the client is authorized by the server, and server authentication can additionally occur. Windows Server supports client authentication at the PPP level using MS-CHAPv2, EAP-TLS, PEAP-MSCHAPv2, PEAP-TLS. Password Authentication Protocol (PAP is not an encrypted password) and CHAP are also supported, but their use is not recommended, since they do not provide for the exchange of key information that is necessary for cryptographic binding. Actually, there are the same authentication methods as in PPTP. The difference from PPTP is that the exchange takes place within an already created encrypted SSL channel.
Now what is this "cryptographic binding". Due to the fact that client and server authentication occurs at different levels, it is possible to attack a person in the middle when an intruder establishes an SSL connection with the server and an unprotected PPP connection with the client.
1. The client establishes a TCP connection to the 443rd port of the SSTP server.
2. The SSL / TLS connection is established over the TCP connection. The client verifies the server certificate.
3. HTTPS greeting passes.
4. The establishment of the SSTP connection begins. All SSTP packets go inside HTTPS. The client sends a request to establish a connection (Call Connect Request message). This message passes the protocol number that will be used inside SSTP; in the current version of the standard it is always PPP.
5. The server checks the request and, if everything is OK, responds to it with a confirmation (Call Connect Acknowledge message), in which it reports a 32-bit random number (ClientNonce) used in the next client response to protect against repetition, as well as a hash list functions for signing the next response (SHA1 and / or SHA256).
6. PPP authorization occurs. All PPP packets are embedded in SSTP packets and, accordingly, are SSL encrypted.
7. The client sends a Call Connected message, which includes the ClientNonce and the Server Certificate Hash (ClientCertificateHash) received during the SSL connection.
This message is signed using the hash function specified by the server (more precisely, the HMAC based on it) and the key obtained in the PPP authorization process. This is done by cryptographic binding. If PPP is used to authorize a protocol that does not support key generation for MPPE (PAP or CHAP), then the HMAC is calculated using a key equal to zero; that is, in fact, cryptographic binding is not performed and the man-in-the-middle attack described above is possible.
8. The server checks the Call Connected message, on this SSTP is considered installed.
9. Ending PPP settings.
Everything, connection is established. Then the parties exchange packets with the data.
')
To distinguish a simple channel from a disconnection, the parties “ping” each other. If there was no packet exchange within 60 seconds, an Echo Request (SSTP control packet) is sent. If there is no response within the next 60 seconds, the connection is lost.
The connection is completed without any special nuances, the parties exchange SSTP messages about the end of the connection and after a few seconds break the connection.
Detailed description of the protocol.
Very short description of the protocol.
The server part of the protocol is included in Windows Server 2008, 2008 R2, 2012, 2012 R2. The following describes the current (and, it seems, the only) version - 1.0.
It is mainly used to connect node-node or network-node. The default connection is port 443, but it can be configured on other ports.
Conditional data packet schema
Conventionally, the protocol stack when transferring data looks like this (only VPN-related headers are shown, without the underlying levels):
The structure of the SSTP package itself:
Flag C = 0 if the packet is with data, and C = 1 if the packet is control.
Few words about cryptography used
SSTP is pretty simple due to the fact that it uses the functionality of other cryptographic protocols. Actually, the only cryptographic function implemented by SSTP itself is the “cryptographic binding”, which is described below.
All data encryption is carried out by the SSL protocol. All packets of SSTP, PPP and higher protocols are transmitted only in encrypted form.
Authorization takes place immediately by three protocols: SSL, PPP and, in fact, SSTP itself.
When an SSL connection is established, the server is authorized by the client using an SSL certificate. Client authentication by the server is allowed, but not supported by any of the server Windows.
At the PPP level, the client is authorized by the server, and server authentication can additionally occur. Windows Server supports client authentication at the PPP level using MS-CHAPv2, EAP-TLS, PEAP-MSCHAPv2, PEAP-TLS. Password Authentication Protocol (PAP is not an encrypted password) and CHAP are also supported, but their use is not recommended, since they do not provide for the exchange of key information that is necessary for cryptographic binding. Actually, there are the same authentication methods as in PPTP. The difference from PPTP is that the exchange takes place within an already created encrypted SSL channel.
Now what is this "cryptographic binding". Due to the fact that client and server authentication occurs at different levels, it is possible to attack a person in the middle when an intruder establishes an SSL connection with the server and an unprotected PPP connection with the client.
more
To protect against this, signing an SSTP connection establishment message (Call Connected message, see below) with a key generated in the PPP authentication process is used. Thus, the server can verify that the one who established the SSL connection and the one who passed the PPP authentication is the same client. Actually, this is called “cryptographic binding”.Those. the abuser first establishes an HTTPS connection to the server. Then, the legitimate client is asked to authenticate with PPP, introducing himself as some PPP (but not SSTP) server, and then sends to the PPP client authorization requests that it receives from the SSTP server within the HTTPS connection, and the server receives the responses received from the legitimate user.
more
In the PPP authorization process, a shared secret is generated between the legitimate client and the server, which cannot be obtained by listening on the PPP connection. Those. the intruder cannot know this secret. The offender also cannot force the client to sign the SSTP message, since the client thinks it has installed an unprotected PPP connection and knows nothing about the SSTP connection.
Connection establishment procedure
1. The client establishes a TCP connection to the 443rd port of the SSTP server.
2. The SSL / TLS connection is established over the TCP connection. The client verifies the server certificate.
3. HTTPS greeting passes.
4. The establishment of the SSTP connection begins. All SSTP packets go inside HTTPS. The client sends a request to establish a connection (Call Connect Request message). This message passes the protocol number that will be used inside SSTP; in the current version of the standard it is always PPP.
5. The server checks the request and, if everything is OK, responds to it with a confirmation (Call Connect Acknowledge message), in which it reports a 32-bit random number (ClientNonce) used in the next client response to protect against repetition, as well as a hash list functions for signing the next response (SHA1 and / or SHA256).
6. PPP authorization occurs. All PPP packets are embedded in SSTP packets and, accordingly, are SSL encrypted.
7. The client sends a Call Connected message, which includes the ClientNonce and the Server Certificate Hash (ClientCertificateHash) received during the SSL connection.
This message is signed using the hash function specified by the server (more precisely, the HMAC based on it) and the key obtained in the PPP authorization process. This is done by cryptographic binding. If PPP is used to authorize a protocol that does not support key generation for MPPE (PAP or CHAP), then the HMAC is calculated using a key equal to zero; that is, in fact, cryptographic binding is not performed and the man-in-the-middle attack described above is possible.
8. The server checks the Call Connected message, on this SSTP is considered installed.
9. Ending PPP settings.
Everything, connection is established. Then the parties exchange packets with the data.
')
Disconnection
To distinguish a simple channel from a disconnection, the parties “ping” each other. If there was no packet exchange within 60 seconds, an Echo Request (SSTP control packet) is sent. If there is no response within the next 60 seconds, the connection is lost.
End connection
The connection is completed without any special nuances, the parties exchange SSTP messages about the end of the connection and after a few seconds break the connection.
Detailed description of the protocol.
Very short description of the protocol.
Source: https://habr.com/ru/post/196134/
All Articles