Option to Ignore CA on Private IP Ranges (RFC1918: 192.168.0.0/16; 172.16.0.0/12; 10.0.0.0/8)

RESOLVED WONTFIX

Status

()

Firefox
Security
--
major
RESOLVED WONTFIX
9 years ago
9 years ago

People

(Reporter: MrIncredible, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2

Security and CA verification can be preserved by simply checking the address: If it is numeric and on a private range, there is no security threat. If a domain name resolves to a private IP, then by all means, make the screen blood red, turn the mouse cursor into a dagger, and scare the hell out of the user.

It makes no sense wasting hours of IT admins' time clicking through all the CA precautions that comes with Firefox, when simply configuring devices on their local private subnet in non-plaintext.

This issue alone is enough to drive loyal Firefox customers to Internet Explorer, Chrome or Opera - which proves much less of pain in dealing with this.



Reproducible: Always

Steps to Reproduce:
1. https://127.0.0.1/
2. https://192.168.0.1/
3. etc...

Comment 1

9 years ago
It's not safe just because it's a private ipaddress : that only means that it's a device on your local network. But it could still be an attack my a malicious device (a big customer of my company has encountered a man-in-the-middle attack this way).

Bug 398721 will help to deal with self-signed certificates and the like (as explain in bug 399277 comment 33 to 36), without exposing the user to the same problems as experienced in Firefox 2 and below. Most users click on any security related dialog (no matter how serious the issue is) ; Firefox 3 makes this a bit harder (and annoying for admins if they encounter it too often), but the error is still that the users are clicking on every ok button they see. Bug 398721 should combat that.

See bug 427293 comment 22 how to limit the number of clicks for those admins. Or install <https://addons.mozilla.org/en-US/firefox/addon/6843>.

Comment 2

9 years ago
that was bug 399275 comment 33 to 36, not bug 399277
(Reporter)

Comment 3

9 years ago
Where could we find more details about the mentioned attack? I am certain that it can be identified, with Firefox displaying a red warning similar to the attack site warning, if detected.

A simple unobtrusive unmissable pop-down explaining that the site 1) is on the local network and 2) can not be authenticated and 3) could be used for impersonating a legitimate site, at least once for each self-signed, local-ip site visited, should be more than adequate - I have yet to see a valid claim that this is insecure, or an example of how this will facilitate an attack.

I understand the implication for large corporations, but - 

1) Is it really up to the browser to ensure the authenticity of their intranet SSL servers? They could always use their public IP's for secure servers.

2) In a properly maintained network this can be eliminated as a security risk, even without the need for user education.

This issue can definitely be dealt with much better than the current, much debated solution.

The mountains of rants, gripes and solutions on the web certainly makes an acceptable solution seems near impossible -- which - if it can't be found in forum/bug posts, maybe Mozilla should look at a feature requesting method similar to the one used on launchad.net for Ubuntu (amongst others), with proposed solutions and votes to each - and make access to this portal clearly visible on the web.

Alternate solution, sure to provoke even more heat:

How about adding a new url handler such as httpsl:// or ssl:// and/or possibly flashing the address bar background when accessing such sites?

---
Here is the current workaround, which goes some way toward alleviating this:

