User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:220.127.116.11) Gecko/20100623 Iceweasel/3.5.10 (like Firefox/3.5.10) Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:18.104.22.168) 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.
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.
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.