Subject: [TLS] Preventing cross-protocol attacks without NPN (was: Request for review: Next Protocol Negotiation Extension)

From: Adam Barth <[email-masked]>
Date: Thu, 19 Aug 2010 01:18:26 -0700

[I've changed the subject because Nathaniel's reply was quite
thoughtful and I suspect many folks have tuned out of the original
thread due to its size.]

On Thu, Aug 19, 2010 at 12:30 AM, Nathaniel W Filardo <[email-masked]> wrote:
> 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?

Yes, precisely.

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

More precisely, it would if either SMTPS or HTTPS required NPN (which
they don't).  It really helps more with (WebSockets, X) for all X
because WebSockets requires NPN and therefore will neither confuse nor
be confused by any other protocol.

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

That's the flaw in your reasoning.  Both are certainly possible, but
(2) is more likely.  Consider the case of HTTP attacking FTP, which we
have experience with in the wild.  Even though FTP requires the client
to authenticate (in this case), an attacker can craft an HTTP request
that tricks the server into thinking the request contains FTP
authentication credentials.  (It's a fun exercise to make this work
with your favorite FTP server implementation.)

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

I wouldn't be so sure.  With HTTP keepalive, an attacker might well be
able to read back bytes from the server and then formulate a second
request that contains the response to the server's challenge.  You're
right that this gets harder, but it's quite far from impossible.

Constructing these attacks is a somewhat subtle business.  It feels a
lot like putting a square peg into a round hole, but we have plenty of
evidence that these attacks exist.  (I don't mean to keep harping on
HTTP attacking other protocols, that's just what we have the most
experience with.)

> That was the only claim I was making.

I understand why you came to the conclusions you did, but this
business is a bit more subtle than it appears at first, much like
achieving mutual authentication over an untrusted network.  ;)

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

If you have a solution that works as well as (or better than) TLS+NPN,
the HyBi working group would likely be quite interested in hearing
your proposal.  You're certainly right that one could imagine
implementing this functionality if we had a better extension mechanism
in TCP, but, sadly, we don't.  Currently, TLS+NPN is the best design
I've seen (I suspect because TLS has a forward-looking extension
mechanism, not because of its encryption facilities).

Kind regards,
Adam

---

From: Martin Rex <[email-masked]>
Date: Thu, 19 Aug 2010 15:48:02 +0200 (MEST)

> with C's production of Q.  Is that not an accurate understanding?

"involve an agent C".  It's about a promiscuous zombie call "web browser"
(not necessarily Mr. Smith in a black suit). ;-)

The last "cross-protocol attack" I complained about was TLS endpoints
chasing AIA URLs from untrusted end-entity certs when faced with
incomplete certificate chains.  There the scenario involved a client
(browser), a server (online bank) who trust each other and a secure
protocol (TLS), which was susceptible to outside(!) attackers injecting
a crafted ServerHello+ServerCertificate handshake message into a newly
established TCP connection.  

The "cross-protocol attack" mentioned with WebSocket, on the other hand,
is about a completely different threat scenario.  There, the worry
is about rightful peers, i.e. Servers attacking clients by serving
them URLs and active content to coerce them in connecting to services
that they shouldn't be connecting to.

Personally, I don't think NPN is going to improve anything.  It is
just going to make things slightly more obscure, but by misleading
the consumers of the technology about where there is the flaw in
their architecure, they're going to significantly increase the
damage in the long run.

Blacklisting known bad stuff is a race that you can not win.

Probably no one would suggest to "enhance" MUA to roam the internet
and collect more spam to present to the user.  Browsers do just that,
they will happily download and annoy end users with significantly
larger amounts of spamvertisement than most users would agree to
when asked.

For Java applets there was originally a security model that the
applet could only callback to the site where it came from.
Security-wise this was a sensible approach.  If something similar
had been done for HTML pages, XSS would be a non-problem and
neither would there be any cross-protocol issues.

Since the services that are listening for plaintext protocols today
are not going to go away anytime soon, why do you think the situation
would improve with NPN?  Is there a "once WebSockets -- forever WebSockets"
requirement, that mixing content from "old" (port 80) and
"new" Web (=through WebSockets) is going to be entirely prohibited?

Cross-Protocol attacks are very very old stuff.
Back in the old days of the IP-Protocols, there were services
such as "chargen 19/udp" and "echo 7/udp" and IIRC, you only needed
to send a UDP datagram with a crafted source ip/port to chargen
to make two machines saturate a network link.

The WebSockets + NPN architecture sounds like a inetd with builtin
TLS and out-of-band protocol signaling instead of relying on the
implicit assumptions of well known ports.

But this approach, especially when _NOT_ sending the next protocol
in the ClientHello (in clear text), is in direct conflict with the
idea to perform server endpoint identification for TLS in a fashion
that clearly distinguishes services by their certificate (attributes),
like ExtendedKeyUsage (EKUs) and Service SubjectAltNames.

Personally, I really dislike the idea of requiring all application
services on a Host to be single-admin'ed and all authentication
and authorization at the TLS layer to be unconditionally host-wide.
That comes close to killing TLS client certificates as a means to
authenticate users if you have differing requirements for applications.

The protection that you're looking for should be provided by IPsec,
not a multiplexing TLS+NPN-enriched WebSockets inetd.

Seperating services on a host into individual processes with
only those privileges and the level of user authentication and
user authorization that these services actually need is sensible
risk management.  Terminating and dispatching EVERY network
connection to a machine in a single application puts us back
into the MS-DOS area (lack of process seperation).

And what exactly do you mean by "Next Protocol".  A lot of stuff
uses HTTP these days, and if you really only distinguish the
next protocol level, then there still is a lot of cross-protocol
attack surface left.  Doesn't SOAP use HTTP as well?
I know that my DSL-router is VERY open-minded to SOAP-requests
for administrative purposes (and no, it doesn't require authentication
for many actions -- different to the administrative WebUI).

-Martin

---

From: Adam Barth <[email-masked]>
Date: Thu, 19 Aug 2010 10:16:10 -0700

Martin,

I think you're right that we could fix these problems by changing the
browser security model to something more like the Java security model.
 However, the browser security model isn't going anywhere any time
soon.

Kind regards,
Adam