Hi All, Openssl Developers, Anyone is considering this is good solution or a bad solution? I sent this serveral days ago,and didn't get any response. anybody please give some response!
should I add some more informations? the testing steps and result? Thanks a lot for your response! Guanjun >>> On 11/21/2011 at 05:49 PM, in message <4ECA1E9C.19D : 22 : 21801>, Guan Jun >>> He wrote: > Hi, > > I have just produced a patch against the upstream HEAD version, to seek a > way to against DoS attack in openssl itself, > the logic is simple, get client's ip addressin BIO layer, and send > this info to upper SSL layer; In SSL layer, > according to the client ip and control policy to do control. > Now, the basic data struct used is list, that's simply, but > time-consuming if large amount of client accessing > it concurrently. So, next step, I'm considering change to use > rb-tree to gain performance, but I have not the > environment to test the accurate performance. For now, I can only > run a DoS attack script to simulate a DoS attack. > > > below are the mails discussed about this issuse several days ago. > >>>> On 11/16/2011 at 02:09 PM, in message > <4ec3c4040200001600009...@novprvlin0050.provo.novell.com>, "Guan Jun He" > <g...@suse.com> wrote: > >> >>>>> 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 > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
