Subject: [Uta] Treating Javascript developers like they are stupid.

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 31 Jan 2014 12:24:55 +0100

Hi!

Caused by a discussion about web sockets I've looked into Javascript a bit. In the web sockets specification they state clearly that ALL errors - dns, network errors, TLS - is just a connection error. The developer should not know, and it is stated a security risk if he gets the information about why a connection failed. It's all up to the browser.

From other sources I've heard that this attitude is pretty strong in Javascript standardization.

I am no Javascript developer - but from googling I can not find an API to check which certificate is used, data from that certificate or crypto methods. Or in the case of failure of TLS - was it because of bad certificate, expired certificate or something else?

In my view this leads to less robust applications. And potentially less secure. There's a lot of connections being opened in Javascript today and all the application can say to the end user is "Oops, something bad happened".

I am not very happy about this. Javascript is used embedded in applications, servers. In classical browsers as well as in mobile apps (phonegap, cordova). A lot of applications are built using these tools.

Anyone else that have more experience of Javascript - is this correct? Where does this attitude come from? Do we want to change it? Can we change it? Are they correct that allowing this help attacking your network?

Questions, questions, questions :-)

/O

From the specification at http://dev.w3.org/html5/websockets/:
========================

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.

In particular, this means the code 1015 is not used by the user agent (unless the server erroneously uses it in its close frame, of course).

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Sat, 1 Feb 2014 00:11:38 +0000

Olle,

That's what I found using the new wonderful IETF archive tool:
https://mailarchive.ietf.org/arch/msg/hybi/KEvFcno-vm-6jx0l9G3rXQ8DQFQ%3D/

" There is one aspect: somewhere/someone brought up that the error reason MUST NOT disclose unwanted info (to a potentially evil script): e.g. HS failed because TLS cert invalid. Otherwise scripts could probe around in intranets etc. It is however a pain (this TLS fail in particular): browser won't render a dialog (since WS is a subresource) and WS error won't disclose TLS error also. So a good script has no chance of giving the user useful feedback .. like check site cert, import some cert or such."

But no further discussion that I could see... W3C (including its archives) could a good resource for this case... 
Orit.

> -----Original Message-----
> From: Uta [mailto:[email-masked]] On Behalf Of Olle E. Johansson
> Sent: Friday, January 31, 2014 3:25 AM
> To: [email-masked]
> Cc: Olle E Johansson
> Subject: [Uta] Treating Javascript developers like they are stupid.
> 
> Hi!
> 
> Caused by a discussion about web sockets I've looked into Javascript a bit. In the
> web sockets specification they state clearly that ALL errors - dns, network
> errors, TLS - is just a connection error. The developer should not know, and it is
> stated a security risk if he gets the information about why a connection failed.
> It's all up to the browser.
> 
> I am no Javascript developer - but from googling I can not find an API to check
> which certificate is used, data from that certificate or crypto methods. Or in the
> case of failure of TLS - was it because of bad certificate, expired certificate or
> something else?
> 
> In my view this leads to less robust applications. And potentially less secure.
> There's a lot of connections being opened in Javascript today and all the
> application can say to the end user is "Oops, something bad happened".
> 
> I am not very happy about this. Javascript is used embedded in applications,
> servers. In classical browsers as well as in mobile apps (phonegap, cordova). A
> lot of applications are built using these tools.
> 
> Anyone else that have more experience of Javascript - is this correct? Where
> does this attitude come from? Do we want to change it? Can we change it? Are
> they correct that allowing this help attacking your network?
> 
> 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.
> 
> In particular, this means the code 1015 is not used by the user agent (unless the
> server erroneously uses it in its close frame, of course).
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta