tcp-udp-sockets: general API approach for dealing with with self-signed/invalid SSL/TLS certificates?

The Firefox OS email app, the driving use-case for Mozilla/Gecko's 
MozTCPSocket implementation, has reached the point where we are 
compelled to be able to establish TCP (and XHR) connections with servers 
with self-signed or otherwise invalid certificates.  Our bug on this is 
at https://bugzil.la/874346 and current related discussion at 
https://groups.google.com/forum/#!topic/mozilla.dev.platform/lT4Mhi-B1JI. The 
most appropriate issue for the tcp-udp-sockets effort is 
https://github.com/sysapps/tcp-udp-sockets/issues/10 but since there's a 
question of API structure it's worth raising this problem on the list 
initially.

I see three obvious styles of addressing this problem:

1) Make TCPSocket capable of addressing this entirely from within its 
API surface.  By default secure connections obey standard browser rules 
for validating certificates.  In the event of a certificate problem an 
error is returned and sufficient details about the certificate provided 
in order to be able to authorize a connection using the otherwise 
invalid certificate.  A nice-to-have is to expose the authorized domain 
names for the certificate to allow the application to realize it could 
try a domain variation to make things okay (after consulting the 
user/safe logic to allow the redirect.)

We then enhance the API so that all secure-connection requests can 
optionally provide a list of certificates that should be allowed despite 
the lack of chained trust from the root.  Super-fancy options include 
allowing TCPSocket to perform certificate pinning by requiring the 
certificate to be one of those provided and ignoring the default browser 
trust roots.

2) Primarily address this in a different Web API designed to add 
certificate exceptions.  TCPSocket would still have to generate 
sufficiently detailed errors so that the exception could be added. 
Specifically, for protocols with startTLS modes of operation the 
exception-adding API would need to either be given the certificate/its 
fingerprint, would need to know how to talk IMAP/POP3/SMTP/etc., or 
would need to be able to be given an already-open stream/TCPSocket at 
the appropriate time.

3) Don't deal with it in the API.
3a) Require the browser/system to show some kind of prompt to ask the 
user if they want to add the exception.  Especially since we treat the 
TCPSocket API as privileged and the app sufficiently trusted, this seems 
horrible since it seems like it would rob the app of its opportunity to 
provide context for the errors and deal with the situation where it's 
clear the user does *not* want to add the exception.
3b) Use some other mechanism to trigger some other browser/system UI to 
deal with the problem.  For example, tell the user where to go in their 
browser preferences/etc.  I don't think this really works with the 
startTLS scenarios.

It's important to note that the Firefox OS email app would ideally want 
whatever solution ends up implemented for TCPSocket to be also be 
implemented for Mozilla/Gecko's non-standard mozSystem XHR property 
(https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest#Non-standard_properties) 
or some other property because we also support ActiveSync-over-HTTPS and 
ActiveSync servers seem even more likely to need exceptions. (Noting 
that Firefox OS already implements adding an exception via click-through 
in a similar fashion to Firefox Desktop, so there are also other 
workarounds available to us at the expense of a degraded UX flow.)

Thanks,
Andrew

Received on Friday, 30 May 2014 03:01:05 UTC