2

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.

4
  • The last block gives some hints: SSL handshake aborted: ssl=0x18e8508: Failure in SSL library, usually a protocol error and routines: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.
    – Izzy
    Aug 24, 2013 at 12:47
  • @Izzy Sadly, I get not even to the certificate stage in Firefox, there is no connection established at all when using 3G. I run some other tests in the next days, and update my question according to my findings. Aug 24, 2013 at 17:30
  • Just coming to my mind: Could it be some "port mapping" problem in your provider's NAT? Maybe your experiments should include binding services to a different port. Using a different SIM (best from another provider) might also yield some interesting results. As you don't even reach "certificate stage": Have you checked logs on your servers, whether there's any incoming request at all? They also may reveal helpful details.
    – Izzy
    Aug 24, 2013 at 17:50
  • 1
    @Izzy 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 telco's application showed 1 MB throughput, and all was a bit sluggish). I think that proves that Android has something to do with this mess. I check my server logs tough, maybe there is NAT involved. Aug 24, 2013 at 19:22

1 Answer 1

1

As you say that the problem exists only on 3G and not on WiFi, this is probably because of some problem with the Access Point of the your network provider. I faced a similar issue sometime back which was because the default access point had a proxy which didn't allow SSL Tunneling. After removing the Port and Proxy from the access point, this problem got resolved.

Source: http://lifepluslinux.blogspot.in/2015/07/errtunnelconnectionfailed-on-mobile.html

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .