416464 - in intranets with many frequently regenerated self-signed certificates, FF3b2 is unusable

Status: RESOLVED INCOMPLETE

(Firefox :: Security, defect)

Description

[ash]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2

I work for a large company with a large number of internal websites using self-signed SSL certificates.  I would guess at hundreds of such sites.  The common configuration for these sites is a) each site is served by several machines behind a load balancer; and b) each machine generates a new certificate whenever the web server comes up.  Every day I visit at least 10 of these sites in ordinary course of doing my job.  With the new SSL dialog, that means i get to confirm about 100 exceptions every day.  That's basically unusable.  I've taken to using IE to visit some of these sites served by a number of machines because after confirming an exception, i never get the same machine again, so that exception never comes into play.

Reproducible: Always

Steps to Reproduce:
1. visit internal
2. see the invalid cert dialog
3. add exception
4. reload the page
5. see the invalid cert dialog for another certificate
6. continue
Actual Results:  
i'm repeatedly prompted for bad certificates

Expected Results:  
i should only be prompted once.  

maybe what's needed is an exception checkbox that allows any certificate for a specific hostname.  Then i could tell FF on a case by case basis that i do expect to get just about any cert for a specific site.

Comment 1

[Kai Engert (:KaiE:)]

You are using security protocols that are designed to be used with verification, and Firefox follows the design. But your environment deliberately ignores that design.

Firefox allows to override, giving you a chance to work in environments like yours.

You are producing a systematic bug in your infrastructure, please don't complain about the fact that you must manually work around your own systematic breaking of security rules.

Seriously, you should find ways to fix your environment. Why do you use security protocols at all?

Either switch to http (as a hack you could use stunnel to strip away ssl) or find ways to synch the certs between your load balanced sites.

I assume your hosts serve some data from or at least synchronize with a shared resource.
Storing the cert on that shared resource and fetching it from there on server init would solve it.

I propose this bug to be resolved as INVALID.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Agreed about the proposed resolution, or alternatively, WONTFIX.

The reporter's certificate scheme is quite vulnerable to MITM attacks.
The purpose of SSL in Mozilla products is to provide real security that
is resistant to attacks, not to provide fun and games with encryption.

Comment 3

[Johnathan Nightingale [:johnath]]

So while I agree that auto-regenerated certs are worse than useless, I also remember Bob Lord's proposal from a while back to create a kind of "here are the domains that I fully embrace the suck for, please stop harassing me."  That sort of died off once we got the exception functionality, but it's really an independent concept.  Before we totally reject this case, can we get a sense for how much pain that would be?

I think it's legitimate for this to be a nearly invisible feature, we're talking about making IT's life easier, not giving users a way to shoot themselves in the foot.  I just don't know what it would take to make it possible.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Let me amplify on comment 2.

The only way that the scheme described in comment 0 could work with FF2
is for the FF2 users to choose to override the error dialog they receive
*EVERY DAY* when they visit any of those servers.  That error dialog is the
ONLY protection that FF2 users have against any form of server impersonation
attacks, including MITM attacks.  Forcing users to override that error
several times each day forcibly trains them to act in a way that renders
them completely 100% vulnerable to impersonation attacks.

Users who habitually override such errors will never notice an impersonation
attack.  A bogus server could be introduced into that environment for
various nefarious purposes, and the users who habitually override all errors
would never know.  A business network with that property, whose users have
no protection against server impersonation attacks, is not a secure network.

Comment 5

[Johnathan Nightingale [:johnath]]

(In reply to comment #4)
> Let me amplify on comment 2.
> 
> The only way that the scheme described in comment 0 could work with FF2
> is for the FF2 users to choose to override the error dialog they receive
> *EVERY DAY* when they visit any of those servers.

I recognize that, and agree that it is a terrible situation.  I'm taking it as stipulated that this is a Very Bad Thing for a network to do.  That it persists, in the face of that, does a great disservice to that network's users.  And yet, it persists!  In the face of that constant hassle!  I join you in finding that unfortunate in the extreme.

So, if we find no technical solution to the problem feasible, if there's no way to make Mozilla a workable browser under these decidedly unsafe intranet conditions, then the low hanging fruit for these network admins will be to say "No Mozilla on the Intranet, go find a browser with a weaker SSL policy."  That policy will be weaker for all sites, not just the ones on this egregiously awful intranet, and those users will be ill-served by it.

One hopes, one prays, that the reporter is in some unusual role - IT or something, that causes him to interact with this brokenness more than others.  At any rate, he is apparently someone who is willing to carte-blanche his intranet sites, and take on the concomitant risks that implies.

My question is, is there any way we can technologically scope his folly, as a last-ditch alternative to sending him to less safe platforms?