1397696 - Local development website can't be accessed over SSL

Status: RESOLVED WORKSFORME

(Core :: Security: PSM, defect)

Description

[peter.row]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36 Edge/15.15063

Steps to reproduce:

1) On Windows 10 Ent 64bit using FF 55.0.3 64bit, in the hosts file in the windows folder I set a domain to use for my local dev site that points to 127.0.0.1, e.g. www.mysite.com  127.0.0.1
2) My web app is hosted on my local IIS web server, and is configured with a self-signed SSL cert.



Actual results:

1) I browse in FF to the site over HTTPS, e.g. https://www.mysite.com and it refuses to go to the site giving insecure cert reasons with no way to override it displayed on the page.
2) I go to Options >> Advanced >> Certificates >> View certificates. I then switch to the Servers tab. I click [Add exception], I enter the HTTPS URL in location field and click [Get Certificate]. After a brief moment it then says "Valid Certificate. This site provides valid, verified identification. There is no need to add an exception."


Expected results:

It either should have gone to my local site OR let me add an exception for it.
When browsing to the site it says the certificate is not valid but then when I try to add exception it says it's valid and I can't add an exception - something is broken

Comment 1

[Dana Keeler (she/her) [:keeler]]

Does your site appear in the file "SiteSecuritServiceState.txt" in your profile directory? You'll probably need to clear HSTS before you can use a self-signed certificate for your site that way (History -> Clear Recent History -> Site Preferences).

Comment 2

[peter.row]

I used the clear history option found in History -> Clear Recent History -> Site Preferences.
The site is still not accessible for the same reasons. I then checked the "SiteSecurityServiceState.txt" file and it was empty.
I tried restarting FF and then trying the site again, same result and the txt file is still empty.

Further investigation:
- When attempting to add the exception as indicated originally, if I click the View button to see the cert details the common name is <machinename>.<windows domain name>, even though I created a self-cert with the name of the URL I used, e.g. www.mysite.com.

- Given previous point I changed my local site to use another self-cert that was named after the machine. This time when I go to add the exception, this time it correctly says the cert is not valid because it's for a different site. It allows me to add it as an exception. HOWEVER - after clearing all site preferences (using option you indicated), restarting FF, trying again FF still refuse to go to the site, giving the same "secure connection failed" with the same reasons and gives no option to continue.

- After the above 2 points in cert manager >> servers >> grouped under <machinename>.<windows domain> are several entries: <machinename>, localhost (with an expiry date in past), <machinename>.<windows domain name> (with an expiry date in past), wwww.mylocalsiteFromHostsFile1.com, www.MyNewLocalSiteFromHostsThatIAmTryingToGetToWork.com

Given that I have now managed to add an exception it still seems like it's broken, it should let me through to the site but it doesn't.

Comment 3

[Dana Keeler (she/her) [:keeler]]

I think clearing site preferences might also clear certificate exceptions, so I wouldn't do that after you've added an exception. Can you post a screenshot of the initial error page you see when you try to visit your development site? (with the "advanced" section expanded)

Comment 4

[peter.row]

Attachment: Showing the page you get when attempting to visit my local dev site

Comment 5

[peter.row]

I double checked and clearing site preferences does not clear certificate exceptions.
Attached screenshot of the page on initial attempt to access local dev site. There is no advanced section to expand as you will see.

If I click the icon in the address part to view cert details is says "Connection is not secure", click arrow to see "Your connection to this site is not private. Information you submit could be viewed by others (like passwords, messages, credit cards etc.)", if I then click view information I get a dialog with the following info:

Web site Identity:
    Web site:     <dev URL>
    Owner:        This web site does not supply ownership information.
    Verified by:  Not specified

Technical details:
    Connection Not Encrypted

    The web site <dev URL> does not support encryption for the page you are viewing.
    Information sent over the internet without encryption can be seen by other people while it is in
    transit.

Comment 6

[Dana Keeler (she/her) [:keeler]]

Oh - this means this probably has nothing to do with certificates and the connection is being terminated before Firefox even gets to that point. Does the site work with other browsers? In any case, you could try setting security.tls.version.max to 3. If that doesn't work, you might capture a handshake with wireshark and attach it here. Basically, it looks like your development server and Firefox can't negotiate a TLS session so the server just closes the connection.

Comment 7

[peter.row]

The site works in all the browsers I tried (IE11, Edge 14.15063.0.0, Chrome 61.0.3163.79 - all 64bit versions), all of them complain about the security of the site but all also let me click a link on that page that reveals another link to continue anyway.

security.tls.version.max was already set to 3.

Given that all the other browsers I tried (even IE11) could negotiate with the server I don't see how it could be the server. For further information I'm using full IIS on my local machine not IIS Express.

Comment 8

[peter.row]

Another piece of information that may help; previously my dev site use to work on FF when I had IIS configured such that I could access via https://localhost/<virtual dir (in my case project name)/, e.g. https://localhost/someproject.

Therefore perhaps somehow FF is by-pass Windows hosts file usage somehow, whereas all other browser respect it?

Comment 9

[Dana Keeler (she/her) [:keeler]]

(In reply to peter.row from comment #7)
> Given that all the other browsers I tried (even IE11) could negotiate with
> the server I don't see how it could be the server. For further information
> I'm using full IIS on my local machine not IIS Express.

Perhaps Firefox is using a TLS feature that other browsers aren't that is causing problems. That's why it would be helpful to have a packet trace I could look at.

(In reply to peter.row from comment #8)
> Therefore perhaps somehow FF is by-pass Windows hosts file usage somehow,
> whereas all other browser respect it?

I don't think Firefox would do this by default, but I'm not sure. Again, wireshark could tell you.

Comment 10

[peter.row]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #9)
> (In reply to peter.row from comment #7)
> > Given that all the other browsers I tried (even IE11) could negotiate with
> > the server I don't see how it could be the server. For further information
> > I'm using full IIS on my local machine not IIS Express.
> 
> Perhaps Firefox is using a TLS feature that other browsers aren't that is
> causing problems. That's why it would be helpful to have a packet trace I
> could look at.
> 
> (In reply to peter.row from comment #8)
> > Therefore perhaps somehow FF is by-pass Windows hosts file usage somehow,
> > whereas all other browser respect it?
> 
> I don't think Firefox would do this by default, but I'm not sure. Again,
> wireshark could tell you.

I starting looking in the FF settings for TLS options when I got to the "Security" section of options. In here there's a part headed "General" under which is an option "Warn you when sites try to install add-ons" - which was ticked - next to this is an [Exceptions] button. For some weird reason I thought to myself I wonder if I put my dev site URL in there will that have an effect. Holy bugs Batman it worked. Despite this being an exception for a site installing an add-on my site is now magically accessible despite FF previously saying effectively "nope, not secure, not gonna let you access it no matter what you do"

In my eyes this new discovery is definitely a bug because the UI indicates this is an exception for sites that I won't get warnings about when they install add-ons, in my case all I'm doing is visiting the site.

This is all kinds of messed up. I only use FF for testing, things like this put me off using it for browsing.

I don't have time to spend investigating why FF is broken right now, so I'll just exploit this flaw for now to carry on. If Mozilla fixes it then great if not then as long as the flaw keeps working.

Comment 11

[peter.row]

It's not resolved, there is still a bug. Exploiting a different bug to workaround another bug is not good.