I have a very weird issue with my phone (Alcatel 997D running Android 4.0.4). Let me start at the beginning. I provide certain services (mostly syncing stuff, Firefox and Cal/CardDAV) on a server with self signed SSL keys that is in my home network. To provide connectivity, I poked a small hole in my router's firewall and have a domain registered which is set to my WAN IP address regularly.
All worked fine some time ago (6 months, I think). But now my phone can't connect to my server when it uses the 3G connection (with all the sync apps, Firefox, Cal/CardDAV sync apps, Firefox with my WAN IP as address), but all works fine when I connect through the local WLAN.
Basically, the only things I changed are the SSL keys on my server, and maybe I installed some small Android updates on the phone. To rule out that it is a problem with the 3G network, I poked another hole in my router's firewall and sent the traffic to one of my other computers (displaying a small web page over http). To my astonishment, the phone could connect to the page over 3G.
This is very unsettling. To rule out that the phone is the problem, I still need to check 3G connectivity on another machine, and try to connect to my server over a foreign WLAN. But just in case: How can I get more information on the Android side? All apps provide more or less meaningless output.
While googleing, I found out that there are more options available for debugging, like installing curl. I'll do this, but ask this question anyway in hope that somebody has seen something similar, or can point me to a trivial error on my side.
There are errors in the system log which indicate SSL handshake problems over the 3G connection. Here are some log entries:
[ 08-24 12:30:02.508 19763:0x4d6c E/NativeCrypto ]
Unknown error during handshake
[ 08-24 12:30:08.274 19763:0x4d6c E/NativeCrypto ]
Unknown error during handshake
[ 08-24 12:30:08.275 19763:0x4d6c W/System.err ]
javax.net.ssl.SSLHandshakeException: javax.net.ssl.SSLProtocolException: SSL handshake aborted: ssl=0x18e8508: Failure in SSL library, usually a protocol error
[ 08-24 12:30:08.275 19763:0x4d6c W/System.err ]
error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol (external/openssl/ssl/s23_clnt.c:683 0x4027f522:0x00000000)
[ 08-24 12:30:08.276 19763:0x4d6c W/System.err ]
at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:460)
[ 08-24 12:30:08.276 19763:0x4d6c W/System.err ]
at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:257)
[ 08-24 12:30:08.276 19763:0x4d6c W/System.err ]
at libcore.net.http.HttpConnection.setupSecureSocket(HttpConnection.java:210)
[ 08-24 12:30:08.276 19763:0x4d6c W/System.err ]
at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.makeSslConnection(HttpsURLConnectionImpl.java:486)
[ 08-24 12:30:08.276 19763:0x4d6c W/System.err ]
at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.connect(HttpsURLConnectionImpl.java:450)
[ 08-24 12:30:08.276 19763:0x4d6c W/System.err ]
at libcore.net.http.HttpEngine.sendSocketRequest(HttpEngine.java:282)
[ 08-24 12:30:08.276 19763:0x4d6c W/System.err ]
at libcore.net.http.HttpEngine.sendRequest(HttpEngine.java:232)
[ 08-24 12:30:08.276 19763:0x4d6c W/System.err ]
at libcore.net.http.HttpURLConnectionImpl.connect(HttpURLConnectionImpl.java:80)
[ 08-24 12:30:08.276 19763:0x4d6c W/System.err ]
at libcore.net.http.HttpURLConnectionImpl.getOutputStream(HttpURLConnectionImpl.java:194)
[ 08-24 12:30:08.276 19763:0x4d6c W/System.err ]
at libcore.net.http.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java:280)
[…]
Caused by: javax.net.ssl.SSLProtocolException: SSL handshake aborted: ssl=0x18e8508: Failure in SSL library, usually a protocol error
[ 08-24 12:30:08.277 19763:0x4d6c W/System.err ]
error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol (external/openssl/ssl/s23_clnt.c:683 0x4027f522:0x00000000)
[ 08-24 12:30:08.278 19763:0x4d6c W/System.err ]
at org.apache.harmony.xnet.provider.jsse.NativeCrypto.SSL_do_handshake(Native Method)
[ 08-24 12:30:08.278 19763:0x4d6c W/System.err ]
at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:410)
[ 08-24 12:30:08.278 19763:0x4d6c W/System.err ]
Connection to other SSL pages, e.g. Mozilla Add-Ons, works with 3G. So I guess that there is something about my SSL keys that the telco or Android do not like. I'll run some tests with other devices and keys.
I tested the 3G network of my provider with a mobile USB modem attached to my Mac, and all just worked, calendar, address book etc (I deactivated Ethernet and WLAN on the Mac, and the application provided by the telco showed 1 MB throughput, and all was a bit sluggish). I think that proves that Android has something to do with this mess.
OK, something that just came to me: I had one app used for calendar syncing that couldn't sync over WLAN after the SSL certificate switch anymore. It threw an exception that complained about an unsupported or unknown critical extension. I think that is the key to solve the problem.
I changed my server certificate and let Android trust the CA, now I have no trouble with untusted certificates over WLAN, the 3G issue remains however. I dug up this about
SSL23_GET_SERVER_HELLO:unknown protocol
according to this, the error:140770FC I got would point to a DNS issue, which would explain why it happens over 3G only, but not why it doesn't happen on the Mac.
To gather a bit more information, I tried to open one of my web pages with Chrome. It issued a
Error 111 (net::ERR_TUNNEL_CONNECTION_FAILED)
which was connected to SSL issues here, but I can't acknowledge that the error disappears after a switch to the standard port. I need better tools for further investigation, maybe I ask another question later.
SSL handshake aborted: ssl=0x18e8508: Failure in SSL library, usually a protocol errorandroutines:SSL23_GET_SERVER_HELLO:unknown protocol, which confirms your problem lies in the SSL part. Strange thing that this does not happen on WiFi. Do you have the chance to try with a different 3G provider? As it does not happen on WiFi, it must be something on their end. Also: Are you presented with a certificate? If so, I'd take a closer look at it and compare it with what you would expect here.