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

Thanks for your mail Andrew,

Before going into your issue on dealing with self-signed/invalid  SSL/TLS certificates I would like to give a short status update on the TCP and UDP Socket API.

The last months all updates in the API have been related to basing the API on the general Streams API, https://github.com/whatwg/streams. The adaptation process could be followed in https://github.com/whatwg/streams/issues/64. So far the TCP and UDP interfaces have been adapted to Streams but TCP server is still to be done. The latest version of the TCP and UDP Socket API is here: http://www.w3.org/2012/sysapps/tcp-udp-sockets/.

This means that I have not worked on support for secure sockets for quite a while. However, your mail is a good trigger for getting the ball rolling on this again. I have quickly read through the discussions in the links you provide but it is a lot and I will need to read it once again more carefully. 

I need to consider the issues you address more but a general comment is that dealing with self-signed/invalid SSL/TLS certificates is not an issue for the TCP and UDP Socket API only. For example you mention your non-standard mozSystem XHR. This may be an argument for your proposed solution 2). It seems as a solution, including a user interface, for adding certificate exceptions is a bit out of scope for the TCP and UDP Socket API and would fit better in separate API.

I am sorry for not being able to give you more elaborate feedback today but as I said above my focus currently is the adaption of the API to Streams and I would like to avoid any other additions to the API until this big rewrite has been done.

Best regards
  Claes


Claes Nilsson
Master Engineer - Web Research
Advanced Application Lab, Technology

Sony Mobile Communications
Tel: +46 70 55 66 878
claes1.nilsson@sonymobile.com

sonymobile.com



> -----Original Message-----
> From: Andrew Sutherland [mailto:asutherland@asutherland.org]
> Sent: den 30 maj 2014 05:01
> To: public-sysapps@w3.org
> Subject: 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 13:02:25 UTC