Hi Tomas,
Thanks for your reply!
On 1/10/2012 at 08:12 PM, in message 20120110131229.7ede5...@redhat.com,
Tomas Hoger tho...@redhat.com wrote:
Hi Guanjun!
On Sun, 11 Dec 2011 20:35:02 -0700 Guan Jun He wrote:
I have just produced a patch against the upstream HEAD version, to
seek a way to fight against DoS attack in openssl itself, the logic
is simple, get client's ip address in BIO layer, and send this info
to upper SSL layer; In SSL layer, according to the client ip and
control policy to do control. And I have just finished the
enhancement to use rb-tree as the main struct, the patch is
attached,and have took a simple test from 2 machines.
It seems you're trying to address more than just CVE-2011-1473 via this
patch, which results in a fairly large patch. Why do you need to track
client IP at all? This issue is about client's ability to do unlimited
number of renegotiations within single connection. To limit that
(either to a maximum total, or rate limiting), you should not really
need to care about client's IP.
If do not care about client's IP, then the rate limiting is aimless, that means
all legitimate ssl requests will be blocked, and cause another 'DoS'.
With client IP, then it can just block the specific(attacking) client ip, all
other
legitimate ssl requests can be processed normally.
You also seem to store IP as 32bit
value, which does not sound like it should work correctly for IPv6.
That should be adjusted to support IPv6, and can be done.
When I produce this patch, s_server and s_client still not support IPv6,
so I didn't consider this.
Your IP tracking probably helps limit total number of handshakes
(initial or renegotiation) from one IP over all connections. It may be
easier to limit handshakes in one connection and enforce connection
limit (max concurrent connections or connection rate) elsewhere, where
it can be done easily and where it's usually done - in firewall. Your
mails suggest that you're actually testing it by doing only initial
handshake over multiple connections, rather than using re-handshakes
within single connection.
On Mon, 19 Dec 2011 02:11:23 -0700 Guan Jun He wrote:
I have just tested and updated the patch,it works ok,and with a
little performance loss(1%). The script used looks like this:
for o3 in `seq 1 254`; do
for o4 in `seq 1 254`; do
host=127.0.$o3.$o4
openssl s_client -ssl3 -connect $host:4433
done
sleep 1
done
the server side is like this: openssl s_server
Please correct me if I'm wrong, but if I remember correctly, s_server
only handles single SSL connection at the time. The next connection is
only accepted (SSL handshake) when the existing connection is closed.
I'd expect the above test to open 1 SSL connection to s_server, with
bunch of other s_client connections being established, but waiting for
SSL handshake. This does not sound like a valid test case.
Seems like you are right!
Do you have any good methord to test this?
Any advice would be appreciated!
Regards,
Guanjun
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
