Chromecast issues

[fniephaus]

I have tried to find out why Chromecast does not work with your sniproxy. I don't understand why, but it looks like the proxy sends "Change Cipher Spec" packets after the "Server Key Exchange" which results in Chromecast sending a new (SSL 3.0) "Client Hello".

Successful connection:

Unsuccessful connection via sniproxy:

Any idea how to deal with this?

[dlundquist]

sniproxy doesn't send a Cipher change spec message, the only TLS message it originates is a TLS alert https://github.com/dlundquist/sniproxy/blob/master/src/tls.c#L49-L54. This appears to be TLS negotiation problem between the upstream server and the chromecast client.

[fniephaus]

#66 seems to address this issue.

[nmav]

I don't believe that #66 addresses that issue. The screen captures do not provide much information on the issue though.

[fniephaus]

You're probably right, I need to investigate this a little further.
I could provide the captured packets if you want to help ;)

[nmav]

On Tue, Feb 18, 2014 at 3:38 PM, Fabio Niephaus notifications@github.comwrote:

You're probably right, I need to investigate this a little further.
I could provide the captured packets if you want to help ;)

You can attach or send them to me. I'm curious on the issue.

regards,
Nikos

[fniephaus]

Here you go:
[link removed]

I've changed the Chromecast's IP address to 10.1.1.20, and my sniproxy's IP to 123.123.123.123. There are two pcap files within the archive. One shows a successful connection via unlocator, the other one the unsuccessful connection via my sniproxy.

Let me know if you need more info.

[nmav]

On 02/18/2014 10:06 PM, Fabio Niephaus wrote:

Here you go:
https://dl.dropboxusercontent.com/u/3720321/sniproxy_pcaps.zip

I've changed the Chromecast's IP address to 10.1.1.20, and my sniproxy's
IP to 123.123.123.123. There are two pcap files within the archive. One
shows a successful connection via unlocator, the other one the
unsuccessful connection via my sniproxy.

Where are these captures taken? Are they on the server or the client
side? Could you have a capture of the failed session on both sides
(server and client)? It seems that there are some packets lost or dropped?

Also if I understand well, the successful is without sniproxy, and the
unsuccessful is with sniproxy?

regards,
Nikos

[fniephaus]

Hey Nikos,
I intercepted the connection between client and server, but I was using an arp spoofing attack which might be the reason for lost packets. Let me do this again next week with a wifi hotspot...sorry about that.
And yes, the successful is without sniproxy, the unsuccessful is with sniproxy.

[dlundquist]

@fniephaus Would you give the bad-request-logging branch a shot, it will log the client hello message in a format I can add to the the TLS unit tests. See #74.

[fniephaus]

I sure will after work!

[fniephaus]

here you go:

parse_packet({0x16, 0x03, 0x00, 0x00, 0x7f, 0x01, 0x00, 0x00, 0x7b, 0x03, 0x00, 0x53, 0x11, 0x18, 0xffffffc9, 0x50, 0xffffffd7, 0xfffffffd, 0xffffffa3, 0x60, 0xffffff89, 0xffffffdc, 0xffffffc0, 0x48, 0xffffffcf, 0xffffff96, 0x44, 0x1c, 0xffffffa8, 0xffffffce, 0x5e, 0xffffffb9, 0x10, 0x5d, 0xffffffe0, 0x66, 0x77, 0xffffff9e, 0x27, 0xffffffcf, 0xffffffe7, 0xffffffbe, 0xffffffd8, 0x00, 0x00, 0x54, 0xffffffc0, 0x14, 0xffffffc0, 0x0a, 0xffffffc0, 0x22, 0xffffffc0, 0x21, 0x00, 0x39, 0x00, 0x38, 0xffffffc0, 0x0f, 0xffffffc0, 0x05, 0x00, 0x35, 0xffffffc0, 0x12, 0xffffffc0, 0x08, 0xffffffc0, 0x1c, 0xffffffc0, 0x1b, 0x00, 0x16, 0x00, 0x13, 0xffffffc0, 0x0d, 0xffffffc0, 0x03, 0x00, 0x0a, 0xffffffc0, 0x13, 0xffffffc0, 0x09, 0xffffffc0, 0x1f, 0xffffffc0, 0x1e, 0x00, 0x33, 0x00, 0x32, 0xffffffc0, 0x0e, 0xffffffc0, 0x04, 0x00, 0x2f, 0xffffffc0, 0x11, 0xffffffc0, 0x07, 0xffffffc0, 0x0c, 0xffffffc0, 0x02, 0x00, 0x05, 0x00, 0x04, 0x00, 0x15, 0x00, 0x12, 0x00, 0x09, 0x00, 0x14, 0x00, 0x11, 0x00, 0x08, 0x00, 0x06, 0x00, 0x03, 0x00, 0xffffffff, 0x01, 0x00}, 132, ...) = 859011120

hope this helps!

[dlundquist]

@fniephaus Thanks, that helps in two ways:

1. It looks like your Chromecast device is using SSL 3.0 rather than TLS, so it is not including the SNI extension.
2. Reveals an issue with the bad request logging code that is probably causing the seg fault in SSL handshake failed #74.

I'm going to fixup the bad-request-logging branch right now, if you want to give it another try.

[fniephaus]

No worries! I'm happy to help!
Yes, the second Client Hello uses SSL 3.0 without the SNI extension, the first one uses TLS with SNI. And the first handshake seems to fail for some reason. I really would like to know why this is happening...