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

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 1 Feb 2014 09:49:11 +0100

Thank you for the feedback!

I find it troublesome not to be able to handle TLS fully is browser based applications, to have it hidden by a layer of "you should not know." 

I understand that some of these "hidden" error codes promotes security in the network where the app is running in a browser, but on the other hand there is a need to build applications that are stronger and helps the user verify the security.

The browser (if we have a clear browser, which is not the case with phonegap or embedded javascript) typically shows issues with the main URL (the one shown in the address bar). If there are issues with ajax connections or web sockets, these are typically not shown to the end user and not communicated to the application. This makes it hard to debug, hard to verify if this is a proper TLS connection and hard to build robust and secure applications.

There are a lot of applications built this way out there and hopefully a lot of TLS usage in these in-app connections. We need a framework for handling security properties of these in-app connections over ajax, websockets and soon the new and sexy webRTC data channels.

/O

On 01 Feb 2014, at 01:11, Orit Levin (LCA) <[email-masked]> wrote:

> 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.
>> 
>> 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).
>> _______________________________________________
>> Uta mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/uta
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: Leif Johansson <[email-masked]>
Date: Sat, 01 Feb 2014 13:31:27 +0100

> I find it troublesome not to be able to handle TLS fully is browser based applications, to have it hidden by a layer of "you should not know." 
+1 on that

---

From: Alyssa Rowan <[email-masked]>
Date: Sat, 01 Feb 2014 13:34:02 +0000

On 31/01/2014 11:24, Olle E. Johansson wrote:
> 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.

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

I think it's not treating JavaScript developers like they're stupid,
so much as (correctly) treating them like they're possibly malicious.
This is a defensive, but sensible and correct approach in practice,
given the most common use case by far: running code from random
websites which users visit, many of which are not even protected en
route by TLS, and many of which transclude IFRAMEs from ad networks
and heaven knows where else, too.

The general case of ECMAScript being used in other things is a
different case, but JavaScript is most commonly used in browsers, and
is (in my view!) an interesting choice for other use cases largely
only because of the symmetry of that existing use and the resulting
very high performance intercompiling runtimes.

It seems particularly reasonable that WebSocket in particular was
designed specifically for browsers (it's in the name, after all). The
reasoning given for that decision seems fairly clear and sound to me,
and I agree with it. It's a basic fingerprinting and scanning risk
otherwise: it's not hard to envision a script potentially doing a
quick 192.168.0.* sweep looking for open routers with default
passwords, etc.

I'd be personally a little wary of proposals which change and possibly
weaken that defensive stance, but really, that one's more up to
browser developers, I think.

That's the core problem: it's untrusted code you're running here, and
if you start giving it specific failure codes for security events, an
attacker may be able to use those failure codes as oracles.

This is something the user-agent (as trusted code) is in a better
position to handle, but the script on a website (as untrusted)
definitely shouldn't be trusted with it, in my opinion.

- -- 
/akr

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 1 Feb 2014 15:41:14 +0200

On Fri, Jan 31, 2014 at 12:24:55PM +0100, Olle E. Johansson wrote:
> 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.
> 
> 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?

One can fairly easily probe local network using Websockets for hosts
and services that exist even without detailed errors...

If a host exists at that address or not, what ports are open, and so
on...

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 1 Feb 2014 15:56:19 +0200

> I find it troublesome not to be able to handle TLS fully is browser based applications, to have it hidden by a layer of "you should not know." 

Even possibly going so far as allowing the browser-based app get a
callback if certificate does not chain to known trust root and being
able to approve or disapprove it (with information about the certificate).

Or even being able to disable trust anchoring and trigger that
callback on any certificate chain.

Rationale: If the app connects to backend servers directly, it
might very well know better what to expect than generic browser.

I have written at least one app (not a webapp tho) that knows what
to expect on server end extremely well, even if the connection is
over "open Internet".

Sidenote: Not the first time I have run into "your should not know."
with security. And the previous case I ran into actually weakened
security (and that was on server side).

I think the thinking there was more "nobody can handle such power
correctly." than "knowledge of such thing would allow attacks.".

-Ilari

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Sun, 02 Feb 2014 08:44:57 +0100

>> I find it troublesome not to be able to handle TLS fully is browser based applications, to have it hidden by a layer of "you should not know." 
+1 but that's probably an issue to be posted to w3c's related working group.

That "inflexibility" is probably also the core reason behind the
existance of Forge, an independent Javascript's TLS stack
https://github.com/digitalbazaar/forge .

-- 
Fabio Pietrosanti (naif)
HERMES - Center for Transparency and Digital Human Rights
http://logioshermes.org - http://globaleaks.org - http://tor2web.org

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 02 Feb 2014 14:37:01 +0200

Hi Alyssa,

Yes, there's a trade-off here but I agree with Olle that there's a lot 
of value in exposing TLS behavior and errors to the app layer. Besides, 
malicious apps can use timing information as a (less informative) 
oracle, e.g. to distinguish between a non-existent host, a failed TCP 
and connection a failed TLS handshake.

And it is more than just errors. Some things I would like to see in the 
interface are:

- Errors, including TLS alerts.
- The ability to know what identity the server is claiming, so as to 
make policy decisions.
- The ability to control TLS policy, such as what protocol version is 
being negotiated (so that the app can avoid SSLv3 even if the browser is 
misconfigured).
- An app should be able to extract channel binding data from TLS, to 
facilitate crypto-binding of the app messages with the transport channel.
- Control of credentials being used for client authentication: client 
certs, symmetric keys used with TLS-PSK, passwords used with TLS-SRP and 
similar. For symmetric keys and passwords, credentials should be pulled 
from a browser-specific "password manager", so the app should never see 
them.

Thanks,
	Yaron

On 02/01/2014 03:34 PM, Alyssa Rowan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> [...]

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Mon, 3 Feb 2014 20:00:48 +0000

My interpretation of this case is that there is a major difference today in "treating" native vs. Javascript application developers due to the existing web security model, with websockets and webrtc leading the pressure for change.

This could have been a topical paper for STRINT (where IETF and W3C experts will meet), unless it is already there.

If not, I don't see any harm of writing and submitting a draft (to UTA) with specific suggestions for changes in the error codes being delivered (through APIs) to web applications using TLS. Time permitting, we may have the right people in and/or outside the room to bounce ideas off each other. Most helpful would be to have a list of allowed codes with justification for each  including an explanation for why it wouldn't lead to additional vulnerabilities already existing using other "techniques".

Orit.

> From: Uta [mailto:[email-masked]] On Behalf Of Yaron Sheffer
> Sent: Sunday, February 02, 2014 4:37 AM
> To: Alyssa Rowan; [email-masked]
> Subject: Re: [Uta] Treating Javascript developers like they are stupid.
> 
> Hi Alyssa,
>