0

My Android app uses TLS to talk to a remote server. For some reason the TLS handshake succeeds when I run my app in Genymotion virtual machine but fails when I run it in a physical phone device.

Looking at the traffic with Wireshark I see the following exchange (server messages are indented):

TLSv1 Client Hello
TLSv1   Server Hello
TLSv1   Certificate
TLSv1 Certificate
TLSv1 Client Key Exchange

sslv3 Client Hello
sslv3   SSLv3 Record Layer: Alert (Level: Fatal, Description: Handshake Failure) (40)

Based on my reading error 40 is this may be because of lack of agreement on a common Cipher Suite:

http://support.citrix.com/article/CTX124731

Upon investigation it seems that server only supports a single Cipher Suite:

Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)

It appears that the TLS_RSA_WITH_AES_128_CBC_SHA is not supported in SSLv3.

What seems odd is why does the handshake start over using SSLV3 protocol with a second Client Hello?

In the successful scenario involving Genymotion Virtual Device the message exchange was as follows:

TLSv1 Client Hello
TLSv1   Server Hello
TLSv1   Certificate
TLSv1 Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message
TLSv1 [TCP Retransmission] Certificate
TLSv1 [TCP Retransmission] Client Key Exchange
TLSv1 New Session Ticket, Change Cipher Spec, Encrypted Handshake Message

****Update*****

I changed app code to force TLSv1 handshake without any fallback to SSLv3 using the following code snippet:

    SocketFactory sf = SSLSocketFactory.getDefault();
    SSLSocket socket = (SSLSocket) sf.createSocket(host, 443);
    socket.setEnabledProtocols(new String[]{"TLSv1", "TLSv1.1", "TLSv1.2"});
    socket.startHandshake();

This showed the following in wireshark:

TLSv1 Client Hello
TLSv1   Server Hello
TLSv1   Certificate
TLSv1 Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
TLSv1   Alert (Level: Fatal, Description: Handshake Failure)

The Alert message details look like this:

+Secure Sockets Layer
  +TLSv1 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
    +Content Type: Alert (21)
    ...
    +Alert Message
      Level: Fatal(2)
      Description: Handshake Failure (40)

I am unable to attach wireshark pcap files due to privacy constraints. Thanks for any help.

Farrukh Najmi
  • 5,055
  • 3
  • 35
  • 54
  • but you already tried to check the date on your physical device is correct? – Ludger Nov 24 '14 at 14:42
  • Both devices are getting time from the network. Just curious what made you think time may be an issue? – Farrukh Najmi Nov 24 '14 at 15:34
  • for example if the date is wrong the server can not do the handshake to spend the period of validity of the certificate. – Ludger Nov 24 '14 at 15:38
  • Thanks Ludger! Both devices have Automatic Date and Time and Automatic Time ZOne. There are two odd things about this: 1. Why does it work on Genymotion on not on physical phone when Android version is same on both (4.4.4) 2. Why does it switch from TLSv1 to sslv3 in the problem case on physical phone What techniques do people use to debug this sort of problem? – Farrukh Najmi Nov 24 '14 at 15:53
  • I do not know but I've developed an application in android and working as a server and communicated with another program developed in C and used an SSL connection and also uses a self-certificate. If you want I can show you an example that may be useful. – Ludger Nov 24 '14 at 16:07
  • Could you describe the network setup? Might there be some kind of (broken) load balancer or SSL accelerator involved which is between the hardware android and the server but not between your emulated android? This could explain the downgrade to SSLv3. – Steffen Ullrich Nov 24 '14 at 17:23
  • @Steffen I think you have something there. The virtual device and phone were on different networks. Swapping the networks caused swapping of failures. Whats even more vexing is that 3 different phones with the same app using data network result in success with one carrier and failure with data networks of 2 other carriers? Does this smell like anything you have seen? – Farrukh Najmi Nov 24 '14 at 21:41
  • @Steffen So it works on AT&T 4G but not on Verizon, T-Mobile data networks. It does not work from my home network provided by Verizon. So it does not work in more networks than the networks it does work in. The server shows only one Cipher Suite supported: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f). The client and server are from different companies. Any suggestions how to determine which side the problem is at and what is causing it? – Farrukh Najmi Nov 25 '14 at 12:28
  • Since it works essentially between client and server and only does not work inside some networks, the problem is probably some "traffic optimization" deep inspection technology within the network. Do you use the default for for https 443 or do you use another port for communication? Also, TLS_RSA_WITH_AES_128_CBC_SHA is a SSLv3 cipher so this is not the reason the SSLv3 handshake fails. But it might be that the server has blocked SSLv3 because of POODLE or uses SNI which is not available with SSLv3. – Steffen Ullrich Nov 25 '14 at 12:39
  • To make matter more weird (and possibly point finger at the apclient being the problem), on the device with the problem scenario where handshake is failing, I can access the server's web page with HTTPS just fine after I add the client's key to chrome browser. I forgot to mention that the communication requires client's private key to sign requests. Does this shed any more light? – Farrukh Najmi Nov 25 '14 at 15:24
  • @Steffen Yes client uses default server port of 443 for communication. Yes server has blocked SSLv3 for Poodle. So if server has SSLv3 disabled and if it only supports TLS_RSA_WITH_AES_128_CBC_SHA which you said is an SSLv3 only Cipher suite then would this explain the problem? If so, why does it workj on some networks? – Farrukh Najmi Nov 25 '14 at 17:47
  • TLS_RSA_WITH_AES_128_CBC_SHA is not SSLv3 only, but it is available starting with SSLv3. It's also available with TLS1.0, 1.1, 1.2. Again, I think the problem are some deep packet inspection devices but is hard to say without packet dump why they might give problems. – Steffen Ullrich Nov 25 '14 at 20:18
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/65648/discussion-between-farrukh-najmi-and-steffen-ullrich). – Farrukh Najmi Nov 25 '14 at 20:43

0 Answers0