Re: HTTPS Connect fails to decrypt

[EricLaw]

Please either email me the SAZ file, or copy/paste the text of the Session's Properties window (right-click it in the Web Sessions list).

 

This list will contain details of why this traffic was not decrypted.

 

On Wednesday, August 22, 2012 12:55:24 PM UTC-7, Richard wrote:

I am working with Fiddler 2 and have HTTPS decryption enabled for all applications and no exclusions. An application opens a connection to talk.google.com on port 5222 (xmpp). This connection is encrypted with SSLv3. Fiddler reports the connection with the following message:
This is a CONNECT tunnel, through which encrypted HTTPS traffic flows.
Fiddler's HTTPS Decryption feature is enabled, but this specific tunnel was configured not to be decrypted. Settings can be found inside Tools > Fiddler Options > HTTPS.

A SSLv3-compatible ServerHello handshake was found. Fiddler extracted the parameters below.

After this, the traffic on the connect tunnel is not decrypted. I have not been able to determine why this happens and the tunnel is not decrypted.

[Richard]

SESSION STATE: Done.
Request Entity Size: 221 bytes.
Response Entity Size: 696 bytes.

== FLAGS ==================
BitFlags: [ResponseGeneratedByFiddler, IsBlindTunnel, ProtocolViolationInRequest] 0x9100
X-PROCESSINFO: cloudprintservice:2196
X-HTTPPROTOCOL-VIOLATION: [ProtocolViolation] The Request's Host header did not match the URL's host component.

URL Host:    talk.google.com:5222
Header Host:    talk.google.com
X-CLIENTPORT: 60949
X-EGRESSPORT: 60950
HTTPS-SERVER-SESSIONID: 50 35 5A B6 8F 88 E5 26 53 7E 59 F6 5B 40 F0 33 33 81 79 09 AA D9 65 8E DA 3A DB 79 B3 FE 6B 23
X-RESPONSEBODYTRANSFERLENGTH: 0
HTTPS-CLIENT-SESSIONID:
X-CLIENTIP: 127.0.0.1
UI-BACKCOLOR: LightYellow
X-ORIGINAL-HOST: talk.google.com
X-HOSTIP: 173.194.79.125
X-NO-DECRYPT: SniffingSuggestedNotHTTPS

== TIMING INFO ============
ClientConnected:    15:18:12.252
ClientBeginRequest:    15:18:12.267
GotRequestHeaders:    15:18:12.267
ClientDoneRequest:    15:18:12.267
Determine Gateway:    0ms
DNS Lookup:         156ms
TCP/IP Connect:    1ms
HTTPS Handshake:    0ms
ServerConnected:    15:18:12.423
FiddlerBeginRequest:    15:18:12.423
ServerGotRequest:    15:18:12.423
ServerBeginResponse:    00:00:00.000
GotResponseHeaders:    00:00:00.000
ServerDoneResponse:    00:00:00.000
ClientBeginResponse:    15:18:12.439
ClientDoneResponse:    15:18:12.486

    Overall Elapsed:    00:00:00.2184056

The response was buffered before delivery to the client.

== WININET CACHE INFO ============
This URL is not present in the WinINET cache. [Code: 2]
* Note: Data above shows WinINET's current cache state, not the state at the time of the request.
* Note: Data above shows WinINET's Medium Integrity (non-Protected Mode) cache only.

[EricLaw]

Additionally, it's worth keeping in mind that Fiddler is a HTTP/HTTPS proxy.

 

It doesn't sound like XMPP is a HTTP(S)-based protocol. If the client in question is merely using a HTTP CONNECT tunnel in an attempt to establish a proxied bytestream but it's not actually using HTTPS through that tunnel, you'll see that the Properties contain a flag x-no-decrypt with value SniffingSuggestedNotHTTPS. That means that Fiddler detected that the CONNECT isn't being used for HTTPS and thus it tagged it as such.

 

On Wednesday, August 22, 2012 3:14:06 PM UTC-7, EricLaw wrote:

[Richard]

Eric,
I'm not sure I understand. The XMPP connection is secured by SSL/TLS and the XMPP protocol flows over that secured connection. It is my understanding that HTTPS is just a name for HTTP flowing over an SSL/TLS secured connection. XMPP over the secure connection should not be any different than HTTP over the secured connection.

It appears that fiddler is sniffing the unencrypted data looking for HTTP content and deciding not to decrypt because it does not find HTTP? If so, why do you restrict the decryption to HTTP content?

btw, thanks for the quick response.

[EricLaw]

Yes, HTTPS is HTTP flowing over a SSL/TLS connection. XMPP, even when you send it over SSL/TLS) isn't HTTP traffic, and thus is out of scope for Fiddler.

 

>XMPP over the secure connection should not be any different than HTTP over the secured connection.

Of course it's different-- it's a completely different protocol!

 

Since it has no way to interpret XMPP traffic (where are the message boundaries? What do the message elements mean?), Fiddler can't display XMPP traffic in any meaningful way, which is why it doesn't. It simply streams the bytes back and forth, to ensure that the traffic being proxied isn't blocked.

 

I think you're now saying: "Hey, I'm looking for a packet sniffer like NetMon or Wireshark to look at this non-HTTP traffic." If that's the case, I'd point you at Netmon and Wireshark.

 

cheers,

Eric