398915 - Secure Connection Failed at https://mozilla.org/ because of hostname mismatch

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Biju]

Secure Connection Failed at https://mozilla.org/

https://mozilla.org/ not automatically redirecting to https://www.mozilla.org/


PS: http://mozilla.org/  works fine.

Comment 1

[Biju]

https://gmail.com/ is also not working...

OK... this is a Firefox issue.


See
http://web-sniffer.net/?url=https%3A%2F%2Fmozilla.org%2F
http://web-sniffer.net/?url=https%3A%2F%2Fgmail.com%2F

Comment 2

[Phil Ringnalda (:philor)]

Bug 327181, I presume?

Comment 3

[Jesse Ruderman]

A nightly from 2007-09-22 shows certificate mismatch dialogs for https://mozilla.org/ and https://gmail.com/, so it didn't exactly "automatically redirect" before bug 327181 landed.  Sounds like this is working as intended.

Comment 4

[Phil Ringnalda (:philor)]

Hmm, if this is exactly as designed, going from telling the user what hostname the server for what they typed actually uses for SSL (the dialog used to say "belongs to mail.google.com", though the "belongs to *.mozilla.org" version wasn't too helpful) to nothing but saying to contact the web site owners (one assumes, by using another browser to connect and find their contact info), perhaps we could put our official advice to those site owners toward the top of this bug, which will certainly wind up prominently featured on bmo/duplicates.cgi, between users' reports and site owners filing "wtf do you expect me to do about your users typing random variations of the hostname I use for SSL, if you won't let me redirect them?"

Comment 5

[Reed Loden [:reed]]

I filed bug 398923 against Mozilla IT to get simple SSL certificates for mozilla.com and mozilla.org.

Comment 6

[Biju]

Issue 1.
--------
Here another problem, due to security reasons many organizations do not allow access to web mail with out https.
One of the way they determine a site web mail is checking word "mail" in the URL.

To access gmail user types https://gmail.com/
Now Firefox blocks it.
So user will switch to IE which works and user stay in IE.


Issue 2.
--------
Assume a company ABC had a secure web site https://abc.tld/
Later they changed name to XYZ and new website as https://xyz.tld/
Current validation logic will force the company also to pay for "abc.tld" SSL Certificate forever. Otherwise company could have a cheaper option just keep "abc.tld" domain name and host on same server.

Remember buying SSL Certificate is costly for third world companies.


So I think 

1) if there is a re-direction we should ignore SSL mismatch.

2) Or give TWO error messages on re-direction like.
 * This site gmail.com uses SSL Certificate issued for 
   another site called mail.google.com
 * And you are redirected to <a href=https://mail.google.com/mail/>
   mail.google.com</a>

3) ALSO https://site.tld/ *should* *match* SSL certificate 
   issued for "*.site.tld"

Comment 8

[David J. Lennon]

User should be presented with the ability to view the site regardless of SSL mismatch or invalid certificate as per previous builds.

This added "functionality" basically stops the user from viewing the vast majority of https:// sites, which is a big big problem!

This could severely restrict Firefox3 adoption, specifically in the security or business community, please reverse!

Comment 9

[Kai Engert (:KaiE:)]

