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

[Marsh Ray <[e-mail]>]

On 08/19/2010 02:30 AM, Nathaniel W Filardo wrote:
>
> The particular class of attacks you're worried about all involve an agent,
> C, making requests to a server S, on behalf of some untrusted third party,
> M.  Further, S thinks that it is speaking P and C thinks that it is speaking
> Q, with P != Q.  It happens to be that S's interpretation of P is compatible
> with C's production of Q.
>
> For concrete example, in the case of P=SMTP and Q=HTTP,
 > []
> NPN does _nothing_ to help here, since TLS is not involved.  _Every_
> cross-protocol attack I am aware of is of this class; if you can provide
> citations otherwise, I would love to see them.

Lately I've been looking into a long-existing credentials forwarding 
attack on NTLM authentication. It's cross-protocol in the sense that the 
authentication can, in fact, be taken from an SMTP connection and used 
to authenticate an HTTPS session.

http://extendedsubset.com/?p=36

The slides pdf linked from there shows a grid of the explored and open 
attack space.

> Now, we can ignore (P,Q) being (SMTP,HTTPS) or (SMTPS,HTTP) since neither
> off-diagonal form is going to be able to bring up the TLS session to
> everybody's satisfaction.

It seems plausible that the attacker might control enough data in the 
Client Hello, e.g. SNI, that it could be usefully interpreted by the 
server. Or more simply, just sending the random binary data would 
probably crash more than one server out there.

> (P,Q)=(SMTPS,HTTPS) with neither C nor S expecting to see authentication
> essentially behaves as (SMTP,HTTP), I agree; TLS NPN helps here.
>
> (P,Q)=(SMTPS,HTTPS) with S expecting C to authenticate will result in a
> cross-protocol attack iff either of the following conditions are met:
>    1. C has a client certificate which S will accept and S does not expect
>       in-band authentication.

I could imagine this happening, and without user intervention. Consider 
a corporate PKI scenario where every user and every server gets their 
cert from the same cert management system run by the IT dept.

>    2. M has been able to specifically craft a P-message involving suitable
>       credentials for C's use in this transmission.

A forwarding attack such as is possible with NTLM could potentially 
allow this.

> Neither of these are terribly realisitic (in my mostly speculative opinion).
> Note that if S's knobs are set such that P requires a challenge-response
> authentication pass, that M will, whp, be unable to successfully take option
> 2.

Well the idea of WebSockets is to give full-duplex communications to 
attacker supplied Javascript. If he can successfully complete the 
initial handshake, it's better to assume anything is possible after that.

> In all, while I have no intrinsic objection to TLS NPN, it seems to me that
> the solution should be independent of the cryptographic provisioning layer,
> since it demonstrably has nothing to do with said functionality.

The TLS layer would seem to have a some of things going for it:

1. It's designed to authenticate-or-fail connections, i.e., it doesn't 
observe Postel's law.

2. Piggybacking on the TLS handshake could save a round trip.

- Marsh