447911 - ECC apparently disabled in FF3 builds

Status: RESOLVED WORKSFORME

(Core :: Security: PSM, defect)

Description

[Bill Price]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; OfficeLiveConnector.1.0)
Build Identifier: firefox 3.0.1 downloaded from Mozilla.com on 7/24/08

An attempt to connect to a server that has an ECC server certificate results in the message that the client and server cannot agree on an encryption algorithm. Use of SSLtap to examine the TLS session negotiation showed that the client does not include any ECC ciphersuites in its set of acceptable ciphersuites. The browsers about:config shows that the default settings for the ECC ciphersuites are set to their default values (strong ECC suites enabled, and weak ones disabled).

Reproducible: Always

Steps to Reproduce:
1.Attempt to connect to server that has ECC server certificate.
2.
3.
Actual Results:  
TLS session errors with message that client and server do not have a common encryption algorithm.

Expected Results:  
TLS session should have been established.

A version of FF3.0.1 on Linux also had the same problem. The Linux version was from a private package but there's no reason to suspect that the NSS libraries were changed.

Comment 1

[Daniel Veditz [:dveditz]]

Wouldn't this be NSS rather than PSM?

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #1)
> Wouldn't this be NSS rather than PSM?

No, but it might be Firefox build config.

ECC is alive and well in NSS, when NSS is built with NSS's Makefiles, 
unmodified.  But FF3 makes a bunch of changes to how it builds NSS, and 
I'll bet that some recent change to how FF3 builds NSS has disabled ECC.
But that's a guess at this point.  It could be a PSM bug or an FF3 build bug.  

I confirm this bug because two different people have reported it on two 
different platforms.

Comment 3

[Kai Engert (:KaiE:)]

I just installed Firefox 3.0.1 on a Windows XP system.
Then I connected to http://ecc.fedora.redhat.com

The site tells me "congratulations, you have connected using ECC".

In other words, this seems to work for me, I can not reproduce your problem.

Could you please allow us to connect to your server, or alternatively use a tool like ssltap to produce a snapshot of the SSL/TLS handshake?
Thanks

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Bill Price has posted some ssltap output in the mozilla.dev.tech.crypto 
newsgroup.  See 
http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/560e28d9d99fcd72/542e7f9743d51ce7?lnk=st

Another test server that can be used is
http://tls.secg.org/index1.php?action=preconnect
You will need to choose a curve acceptable to FF3, such as secp384r1,
and will need to create an exception for the cert :(
If you can connect at all, it will produce an output result that is similar
in content to ssltap.

Christophe downloaded FF 301 for MacOS and tried with that server with 
successful results.  So far, the failures have been seen on Windows and Linux.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

Today I went and visited with someone who was having symptoms similar to 
those reported by Bill Price.  Our conclusion was that there is a firewall
product that is actively interfering with the TLS handshake when that 
handshake attempts to negotiate an ECC cipher suite.  ssltap, run on the 
client side of that firewall showed that the client sent a TLS client hello 
that contained all the expect stuff for ECC, and then saw no response until
the connection was dropped.  However on the server side, a lot more things 
happened, including the server receiving an SSL alert record (that the 
browser never sent) claiming the server had negotiated a bad parameter.  
We were able to setup an encrypted tunnel through that firewall, and 
through that tunnel, we were able to connect our browser to the server 
without any problems at all.  So, clearly there is a firewall that is 
disallowing ECC connections.  That solves the problem for one person.

I also learned today that there is at lease one Linux distribution of NSS 
3.12 that has completely disabled all ECC support in softoken.  

So, I strongly suspect that there is actually no problem with the binaries
that Mozilla is distributing, and the problems are in firewall equipment,
and/or other distributions.  

Bill, what's your current status on this issue?  Had any luck?

Comment 6

[Daniel Veditz [:dveditz]]

(In reply to comment #5)
> I also learned today that there is at lease one Linux distribution of NSS 
> 3.12 that has completely disabled all ECC support in softoken.  

if you can't say who, do you at least know why?

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

ECC works fine in builds distributed by Mozilla.
Some other distributions of Mozilla clients (like Firefox) have disabled ECC.
If you're unlucky enough to have one of those distributions, take it up with
those distributors, or get a free download from mozilla.org.