[Q] A persistent SSL error - I think there's a problem with the CM9 / CM10 codebase?

[rhd-android]

I thought I was smart, until this mystery completely stumped me. I've sought out as much data as possible, but I'm utterly puzzled as to what is causing the problem. I would be really curious to see if anyone can digest my data and come up with a conclusion! My phone is the Sensation 4G.

The Problem:
- Certain (but not all) HTTPS websites requiring SSL don't work and create an error #107 (screenshot below).
- The most notable example is Twitter's HTTPS site, but there are lots of others.

When it Happens:
- The error does not occur on my phone, if I switch to WiFi, or use someone else's SIM.
- The error does not occur on the Galaxy Note (stock), using my SIM.
- The problem occurs on the HTC Desire Z (CM9), using my SIM.
- The problem occurs on my phone, regardless of ROM used. It happens in ICS (AOSP), and in JB (CM10).
- The problem occurs in both Chrome and the stock browser.

Table Summarizing My Data:

Observations / Theories:
- It cannot be my SIM (or the account), because my SIM inserted into a Galaxy Note had no problem.
- It cannot be the Sensation 4G hardware, because the problem doesn't occur with WiFi, and the problem also occurs on the Desire Z hardware.
- It cannot be HTC phones in general, because the Desire Z has no problem with the Wifi or with a Rogers SIM.
- It cannot be ROM related, because the problem occurs in CM9, CM10, and AOSP.

But these observations don't actually lead to a conclusions about what the problem could be caused by.....


NEW INFORMATION:

A new development has lead me to believe that this must be a more widespread problem than I initially suspected. I think there's a common/persistant problem with CyanogenMod that affects certain SSL connections on Bell Mobility's network. What's this new development?

- I bought a brand new phone 2 days ago. A Galaxy SII HD LTE.
- This also means I got a brand new SIM card because the new phone required MicroSIM
- I didn't migrate anything from my old phone.

And here's the kicker. The new phone, with the new SIM, running a fresh install of CM9, also cannot connect to certain SSL sites. The same error #107 occurs, and just like before, if I switch the new phone onto WiFi, there are no problems. Similarly, if I leave the phone with the stock ICS, no problems.

At this stage, the ONLY common denominators are:
- Bell Mobility network
- CyanogenMod 9 or 10

And since the Bell Mobility network can be ruled out (since the stock OS on this phone works, as do other Bell Mobility phones), the problem must be something to do with CyanogenMod.

 

[rhd-android]

I have some additional data / clues to add to the mix here:

