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

[Marsh Ray <[e-mail]>]

On 08/17/2010 04:00 PM, Brian Smith wrote:
> Marsh Ray wrote:
>> On 08/17/2010 11:49 AM, Adam Barth wrote:
>> Run protocols on their designated port. Don't overload port numbers.
>> Don't allow unauthenticated connections to do anything significant (like
> send
>> mail) on any port (source IP does not count as authentication).
>> Don't allow web pages to initiate arbitrary connections.
>
> Following these guidelines would subject the client and server to very
> simple and effective DoS attacks, which are already so common that we accept
> them as part of the status quo. Relying on these guidelines would subject
> the client and server to cross-protocol attacks unless everybody else in the
> world follows them.

I don't get it, it's basic stuff. What part of those recommendations 
"subject the client and server to simple and effective DoS attacks" in a 
way that they weren't already?

Port 443 isn't magic. It's just as DoS-able as others, if not more so. 
Multiplexing multiple protocols on top of port 443 might even limit your 
options in the event of an actual DoS (possibly inadvertent).

Oh and I forgot: disable NTLM (my latest crusade).
http://extendedsubset.com/?p=36

>> Is there an example of a use for this protocol which is, in fact, highly
> latency-
>> sensitive on the very first connection to the app server of the session?
>
> Google, Amazon.com, and others claim significant decreases in revenue that
> correlate with increases in latency of 100ms or even less.

Interesting, I had heard of that. Link?

I like a snappy web site as much as anybody, but this WebSocket thing 
seems somewhat ancillary. Possibly some of these app-heavy pages would 
improve the perceived responsiveness if they would just load the HTML 
and size the rectangles fully before starting with a zillion background 
requests.

> Firewall and HTTP proxy administrators are the attackers in the scenarios
> that are being defended against. Not every Firewall or proxy is benevolent,
> and even many that aren't intentionally malicious are harmful due to poor
> implementation or configuration.

Never pick a fight with the guy who's holding your power cord.
He wins every time.

> 1. Denial of service caused by a MitM that selectively allows traffic based
> on the port number; i.e. the firewall attack. This extension allows the
> client and server to work around the firewall attack if the attacker has
> left any opening, which they almost always do.

By definition, it cannot be an attack if it's by the equipment's 
rightful owner. You seem to be of the opinion that you or some other 
entity have some kind of right of transit over private networks. I 
believe one should acting like a respectful invited guest on another's 
network. Displaying that arrogant attitude is a large part of why admins 
are distrustful of new network software and have resorted to blocking 
everything by default.

If you are actually in some kind a repressive political environment you 
might be better served with a special purpose VPN solution designed for 
strong anonymity.

> 2. Traffic analysis that allows a MitM to determine the user's actions even
> when the communication is taking place over TLS, using the port number
> and/or plaintext information sent in the TLS handshake (SNI extension,
> certificates, etc.). For example, currently it isn't possible to build a
> system that uses SMTP and IMAP but which hides the user's action (sending or
> receiving) from a MitM; this extension (or a similar one) would enable
> implementations to make such traffic analysis significantly more difficult
> and hopefully prohibitively expensive, especially if used in conjunction
> with  a careful padding scheme.

This is expected to make it hard for TA to distingush between HTTP, 
SMTP, and IMAP? Really?

> 3. Cross-protocol attacks as described by Adam. This extension allows the
> client and server to explicitly specify what protocol they expect to be used
> on the connection. This is a useful feature even for applications that don't
> want to support overloading ports with multiple protocols. It is difficult
> to extend application layer protocols with these cross-protocol attack
> protections, because those extensions themselves may be exploitable with
> cross-protocol attacks.

I can see how this could be an improvement.

Consider the status quo, I open an url into a browser: 
https://www.example.com/

https:           = specifies HTTP over TLS
www.             = a convention associated with HTTP
example.com      = the only useful part
DNS lookup 'example.com'
DNS lookup 'www' = resolve servers for HTTP
TCP port 443     = assigned port for HTTP over TLS
Baked into server's cert: "Ext key usage = TLS Web Server Auth" = HTTP
Client request 1: "GET / HTTP/1.1"         HTTP
Client request 2: "Host: www.example.com"  www -> HTTP again
Server response: "HTTP/1.1 200 OK"         HTTP

In this simple example we already have the protocol "HTTP" stated 
explicitly or associated by convention ten times!

One might think this would be good enough to indicate what the intended 
protocol is, but as you say there are apparently people with 
unauthenticated SMTP and IMAP servers listening on port 443.

My question is this: What's going to be different this time?

If we really need another protocol identifier because the ones we have 
don't hold up under attack, let's do it right this time! It needs to be 
treated just as security-critical as checking the name on a server 
certificate.

