Closed Bug 575274 Opened 14 years ago Closed 14 years ago

SSL/TLS certificate name mismatch ignored for redirects.

Categories

(Core :: Security: PSM, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: mozilla-nospam, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100623 Iceweasel/3.5.10 (like Firefox/3.5.10)
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100623 Iceweasel/3.5.10 (like Firefox/3.5.10)

When accessing an https:// link that returns an HTTP direct, the name of the SSL/TLS certificate is not compared against the actual host name of the server.

This is a security issue, since a man-in-the-middle could trick a user into visiting a phishing web site.

Reproducible: Always

Steps to Reproduce:
1. Visit the https://google.com/ link.

2. Note that you are redirected to a non-secure URL. There is no warning.

3. Note that the SSL/TLS certificate of the google.com site was issued for 'www.google.com', not 'google.com'.
Actual Results:  
No warning was issued.

Expected Results:  
A warning should have been issued. Something like "the certificate does not match the host name of the site you are visiting".

$ openssl s_client -connect google.com:443 | tee /tmp/log.txt
CONNECTED(00000003)
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDITCCAoqgAwIBAgIQL9+89q6RUm0PmqPfQDQ+mjANBgkqhkiG9w0BAQUFADBM
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0wOTEyMTgwMDAwMDBaFw0x
MTEyMTgyMzU5NTlaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRcw
FQYDVQQDFA53d3cuZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA6PmGD5D6htffvXImttdEAoN4c9kCKO+IRTn7EOh8rqk41XXGOOsKFQebg+jN
gtXj9xVoRaELGYW84u+E593y17iYwqG7tcFR39SDAqc9BkJb4SLD3muFXxzW2k6L
05vuuWciKh0R73mkszeK9P4Y/bz5RiNQl/Os/CRGK1w7t0UCAwEAAaOB5zCB5DAM
BgNVHRMBAf8EAjAAMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwudGhhd3Rl
LmNvbS9UaGF3dGVTR0NDQS5jcmwwKAYDVR0lBCEwHwYIKwYBBQUHAwEGCCsGAQUF
BwMCBglghkgBhvhCBAEwcgYIKwYBBQUHAQEEZjBkMCIGCCsGAQUFBzABhhZodHRw
Oi8vb2NzcC50aGF3dGUuY29tMD4GCCsGAQUFBzAChjJodHRwOi8vd3d3LnRoYXd0
ZS5jb20vcmVwb3NpdG9yeS9UaGF3dGVfU0dDX0NBLmNydDANBgkqhkiG9w0BAQUF
AAOBgQCfQ89bxFApsb/isJr/aiEdLRLDLE5a+RLizrmCUi3nHX4adpaQedEkUjh5
u2ONgJd8IyAPkU0Wueru9G2Jysa9zCRo1kNbzipYvzwY4OA8Ys+WAi0oR1A04Se6
z5nRUP8pJcA2NhUzUnC+MY+f6H/nEQyNv4SgQhqAibAxWEEHXw==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
---
No client certificate CA names sent
---
SSL handshake has read 1772 bytes and written 307 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
    Session-ID: 17194BD4BB16C82A18DFE17E13C8BB4CC040BF7ECC96555ADA4235227E31FB5D
    Session-ID-ctx: 
    Master-Key: 51478018BDF34762F1F6B0D9FC8E32BCDCA643A7B7E032E78ABF43A905A4FE2068F1E5B254834BAC984E963431032F73
    Key-Arg   : None
    Start Time: 1277736602
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
HTTP/1.0 302 Found
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Location: http://www.google.com
Content-Length: 218
Date: Mon, 28 Jun 2010 14:50:12 GMT
Server: GFE/2.0

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="http://www.google.com">here</A>.
</BODY></HTML>
> When accessing an https:// link that returns an HTTP direct ...

That should have read "When accessing an https:// link that returns an HTTP redirect ...", sorry about that.
This shouldn't happen, we should verify the cert before trying anything at the HTTP protocol level--it should fail before we get to the redirect. But redirect it does. Whether the redirect target is secure or not is irrelevant, if we haven't established trust in the server we should not trust anything it tells us. Bad guys can run SSL sites with no problem so an HTTPS redirect isn't any safer.

I can confirm that the cert appears to be a non-match using wget ("ERROR: certificate common name 'www.google.com' doesn't match requested host name 'google.com'") and having fetched it in openssl the cert doesn't appear to have Server AltNames.
Status: UNCONFIRMED → NEW
Component: Security → Security: PSM
Ever confirmed: true
Product: Firefox → Core
QA Contact: firefox → psm
blocking2.0: --- → ?
Google is using TLS SNI to give a correct certificate to Firefox.  Old tools (such as curl 7.16.4) show an error, but new tools (such as curl 7.18.2) don't.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Thanks Jesse for your investigation.

This bug report illustrates a common problem for which it would, IMO, be 
very desirable for Firefox to provide a solution.  

Users want to see some detail regarding a redirect.  Perhaps they want to 
see the actual content of the redirect http response, or perhaps they want
to look at the SSL server certificate used for the connection over which 
the redirect was received.  But Firefox gives them no convenient way (AFAIK)
to "single step" through a redirect (or series of redirects) so that they can
exmaine the details at each step.  So, they resort to using other client tools, tools tht fail to faithfully reproduce the exact sequence of events that they experienced with Firefox.  The result is misdiagnosis.  This is fairly common.

So, I'd like to suggest that Firefox have a debugging/diagnostic feature to 
enable users to "single step" through redirection of the main page/frame/framset, offering opportunities to examine certificates in cert manager 
and perhaps other tools (page info, page source) along the way.
Sounds like an excellent idea for an enhancement request to be filed on Necko.  Nelson, can you do that?

Does this bug need to be security-sensitive?
Can you do that with Firebug today, or are changes to Necko needed?
You can prevent a redirect from happening (by making the relevant security check fail).  Firebug could do that.  But there's no way to then make us take the redirect.
This bug has no need to remain hidden, right?
In my opionen, you can disclose it. Sorry for the false alarm.
Group: core-security
blocking2.0: ? → ---
You need to log in before you can comment on or make changes to this bug.