As I mentioned previously, no problem occurs over WIFI, but the problem occurs if I switch to mobile data. So I took a logcat of the failure (error 107 when trying to retrieve https://www.twitter.com) over mobile data, followed by another logcat of the problem not occurring over wifi.

The problem occurring (mobile data):

W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
W/IInputConnectionWrapper( 1701): getExtractedText on inactive InputConnection
W/ThrottleService(  348): unable to find stats for iface rmnet0
E/chromium( 1701): [ERROR:ssl_client_socket_openssl.cc(803)] handshake failed; returned -1, SSL error code 1, net_error -107
E/chromium( 1701): [ERROR:ssl_client_socket_openssl.cc(803)] handshake failed; returned -1, SSL error code 1, net_error -107

Everything working fine (wifi):
(I redacted a few portions that seemed to be unique IDs in URLs. I replace the IDs with "--redacted--")

W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443
I/dalvikvm( 1701): Jit: resizing JitTable from 4096 to 8192
D/dalvikvm( 1701): GC_CONCURRENT freed 6169K, 68% free 5376K/16643K, paused 8ms+12ms, total 185ms
I/chromium( 1701): [INFO:CONSOLE(17)] "Revision: --redacted--", source: https://mobile.twitter.com/ (17)
D/ChromeBrowserSyncAdapter( 1701): no delayed sync
I/chromium( 1701): [INFO:CONSOLE(0)] "Creating Application Cache with manifest https://mobile.twitter.com/cache/manifest", source:  (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Checking event", source:  (0)
W/chromium( 1701): [WARNING:spdy_session.cc(1117)] Received data frame for invalid stream 13
I/chromium( 1701): [INFO:CONSOLE(463)] "Loaded: 1787", source: https://mobile.twitter.com/ (463)
I/chromium( 1701): [INFO:CONSOLE(462)] "Started: 1855", source: https://mobile.twitter.com/ (462)
I/chromium( 1701): [INFO:CONSOLE(53)] "appcache: checking", source: https://mobile.twitter.com/ (53)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Downloading event", source:  (0)
I/chromium( 1701): [INFO:CONSOLE(53)] "appcache: downloading", source: https://mobile.twitter.com/ (53)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (0 of 12) https://ma.twimg.com/twitter-mobile/--redacted--/html5/framework/core/assets/m_spinner_black.png", source:  (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (1 of 12) https://ma.twimg.com/twitter-mobile/--redacted--/html5/applications/m5/views/core/timelines/assets/dotted-pattern.png", source:  (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (2 of 12) https://mobile.twitter.com/i/templates/m5", source:  (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (3 of 12) https://mobile.twitter.com/", source:  (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (4 of 12) https://ma.twimg.com/twitter-mobile/--redacted--/html5/framework/core/assets/twitter_logo.png", source:  (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (5 of 12) https://ma.twimg.com/twitter-mobile/--redacted--/html5/plugins/defer/pullrefresh/assets/pulltorefresh_bg.png", source:  (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (6 of 12) https://ma.twimg.com/twitter-mobile/--redacted--/html5/applications/m5/assets/sprite_mobile.png", source:  (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (7 of 12) https://mobile.twitter.com/assets/m5_defer.js", source:  (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (8 of 12) https://ma.twimg.com/twitter-mobile/--redacted--/html5/framework/core/assets/m_spinner_white.png", source:  (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (9 of 12) https://ma.twimg.com/twitter-mobile/--redacted--/html5/applications/m5/views/core/profile/assets/bg_profile_empty.png", source:  (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (10 of 12) https://mobile.twitter.com/assets/m5_defer_ssl.css", source:  (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (11 of 12) https://ma.twimg.com/twitter-mobile/--redacted--/html5/applications/m5/views/core/timelines/assets/list-gap.png", source:  (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Progress event (12 of 12) ", source:  (0)
I/chromium( 1701): [INFO:CONSOLE(0)] "Application Cache Cached event", source:  (0)
I/chromium( 1701): [INFO:CONSOLE(467)] "appcache: cached", source: https://mobile.twitter.com/ (467)
W/chromium( 1701): [WARNING:http_stream_factory_impl_job.cc(1035)] Falling back to SSLv3 because host is TLS intolerant: twitter.com:443

 

[rhd-android]

This thread hasn't seemed to attract attention, but some new information has lead me to the conclusion that this is really a problem someone should look at.

In a nutshell, I've bought a brand new phone, with a brand new SIM, and installed a fresh CM9. The problem is present in this new phone also. The only common denominator, apart from the mobile carrier (which can be ruled out for reasons discussed in the OP), is CyanogenMod.

Check out the bottom of the OP, under "New Information" in red.

 

[xraycat]

I have the same issues running an AOSP version of Android 4.2 (Paranoid Android 2.99.4) on my Galaxy Nexus. I use the Bell network as well and regularly get SSL errors. Once I switch to wifi I don't receive the errors.

 

[rhd-android]

I have the same issues running an AOSP version of Android 4.2 (Paranoid Android 2.99.4) on my Galaxy Nexus. I use the Bell network as well and regularly get SSL errors. Once I switch to wifi I don't receive the errors.

I have talked to one other person (in real life) that has this issue too. For an issue that wouldn't naturally come up in conversation, it's pretty noteworthy that I've found even one other person with this issue (I'm not in a big population center, nor do I talk about phones with random people frequently). Just a passing acquaintance, so not somebody I could grill about the specifics. But he verified that he was running CM, and that the issue only occurred when using his Bell sim, and cell data. It didn't happen when using wifi, nor when on holidays using a foreign cell network.

So, there is something about CM that doesn't behave well with bell in certain situations. It's clear that some SSL sites do in fact work. That might seem like inconsistency, but it's not. The sites that don't work, CONSISTENTLY don't work. Twitter is the easiest example to point to, because it's a mainstream site that everyone recognizes. But there are tons of sites, that fall victim to this same issue when running on the Bell network with CM.

It's very frustrating that nobody has shown any interest in trying to figure this out.

Here's an interesting update:

- I tried an experiment, and setup a VPN to tunnel my mobile data through. I just signed up for one of those $5 per month anonymizer services that gives you a PPTP connection (is that what it's called?). Anyway, the minute I flip it on, everything works. Still using mobile data from Bell, but tunneling it through a VPN. No problems. The minute I turn back OFF the VPN and just use the straight Bell data, back to problems.

- It's not a permanent fix (because it's costing me $5 a month), but it's an easy workaround until someone takes an interest in this issue and helps sort it out. I've done everything I can, and even posted logcats. At this stage, finding a resolution is a few degrees above my comprehension level.

 

[Dream_Team]

Hello guys !
I'm the owner of a Nexus 4 (on Virgin, which is Bell's network), and while this is not the good forum, I am concerned by this bug.
Running CM10 nightly, I have this SSL error.
It's really a OS problem, as you guys figured it out. Except that this time, the stock rom works perfectly.

