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

["Brian Smith" <[e-mail]>]

Marsh Ray wrote:
> On 08/17/2010 11:49 AM, Adam Barth wrote:
> Run protocols on their designated port. Don't overload port numbers.
> Don't allow unauthenticated connections to do anything significant (like
send
> mail) on any port (source IP does not count as authentication).
> Don't allow web pages to initiate arbitrary connections.

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.

> Is there an example of a use for this protocol which is, in fact, highly
latency-
> sensitive on the very first connection to the app server of the session?

Google, Amazon.com, and others claim significant decreases in revenue that
correlate with increases in latency of 100ms or even less. 

> To a large extent it seems the motivation here is to overlay another
namespace
> of type opaque <0..255> for negotiating app layer protocols separate from
the
> well-known port assignments thus bypassing the IANA and the control of
> firewalls and site admins.

Firewall and HTTP proxy administrators are the attackers in the scenarios
that are being defended against. Not every Firewall or proxy is benevolent,
and even many that aren't intentionally malicious are harmful due to poor
implementation or configuration.

> I know WebSockets isn't on trial here, but it seems like one of the main
> justifications for NPN.

I think it would be better for this discussion to focus on the actual
security improvements that this extension enables for all protocols.
Otherwise, too much discussion will be about alternatives that work for
WebSockets but don't solve the same problems for other protocols. Here are
the attacks that this extension helps mitigate:

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.

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.

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.

It is hard to believe that a significant number of attacks can be prevented
simply by using port 443 for everything. But, it would really work a lot of
the time; it is difficult for the attacker to counteract this defense,
because often the attacker has a business or political need to avoid
disrupting HTTPS on port 443; otherwise they would have disabled that
already. The amazing ability of Skype to punch through firewalls is partly
due to such port 443 tunneling.

One thing I will say about this extension in conjunction with WebSockets: I
think that it is unrealistic to expect many service providers to enable or
require TLS simply for the privacy benefits of their users. 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.
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.

Cheers,
Brian