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 _______________________________________________ Pan-devel mailing list Pan-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-devel