Sadly, I'll have to go back to vanilla, since it also breaks some apps.
If you only need a workaround for websites, consider using Firefox. It has it's own SSL implementation, and it works perfectly.

 

[rhd-android]

I hear you. Firefox helps, but as you've pointed out THE SSL/BELL FLAW IN CYANOGENMOD ALSO BREAKS APPS! For example, eBay. The eBay app obviously uses the OS SLL stack behind the scenes, because CM9 and CM10, when using Bell, break the eBay app.

Frankly, its really frustrating. Most people can change almost anything about their smartphone setup at will, EXCEPT their carrier (without paying dearly).

There is basically no way to use a custom CM rom on Bell, until someone addresses this. Unfortunately, I am a nobody on this forum, so until someone important notices the problem, I suspect the answer is to use vanilla factory roms, or avoid Bell (if you have that option)

Sad

Sent from my SGH-I757M using xda app-developers app

 

[Dream_Team]

I'm starting to think that this is "easily" fixable.

I just installed an AOKP rom over my CM10 without erasing my settings and the SSL bug was STILL here. Once I wiped /data, the SSL bug was gone. So it's not really a CM codebase bug, as in a fautly lib, but some of it's settings that's broken. I'll investigate more since I have access to working/non working roms and get back to you guys.

EDIT : Ok, so I removed both the Proxy and it's port (they BOTH need to be undefined) from the pda.bell.ca APN and saved the changes. I can now access everything.

Too bad I had to sacrifice all of my music/pictures/app/settings for this, but heh. I hope it works for you ! Someone needs to report this to the CM team.

 

[rhd-android]

I'm starting to think that this is "easily" fixable.

I just installed an AOKP rom over my CM10 without erasing my settings and the SSL bug was STILL here. Once I wiped /data, the SSL bug was gone. So it's not really a CM codebase bug, as in a fautly lib, but some of it's settings that's broken. I'll investigate more since I have access to working/non working roms and get back to you guys.

EDIT : Ok, so I removed both the Proxy and it's port (they BOTH need to be undefined) from the pda.bell.ca APN and saved the changes. I can now access everything.

Too bad I had to sacrifice all of my music/pictures/app/settings for this, but heh. I hope it works for you ! Someone needs to report this to the CM team.

You, sir, have solved the problem.

I can confirm that on a previously "SSL-bug-ridden" CM9 rom, simply un-setting the Proxy, and the Port, has resolved the issue completely!

Brilliant!

 

[rhd-android]

You, sir, have solved the problem.

I can confirm that on a previously "SSL-bug-ridden" CM9 rom, simply un-setting the Proxy, and the Port, has resolved the issue completely!

Brilliant!

Here's an annoying side-effect.

If you disable the proxy entry in the APN settings, you can't have LTE anymore

 

[stimoceiver]

more of the same

same issue on chinese made generic MTK6589 based "Star S7589" phone.

SSL error 107 errors.

from "about phone" page:

Model number: v89_jbl1a698

Android Version: 4.2.1

Baseband Version: MOLY.WR8.W1248.MD.WG.MP.V6.P4, 22013/04/12 17:49

Kernel Version: 3.4.5 [email protected] #1 Mon Apr 22 11:15:49 CST 2013

Build number: v89_jbl1a698_20130422

After seeing this error, I installed Kurt Huwig's SSL Verify from the app store:

url to play store -> play.google.com/store/apps/details?id=de.huwig.sslverify&hl=en

Here is the screenshot (aborted because every last site returned "certificate mismatch"):

url to screenshot -> dumpt.com/img/viewer.php?file=s1tppuca9avpxtxqg50p.jpg

This is the 2nd phone from this vendor. 1st one wouldnt stay connected to the tower so I never had a chance to encounter this issue.

I am quite concerned about the possibility of these certificate chain errors reflecting intentional preloaded MITM capability.

