Let’s have some fun and decrypt some SSTP traffic, something quick this time, more details in a future post.
The SSTP VPN server is Forefront TMG 2010 RC running on Windows Server 2008 R2 SE(RRAS provides the VPN functionality, TMG provides the firewalling).
The SSTP VPN client is the one from Windows 7 x64 Ultimate.
Using Wireshark as described here, we can capture the traffic of the client side:
The downside is that Wireshark currently does not have a SSTP dissector, so we will manually “split” the hex stream and identify some packets.
Note that although above we’ve specified ‘http’ on Wireshark, bellow it will not be always HTTP in the decrypted packets.
Let’s proceed, the cipher suite used is TLS_RSA_WITH_AES_128_CBC_SHA (0x002f), the server’s IP address is 192.168.22.234 and the client's IP address is 192.168.22.11:
Initialization phase, right after the TLS successful negotiations(the client and server agreed on the cipher suite to be used, the client has successfully authenticated the server verifying its certificate), the client sends to the server a HTTP request using the HTTP method SSTP_DUPLEX_POST and HTTP 1.1, note that the URI (/sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/) is well known to the server and client. Also note that client uses the Content-Length 18446744073709551615(ULONGLONG_MAX).
SSTP_DUPLEX_POST /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ HTTP/1.1
SSTPCORRELATIONID: {AD8088D2-ABDE-4CCB-8397-F4C2D9964F43}
Content-Length: 18446744073709551615
Host: sstp.carbonwind.net
The SSTP VPN server, upon receiving this request, validates the method(SSTP_DUPLEX_POST) and the HTTP version(1.1).
All is fine bellow, the server can accept the new connection, thus the server sends back an HTTP STATUS OK message to the client.
HTTP/1.1 200
Content-Length: 18446744073709551615
Server: Microsoft-HTTPAPI/2.0
Date: Tue, 10 Nov 2009 10:38:36 GMT
The Call Connected message, a step often overlooked from SSTP presentations, the SSTP client completes the crypto binding by sending this message(also it indicates to the server that it is ready to send data traffic). The server validates the Crypto Binding attribute in the Call Connected message received from the SSTP client. Only after this validation data traffic should be allow to flow. This crypto binding is used to avoid certain MITM attacks, ensuring that the SSTP client and the SSTP server that participated in the inner authentication(PPP) are the same that participated in the outer (or SSL/TLS) authentication phase(I’m not sure this is the most fortunate expression, I hope you’ve catch the drift :) ).
The crypto binding is achieved by tying the inner (PPP) authentication, using the inner (PPP) authentication phase keys, to the outer (or SSL/TLS) authentication phase, the client has to send a value(Compound MAC, computed using the keying material that is generated during PPP authentication), proving to the SSTP server that the PPP authentication was used for SSTP communications.
The Call Connected message contains the same nonce value that the server sent in a previous message(Call Connect Acknowledge), not pictured bellow. And also contains the server's certificate hash, using either SHA-1 or SHA256.
Note that although bellow Wireshark says something about HTTP, actually there isn’t any HTTP there, only a SSTP packet:
-------------------
Ethernet
-------------------
IP
-------------------
TCP
-------------------
SSL
-------------------
SSTP
-------------------
SSTP Version (1 byte): 0x10 (Major Version: 0x1, Minor Version: 0x0)
Reserved (7 bits): 0
C (1 bit): 1 (Control Packet)
LengthPacket (2 bytes):
-R (4 bits): 0x0
-Length (12 bits): 0x070
Message Type (2 bytes): 0x0004 (SSTP_MSG_CALL_CONNECTED)
Num Attributes (2 bytes): 0x0001
Reserved1 (1 byte): 0x00
Attribute ID (1 byte): 0x03 (SSTP_ATTRIB_CRYPTO_BINDING)
-LengthPacket1 (2 bytes):
--R1 (4 bits): 0x0
--Length1 (12 bits): 0x068
-Reserved2 (3 bytes): 0x000000
-Value:
---Hash Protocol Bitmask: 0x02 (CERT_HASH_PROTOCOL_SHA256)
---Nonce(32 bytes):
53 df a2 01 8f bd 20 6c d8 16 02 00 e8 ea c9 0c
eb 10 ae 81 07 6e c2 29 32 ba fa 32 6a 7e a0 18
---Certificate Hash(32 bytes):
e6 a6 79 6e 7f 68 6d 87 ac 04 15 d1 e3 f8 12 9d
22 c2 2a 8c 06 c3 f5 20 e8 96 28 ff 3c 18 50 d8
---Compound MAC(32 bytes):
63 2e d7 db 3a a2 ad 86 3c 64 d8 a9 fb d9 4d b8
a2 61 16 6e 94 92 cf 6c 30 94 cf 5b cd e3 ad 88
A data packet(ICMP Echo Request message from the SSTP VPN client destined to a server behind the SSTP VPN server, the client has been assigned an on-subnet IP address, 192.168.10.155).
Again note that although bellow Wireshark says something about HTTP, actually there isn’t any HTTP there, and that I’ve “stripped” some info from this packet(to be more exactly IP/ICMP details from the ICMP Echo Request send by the client), showing only relevant parts:
-------------------
Ethernet
-------------------
IP
-------------------
TCP
-------------------
SSL
-------------------
SSTP
-------------------
PPP
-------------------
Client’s Packet
-------------------
SSTP Version (1 byte): 0x10 (Major Version: 0x1, Minor Version: 0x0)
Reserved (7 bits): 0
C (1 bit): 0 (Data Packet)
LengthPacket (2 bytes):
-R (4 bits): 0x0
-Length (12 bits): 65 bytes (0x041)
Data:
-Point-to-Point Protocol
--Protocol: IP (0x21)
-Internet Protocol
--Version: 4 (0x4)
--Header Length: 20 bytes (0x5)
--Src: 192.168.10.155 (0xc0a80a9b)
--Dst: 192.168.10.2 (0xc0a80a02)
-Internet Control Message Protocol
--Type: 8 (Echo (ping) request) 0x08
--Code: 0 (0x00)
--Data (32 bytes):
61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70
71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69
References: