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

[Adam Barth <[e-mail]>]

On Wed, Aug 18, 2010 at 2:37 AM, Juho Vähä-Herttua <[e-mail]> wrote:
> On 18.8.2010, at 11.42, Adam Barth wrote:
>> Thanks for your feedback.  This looks to be an area in which we can
>> improve the extension.
>
> This is a serious concern so far, since if the selected_protocol is not very well defined, two different users of the NPN extension might be conflicting. I don't know if using the port assignments is a good idea, since there are many undocumented and conflicting port uses as well. On the other hand a string identifier just feels a bit dirty...

It seems likely we'd want an IANA registry to avoid conflicts, similar
to the HTTP header registry.

> If that handshake is garbage, are there similar plans to "fix" the plain HTTP version of WebSockets, or is the plan that NPN would be used with TLS and the old handshake is used with HTTP? This sounds like it makes the life of WebSockets implementors a much harder, since they have to consider two completely different schemes, wouldn't it?

The plan is to remove the HTTP version.

> Since the plan of NPN is to improve the security of WebSockets, what kind of attacks it protects against, compared to simply having the HTTP style handshake negotiation inside a secure TLS connection?

Cross-protocol attacks, as described above.  I know the thread has
gotten pretty long, but hopefully you'll be able to find the answer
now that you have the key words.

> I understand that the protocol is much "cleaner" in a way with NPN, but in case it is to be used the earlier concerns about selecting a correct certificate based on the protocol type are valid as well. I think having the NextProtocol handshake message before the ChangeCipherSpec and using renegotiation in case the contents need to be protected could be considered.

Indeed.  That does seem worth considering.

> Sorry if some questions are already answered, this is a long thread and I haven't read all the messages that carefully. I'm just trying to sum up here what I've seen so far.

Yeah, I imagine this thread is pretty unapproachable at this point.  :-/

On Wed, Aug 18, 2010 at 1:47 PM, Nathaniel W Filardo <[e-mail]> wrote:
> 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.

Browser vendors do not want to add more attack surface.  We're stuck
with HTTP, but that doesn't mean we should add more protocols that
make the same security mistakes.

> 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.

We're not trying to solve cross-protocol attacks for every protocol in
the work.  We're trying to design a new protocol that is immune to
cross-protocol attacks.

> 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!)

That's not an accurate understanding of how cross-protocol attacks
work.  Whether or not we're inside a TLS tunnel, the issues are the
same.  One way to understand this is to think about a VPN.  Clearly it
doesn't matter whether the cross-protocol attacks are taking place
inside an IPv6 tunnel, does it?

> 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?

I'd in fact prefer to use IPv6, but WebSockets must work with IPv4.

Kind regards,
Adam