Rather than opaque<0..255> we need defined encoded values. If not, as 
someone suggested, using existing port assignments, then perhaps a 
string. These values should be assigned by IANA. There should be a 
convention for private-use and experimental identifiers. The valid 
characters, whitespace rules, and the exact method of string comparison 
must be defined.

Use with underlying transports other than TCP should be defined i.e., do 
the rules still apply if you run TLS over raw serial or stdin/stdout?
What about DTLS?

Is there ever a case for more than one instance of a protocol on an 
address? If you want to start another http server, say for app 
development, is there an equivalent to "port 8080"? If so, wouldn't 
browsers and other client apps need a way to specify it in the url?

Are any security properties associated with some names and not others? 
Is there an equivalent to privileged "low numbered ports"? Should OS 
permissions be involved in who can start a new server?

How is client cert auth to be performed? Is it a problem that it's not 
configurable per-protocol?

Note that MS Windows has had, for many years now, an in-kernel https 
server which by default takes port 443. They support multiple protocols 
for RPC, remote access, and of course web serving all on the same port. 
I believe they support PPTP VPNs on 443 with a similar mechanism. What 
can we learn from that experience which might help in this design?
(did I mention that everyone should disable NTLM?)

Insecure (without RFC 5746) renegotiation can now easily be a 
cross-protocol attack. Should this spec forbid it?

Could it be made an option to get the server's list of protocols while 
under a basic encrypted session, providing that confidentiality like for 
client certificates?

Should the client's SNI be allowed to or prohibited from influencing the 
server's list of supported protocols?

Would it be advantageous for the client-selected protocol to be allowed 
to influence the cert presented by the server? It's not unusual to need 
different certs for different protocols after all. Can this be 
accomplished through renegotiation? Wouldn't that leak information about 
what protocol was chosen?

Will this have implications for protocols that need to poke holes for 
incoming connections  E.g., STUN, UPnP?

> It is hard to believe that a significant number of attacks can be prevented
> simply by using port 443 for everything. But, it would really work a lot of
> the time; it is difficult for the attacker to counteract this defense,
> because often the attacker has a business or political need to avoid
> disrupting HTTPS on port 443; otherwise they would have disabled that
> already. The amazing ability of Skype to punch through firewalls is partly
> due to such port 443 tunneling.

I used to work for a VPN company. We prided ourself on our client 
software being able to find a way back to the datacenter with minimal 
user intervention in nearly all circumstances. But we were also not 
going to go around boasting "Ha ha we can exfiltrate through anything 
you leave open I dare you to block [method X] Mr. Admin we pwn ur netz".

There's no way an IETF protocol can "lie low" in this respect. If the 
proposed scheme gains widespread adoption, firewalls will of necessity 
evolve to manage it (regardless of whether that can be done correctly).

http://www.google.com/search?q="Data+Loss+Prevention"+ssl

It's one thing for a P2P app to disregard the admin's preferences, they 
are budgeting ongoing development time to continually evolve their 
connection smuggling techniques in a cat-and-mouse arms race. But an 
IETF protocol is a different matter. It's published, it gets used, 
vendors sell boxes to accelerate and manage it, admins deploy the boxes 
as well as other tools.

My concern is that at the end of the day we end up with no great victory 
in transport neutrality. Instead we get might just get another layer of 
redundant indirection, more protocol complexity, and worst of all, 
TLS-intercepting MitM proxies sprouting all over the net like dandelions.

> One thing I will say about this extension in conjunction with WebSockets: I
> think that it is unrealistic to expect many service providers to enable or
> require TLS simply for the privacy benefits of their users.

Agreed.

> Many service
> providers do not care about their users' privacy enough to spend any extra
> money to protect it. If this extension becomes the standard way to enable
> interoperable WebSockets support, then even service providers that are
> apathetic about MitM protection might having a compelling reason to use TLS.

But if it requires a software (if not hardware) upgrade to support the 
extension, wouldn't that just encourage deployments to use plain HTTP?

> Then their end-users can enjoy improved privacy and better authentication of
> servers when otherwise it may never be made available for them. I think this
> could result in a snowball effect that would make encrypted and
> server-authenticated communication much more common or even eventually
> ubiquitous. I think the chance that this happening is reason enough to
> integrate this mechanism into TLS.

That would be nice, but it doesn't seem likely. For example, I use two 
"social networking" sites, Twitter and LinkedIn. They both appear to 
support https urls, but fail in several ways. The sites regularly load 
resources (even script) from plain http urls. Clicking on links 
sometimes drops back to http. When they send emails or alerts from other 
apps, the links are all http. Twitter actually looks like it's gotten a 
bit better, but LinkedIn seems to just redirect me away from https 
completely. The point being that making a secure site requires a 
commitment to a significant development project.

As appealing as the idea sounds to me, "encouraging" a transition before 
people would choose it on their own is likely to lead to a lot more 
self-signed certs out on the web.

- Marsh