1350125 - Consider support for extending isSecureContext=false

Status: RESOLVED WONTFIX

(Core :: DOM: Security, enhancement, P3)

Description

[Jonathan Kingston [:jkt] he/him]

Currently Firefox implements isSecureContext based upon the specification https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy

However there might be cases where we would like to tighten to more threats like the one mentioned in Bug 1349897.

So the proposed changes are:
1. Treat Bug 1310447 as an indicator for isSecureContext
2. For new cases that we decide deserve the broken padlock, we treat as isSecureContext=false
3. Request a specification change to permit User Agents to decide when to increase the scope of when isSecureContext=false ()

1. Would make all currently insecure contexts as having a broken padlock.
The stretch goal of making all mixed content have a broken padlock as a different preference as being isSecureContext=false might be way too far though. (being that there isn't an obvious exploit for passive mixed content causing issues with  'Powerful Features')

- I am also not sure regarding this change if any case of isSecureContext=true should ever have a broken padlock so the stretch of mixed content I think should either break isSecureContext or we don't do it at all (especially as we are a very long way off setting that as a default anyway).

3. There is some allowance in the specification for localhost but not anything the user agent provides. There is a risk of User Agents then have the control to ban whatever they like. Perhaps the specification could allow some easy way to amend the spec without it being outside of process

Comment 1

[Jonathan Kingston [:jkt] he/him]

Dan,

I know we discussed this on IRC and your view is that we could tighten the specification to allow us to set isSecureContext=false based upon if the cert is self-signed.

The breakage would be for geolocation or service workers for self signed certificates and any other features we deprecate with isSecureContext=false.

- Should we get telemetry before setting this?
- This could make development harder perhaps?
  - Would we exempt certain domains?
  - Also turn this off with a pref?
- Would we need to file an intent to remove?
- Would we file a spec change to WebAppSec before or after removal?
- Will this advocate the usage of adding CA's to the trust store?

Thanks

Comment 2

[Darkspirit]

If I would generate an own CA, sign a certificate and import the CA into Firefox, I wouldn't be affected of this, right?

Could a self-signed certificate has Name Contraints https://tools.ietf.org/html/rfc5280#section-4.2.1.10 + https://wiki.mozilla.org/CA:NameConstraints (bind a CA to specific Domain Names) and get imported by the user as regular CA?

I would say the use of an already imported self-signed cert is "not a secure context" if its beyond the validity period (+maybe if one greater than x years), hasn't a matching SAN (DNS and/or IP), not a SHA2 signature and has not RSA 2048 bits or ECDSA P-256 as minimum.

And I would say everything matching this is a "not secure context":
- TLS 1.0 + 1.1 
- non-PFS ciphers 
- SHA1 cert signature 
- SHA1 ciphers
- invalid OCSP Stapling
- unencrypted connection (http, ftp, ws)
- (and later: invalid DNSSEC/DANE stapling bug 672600)
- already imported self signed cert is out of date, hasn't a matching SAN, no SHA2 signature, RSA is below 2048 bits
- a site loading a resource from an origin which has one of the problems mentioned before
You can then surf on such a website with a mixed content icon or crossed padlock and haven't all the nice features.
Related: https://bugzilla.mozilla.org/show_bug.cgi?id=1325171#c6

Comment 3

[Daniel Veditz [:dveditz]]

(In reply to Jonathan Kingston [:jkt] from comment #1)
> I know we discussed this on IRC and your view is that we could tighten the
> specification to allow us to set isSecureContext=false based upon if the
> cert is self-signed.

I don't think I would have ever said that. If a user knows what they are doing accepting a self-signed cert can be perfectly secure. That's why we default to permanent overrides, because we turn it into a Trust On First Use model (like SSH) to avoid users becoming habituated to doing the override on each visit and not noticing the one time the cert is actually different due to an attack.

If the user has told Firefox "This certificate is secure for this site" then we should treat it as secure. If we have a problem with that we should make adding an exception harder (more "I know what I'm doing" hoops) not treat it as insecure.

I would be happy to consider an alternate "user-trusted" icon to replace the lock, which we could also use in the user-installed MITM root case. But isSecureContext should still be true and the icon should be informative, not negative if we can come up with something. Not a broken lock, something different entirely. Chrome seems to be switching to words ("Secure", "Not Secure") so maybe just go with words: "User Trusted".

> - Should we get telemetry before setting this?

ABSOLUTELY! We probably want this telemetry anyway. In fact maybe we have it? Seems like something rbarnes and dkeeler would have wanted to gather before. If possible we should distinguish the MITM-root case from the override case.

> - This could make development harder perhaps?
>   - Would we exempt certain domains?

I don't think we should do it, so no :-). the user override _is_ the exemption.

>   - Also turn this off with a pref?

yes, potentially breaking changes would have to be shipped with a pref.

> - Would we need to file an intent to remove?

yes, if we did this (I don't think we should).

> - Would we file a spec change to WebAppSec before or after removal?

Before, and it should be discussed before filing a spec change.

> - Will this advocate the usage of adding CA's to the trust store?

I don't understand this question.

Comment 4

[Daniel Veditz [:dveditz]]

In fact we do have telemetry:

https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2017-03-22&keys=__none__!__none__!__none__&max_channel_version=beta%252F53&measure=SSL_CERT_ERROR_OVERRIDES&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-03-07&table=0&trim=1&use_submission_date=0

and also SSL_CERT_VERIFICATION_ERRORS

26% of our beta users have at least one permanent cert override: SSL_PERMANENT_CERT_ERROR_OVERRIDES. You're talking about potentially breaking a lot of users.

Comment 5

[Jonathan Kingston [:jkt] he/him]

Thank you Dan for the feedback and the follow up!

Perhaps the stats suggest that we should be considering the "user-trusted" icon, which would let them be aware of their cert choice. It may be interesting to get stats on if the handshake was previously overriden to decide how often the user doesn't need the TOFU.

Thanks for the input on extending isSecureContext also, I have a feeling we might consider doing this for other decisions like low quality certs etc. (I have a hunch we might already doing this however I will reread the code)

I'm going to close this as I think you have answered the question on how we can approach increasing the security of isSecureContext. As mentioned we shouldn't do this in this case, besides consider a user-trusted padlock or something similar I will address this in Bug 1349897.

Comment 6

[Jonathan Kingston [:jkt] he/him]

Sorry looking at the stats again, I believe we have the stats I was talking about:

> It may be interesting to get stats on if the handshake was previously overriden to decide how often the user doesn't need the TOFU

~0.49% have accepted previously or this time and ~25% have 1 or more cert in their store.

I'm not sure if capturing the number of clicks on accepting the error would give us anything else. Perhaps time since accepting the cert exception might help gauge if users have forgotten about it.