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

[Adam Barth <[e-mail]>]

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


On Thu, Aug 19, 2010 at 6:48 AM, Martin Rex <[e-mail]> wrote:
> 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
>