437978 - [RFC] Handle 301 redirect even if certificate is invalid?

Status: RESOLVED WONTFIX

(Core :: Security: PSM, enhancement)

Description

[Timwi]

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

Comment 1

[Johnathan Nightingale [:johnath]]

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.

Comment 2

[Johnathan Nightingale [:johnath]]

Kai, do you agree?

Comment 3

[Jesse Ruderman]

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.

Comment 4

[Timwi]

> 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?

Comment 5

[Eddy Nigg (StartCom)]

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.

Comment 6

[Johnathan Nightingale [:johnath]]

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.

Comment 7

[Timwi]

> 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).

Comment 8

[Kai Engert (:KaiE:)]

I agree with WONTFIX.

Comment 9

[Timwi]

Please provide justification for the WONTFIX. (As I already said, comment #3 is not a justification.)

Comment 10

[Kai Engert (:KaiE:)]

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.

Comment 11

[Jesse Ruderman]

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).

Comment 12

[Timwi]

> 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.