Re: [TLS] Request for review: Next Protocol Negotiation Extension

[Adam Barth <[e-mail]>]

On Tue, Aug 17, 2010 at 4:30 PM, Michael D'Errico <[e-mail]> wrote:
> Last night at about midnight I awoke with a revelation
> that this whole WebSockets protocol could be a hoax.

I assume you that WebSockets is not a hoax.

Your opinion appears to be based on an older version of the protocol.
Many of your complaints below have been addressed in more recent
versions of the protocol.  If you're interested in this work, I
encourage you to participate in the HyBi working group.

On Tue, Aug 17, 2010 at 5:14 PM, Marsh Ray <[e-mail]> wrote:
> On 08/17/2010 04:00 PM, Brian Smith wrote:
>> Following these guidelines would subject the client and server to very
>> simple and effective DoS attacks, which are already so common that we
>> accept
>> them as part of the status quo. Relying on these guidelines would subject
>> the client and server to cross-protocol attacks unless everybody else in
>> the world follows them.
>
> I don't get it, it's basic stuff. What part of those recommendations
> "subject the client and server to simple and effective DoS attacks" in a way
> that they weren't already?

I'm sorry, but I don't understand your question.  Cross-protocol
vulnerabilities need not be related to DoS.  In particular, the
example I gave earlier in the thread was about spam.

> Port 443 isn't magic. It's just as DoS-able as others, if not more so.
> Multiplexing multiple protocols on top of port 443 might even limit your
> options in the event of an actual DoS (possibly inadvertent).

Indeed.  We're not talking about DoS protection.

> Oh and I forgot: disable NTLM (my latest crusade).
> http://extendedsubset.com/?p=36

I don't understand how this relates to the topic at hand.

>> Google, Amazon.com, and others claim significant decreases in revenue that
>> correlate with increases in latency of 100ms or even less.
>
> Interesting, I had heard of that. Link?

This is a well-established fact.

> I like a snappy web site as much as anybody, but this WebSocket thing seems
> somewhat ancillary. Possibly some of these app-heavy pages would improve the
> perceived responsiveness if they would just load the HTML and size the
> rectangles fully before starting with a zillion background requests.

I don't think this is the proper forum to debate the performance
requirements of the WebSocket protocol.  Suffice it to say that the
folks who want to use the protocol want it to be fast.  That doesn't
sound unreasonable to me.

>> 1. Denial of service caused by a MitM that selectively allows traffic
>> based
>> on the port number; i.e. the firewall attack. This extension allows the
>> client and server to work around the firewall attack if the attacker has
>> left any opening, which they almost always do.
>
> By definition, it cannot be an attack if it's by the equipment's rightful
> owner. You seem to be of the opinion that you or some other entity have some
> kind of right of transit over private networks. I believe one should acting
> like a respectful invited guest on another's network. Displaying that
> arrogant attitude is a large part of why admins are distrustful of new
> network software and have resorted to blocking everything by default.
>
> If you are actually in some kind a repressive political environment you
> might be better served with a special purpose VPN solution designed for
> strong anonymity.

With or without this extension, the current plan in the HyBi working
group is to multiplex WebSockets with HTTPS over port 443.  If you
think that's a bad idea, you'll need take that up with the HyBi
working group.  The purpose of this TLS extension is to improve the
security of the protocol, not to enable multiplexing.

>> 2. Traffic analysis that allows a MitM to determine the user's actions
>> even
>> when the communication is taking place over TLS, using the port number
>> and/or plaintext information sent in the TLS handshake (SNI extension,
>> certificates, etc.). For example, currently it isn't possible to build a
>> system that uses SMTP and IMAP but which hides the user's action (sending
>> or
>> receiving) from a MitM; this extension (or a similar one) would enable
>> implementations to make such traffic analysis significantly more difficult
>> and hopefully prohibitively expensive, especially if used in conjunction
>> with  a careful padding scheme.
>
> This is expected to make it hard for TA to distingush between HTTP, SMTP,
> and IMAP? Really?

