User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.9) Gecko/2008052906 Firefox/3.0 Many websites are reachable both at "domain.com" and at "www.domain.com". They usually transparently 301-redirect from the "domain.com" domain to the one with www in front. However, quite frequently the SSL certificate is valid only for the domain with "www". I think that in this special case -- where the certificate is valid for another domain, but the site is emitting a 301 redirect *for that domain* for which the certificate is valid, then perhaps the redirect should be handled normally and the user not bothered. Reproducible: Always
Moving this to Core, but I suspect it might be a WONTFIX. We can't see the 301 until we have completed a successful SSL handshake, and it's the handshake itself that is failing right now. bug 402210 does the next best thing, I think, making you one click away in cases where the redirect is "probably" safe.
Kai, do you agree?
I think this should be WONTFIX as well. If you click an https bookmark, you shouldn't have to look carefully at the address bar again to verify that it loaded the site you thought it loaded.
> If you click an https bookmark, you shouldn't have to look carefully at the > address bar again to verify that it loaded the site you thought it loaded. What? So you're going to remove support for 301 redirects in HTTPS altogether?
Redirects are part of HTTP and can't be removed without breaking existing standards. The issue at hand is, that redirects can only happen AFTER the handshake and sending of the headers.
What Eddy said - no one is removing anything, we're just discussing whether or not the behaviour you describe, "accept bad certificate long enough to see if it's a redirect, then if it isn't, go back to failing the SSL handshake," is feasible or desirable. Jesse's point was that the behaviour you describe isn't generically desirable, but obviously site A presenting a trusted cert during handshake and then 301'ng to site B (presenting trusted, but possibly different cert) is an acceptable exchange with no one claiming to be anything they're not - no one is suggesting we change that, or any other behaviour.
> no one is removing anything I realise that, I was just pointing out that Jesse Ruderman's argument in comment #3 would imply that (and therefore the argument is bogus).
I agree with WONTFIX.
Please provide justification for the WONTFIX. (As I already said, comment #3 is not a justification.)
When using HTTPS, SSL is a wrapper around HTTP. A successful protocol conversation of the wrapper is a precondition to executing any HTTP conversation. Please note that HTTP conversation (even a GET request) can include user credentials, passwords or session tickets. If we'd temporarily allow to drop the SSL security for learning about potential redirects, we'd potentially leak information over a questionable channel.
Johnath's comment 6 is an accurate clarification of comment 3. Clicking a bookmark to a trusted https: site shouldn't cause you to end up at a site owned by someone else *due to a MITM attack*. If the trusted site itself has a redirect, it's probably benign (e.g. a redirect to another domain owned by the same people, also using https).
> Johnath's comment 6 is an accurate clarification of comment 3. Yes, but it doesn't justify a WONTFIX. Kai's comment #10 does however. Thanks Kai.