I captured and decrypted an HTTPS request using fiddler. It looks about like this:
CONNECT qwer1234.com:443 HTTP/1.0
User-Agent: Blabla Example/1.0
Host: qwer1234.com:443
Content-Length: 0
Connection: Keep-Alive
Pragma: no-cache
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
Version: 3.3 (TLS/1.2)
Random: 13 35 55 0B F2 3C 9D A3 A2 C2 E4 3E 66 FA D3 DD E5 15 27 33 F1 E6 CD A5 E0 C4 10 4E 41 67 32 8E
SessionID: empty
Extensions:
renegotiation_info 00
server_name qwer1234.com
status_request 01 00 00 00 00
elliptic_curves secp256r1 [0x17], secp384r1 [0x18]
ec_point_formats uncompressed [0x0]
signature_algorithms 00 01 06 07 05 08 03 09 04 03 06 04 04 07 01 09
SessionTicket empty
Ciphers:
[003C] TLS_RSA_WITH_AES_128_CBC_SHA256
[002F] TLS_RSA_AES_128_SHA
[003D] TLS_RSA_WITH_AES_256_CBC_SHA256
[0035] TLS_RSA_AES_256_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[C027] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C02B] TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
[C023] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
[C02C] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
[C024] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
[C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[0040] TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[006A] TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
[0038] TLS_DHE_DSS_WITH_AES_256_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5
Compression:
[00] NO_COMPRESSION
Is this a special kind of HTTPS request? Why is only half of the request excrypted? What do the random generated numbers mean / what are they for? How would I send this request using a WinHttpRequest? How does it differ from other HTTPS requests?
I'm kind of bad in finding the right places to ask questions like this. Tell me if you think that I should have asked this on a different page and if so, where.
This isn't a HTTPS request at all, it is a CONNECT
tunnel through which HTTPS traffic subsequently flows. Client applications first send a CONNECT
request to the proxy (like Fiddler) to tell them where to establish a TCP/IP connection to, then after the connection establishes, a HTTPS handshake is performed and the requests are sent.
When showing you the CONNECT tunnel, Fiddler analyzes the parameters and displays them for you to read. The actual HTTPS requests will appear after this tunnel in the Web Sessions list, if and only if you have enabled HTTPS decryption in the Tools > Fiddler Options > HTTPS screen.