Closed
Bug 398915
Opened 17 years ago
Closed 17 years ago
Secure Connection Failed at https://mozilla.org/ because of hostname mismatch
Categories
(Core :: Security: PSM, defect)
Core
Security: PSM
Tracking
()
RESOLVED
INVALID
People
(Reporter: BijuMailList, Assigned: KaiE)
References
Details
Secure Connection Failed at https://mozilla.org/ https://mozilla.org/ not automatically redirecting to https://www.mozilla.org/ PS: http://mozilla.org/ works fine.
Component: www.mozilla.org → Networking
Product: mozilla.org → Core
QA Contact: www-mozilla-org → networking
Version: other → Trunk
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•17 years ago
|
||
Bug 327181, I presume?
Assignee: nobody → kengert
Blocks: https-error-pages
Component: Networking → Security: PSM
Flags: blocking1.9?
OS: Windows XP → All
QA Contact: networking → psm
Hardware: PC → All
Comment 3•17 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
Comment 4•17 years ago
|
||
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•17 years ago
|
||
I filed bug 398923 against Mozilla IT to get simple SSL certificates for mozilla.com and mozilla.org.
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•17 years ago
|
||
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!
Assignee | ||
Comment 9•17 years ago
|
||
(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
Assignee | ||
Updated•17 years ago
|
Flags: blocking1.9?
Comment 10•17 years ago
|
||
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.
Assignee | ||
Comment 11•17 years ago
|
||
(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•17 years ago
|
||
(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...)
Assignee | ||
Comment 13•17 years ago
|
||
(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•17 years ago
|
||
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•17 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 16•17 years ago
|
||
(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•17 years ago
|
||
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.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → INVALID
Comment 18•17 years ago
|
||
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•17 years ago
|
||
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.
Assignee | ||
Updated•17 years ago
|
Summary: Secure Connection Failed at https://mozilla.org/ → Secure Connection Failed at https://mozilla.org/ because of hostname mismatch
Comment 21•17 years ago
|
||
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. :)
You need to log in
before you can comment on or make changes to this bug.
Description
•