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

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

On Wed, Aug 18, 2010 at 01:59:42PM -0700, Adam Barth wrote:
> > 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?

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.  Is that not an accurate understanding?

For concrete example, in the case of P=SMTP and Q=HTTP, M requests that C
make a POST request to S; S in turn will typically ignore C's HTTP
verb/object/version line and any headers.  Reason being, HTTP verbs and
options (which all involve a : before whitespace) don't overlap with the
SMTP vocabuarly, and so S ignores them as malformed lines.  Note that TLS
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.

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.

(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.
  2. M has been able to specifically craft a P-message involving suitable
     credentials for C's use in this transmission.
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.  TLS NPN doen't hurt here, but there's not a lot of headroom for it to
help -- the connection is likely going to fail anyway.

That was the only claim I was making.

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.

--nwf;