I'm no newb to tech, security, or electronics, but my understanding of the CA chain is far from that of a developer. But one of the more paranoid of my friends, with equal or greater astuteness in the field of network security, had previously suggested that a lot of chinese phones come with pre-installed kernel vulnerabilities where certain syscalls run natively as root.

So needless to say, I'm posting this here in hopes that someone could offer an explanation for the output of SSL Verify that reflects a harmless, unintentional, and perhaps ubiquitous flaw in certain codebases (as has been suggested above) as opposed to, my worst fear, an imminent threat to whatever percentage of the android devices have this vulnerability.

EDIT:
I just tried creating a new APN (even though I am an AT&T customer the APN is [email protected]) with only the most minimal of parameters (both proxy fields blank etc.) when compared to the default which is presumably supplied by the tower/provider.

But regardless of whether this solves the SSL error 107 issue, running SSL Verify still shows the same list of certificates/signatures as mismatched as in the screenshot.

However I note, when watching the program run, that it is not ALL the domains that SSL verify checks - but it is at least half of them. If anyone has a rational explanation for this - or knows of another app I could install to attempt to verify the output - please let me know.

 

[pattmyn]

Here's an annoying side-effect.

If you disable the proxy entry in the APN settings, you can't have LTE anymore

I just tested it and I'm good to go on LTE. Maybe check your ROM's modem to make sure they included the right bands for your model? I know I had to flash over an AT&T modem configuration on a ROM that said it worked flawlessly with the Canadian models.

I was having the same issue and the APN edit fixed it. Good work OP!

A fun quirk I had before was my longer texts being split 160 character bites when the phone should have been using the newer long SMS (which is a type of MSS lol). I worked on that for months. SIM was the issue and it didn't even know its own phone number lol. I finally got a replacement SIM this week after being dicked around for months.

Now if someone can just get SMS delivery reports working, all would be well in the world...

 

[hilroy97]

You, sir, have solved the problem.

I can confirm that on a previously "SSL-bug-ridden" CM9 rom, simply un-setting the Proxy, and the Port, has resolved the issue completely!

Brilliant!

Recently loaded CM 10.1 on my Galaxy S3 (i747M) on Bell. Came across this issue and this thread helped me out.

Thanks to all.


Ed

 

[simboo]

Well,

Erasing Proxy and port saving and rebooting did not solve the problem for me.

Bell I747 running CM10.2 d2att (android 4.3.1)
Chrome beta 33.0.1750.70

After rebooting the phone, values in Proxy and Port come back to their old values.

My SSL problem happens when I try to do a search from the address bar directly. It loads a blank page, I hit refresh and then the SSL error is displayed.

When you do a search in chrome, it does it via h t t p s : / / ...

My Mobile network settings at a glance:

Network mode: GSM/WCDMA/LTE
Roaming mode: home only
CDMA subscription: NV

Access point name: pda.bell.ca
Proxy is getting its old value again and again: web.wireless.bell.ca
Port: 80
APN type: default, *
Bearer: unspecified

EDIT:

Changing "bearer" setting to LTE crashed the phone after I turned off the display and then back on again. Force rebooted (Power+Vol Down), crashed on reboot once, then came back to life and now it works normally. I don't have the SSL error anymore...

Go figure.

 

[Motorllica]

This thread fixed my Ssl issues. Cm11, Galaxy s4, on Bell.

Deleted port/proxy, also set bearer to lte (just incase).

Works flawless now. Signed up to xda to say thanks.

 

[superkev]

I'm starting to think that this is "easily" fixable.
Ok, so I removed both the Proxy and it's port (they BOTH need to be undefined) from the pda.bell.ca APN and saved the changes. I can now access everything.

Thank you so much for figuring this out! It was bugging me on CM11 on my Nexus 4 and I thought I was just going to have to live with it!

 

[MorphlinQc]

Thank you, thank you, thank you, THANK YOU! Been trying to figure this out for 6 months, since I got Bell...

 

[MinisterPhobia]

I'm having this issue on a Nexus 6, stock OS, APN has no proxy or port set, by default. The odd thing is that this worked when I got the phone and in the last couple of weeks, stopped working.

 

[jcmascolo]

On the Bell network with HTC One M8 on Sense 6 and Android 5.0.1 and couldn't go to certain sites due to SSL error connection and recently also an app.
Removing Proxy value (web.wireless.bell.ca) and Port 80 fixed it for me so far! Thanks!

 

[ambusher2991]

Remove Proxy and Port from your access point

I don't think that there is a problem in CM codebase. Try removing the Port and Proxy from your mobile access point