W3C home > Mailing lists > Public > public-sysapps@w3.org > May 2014

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

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Fri, 30 May 2014 09:33:26 +0200
Message-ID: <53883446.2040705@gmail.com>
To: Andrew Sutherland <asutherland@asutherland.org>, "public-sysapps@w3.org" <public-sysapps@w3.org>
Another option is regarding e-mail as a specific per-installed application
not needing a standardized web API.

This is similar to the ARM/GP folks' take on payments which mandates such
applications to be written in C.


On 2014-05-30 05:00, Andrew Sutherland wrote:
> 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 07:33:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:20 UTC