That's not the goal.  Please refer to my earlier emails for a
description of the security properties we seek to obtain with this
extension.

>> 3. Cross-protocol attacks as described by Adam. This extension allows the
>> client and server to explicitly specify what protocol they expect to be
>> used
>> on the connection. This is a useful feature even for applications that
>> don't
>> want to support overloading ports with multiple protocols. It is difficult
>> to extend application layer protocols with these cross-protocol attack
>> protections, because those extensions themselves may be exploitable with
>> cross-protocol attacks.
>
> I can see how this could be an improvement.

Indeed.  That's because this is the problem we seek to solve with this
extension.

[Snip example]

> In this simple example we already have the protocol "HTTP" stated explicitly
> or associated by convention ten times!
>
> One might think this would be good enough to indicate what the intended
> protocol is, but as you say there are apparently people with unauthenticated
> SMTP and IMAP servers listening on port 443.

Folks can run whatever services they like on whatever port they like.
It's our job not to introduce vulnerabilities into their deployments.

> My question is this: What's going to be different this time?

The difference is that it's a prior reasonable for a web page to
generate an HTTP POST request to port 25 on smtp.example.com.  It's
only after we learn of HTTP -> SMTP cross protocol attacks that we
need to look for a heuristic to block the attack.  In the protocol
we're proposing, it's unreasonable (read: a violation of the
specification) to try to talk SMTP over a TLS tunnel after agreeing
that the next protocol is WebSockets.  The extension adds the
semantics that are present only heuristically currently, letting us
gain a strong security property.

> If we really need another protocol identifier because the ones we have don't
> hold up under attack, let's do it right this time! It needs to be treated
> just as security-critical as checking the name on a server certificate.

Indeed.  I believe NPN is the right way to do it.  It is treated as a
security-critical component by the WebSocket protocol.

> Rather than opaque<0..255> we need defined encoded values. If not, as
> someone suggested, using existing port assignments, then perhaps a string.
> These values should be assigned by IANA. There should be a convention for
> private-use and experimental identifiers. The valid characters, whitespace
> rules, and the exact method of string comparison must be defined.

I believe that's how the extension works.

> Use with underlying transports other than TCP should be defined i.e., do the
> rules still apply if you run TLS over raw serial or stdin/stdout?
> What about DTLS?

Marsh, you seem confused.  Are you reading the same document I am?
Where's the dependence on TCP?

> Is there ever a case for more than one instance of a protocol on an address?
> If you want to start another http server, say for app development, is there
> an equivalent to "port 8080"? If so, wouldn't browsers and other client apps
> need a way to specify it in the url?

This is present in WebSockets.  It is, in fact, carried in the URL, as
you suggest.  I feel like you and I are in violent agreement.  All the
things you're asking for are already the case.

> Are any security properties associated with some names and not others? Is
> there an equivalent to privileged "low numbered ports"? Should OS
> permissions be involved in who can start a new server?

No.  The semantics of the protocol are defined by the protocols themselves.

> How is client cert auth to be performed?

There's no interaction between NPN and client auth.  It's performed in
precisely the way it is today.

> Is it a problem that it's not configurable per-protocol?

Not that I'm aware of.

> Note that MS Windows has had, for many years now, an in-kernel https server
> which by default takes port 443. They support multiple protocols for RPC,
> remote access, and of course web serving all on the same port. I believe
> they support PPTP VPNs on 443 with a similar mechanism. What can we learn
> from that experience which might help in this design?
> (did I mention that everyone should disable NTLM?)

I'm not familiar with this design.  You're seem unduly concerned with
multiplexing.  That's not the essential feature here.  The essential
feature is agreement about what protocol we're going to speak over the
encrypted tunnel.  WebSockets would want NPN even if it were always
run on a dedicated port.

> Insecure (without RFC 5746) renegotiation can now easily be a cross-protocol
> attack. Should this spec forbid it?

Perhaps.  I haven't studied this question in detail.  Note that the
answer is non-obvious because the attacks that RFC 5746 is meant to
address occur in a different threat model than the one we're concerned
with here.

