>>> On 11/15/2011 at 10:42 PM, in message <20111115154237.7dca96f4@laverne>, >>> Hanno Böck<ha...@hboeck.de> wrote: > Am Tue, 15 Nov 2011 02:48:28 -0700 > schrieb "Guan Jun He" <g...@suse.com>: > >> Add a switch to renegotiation, so that renegotiation can be >> controled by program. And it provides a way to programmer to >> implement some sort of custom throttling. Basically, this patch is >> produced with the background of CVE-2011-1473, the DoS against >> renegotiation.You guys must have known it.Maybe the patch is not that >> useful for some use cases.But, it's the first step, and it gives apps >> a easy choise to fight against DoS. And, maybe the second steps can >> also be done in openssl, add a simple monitor to monitor client >> initiatd renegotiations(for each session or just globally), and >> according to the monitoring result to set the renegotiation switch >> for a time slice.the monitor can be as simple as just a counter,I'm >> still seeking an efficient way to do this.And ask for comments and >> advices from you guys. > > If I understood the THC DoS, this is completely pointless. Their tool > uses renegotiation, but there's absolutely nothing special about > renegotiation, the attack works also with normal connections. > > See THC on this matter: > "SSL-DOS released. Some organizations already found out > about this release a while ago and mistakenly identified it as an > SSL-RENEGOTIATION BUG. This is not true. The tool can be modified to > work without SSL-RENEGOTIATION by just establishing a new TCP > connection for every new handshake. " > http://www.thc.org/thc-ssl-dos/ > > > Also, there's been a lot of mixup with old and new renegotiation and > wrong infos floating around. The THC DoS is not really related to that. > > It's not easy to find a clean way to mitigate those issues - the core > problem is that a connection causes more load on the server than on the > initiating client - changing that would be possible only in the TLS > design. Connection limits can help (though they shouldn't be > limited to renegotiation), but it's not really a nice solution.
A simple renegotiation needs more actions than normal connection on the server, so it can do some help if the attacking client ask for renegotiations. For normal connections, if not do connection limits,perhaps there is no way to do control in tls itself without changing the design.And that's an issuse that any server must face to, and basically that can not be done in high layer of the protocals, but it's possible to do it in the low layer of the protocals or need info from the low layer. It would be possible only in the tcp/ip connection layers,in that layer server side can get the ip address of the client,according to that the tcp/ip layer can do control only against the attacking client. By the above tips, * client and server co-work. tls can add an item "ip-address-of-the-client" to the handshake protocal in client side(this can be done transparently in SSL_set_bio), and in server side tls can change to ask for client's ip address while establishing a tls connection. but this is not compatible with the tls version not added this. * do all transparently in server side. in BIO level get client's ip address, add it to the SSL struct, and send it to do subsequent process. this is compatible. the left steps are to 'monitor' the actions of each client, if decided an attack,simply take some actions to against that client, e.g. forbid that client for a time slice. Regards, Guanjun ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
