On 5/28/2014 5:30 PM, Andrew Sutherland wrote:
tl;dr: We need to figure out how to safely allow for invalid
certificates to be used in the Firefox OS Gaia email app. We do want
all users to be able to access their email, but not by compromising
the security of all users. Read on if you work in the security field
/ care about certificates / invalid certificates.
Certificate verification failures, I think, can happen for one of the
following reasons, sorted by rough order that I expect they happen:
* Untrusted CA/self-signed certificate
* Domain name mismatch (e.g., a certificate for foobar.mozilla.org is
used on site foobar.allizom.org)
* Expired certificate
* Insufficiently secure certificate (e.g., certificates that violate
CA/Browser Forum rules or the like. I don't know if we actually consider
this a failure right now, but it's a reasonable distinct failure class IMHO)
* Explicitly revoked
* Malformed certificate
It seems to me that some of these are more tolerable than others. There
is a much different risk profile to accepting a certificate that expired
two days ago versus one that fails an OCSP validation check.
* the exception is per-domain, not per-port, so if we add an exception
for port 993 (imaps), that would also impact https.
It's per-host:port. I recently had to add a cert override for an NNTPS
server by hand.
In bug https://bugzil.la/874346 the requirement that is coming from
partners is that:
- we need to imminently address the certificate exception problem
- the user needs to be able to add the exception from the account
setup flow. (As opposed to requiring the user to manually go to the
settings app and add an exception. At least I think that's the request.)
I know you and I discussed this in another context not too long ago, and
the common consensus we had agreed then was that doing a non-automatic
manual labor to set up the exception was ideal. Requiring it from the
account setup flow is... slightly disconcerting to me.
== Proposed solution for informed, safe decision-making
This is a problem I've been thinking about in a slightly different
situation (specifically, for S/MIME certificates). Unfortunately, my
blog post containing these thoughts is still in the process of being
written, so I can't refer you to that post yet.
We have an excellent chance to try to rethink CA infrastructure in this
process beyond the notion of a trusted third-party CA system (which is
already more or less broken, but that's beside the point). My own views
on this matter is that the most effective notion of trust is some sort
of key pinning: using a different key is a better indicator of an attack
than having a valid certificate; under this model the CA system is
largely information about how to trust a key you've never seen before.
There is a minor gloss point here in that there are legitimate reasons
to need to re-key servers (e.g., Heartbleed or the Debian OpenSSL
entropy issue), and I don't personally have the security experience to
be able to suggest a solution here.
I'm not necessarily asking that we immediately find the best solution
right now (particularly given partners' demands for immediacy), but
rather that we think about a solution that can eventually be proposed
for standardization in appropriate standards bodies, and also that we
design a solution that ought to require mostly "technical" fixes as
opposed to architectural redesigns. I know the IETF is currently working
on an extension for key pinning in HTTP that may be relevant here:
<https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/>.
Another relevant fact for the design future is the eventual introduction
of DANE and DNSSEC, which allows the DNS records to indicate the
intended keys of TLS connections. That's not feasible for the near
future, though, especially as I don't think Mozilla has even started
implementing DANE.
I propose that we use a certificate-observatory-style mechanism to
corroborate any invalid certificates by attempting the connection from
1 or more trusted servers whose identity can be authenticated using
the existing CA infrastructure.
Doesn't the EFF's SSL Observatory already track the SSL certificates to
indicate potential MITMs?
For example, if the email app contacts sketchy.example.com and finds
the certificate does not validate, I propose that:
* TCPSocket/XHR with mozSystem return information on the
certificate/chain that we received.
I think that, in any case, the exact reason for certificate errors [in
terms of the taxonomy I described above] should be returned if
validation fails.
[ I should also point out that I'm planning on asking the WebCrypto
working group about standardizing some certificate stuff--particularly
validation--for S/MIME, since I really, really, really don't want to try
write an OCSP verifier in JS. The discussion of how to identify
certificate details may be relevant for that effort as well. ]
* We contact the trusted server, for example,
certchecker.mozilla.org. We tell it the domain we tried to contact,
the IP, the port, the protocol, initial-TLS versus startTLS, and the
certificate we got back.
Only over TLS, of course. And if that fails, the user has to execute
$NOT_A_MERE_CLICKTHROUGH steps to fix it.
* The trusted server attempts to initiate the same connection.
Would it be feasible to ask of partners that they register at least the
fingerprints of their certificates with the trusted server? Then we
could require that the connection's certificate use the same fingerprint
as it has on record, which ought to improve security in the face of
MITMs, excepting issues with firewall MITMs which are really entirely
separate classes of attacks. On the other hand, it would require care in
figuring out how to handle migration of public keys cleanly.
I'd like to imagine that, when DANE support becomes available, we could
assume an untrusted or self-signed certificate is valid if it passes
DNSSEC on the DANE entries.
Alternatively, we could not require pre-registration of fingerprints if
it's already published via DANE. While a do-it-now setup would still
require a trusted server to do the DANE lookups, it would allow for an
eventual retiring of the trusted server middleman and Single Point of
Failure and help prod people to roll out DANE. And maybe even make DANE
more of a priority in Mozilla's codebase? :-)
== Proposed solution for exceptions / allowing connections
There are a variety of options here, but I think one stands above the
others. I propose that we make TCPSocket and XHR with mozSystem take
a dictionary that characterizes one or more certificates that should
be accepted as valid regardless of CA validation state. Ideally we
could allow pinning via this mechanism (by forbidding all certificates
but those listed), but that is not essential for this use-case. Just
a nice side-effect that could help provide tighter security guarantees
for those who want it.
[ Similar concerns potentially exist for S/MIME, which is mostly the
angle I've thought about this previously. ]
I've preferred to think of the ideal solution as an introduction of a
pinning mechanism, but this needs to take into account revocation and
key upgrades (both gradual, crypto keys-are-now-crackable upgrades and
Heartbleed-level "emergency" key upgrades). I'd propose that your
modifications to TCPSocket et al not have the pinned certificates
override certificates that fail a revocation check.
* Any solution that requires the user to manually verify a fingerprint
for security seems guaranteed to not provide any security.
An unusable secure solution ought to be considered an oxymoron:
usability and security are not orthogonal concepts.
== Other options?
I'm not sure where the best place to put these comments are, so here
they go:
1. Any solution should try to only permit the "easy" certificate
override on account configuration. This minimizes scope for potential
MITM attacks.
2. Any solution should also recognize that re-keying of servers is going
to need to happen at some point. I don't know if this point will be
before a "better" long-term solution can be put in place or not.
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
