500299 - Incorrectly shows EV green bar even for CNAME != CN mismatch

Status: RESOLVED WORKSFORME

(Firefox :: Security, defect)

Description

[Chris Palmer]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.11) Gecko/2009060309 Ubuntu/9.04 (jaunty) Firefox/3.0.11
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.11) Gecko/2009060309 Ubuntu/9.04 (jaunty) Firefox/3.0.11

When I browse to by IP address to a server that has a legitimate EV cert, but the cert is issued to "www.isecpartners.com", Firefox shows me the green EV bar. I believe that instead it should warn me that the CN does not match what's in the URL. 

However, this only happens when I get 302'd to the https:// URL from the http:// URL. (Our server is configured to bounce people to HTTPS if they visit by HTTP.) When I browse directly to https://10.13.40.21, I do not get the green EV bar (but I don't get a warning either).

Reproducible: Always

Steps to Reproduce:
1. Browse by HTTP to a site that bounces you to HTTPS with an EV cert, but browse to it by IP instead of by name.

Actual Results:  
I get the green EV bar.

Expected Results:  
Firefox warns me when I go to https://isecpartners.com, since our cert is signed for "www.isecpartners.com". I think Firefox should give me the same warning in this case.

https://labs.isecpartners.com/chris/ev-wrong-cname-01.png

https://labs.isecpartners.com/chris/ev-wrong-cname-02.png

Comment 1

[Daniel Veditz [:dveditz]]

http://10.13.40.21 did nothing for me (rfc1918 private address)

http://66.237.62.198/ loaded your site but did not bounce me to https.
ditto http://isecpartners.com and http://www.isecpartners.com load without redirecting to SSL.

https://66.237.62.198/ failed with a cert mismatch error, as does https://isecpartners.com

https://www.isecpartners.com shows me the EV treatment.

You said you don't get an error for https://10.13.40.21 -- is it possible you've added a cert-mismatch override exception for that address? In the Advanced prefs click the "View Certificates" button on the Encryption tab, and then check the "Servers" list for exceptions.

However, even guessing that you added an exception doesn't explain anything. I added an exception for our own https://63.245.209.91 and then when I bounce from http://63.245.209.91 over to https I see the addons.mozilla.org site but not the green/EV treatment. We use a 301 and you said a 302 redirect, but could that really be treated differently?

... tried paypal, but they redirect to https://www.paypal.com explicitly, so can't test.

==> getting https://IP-address loaded AT ALL without having specified an exception is a HUGE bug -- death of SSL, film at 11. I'm confident you specified an exception at some point. Check your saved exceptions, or retest in a new profile.

==> I see the green in your screenshot, but I can't reproduce. Kaie: do you have a test server/cert that does a 302 redirect rather than a 301? Would it make a difference in the code?

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Even if the reporter has set an exception, he should not get EV treatment 
for a cert that uses an exception.

Comment 3

[Chris Palmer]

I do have an exception for that site, but as Nelson says, I think I should not get the EV treatment even so, due to the CNAME != CN mismatch.

Also, to test this, you have to have a server set up to redirect all HTTP requests to URL u to https://$u. So testing it is a little tricky.

http://66.237.62.198/ is hosted on a server that does not yet have the configuration -- http://10.13.40.21 is our internal test URL for the staging server.

Comment 4

[Daniel Veditz [:dveditz]]

Could you try the same thing with  http://63.245.209.91 (and set an exception for that). Do you also see EV behavior for that redirect? I don't.

Comment 5

[Daniel Veditz [:dveditz]]

We all agree that a site reached through an exception should not get EV treatment. The question is why are you seeing this and we aren't?