http://kb.mozillazine.org/Browser.ssl_override_behavior
http://kb.mozillazine.org/Browser.xul.error_pages.expert_bad_cert
(a la https://bugzilla.mozilla.org/show_bug.cgi?id=402207)

Setting first option to 2, and last option to true, goes some way toward alleviating this, reducing the number of clicks to 2, with a 3 second delay inbetween, upon first opening a device.

--- 
For more ideas and rants, in addition to several other "bug" posts, here is another starting point: http://pandion.ferrus.net/2008/07/31/mozilla-ssl-policy-bad-for-the-web
First off, let's be clear here.  Anyone in a position to MitM you is, nearly by definition, in a position to control the IP addresses to which you are redirected. The standard attack pattern for someone using ettercap or any of its cousins is to establish themselves on a network, likely by creating a rogue access point, but they could also just ARP poison an existing network, and by doing so, cause your attempts to browse to any site to end up at their machine.

RFC1918 addresses are not privileged at all in this case, because the intrinsic assumption of a "non-routable" address is that the attacker is not on your network, an assumption these tools are quite happy to violate. They'll spoof whatever addresses you like, and if we give some addresses a shortcut around detection, of course that's where they'll go first.  So in the general case, privileging specific IP ranges is a non-starter for me.

Having said that, there has been talk historically about a way to let individual users volunteer to be MitM'd, because they find the clicks annoying, most likely through an about:config option that would take a list of IPs or ranges (initially empty) for which SSL warnings are ignored. This is a pretty crappy option to support, it means that one well meaning blogger who writes about "getting rid of annoying SSL warnings" can "teach" his or her entire readership how to make themselves vulnerable to attack, but it would certainly make things easier for IT administrators, and I do think there's value in doing that.

It would be nice, of course, if we could make IT's life easier without opening up a generic hole in the product, which is why I wrote the addon Jo references,

https://addons.mozilla.org/en-US/firefox/addon/6843

Have you tried it?  Does it not work for your situation? That addon makes ignoring an SSL warning a one-click operation, which is at least parity with other browsers, but also lets you control whether such exceptions are remembered permanently or not, cutting down the hassle factor further, I should think?  Obviously, that still requires IT to install the addon, but IT folk also tend to be a lot more astute when it comes to the availability of addons and an understanding of how they work, so I'd like for that to give them what they need without softening the stance of the browser itself.

Comment 5

9 years ago
(In reply to comment #0)
> If a
> domain name resolves to a private IP, then by all means, make the screen blood
> red, turn the mouse cursor into a dagger, and scare the hell out of the user.

I'm sorry, but that's not correct. We use SSL certificates for our internal networks extensively and all certificates resolve internal private IP addresses.
(Reporter)

Comment 6

9 years ago
I am not suggesting giving a list of IP's to be excluded - that would be a huge security threat!

BUT: Handling self-signed certs on private subnets ala RFC 1918 differently, is a great, innovative and viable solution.

If any domain name resolves to a private range, Firefox can give an attack page. If IP is numeric, and local, pop-down info box.

PS Mitm Addon broken on Linux FF 3.0.3, Linux FF3.0.6; Vista FF 3.1 - if it does anything different from the built-in about:config options mentioned previously.
(Reporter)

Comment 7

9 years ago
(In reply to comment #5)
> (In reply to comment #0)
> > If a
> > domain name resolves to a private IP, then by all means, make the screen blood
> > red, turn the mouse cursor into a dagger, and scare the hell out of the user.
> 
> I'm sorry, but that's not correct. We use SSL certificates for our internal
> networks extensively and all certificates resolve internal private IP
> addresses.

We are not talking about sites with valid SSL certificates - we are talking about sites with self-signed ssl cerificates - and only about handling them as special cases, by giving a pop-down instead of a "get certificate", "add exception" rigmarole - or at the very least an about:config option to enable the pop-down behavior for RFC1918 addresses.
(Reporter)

Updated

9 years ago
Summary: Option to Ignore CA on Private IP Ranges (192.168.0.0/16; 10.0.0.0/8; etc...) → Option to Ignore CA on Private IP Ranges (RFC1918: 192.168.0.0/16; 172.16.0.0/12; 10.0.0.0/8)

Comment 8

9 years ago
(In reply to comment #3)
> Where could we find more details about the mentioned attack? I am certain that
> it can be identified, with Firefox displaying a red warning similar to the
> attack site warning, if detected.

I can't supply details, except that it was a hardware device inserted in the network (wired, not wireless).

Comment 9

9 years ago
I agree with the reporter: complaining about the lack of a CA cert on https://192.168.0.1/ doesn't protect users from any kind of attack.  I think Firefox should allow the connection and show the identity as "local network" (in gray or blue).
(In reply to comment #7)
> We are not talking about sites with valid SSL certificates - we are talking
> about sites with self-signed ssl cerificates

We know what you're talking about. We understand the suckage for admins to the extent Johnathan wrote an addon and I wrote an about:config pref to reduce the number of clicks, and are changing the default value for browser.ssl_override_behavior in the next Firefox to reduce the necessary clicks for everyone not just those in the know about hidden prefs.

You, however, have not acknowledged the very real security threats, threats that are not mere paranoid fantasies of security developers but have been used in real life with publicly available software to help people pull it off.

Are you talking about actual user-facing "sites" or hardware devices as in bug 399275? For user-facing sites how many could there be? Users should make the exceptions permanent (the default) and they won't be bothered again. If there are a lot of them then it sounds like a large organization that would be better served with an organizational root-cert which users install one time.

If you're talking about hardware devices with built-in certs then we agree it sucks. We don't yet have a great solution, but ignoring real attacks to make things easier isn't one.

Intranet sites are not automatically safer, they could well be your co-workers infected laptop running interception malware.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.