If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

ECC apparently disabled in FF3 builds

RESOLVED WORKSFORME

Status

()

Core
Security: PSM
RESOLVED WORKSFORME
9 years ago
9 years ago

People

(Reporter: Bill Price, Assigned: kaie)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
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.
(Reporter)

Updated

9 years ago
Component: Security: CAPS → Security: PSM
Wouldn't this be NSS rather than PSM?
Assignee: dveditz → kaie
QA Contact: caps → psm
(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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: TLS Client Hello does not offer ciphersuites that use ECC → ECC apparently disabled in FF3 builds
(Assignee)

Comment 3

9 years ago
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
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.
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?
(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?
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.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.