On 11/15/2011 at 10:42 PM, in message 2015154237.7dca96f4@laverne,
Hanno
Böckha...@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
