Search Support

Beware of phishing attacks: Mozilla will never ask you to call a number or visit a non-Mozilla website. Please ignore such requests.

Learn More

Lolu chungechunge lwabekwa kunqolobane. Uyacelwa ubuze umbuzo omusha uma udinga usizo.

Cannot connect using SSLv3 to my router so as to upgrade it to use TLS

  • 12 uphendule
  • 8 zinale nkinga
  • 175 views
  • Igcine ukuphendulwa ngu tdial

more options

I need to connect using SSLv3 to MY router, on MY LAN, where there is NO meaningful risk of a MITM attack. Please provide instructions for doing so.

I have read through several other questions and the non-responsive answers. The best of them recommends obtaining and installing an old Firefox version from an unknown source. This as a circumvention for an apparently unalterable correction to a security exposure that does not exist on my network. It is quite unacceptable to be told that to work around a correction to a known potential vulnerability that does not exist I must install a large single purpose program that exposes not only that vulnerability but probably a number of others that might actually be of concern.

It is well and good to provide software and default settings that provide as much security as possible. It is unintelligent, however, to do it in such a way as to prevent circumvention in cases where the risk is known to be zero.

For the record, I have changed the following settings without success:

security.tls.insecure_fallback_hosts;192.168.1.2 security.tls.version.fallback-limit;0 security.tls.version.min;0

All Replies (12)

more options

It is possible that apart from SSL3 you also need support for cipher suites that are no longer supported. On Linux it shouldn't be a problem to install an older Firefox version that supports your modem and use that version with its own profile to access the device.

You can still find all Firefox versions on the Mozilla CDN server.

Okulungisiwe ngu cor-el

more options

Would the possibly unsupported cipher suites be ones unsupported by Mozilla or unsupported/unavailable on Debian 8.2 and perhaps other distributions? Further information about this might be useful.

Installing an older, presumably buggier, and generally less secure, Firefox version seems a poor alternative to enabling a specific security downgrade that in the specific circumstances presents no risk at all and in general does not present a major risk for most people. Again, the releases directory, while quite extensive, seems not to contain release notes that might indicate what support was dropped, and when. A link to

https://www.mozilla.org/en-US/firefox/releases/

Examining this suggests that the last release with SSLv3 support was 33.1; the examination also suggests a large number of reasons why running this release would be a really bad idea from a security standpoint. It is easier and safer to log on to the router, switch it back to http, and use the current Chromium or Firefox browser. Unfortunately, many or most users will not be able to do that and may be stuck with routers that are insecure and cannot be updated easily with later and more secure firmware - because they did the right thing and secured their router's administration interface.

The response suggests that this is a "WON'T FIX." If so, Mozilla.org should give serious thought to changing their position. Proper network security depends on many different things. It is not appropriate for a single vendor to make arbitrary decisions that may improve security from the narrow viewpoint of their products but have an unintended consequence of forcing users to degrade other aspects of security to compensate. While the target of this particular screed is Mozilla, they are not alone: it appears that Chromium and Internet Explorer suffer from the same type of change.

more options

Is Google Chrome also not able to access that router?

From Firefox there are at least older version available and if you only use them to access your router and not for browsing internet then there shouldn't be a problem.

Do you know what the last Firefox version was that worked with the router?

Then you can check the connection details and what cipher suite is used. That is what I do if someone posts a problem with a website server and I can replicate the problem to see if there is a workaround. Sometimes you can force another cipher suite by disabling cipher suites that are further up in the list that Firefox uses to try to establish a connection.

Okulungisiwe ngu cor-el

more options

I think Firefox 38 was the last version with SSLv3 plumbing.

(Removed completely from Fx39 by bug #1106470)

Okulungisiwe ngu jscher2000

more options

I was using 38.3.0, so it appears the damage was done before that. Looking at release notes suggests it might have been disabled in R.37 ("Disabled insecure TLS version fallback for site security") or possibly killed by disallowing RC4 in R.36, which also might have affected certificate processing ("Phasing out Certificates with 1024-bit RSA Keys"). It may be that the code remained in R.38 but was disabled, and earlier removal of RC4 or short key support may be the problem.

I stand by my claim that it is inadvisable to remove legacy security components simply because they no longer offer the protection they once did. Using a vulnerable SSL is not worse than using insecure HTTP.

jscher2000 said

I think Firefox 38 was the last version with SSLv3 plumbing. (Removed completely from Fx39 by bug #1106470)
more options

But in Firefox 38.3.0esr you may still be able to re-enable SSLv3 in about:config --

(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button promising to be careful.

(2) In the search box above the list, type or paste TLS and pause while the list is filtered

(3) Double-click the security.tls.version.min preference and reduce the value from 1 to 0 (that's a zero)

-- that no longer has any effect in Firefox 39 and later.

Okulungisiwe ngu jscher2000

more options

For websites you can probably add such a website domain to a whitelist pref, but that may not work with a router that you access via the IP address.

Disabling this security altogether is not recommended, but you can consider to use a separate profile if you can make it work in Firefox 38 or lower.

  • security.tls.insecure_fallback_hosts
  • security.tls.version.fallback-limit

See also:

more options

Yes, current versions of Chromium, as well as Internet Explorer, exhibit the same defect, with equal opaqueness to prevent diagnosing the problem in detail. Unfortunately I do not know the last version that worked; this router logs to a log server and rarely needs admin access. It probably has been over a year since I had occasion to do that.

An old version of Firefox might solve the problem, or might not, depending on details that the error panel does not report. For instance, if Firefox SSL depends on shared libraries supplied by the OS, and the OS has changed them to cause the error, a different Firefox (or Chrome) might be, at best, a partial answer. In any event it would be cruft, and a browser which would be used for only one purpose and unsafe to use for others. Disabling more preferred (and therefore more secure) ciphers arguably is an inferior option to either using a backlevel browser or my alternative of using non-SSL http.

=> Does Firefox have a log to report details of such events, or a debug mode that will enable data collection for faults like that of the current topic?


cor-el said

Is Google Chrome also not able to access that router? From Firefox there are at least older version available and if you only use them to access your router and not for browsing internet then there shouldn't be a problem. Do you know what the last Firefox version was that worked with the router? Then you can check the connection details and what cipher suite is used. That is what I do if someone posts a problem with a website server and I can replicate the problem to see if there is a workaround. Sometimes you can force another cipher suite by disabling cipher suites that are further up in the list that Firefox uses to try to establish a connection.
more options

Before opening this thread I already had changed:

security:tls:version:min from 2 to 0 security:tls:version:fallback-limit from 3 to 0 security:tls_insecure_fallback_hosts from (null) to my router's name, which is resolved correctly by the local DNS server.

These changes did not have the desired effect. The initial post stated that, but somewhat imprecisely.

more options

Sorry, I missed that in your original question. Could you double-check on this test page: https://zmap.io/sslv3/sslv3test.html

more options
more options

Same response, I think:

The connection to <FQDN> was interrupted while the page was loading.

   The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
   Please contact the website owners to inform them of this problem.

jscher2000 said

Sorry, I missed that in your original question. Could you double-check on this test page: https://zmap.io/sslv3/sslv3test.html