W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > March 2017

Re: [webrtc-pc] DTLS failures

From: Bernard Aboba via GitHub <sysbot+gh@w3.org>
Date: Fri, 24 Mar 2017 22:29:38 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-289158268-1490394576-sysbot+gh@w3.org>
Now that browser DTLS implementations are moving to DTLS 1.2 with ECSDA support (and soon, 1.3), backward compatibility issues can arise with applications based on older code that only supports DTLS 1.0 and RSA certificates.  For example,  if an application running on a browser that defaults only to ECDSA certificates does not use the certificate management API to create an RSA certificate, it will fail to interoperate with a mobile application based on an older implementation that only supports RSA certificates.  So if the application can determine that this is what went wrong it could figure out what went wrong. 

I do not think that crypto capabilities or version mismatch negotiation failures would necessarily run afoul of the warning in the Websockets API spec, but fingerprint match failure might.  Here is the prohibition from that spec (https://html.spec.whatwg.org/multipage/comms.html#feedback-from-the-protocol):

User agents must not convey any failure information to scripts in a way that would allow a script to distinguish the following situations:

A server whose host name could not be resolved.
A server to which packets could not successfully be routed.
A server that refused the connection on the specified port.
A server that failed to correctly perform a TLS handshake (e.g., the server certificate can't be verified).
A server that did not complete the opening handshake (e.g. because it was not a WebSocket server).
A WebSocket server that sent a correct opening handshake, but that specified options that caused the client to drop the connection (e.g. the server specified a subprotocol that the client did not offer).
A WebSocket server that abruptly closed the connection after successfully completing the opening handshake.
In all of these cases, the the WebSocket connection close code would be 1006, as required by the WebSocket Protocol specification. [WSP]

Allowing a script to distinguish these cases would allow a script to probe the user's local network in preparation for an attack.

-- 
GitHub Notification of comment by aboba
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1092#issuecomment-289158268 using your GitHub account
Received on Friday, 24 March 2017 22:29:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 9 October 2019 15:14:52 UTC