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

[Nathaniel W Filardo <[e-mail]>]

On Wed, Aug 18, 2010 at 02:29:02PM -0400, Adam Langley wrote:
>[snip] 
> 1. Introduction
> 
> As the Internet has evolved, it has become commonplace for hosts to
> initiate connections based on untrusted and possibly hostile data.
> HTTP [RFC2616] clients are currently the most widespread example of
> this as they will fetch URLs based on the contents of untrusted
> webpages.
> 
> Any time that a connection is initiated based on untrusted data there
> is the possibility of a cross-protocol attack.  If the attacker can
> control the contents of the connection in any way (for example, the
> requested URL in an HTTP connection) they may be able to encode a
> valid message in another protocol.  The connecting host believes that
> it is speaking one protocol but the server understands it to be
> another.  The application of Postel's Law exacerbates the issue as
> many servers will permit gross violations of the expected protocol in
> order to achieve maximum compatibility with clients.
> 
> The WebSockets [websockets] protocol seeks to allow low-latency,
> full-duplex communication between browsers and HTTP servers.  However,
> it also permits an unprecedented amount of attacker control over the
> contents of the connection.  In order to prevent cross- protocol
> attacks, a mechanism to assure that both client and server are
> speaking the same protocol is required.  To this end, Next Protocol
> Negotiation extends the TLS [RFC5246] handshake to permit both parties
> to agree on their intended protocol.

I realize this is the TLS mailing list, but...

WebSockets are, AFAIK, designed to have a mandatory HTTP-alike header
specifically so that they can be discriminated from HTTP without requiring
any lower level identification being necessary (though apparently the drafts
of the WS specification are less than perfect about maintaining this
guarantee).  In any case, this ought to render any concerns of being unable
to make WS connections while still making HTTPS connections moot; they can
_already_ be intermixed on port 443.  Moreover, cross-protocol attacks do
not require the advanced control present in WS (though surely it helps);
HTTP has proven to be sufficiently useful to carry out cross-protocol
attacks against both SMTP and IRC servers.  It seems odd to me that secure
WS is the forcing issue here.

It also seems very odd to me that this is being viewed as a TLS-only thing.
Cross-protocol attacks are not limited to the world of secured TLS streams
(see above), and TCP ports are not in fact protocol identifiers, despite
some traditions that conflate the two concepts.  If cross-protocol attacks
are a concern (and I'm not saying they're not), then TLS NPN is necessary
but insufficient -- the outer layers and insecure links must also be
protected.

Further, protocols inside TLS are already implicitly weakly protected if the
endpoints require authentication.  There isn't any way that my web browser
can carry out an HTTPS cross-protocol attack against an SMTPS server, unless
the attacker already knows the appropriate SMTP credentials or I have client
certs accepted by the SMTPS server loaded in my browser.  Any attempt the
browser makes at authenticating via HTTP mechanisms is going to be ignored
by the SMTPS server.  If I require STARTTLS for SMTP, I'm in an even better
position than if I were using just SMTPS, as the client cert issue is gone.
(Would that the HTTP world actually believed in Upgrade: for starting TLS!)

Are there, in fact, attempts to mark sender's intended protocol outside of
TLS being concurrently worked on (perhaps by extending the use of IPv6's
Next Header field across the TCP header)?  If not, why should we believe
that standardization and adoption of a TLS-only NPN will help much at all?

Thanks.
--nwf;