Adblock Plus and (a little) more
Weird SSL misconfigurations · 2013-10-01 13:40 by Wladimir Palant
TL;DR: Some Firefox installations don’t support strong encryption and I wonder why that is.
There is one issue with relying on community-supplied filter lists in Adblock Plus: these lists are sometimes hosted on unreliable services that will go down without any prior notice. That’s why a fallback solution had to be designed in the early stages of the projects: if a client cannot reach a filter download server several times in a row it should query a fallback URL which could reply with a new location for that filter list. These fallback requests can also be used to notice issues with filter downloads that the owners of the filter lists didn’t notice themselves.
While that mechanism proved very useful over the years, one issue wasn’t anticipated originally: the fallback URL was being triggered constantly, even for filter lists that were accessible just fine. Some people consistently failed to download filter lists (while still being able to access the fallback URL), be it because of strange misconfigurations, malfunctioning security software or weird proxy servers. The range of possible issues increased significantly once all Adblock Plus requests switched to SSL.
The numbers were still pretty low however — until mid-August when we’ve reconfigured easylist-downloads.adblockplus.org to use the recommended SSL settings (disabled SSLv3 and weak cyphers). All the sudden the prevalent reported error became SSL_ERROR_NO_CYPHER_OVERLAP — it seems that at least several thousands Firefox users cannot use any strong cyphers.
Obvious suspicion would be extremely outdated clients. And indeed, many of these fallback requests come from outdated Firefox and Adblock Plus versions. However, they are not that outdated, mostly at least Firefox 17 and sometimes even the current Firefox 24. The outdated versions seem to be rather a consequence of the same SSL issues, I guess that they prevent these clients from connecting to Mozilla’s update servers as well.
A glance at about:config offers another possible explanation: under security.ssl3 one can switch off specific cyphers. I cannot really imagine somebody switching off all strong cyphers however, whether intentionally or by accident. Data corruption causing this issue is IMHO too unlikely to be responsible for thousands of misconfigured clients. Malice is however still an option: given the suspicion that NSA conducts SSL downgrade attacks, the idea that settings for some clients could be manipulated to use only insecure protocols while keeping appearances of secure communication isn’t too far-fetched. Of course, changing browser configuration requires the system to be compromised in the first place so this approach only makes sense for a stealth operation where no software should be installed permanently on the system.
I’m normally not into paranoia so I am looking forward to more reasonable explanations. Did I miss something obvious?
Comment [6]
Commenting is closed for this article.
Stefan · 2013-10-01 14:56 · #
Hm, have you considered users turned it off by accident? I’m thinking some users might’ve switched the recently removed settings in Firefox’ options dialog because they tried to get rid of Firefox’ “this page uses an invalid cert”. Another reason might be the more or less recent articles about RC4 and BEAST attacks. Maybe users turned some ciphers off to mitigate that vector, but forgot to turn it back on?
PS: I was quite confused why the submit button was disabled until I clicked preview. I’d appreciate if you could make the reason more obvious.
Reply from Wladimir Palant:
Yes, it says “I cannot really imagine somebody switching off all strong cyphers [..] by accident” in my blog post so I considered that possibility. However, from all I know there never was a UI for these settings, one would have to go to about:config. Also, it’s a dozen settings that would need to be disabled, most of them not related to RC4. I honestly cannot see how somebody would turn them off by accident.
malte · 2013-10-01 17:26 · #
Back when I first switched my filter list to SSL, I ran into similar problems by relying on SNI. For some reason, things didn’t work for a lot of users, even though Firefox had already supported it for quite some time.
The most plausible scenario I came up with back then was that these people are using MITM proxies (some security solutions do that) that use an outdated SSL stack. However, I wasn’t able to verify that.
Reply from Wladimir Palant:
MITM proxies from security solutions is something I would mostly expect in large corporate environments. I checked ten IP addresses and only three looked like they could originate in a corporate network, the rest were clearly dynamic IPs assigned by some ISP.
Fernando Miguel · 2013-10-02 18:49 · #
Some ISPs also have transparent proxies that could cause issues with SSL
on my last job, we saw lots of that in northern africa
Reply from Wladimir Palant:
Yes, proxies cause tons of issues but it’s their IP address in the logs then – not the dynamic IP address of the customer.
Fernando Miguel · 2013-10-02 18:55 · #
also, check https://www.ssllabs.com/ssltest/analyze.html?d=easylist-downloads.adblockplus.org for any bad conf on the SSL side of things
Reply from Wladimir Palant:
I did – that’s the web site recommending that weak ciphers are disabled :)
Onno Ekker · 2013-10-06 11:11 · #
Some countries don’t get strong SSL because of export restrictions. Maybe that’s what causing this problem in some cases?
Reply from Wladimir Palant:
That paragraph seems very outdated, from all I know the export restrictions on encryption have been lifted more than a decade ago. See “http://en.wikipedia.org/wiki/Export_of_cryptography_in_the_United_States#Current_status” for example – none of the remaining restrictions seem to apply to browsers, and I’m not aware of Mozilla implementing any country-specific restrictions to SSL.
Gervase Markham · 2013-10-08 15:51 · #
I can’t think of any reason either; if and when you find out (is there any way of contacting such users?) I would be absolutely fascinated to know the answer.
Gerv