Re: [Pan-devel] at GIT 7e49a9b still the same here, plus some research I've done (seems AW works, but not GN nor Gmane (Re: ANN: SSL Support))

[Duncan]

SciFi posted on Sat, 19 Nov 2011 04:48:08 +0000 as excerpted:

> Here's a bit of recent history about TLS, if anyone wonders:
> A cursory examination of security discussions seems to show
> that TLS turns out to be an UN-secure protocol.
> It's apparently been "cracked" successfully, too many times,
> so we users have been warned about using TLS anymore.
> In fact, I believe Firefox et al have set TLS inactive as default
> for HTTPS protocols etc.

AFAIK, it's not that TLS itself is insecure, it's allowing
dynamic renegotiation of the security level after initial
negotiation and establishment that's the problem.

There's actually two problems here.

One is simply trying to limit DoS (denial of service) attacks on the 
server, since the (normally initial only) public/private asymmetric key 
handshake is far more CPU intensive than maintaining the established 
symmetric-key connection once fully negotiated.  By repeatedly forcing 
renegotiation (as the standard unfortunately allows) it's possible to 
force the server to devote inordinate resources to that single 
connection, thus severely limiting the number of concurrent connections 
available, ie: DoS attack, and a quite simple one at that!

But many servers already refused to allow repeated renegotiation, 
allowing the initial optional upgrade from plain text to a secure 
connection as negotiated, but refusing to renegotiate the connection 
after that.  And in practice, very few "real" clients try to renegotiate 
in any case.  They'll do an initial upgrade and stay at that level, 
period.

The second problem is as you mentioned, a rather complicated but still 
possible in some situations, middle-man attack, via forced renegotiation 
to something the middleman can intercept.  Succeeding at this is 
challenging, however, since it involves knowledge of sequence numbers and 
some luck in terms of windows of opportunity, race conditions, etc.  
However, modern hardware has made this far easier than it was years ago, 
when the standards were first hashed out.

So disregarding the letter of the original standard and refusing 
renegoation after the initial upgrade turned out to be best security 
practice in any case, and is now STRONGLY recommended for both ends.

Given the above, one might ask why renegotiation of the connection beyond 
the initial opportunistic upgrade (which does have quite some advantages) 
was ever allowed in the first place, since it's not all that useful in 
practice and tends not to be used.

That's a VERY good question, actually.  There's certainly a group that 
believes it was no accident, however, and that the NSA, Echelon, etc, may 
well have had something to do with it.  Of course the trouble for these 
security agencies, etc, whether the original renegotiation weaknesses can 
be attributed to them or not, is that now days, it's not just them that 
have the necessary technical capacity, but pretty much any national-level 
security agency (think the attack on Google's certs that is commonly 
attributed to Iran, we know THEY are interested, and the various attacks 
on gmail attributed to the Chinese, so are THEY!), and a number of 
reasonably technically advanced criminal gangs in Russia (we know of 
them, others?) as well.  So if the NSA, etc, DID have a hand in the 
original weakness of the standard, it has certainly come back to haunt 
them, now.

So what firefox, et. al. are doing, is simply disallowing repeated 
renegotiations of the connection once the initial secure connection is 
negotiated.

Unless of course you're reading different security information than I've 
been following as the various developments have hit the news...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman