Firefox 5 unable to renegotiate on SSL socket

Bug #798672 reported by Thomas Tanghus
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Won't Fix
Medium
firefox (Ubuntu)
Won't Fix
High
Unassigned

Bug Description

Binary package hint: firefox

When trying to login to https://www.pensionsinfo.dk/cgi-bin/oces.pl via https://www.pensionsinfo.dk/Borgerservice/login.html (the button "Log ind med Digital Signatur...") I get the error:

"Secure Connection Failed
          An error occurred during a connection to www.pensionsinfo.dk.

Renegotiation is not allowed on this SSL socket.

(Error code: ssl_error_renegotiation_not_allowed)
  The page you are trying to view can not be shown because the authenticity of the received data could not be verified.
  Please contact the web site owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site."

It works OK in Google Chrome.

lsb_release -rd
Description: Ubuntu 11.04
Release: 11.04

apt-cache policy firefox
firefox:
  Installed: 5.0~b5+build1+nobinonly-0ubuntu0.11.04.1
  Candidate: 5.0~b5+build1+nobinonly-0ubuntu0.11.04.1
  Version table:
 *** 5.0~b5+build1+nobinonly-0ubuntu0.11.04.1 0
        500 http://archive.ubuntu.com/ubuntu/ natty-proposed/main i386 Packages
        100 /var/lib/dpkg/status
     4.0.1+build1+nobinonly-0ubuntu0.11.04.3 0
        500 http://dk.archive.ubuntu.com/ubuntu/ natty-updates/main i386 Packages
     4.0.1+build1+nobinonly-0ubuntu0.11.04.1 0
        500 http://security.ubuntu.com/ubuntu/ natty-security/main i386 Packages
     4.0+nobinonly-0ubuntu3 0
        500 http://dk.archive.ubuntu.com/ubuntu/ natty/main i386 Packages

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: firefox 5.0~b5+build1+nobinonly-0ubuntu0.11.04.1
ProcVersionSignature: Ubuntu 2.6.38-10.44-generic 2.6.38.7
Uname: Linux 2.6.38-10-generic i686
NonfreeKernelModules: fglrx
Architecture: i386
Date: Fri Jun 17 14:28:08 2011
FirefoxPackages:
 firefox 5.0~b5+build1+nobinonly-0ubuntu0.11.04.1
 flashplugin-installer N/A
 adobe-flashplugin 10.3.181.22-0natty1
 icedtea-plugin N/A
InstallationMedia: Kubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
ProcEnviron:
 LANGUAGE=en_CA
 PATH=(custom, user)
 LANG=en_CA.UTF-8
 LC_MESSAGES=en_CA.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox
UpgradeStatus: Upgraded to natty on 2011-06-05 (12 days ago)

CVE References

Revision history for this message
In , Matěj Cepl (mcepl) wrote :

When trying to login to my account at myopenid.com with SSL certificate I get error:

Secure Connection Failed
          An error occurred during a connection to www.myopenid.com.
Renegotiation is not allowed on this SSL socket.
(Error code: ssl_error_renegotiation_not_allowed)

Using mozilla binary
Mozilla/5.0 (X11; Linux i686 on x86_64; rv:2.0b6) Gecko/20100101 Firefox/4.0b6

Revision history for this message
In , Emaldona (emaldona) wrote :

On https://developer.mozilla.org/NSS_3.12.6_release_notes
see the section titled SSL3 & TLS Renegotiation Indication Extension

the default setting is
# [2|r|R]: SSL_RENEGOTIATE_REQUIRES_XTN (default)
Only allows renegotiation if the peer's hello bears the TLS renegotiation_info extension. This is the safe renegotiation.

Downstream distributions can opt to change the default to
[3|t|T]: SSL_RENEGOTIATE_TRANSITIONAL
Disallows unsafe renegotiation in server sockets only, but allows clients to continue to renegotiate with vulnerable servers. This value should only be used during the transition period when few servers have been upgraded.

Revision history for this message
In , Dveditz (dveditz) wrote :

Is this using the Mozilla-produced binary or a Red Hat one?

Kai: Does Mozilla have different renegotiation settings between Firefox 4 and the 3.6 branch? I know we talked about getting more strict later, but Firefox 4 probably isn't later enough.

Revision history for this message
In , Emaldona (emaldona) wrote :

I spoke to Matej online earlier and he said he using Mozilla's iirc.

Revision history for this message
In , Matěj Cepl (mcepl) wrote :

(In reply to comment #2)
> Is this using the Mozilla-produced binary or a Red Hat one?

This is 4.0b6 x86_64 from ftp.mozilla.org

Revision history for this message
In , Wan-Teh Chang (wtc-google) wrote :

Matej: thanks for the bug report. https://www.myopenid.com
does not support the TLS renegotiation_info extension. This
is why Firefox reports the ssl_error_renegotiation_not_allowed
error when https://www.myopenid.com requests old-style (insecure)
renegotiation.

Please submit a bug report to the website administrator of
https://www.myopenid.com to have their SSL implementation upgraded.

In Firefox, you can work around this server security problem as follows.
1. Type about:config in the location bar.
2. Type security.ssl.renego_unrestricted_hosts in the Filter field
3. Add www.myopenid.com to the value of the
   security.ssl.renego_unrestricted_hosts preference.

Revision history for this message
In , Dveditz (dveditz) wrote :

We need to document the TLS Renegotiation prefs on MDC so SUMO folks have somewhere to point people having problems. These prefs are currently documented at https://wiki.mozilla.org/Security:Renegotiation but in a developer-oriented fashion.

The basic functionality was added to Firefox 3.6.2 and 3.5.9

What is new in Firefox 4 is the default for the pref security.ssl.allow_unrestricted_renego_everywhere__temporarily_available_pref

The setting is 'true' in the older branches and 'false' (safe) in FF4.

In the default settings the stable branches CAN renegotiate safely if the site supports the updated protocol. On the trunk we REQUIRE safe renegotiation. This will break some sites.

This still doesn't protect users against the more likely initial-negotiation attack (the one used against Twitter, for example). Until we turn on one or both of the other two prefs users have to rely entirely on the site to disable renegotiation or implement the new protocol.

The next step would be to disable positive SSL notification for broken sites with the pref security.ssl.treat_unsafe_negotiation_as_broken -- but currently too many sites are broken (including about a third of SSL sites that appear to have disabled renegotiation and are probably safe, but the browser can't tell).

The last step would be to enable the pref security.ssl.require_safe_negotiation and reject connections to any site without support for the new protocol. That will take a while if the SSLv2 experience teaches us anything.

Reopening the bug for Mr. Firefox (Johnathan) to agree documenting the new behavior is good enough and so Sheppy notices the dev-doc-needed (not sure his queries see closed bugs).

Revision history for this message
In , Smooney (smooney) wrote :

It seems like this is not a product blocker but we should have the docs ready for FF4. Does this sound reasonable? How can we get it out of the nomination queue.

Revision history for this message
In , Eshepherd (eshepherd) wrote :

It's on the list of things to document and will be gotten done when we can.

Revision history for this message
In , Mbeltzner (mbeltzner) wrote :

Johnath, would appreciate your weigh-in here as well - bad tradeoff here between "being insecure" and "being compatible." My feeling is that this is WONTFIX with a follow-up to the various sites explaining why they won't work in Firefox 4.

Agreed?

Revision history for this message
In , Johnath (johnath) wrote :

Agreed. I hate the compat hit, but this problem has been known for a while, we winced and took the compat path on 3.5/3.6, we have a pref for truly broken scenarios in 4.0.

Tagging this with user-doc-needed. I also think it should be WONTFIX, but will defer to an actual PSM peer (WTC, Kai?) instead of using my quasi-peer status here. :)

Revision history for this message
In , Kai Engert (kaie) wrote :

I agree with WONTFIX

I'm glad we all agree on the more secure path.

Revision history for this message
In , Clibois-work (clibois-work) wrote :

Hello, is there a final decision about the default value of this parameter ?

Most of the ssl site are not yet upgraded to support the ssl fix.
So there will be a lot of trouble for the client using services which lessen friendlyness of some application.

I think it's important for firefox adoption that things are in touch with the reality and I don't think it's the responsability of firefox to impose this ssl fix.

Revision history for this message
Thomas Tanghus (tanghus) wrote :
Micah Gersten (micahg)
summary: - Firefox 4 unable to renegotiate on SSL socket
+ Firefox 5 unable to renegotiate on SSL socket
Revision history for this message
Thomas Tanghus (tanghus) wrote : Re: [Bug 798672] Re: Firefox 5 unable to renegotiate on SSL socket

On Friday 17 June 2011 23:41:31 you wrote:
> ** Summary changed:
>
> - Firefox 4 unable to renegotiate on SSL socket
> + Firefox 5 unable to renegotiate on SSL socket

Oops. Old habit ;-)

--
Best regards / med venlig hilsen

Thomas Olsen

Revision history for this message
Micah Gersten (micahg) wrote :

Thank you for reporting this to Ubuntu. Unfortunately, that site is using an out of date secure connection protocol. Please report this to the website owner. You can reference the upstream Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=597419 as well as this error from the Error Console in Firefox:
www.pensionsinfo.dk : server does not support RFC 5746, see CVE-2009-3555

Changed in firefox (Ubuntu):
importance: Undecided → High
status: New → Won't Fix
Changed in firefox:
importance: Unknown → Medium
status: Unknown → Won't Fix
Revision history for this message
Thomas Tanghus (tanghus) wrote : Re: [Bug 798672] Re: Firefox 5 unable to renegotiate on SSL socket

On Saturday 18 June 2011 00:13:05 you wrote:
> Thank you for reporting this to Ubuntu. Unfortunately, that site is using
> an out of date secure connection protocol. Please report this to the
> website owner.

Thank you for the swift response. I will contact the site owner.

--
Best regards / med venlig hilsen

Thomas Olsen

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.