Re: [TLS] Preventing cross-protocol attacks without NPN (was: Request

[Martin Rex <[e-mail]>]

Nathaniel W Filardo <[e-mail]> 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.  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