[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnuzilla] Unable to browse https://gnupg.org/ with IceCat

From: Mark H Weaver
Subject: Re: [Bug-gnuzilla] Unable to browse https://gnupg.org/ with IceCat
Date: Sat, 06 Feb 2016 08:47:05 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Mark H Weaver <address@hidden> writes:

> When I try to connect to https://gnupg.org/ with IceCat 38.6.0, I get
> the following error:
>   Secure Connection Failed
>   An error occurred during a connection to gnupg.org. Cannot communicate
>   securely with peer: no common encryption algorithm(s). (Error code:
>   ssl_error_no_cypher_overlap)
> Epiphany is able to connect successfully.
> At first I thought that perhaps the web server at gnupg.org was poorly
> configured, but apparently that's not the case.  It seems to have an
> excellent TLS configuration.
> I eventually found that the problem was caused by these lines in
> data/settings.js in the gnuzilla source, which end up in
> browser/app/profile/icecat.js in the IceCat source tarballs:
>   // Avoid logjam attack
>   pref("security.ssl3.dhe_rsa_aes_128_sha", false);
>   pref("security.ssl3.dhe_rsa_aes_256_sha", false);
>   pref("security.ssl3.dhe_dss_aes_128_sha", false);
>   pref("security.ssl3.dhe_rsa_des_ede3_sha", false);
> These lines disable several important cipher suites, despite the fact
> that Logjam was fixed in every reputable system over 8 months ago.
> For now, users can work around this problem by going into about:config
> and changing these settings to "true".  I'm also going to remove these
> customizations from the IceCat build in GNU Guix.

After doing this, I discovered that the last two of those preferences
above don't even exist anymore.  In other words, the lines above
actually *created* the "security.ssl3.dhe_dss_aes_128_sha" and
"security.ssl3.dhe_rsa_des_ede3_sha" preferences, although apparently
there's no code that actually looks at those settings.

I used an online checker to verify that after this change, my IceCat
browser is safe against the Logjam attack.

Finally, note that the relevant code that needed to be patched here is
NSS, which is bundled with IceCat itself and used by default.  So, the
only way that a user compiling IceCat could become vulnerable to Logjam
is if they explicitly asked to use an external copy of NSS that was old
and had not been patched.

I think those lines should be removed from upstream IceCat.

What do you think?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]