(In reply to comment #8)
> User should be presented with the ability to view the site regardless of SSL
> mismatch or invalid certificate as per previous builds.

It's possible, but we don't "present" it, because of security risks (task oriented users will click through, even on phishing attacks)


> This added "functionality" basically stops the user from viewing the vast
> majority of https:// sites, which is a big big problem!

It doesn't stop you. If the server admin configured the site to work on both hostnames, then the server admin should use a cert that is valid for both hostnames.

Try to ask your CA to issue a cert that is valid for both www.domain.com and domain.com

Comment 10

[David J. Lennon]

With respect it should be presented - Home / business users aren't going to flick through tons of options to find the ability to turn on something they should be able to do from the word 'go'.

Plus businesses aren't going to start sorting out their certs just because Firefox3 doesn't like it - waste of resources on their part.

Comment 11

[Kai Engert (:KaiE:)]

(In reply to comment #10)
> With respect it should be presented - Home / business users aren't going to
> flick through tons of options to find the ability to turn on something they
> should be able to do from the word 'go'.

We don't want users to enable it.
The option to override is only available for power users who are absolutely sure they know what they are doing.

The right solution is for server admins to stick to the rules and set up a valid cert (fix their server).


> Plus businesses aren't going to start sorting out their certs just because
> Firefox3 doesn't like it - waste of resources on their part.

It's not a waste of resources, it helps to set up a valid security infrastructure.

Comment 12

[Sander]

(In reply to comment #9)
> Try to ask your CA to issue a cert that is valid for both www.domain.com and
> domain.com

Is this even possible with self-signed certificates? I've been googling till the cows came home, but no one, anywhere, seems to have instructions for how to generate such a certificate. (With apologies for using bugzilla as a support forum. I just wish there was some separate SSL infrastructure for banks and other critical apps, so that those of us who only want some basic encryption on their personal sites don't have to suffer quite so much...)

Comment 13

[Kai Engert (:KaiE:)]

(In reply to comment #12)
> (In reply to comment #9)
> > Try to ask your CA to issue a cert that is valid for both www.domain.com and
> > domain.com
> 
> Is this even possible with self-signed certificates?

If your certificate is self-signed, it will be rejected, because it is not trusted. Even if you fix the mismatch issue.


I think your questions are answered in RFC 3280, in particular you'd use the subjectAltName extension to list all valid names.

Comment 14

[Justin Fitzhugh]

While I understand the security implications stated above, I think that it's *extremely* important to have a way to enable the old FF2 behavior of a click-through button for technical users.  I use the browser extensively to access ssl-based sites which do not have the same host name as the cert (i.e. accessing via ip address), a self-signed cert, or wildcard certs.  Often these are internal systems and I am connected via VPN, so man in the middle attacks are not a concern, and want to be able to click through the warning.

Beltzner suggested a about:config pref to enable this behavior - perhaps this would be a good compromise so people who understand the implications of click through warnings can enable the functionality?

Comment 15

[Dave Miller [:justdave]]

And what Justin didn't mention is that many of these sites on our internal network are hardware devices with no capability to change the certificate.  If this isn't a pref, you're going to force most network administrators to use another browser by necessity.

Comment 16

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #14)
> Beltzner suggested a about:config pref to enable this behavior - perhaps this
> would be a good compromise so people who understand the implications of click
> through warnings can enable the functionality?

Bug 399275 filed for this suggestion

Comment 17

[Mike Beltzner [:beltzner, not reading bugmail]]

justdave: this bug remains INVALID, as it's per-design. I've opened a new bug for the pref-idea, and people can open alternative feature requests as well, but this bug really shouldn't be REOPENED.

Comment 18

[matthew zeier [:mrz]]

A real-world example - 

Mozilla uses HP servers which have an onboard lights-out-management system
called iLo and is accessible only over https (and ssh).  A fresh-out-of-the-box
HP iLo uses a self-signed certificate and some internally generated hostname
(not a FQDN either, just a hostname) based off it's serial number.  

What I'm looking at is the inability to connect to the iLo webui to even begin
to change the certificate.  I feel like you're forcing me to use IE/Safari to
login, generate a CSR and import a key on a system that does not justify a real
paid-for certificate.  And to further complicate things, the iLo hostname isn't
static - it changes to reflect the hostname of the system which could be
rebuilt and end up with a new hostname.

I have 100+ machines and I couldn't justify spending 100 * $godaddy to get my
work done.  Even if I used a self generated root certificate and then signed
iLo CSRs, I'd still be burdened by the occasional iLo hostname change.  At that
point, I'd stop using Fx for management of these machines.

Comment 19

[Johnathan Nightingale [:johnath]]

Self-signed certs continue to be my biggest concern with bug 327181 as well, since the other errors are all genuinely invalid, whereas an SS-cert is just unattested.  Then again, this bug was originally opened for a domain-mismatch cert, which is genuinely invalid.  I've already filed bug 398718 to clarify the language of the error pages, and it's clear that even technically sophisticated users could benefit from this clarification, in addition to beltzner's bug about a pref to toggle behaviour.

As a purely informational point while the other bugs churn, any site with a broken cert that you need to interact with can be added to the exceptions list as it always could - the UI is just further away (hence the aforementioned need for clarification/simplification).  If you open up your cert manager (Advanced Options->Encryption) you can use "Add Exception" to.. well.. add an exception.  This will allow overrides of domain mismatch, expiry, un-attested certs (whether self-signed or unknown issuer,) pre-issuance, everything except revocation, basically, since a revoked cert is an affirmative sign of nasty.

Comment 21

[Mike Connor [:mconnor]]

As a note, wildcard certs should be ok in general (plenty of sites legitimately
use them, and afaik we don't block them)  the *.foo.com vs. foo.com case is
tricky, in theory SSL providers should be able to specify this as Kaie points
out.

You should be able to have *.internal.foo.com as a single cert, and
sign/install your own root anyway.  It actually feels like a better plan, since
if you do get a bogo-cert, you know something's actually wrong, rather than
just clicking through heedlessly. :)