> Could it be made an option to get the server's list of protocols while under
> a basic encrypted session, providing that confidentiality like for client
> certificates?

In the scenarios we're interested in, the client is initiating a
particular protocol.  There's no need to discover what other protocols
the server might speak.

> Should the client's SNI be allowed to or prohibited from influencing the
> server's list of supported protocols?

The server is permitted to refuse any connection it doesn't like for
any reason.  The phase of the moon can influence whether the server
opts to complete the handshake.

> Would it be advantageous for the client-selected protocol to be allowed to
> influence the cert presented by the server? It's not unusual to need
> different certs for different protocols after all. Can this be accomplished
> through renegotiation? Wouldn't that leak information about what protocol
> was chosen?

This issue has been discussed previously on this thread.  Please read
my prior responses for the answer to your question.

> Will this have implications for protocols that need to poke holes for
> incoming connections  E.g., STUN, UPnP?

No.

> I used to work for a VPN company. We prided ourself on our client software
> being able to find a way back to the datacenter with minimal user
> intervention in nearly all circumstances. But we were also not going to go
> around boasting "Ha ha we can exfiltrate through anything you leave open I
> dare you to block [method X] Mr. Admin we pwn ur netz".

This paragraph seems like a non-sequitur.

> There's no way an IETF protocol can "lie low" in this respect. If the
> proposed scheme gains widespread adoption, firewalls will of necessity
> evolve to manage it (regardless of whether that can be done correctly).
>
> http://www.google.com/search?q="Data+Loss+Prevention"+ssl
>
> It's one thing for a P2P app to disregard the admin's preferences, they are
> budgeting ongoing development time to continually evolve their connection
> smuggling techniques in a cat-and-mouse arms race. But an IETF protocol is a
> different matter. It's published, it gets used, vendors sell boxes to
> accelerate and manage it, admins deploy the boxes as well as other tools.
>
> My concern is that at the end of the day we end up with no great victory in
> transport neutrality. Instead we get might just get another layer of
> redundant indirection, more protocol complexity, and worst of all,
> TLS-intercepting MitM proxies sprouting all over the net like dandelions.

I'd encourage you to bring this point of view to the HyBi working
group.  It, however, is unrelated to whether we use the NPN extension.
 Currently, that working group takes the opposite viewpoint as a
requirement of the protocol, regardless of whether the protocol
involves NPN.

>> Many service
>> providers do not care about their users' privacy enough to spend any extra
>> money to protect it. If this extension becomes the standard way to enable
>> interoperable WebSockets support, then even service providers that are
>> apathetic about MitM protection might having a compelling reason to use
>> TLS.
>
> But if it requires a software (if not hardware) upgrade to support the
> extension, wouldn't that just encourage deployments to use plain HTTP?

Plain HTTP does not support the use cases WebSockets supports.  If it
did, there would be no need to invest in WebSockets.

>> Then their end-users can enjoy improved privacy and better authentication
>> of servers when otherwise it may never be made available for them. I think
>> this
>> could result in a snowball effect that would make encrypted and
>> server-authenticated communication much more common or even eventually
>> ubiquitous. I think the chance that this happening is reason enough to
>> integrate this mechanism into TLS.
>
> That would be nice, but it doesn't seem likely. For example, I use two
> "social networking" sites, Twitter and LinkedIn. They both appear to support
> https urls, but fail in several ways. The sites regularly load resources
> (even script) from plain http urls. Clicking on links sometimes drops back
> to http. When they send emails or alerts from other apps, the links are all
> http. Twitter actually looks like it's gotten a bit better, but LinkedIn
> seems to just redirect me away from https completely. The point being that
> making a secure site requires a commitment to a significant development
> project.
>
> As appealing as the idea sounds to me, "encouraging" a transition before
> people would choose it on their own is likely to lead to a lot more
> self-signed certs out on the web.

Be that as it may, it's irrelevant to topic currently under discussion.

Adam