1481838 - No longer allowed to accept bad SSL certificates from trusted sources

Status: RESOLVED WONTFIX

(Core :: Security, defect)

Description

[Andrew N]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170824053622

Steps to reproduce:

Went to site on my company's Intranet
https://blahblah.dev/foo/bar.html



Actual results:

Got a page saying:

Secure Connection Failed
An error occurred during a connection to sys12.wpaz.dev. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.

With an option to "Try Again"


Expected results:

In older version of Firefox (such as v55) the option to accept the bad certificate anyway existed.  I'm on an Intranet, so I absolutely _must_ trust this certificate for my job.

I should be able to trust bad certificates on Intranets, like I used to be able to.

Comment 1

[Hani Yacoub, Desktop QA]

Couldn't reproduce this issue. I will set it to "Security" component, I think it's a good starting point.

Comment 2

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

That error code usually means the server Firefox is talking to isn't actually using TLS (SSL). Have you confirmed that you have the right port number and that the server is using TLS?

Comment 3

[Andrew N]

Unfortunately, though I've asked, I haven't received any technical details, except this:

So the [blahblah.dev] domain doesn’t have SSL enabled, it uses the intra-front interface to reach the [yaddayadda] servers, you can use this domain to reach it which passes through the fake-internet to reach the [yaddayadda] though: http(s)://yaddayadda.dev.



But all of that has nothing to do with the point of this bug report.


The point is that on an Intranet Firefox _USED TO_ tell me the site wasn't secure, but still allow me to "Add Exception".

It no longer does.

It should.

This bug is a request to re-implement that feature.  Perhaps a better error message would be good, like "That server is not using SSL" or "It has no certificate".

Perhaps implement Zoning, so I can say ".dev is an Intranet domain and should be treated as secure, even if not."

Comment 4

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

Oh - I overlooked that you were using a .dev domain. Unfortunately, the long story made short is that you won't be able to add exceptions for .dev domains any more. See https://medium.engineering/use-a-dev-domain-not-anymore-95219778e6fd for much more information, but basically Google owns the .dev tld and has mandated that every .dev site use https without the ability to add overrides. One way you could get around this would be to generate your own root CA, import and trust it in Firefox, and use that CA to issue the certificates you use in your .dev servers. (In general, though, I recommend you stop using .dev)

As for the unhelpful error message when you try to access a site as https but it's speaking http, see bug 445098.

Comment 5

[Andrew N]

Oh crud.

Thanks for the info!  I'll pass this on to the team that maintains our Intranet.

In looking around it seems that there is a way to override this for Internet Explorer (which involves creating a registry key).
See: https://support.microsoft.com/en-us/help/3071338/internet-explorer-11-adds-support-for-http-strict-transport-security-s  

(Oddly enough, we have Windows 7 with IE 11, and the above site works fine there. And I do not have that key in my registry.)

Would it be possible to implement a similar override for this in Firefox with an about:config key?

Comment 6

[Andrew N]

It turns out that the way to override this behaviour in Firefox is to set network.stricttransportsecurity.preloadlist to false in about:config.