Re: [PATCH: CVE-2011-1473]: Fight against DoS in openssl
Hi Tomas and All, On 1/16/2012 at 11:31 PM, in message 20120116163148.4f325...@redhat.com, Tomas Hoger tho...@redhat.com wrote: On Wed, 11 Jan 2012 21:04:33 -0700 Guan Jun He wrote: 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'. The issue is about renegotiations. If the fix allows all initial handshakes and only penalizes all connections that do many rehanshakes, there's no DoS as you suggest and should be sufficient to address CVE-2011-1473. Actually,the patch is based on the ssl protocol's client hello, initial handshakes and rehanshakes both use this, so the patch does not differ them, find one client hello just increase the counter. So, it can fix both 'initial handshakes DoS' and 'rehanshakes DoS'. thanks, Guanjun __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH: CVE-2011-1473]: Fight against DoS in openssl
On 1/16/2012 at 11:31 PM, in message 20120116163148.4f325...@redhat.com, Tomas Hoger tho...@redhat.com wrote: On Wed, 11 Jan 2012 21:04:33 -0700 Guan Jun He wrote: 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'. The issue is about renegotiations. If the fix allows all initial handshakes and only penalizes all connections that do many rehanshakes, there's no DoS as you suggest and should be sufficient to address CVE-2011-1473. Actually,the patch is based on the ssl protocol's client hello, initial handshakes and rehanshakes both use this, so the patch does not differ them, find one client hello just increase the counter. So, it can fix both 'initial handshakes DoS' and 'rehanshakes DoS'. thanks, Guanjun 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? You want something that does not block rehandshakes. s_server should be sufficient if you're only after limiting renegotiations within one connection. httpd blocks client-initiated renegotiation for a while. stunnel may work as a good target. You probably want to look at something using custom BIO too. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH: CVE-2011-1473]: Fight against DoS in openssl
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
Re: [PATCH: CVE-2011-1473]: Fight against DoS in openssl
Hi,
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
There is only 1GB memory in my testing machine, so I just tested with
254/254*2/254*5/254*10 client ip,
if got more client ip, the memory can be eaten up quickly(too many process
'openssl s_client').
the testing methord I used:
* compare the time used by the original openssl s_server(not applied the
patch), and the applied patch openssl s_server to process
lots of client's requests.
Hope your response and comment!
Regards,
Guanjun
On 12/12/2011 at 11:35 AM, in message
4ee5e6e60216b...@novprvlin0050.provo.novell.com, Guan Jun He
g...@suse.com wrote:
Hi,
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.
the test script looks like this:
#thc-ssl-dosit() { while :; do (while :; do echo R; done) | openssl s_client
-ssl3 -connect hostname:4433 2/dev/null; done }
thc-ssl-dosit() { openssl s_client -ssl3 -connect hostname:4433 2/dev/null;}
for x in `seq 1 5000`; do thc-ssl-dosit done
and looks like it works ok,and perform very well.
But, still, I can not give real pressure to the rb-tree, actually only 2
different ip address used,
and 'openssl s_client' have no option to use a bonding ip address, so, still
have no environment
to make a real pressure test.Do you have any method to do this?If someone
think add a bonding ip address
option is a good idea, please response.
The struct has been changed to use rb-tree, so, the performance can be
estimated.
Please response and comment!
thanks,
Guanjun
diff -Nupr openssl/ssl/s3_srvr.c openssl.1/ssl/s3_srvr.c
--- openssl/ssl/s3_srvr.c 2011-09-05 21:36:22.0 +0800
+++ openssl.1/ssl/s3_srvr.c 2011-12-19 16:56:10.0 +0800
@@ -169,6 +169,497 @@
#include openssl/krb5_asn.h
#endif
#include openssl/md5.h
+#include time.h
+
+static time_t start = 0;
+static int timer_interval = 300;/*5 min, these 2 values are configure-able*/
+static int dos_benchmark = 3000;
+
+typedef enum color_t
+{
+ RED = 0,
+ BLACK = 1
+}color_t;
+
+typedef struct rb_node_t
+{
+ struct rb_node_t *left, *right, *parent;
+ struct rb_node_t *next;/*also keep a simple list, for destroy a tree*/
+ unsigned long key;/*ip*/
+ unsigned long data;/*counter*/
+ color_t color;
+}rb_node_t;
+
+static rb_node_t* rb_dlist = NULL;
+static rb_node_t* rb_iter = NULL;
+static rb_node_t maxCounterNode;
+static rb_node_t* clist = NULL;
+static rb_node_t* blacklist = NULL;
+
+rb_node_t* rb_insert(unsigned long key, unsigned long data, rb_node_t* root);
+rb_node_t* rb_insert2(rb_node_t* node, rb_node_t* root);
+
+rb_node_t* rb_search(unsigned long key, rb_node_t* root);
+/*rb_node_t* rb_search(rb_node_t* node, rb_node_t* root);*/
+
+rb_node_t* rb_erase(unsigned long key, rb_node_t* root);
+/*rb_node_t* rb_erase(rb_node_t* node, rb_node_t* root);*/
+
+void rb_destroy(rb_node_t* root);
+
+void rb_destroy(rb_node_t* root)
+{
+ rb_node_t* tmp_node = NULL;
+ while(root)
+ {
+ tmp_node = root-next;
+ free(root);
+ root = tmp_node;
+ }
+}
+
+static rb_node_t* rb_new_node(unsigned long key, unsigned long data)
+{
+ rb_node_t *node = (rb_node_t*)malloc(sizeof(struct rb_node_t));
+ if (!node)
+ {
+ return NULL;
+ }
+ node-key = key;
+ node-data = data;
+ return node;
+}
+
+static rb_node_t* rb_rotate_left(rb_node_t* node, rb_node_t* root)
+{
+ rb_node_t* right = node-right;
+ if ((node-right = right-left))
+ {
+ right-left-parent = node;
+ }
+ right-left = node;
+
+ if ((right-parent = node-parent))
+ {
+ if (node == node-parent-right)
+ {
+ node-parent-right = right;
+ }
+ else
+ {
+ node-parent-left = right;
+ }
+ }
+ else
+ {
+ root = right;
+ }
+ node-parent = right;
+
+ return root;
+}
+
+static rb_node_t* rb_rotate_right(rb_node_t* node, rb_node_t* root)
+{
+ rb_node_t* left = node-left
[PATCH: CVE-2011-1473]: Fight against DoS in openssl
Hi,
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.
the test script looks like this:
#thc-ssl-dosit() { while :; do (while :; do echo R; done) | openssl s_client
-ssl3 -connect hostname:4433 2/dev/null; done }
thc-ssl-dosit() { openssl s_client -ssl3 -connect hostname:4433 2/dev/null;}
for x in `seq 1 5000`; do thc-ssl-dosit done
and looks like it works ok,and perform very well.
But, still, I can not give real pressure to the rb-tree, actually only 2
different ip address used,
and 'openssl s_client' have no option to use a bonding ip address, so, still
have no environment
to make a real pressure test.Do you have any method to do this?If someone think
add a bonding ip address
option is a good idea, please response.
The struct has been changed to use rb-tree, so, the performance can be
estimated.
Please response and comment!
thanks,
Guanjun
diff -Nupr openssl/ssl/s3_srvr.c openssl.1/ssl/s3_srvr.c
--- openssl/ssl/s3_srvr.c 2011-09-05 21:36:22.0 +0800
+++ openssl.1/ssl/s3_srvr.c 2011-12-09 13:14:56.0 +0800
@@ -169,6 +169,499 @@
#include openssl/krb5_asn.h
#endif
#include openssl/md5.h
+#include time.h
+
+static time_t start = 0;
+static int timer_interval = 300;/*5 min, these 2 values are configure-able*/
+static int dos_benchmark = 3000;
+
+typedef enum color_t
+{
+ RED = 0,
+ BLACK = 1
+}color_t;
+
+typedef struct rb_node_t
+{
+ struct rb_node_t *left, *right, *parent;
+ struct rb_node_t *next;/*also keep a simple list, for destroy a tree*/
+ unsigned long key;/*ip*/
+ unsigned long data;/*counter*/
+ color_t color;
+}rb_node_t;
+
+static rb_node_t* rb_dlist = NULL;
+static rb_node_t* rb_iter = NULL;
+static rb_node_t maxCounterNode;
+static rb_node_t* clist = NULL;
+static rb_node_t* blacklist = NULL;
+
+rb_node_t* rb_insert(unsigned long key, unsigned long data, rb_node_t* root);
+rb_node_t* rb_insert2(rb_node_t* node, rb_node_t* root);
+
+rb_node_t* rb_search(unsigned long key, rb_node_t* root);
+/*rb_node_t* rb_search(rb_node_t* node, rb_node_t* root);*/
+
+rb_node_t* rb_erase(unsigned long key, rb_node_t* root);
+/*rb_node_t* rb_erase(rb_node_t* node, rb_node_t* root);*/
+
+void rb_destroy(rb_node_t* root);
+
+void rb_destroy(rb_node_t* root)
+{
+ rb_node_t* tmp_node = NULL;
+ while(root)
+ {
+ tmp_node = root-next;
+ free(root);
+ root = tmp_node;
+ }
+}
+
+static rb_node_t* rb_new_node(unsigned long key, unsigned long data)
+{
+ rb_node_t *node = (rb_node_t*)malloc(sizeof(struct rb_node_t));
+ if (!node)
+ {
+ return NULL;
+ }
+ node-key = key;
+ node-data = data;
+ return node;
+}
+
+static rb_node_t* rb_rotate_left(rb_node_t* node, rb_node_t* root)
+{
+ rb_node_t* right = node-right;
+ if ((node-right = right-left))
+ {
+ right-left-parent = node;
+ }
+ right-left = node;
+
+ if ((right-parent = node-parent))
+ {
+ if (node == node-parent-right)
+ {
+ node-parent-right = right;
+ }
+ else
+ {
+ node-parent-left = right;
+ }
+ }
+ else
+ {
+ root = right;
+ }
+ node-parent = right;
+
+ return root;
+}
+
+static rb_node_t* rb_rotate_right(rb_node_t* node, rb_node_t* root)
+{
+ rb_node_t* left = node-left;
+
+ if ((node-left = left-right))
+ {
+ left-right-parent = node;
+ }
+ left-right = node;
+
+ if ((left-parent = node-parent))
+ {
+ if (node == node-parent-right)
+ {
+ node-parent-right = left;
+ }
+ else
+ {
+ node-parent-left = left;
+ }
+ }
+ else
+ {
+ root = left;
+ }
+ node-parent = left;
+
+ return root;
+}
+
+static rb_node_t* rb_insert_rebalance(rb_node_t *node, rb_node_t *root)
+{
+ rb_node_t *parent, *gparent, *uncle, *tmp;
+
+ while ((parent = node-parent) parent-color == RED)
+ {
+ gparent = parent-parent;
+ if (parent == gparent-left)
+ {
+ uncle = gparent-right;
+ if (uncle uncle-color == RED)
+ {
+ uncle-color = BLACK;
+ parent-color
Re: A possible way to against DoS in openssl
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 4ec3c40402169...@novprvlin0050.provo.novell.com, Guan Jun He g...@suse.com wrote: 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
Re: patch to add a switch for renegotiation (finding a solution against DoS)
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
patch to add a switch for renegotiation
Hello,
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.
Regards,
Guanjun
diff -Nupr openssl.orig//ssl/t1_lib.c openssl//ssl/t1_lib.c
--- openssl.orig//ssl/t1_lib.c 2011-11-15 16:52:13.0 +0800
+++ openssl//ssl/t1_lib.c 2011-11-15 17:00:53.0 +0800
@@ -1052,6 +1052,10 @@ int ssl_parse_clienthello_tlsext(SSL *s,
}
else if (type == TLSEXT_TYPE_renegotiate)
{
+ if (getenv(OPENSSL_NO_RENEGOTIATION) != NULL)
+ {
+ return 0;
+ }
if(!ssl_parse_clienthello_renegotiate_ext(s, data,
size, al))
return 0;
renegotiate_seen = 1;
Re: We want to add a switch to openssl's zlib compression methord
On 6/10/2011 at 09:35 PM, in message 20110610133552.ga26...@panix.com, Thor Lancelot Simon t...@panix.com wrote: On Fri, Jun 10, 2011 at 01:01:49PM +0200, Dr. Stephen Henson wrote: There is SSL_OP_NO_COMPRESSION. In that case, the suggestion to provide a config file setting for default options seems particularly excellent. Thanks a lot for your replys! So, I will prepare the patch, will be patch be accepted? Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org best, Guanjun __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: We want to add a switch to openssl's zlib compression methord
Thanks a lot for your reply! On 6/8/2011 at 09:42 PM, in message 20110608134254.ga6...@panix.com, Thor Lancelot Simon t...@panix.com wrote: On Tue, Jun 07, 2011 at 10:58:20PM -0600, Guan Jun He wrote: Hi, Openssl Developpers: We have a platform with cryptographic hardware,and we try to take advantage of the platform's hardware cryptographic features.But openSSL compresses data before the encryption, having a massive performance impact(throughput decrease, CPU load increase) on platforms with cryptographic hardware. There are probably two methords to work-around it: * environment variable, the attached patch is written for this methord. it's produced against oepnssl version 0.9.8, it other versions also need the patch,we are glad to submit it. * add an item to configure file openssl.cnf. What do you think about this? Again, I think this should be configured via an option on the SSL_CTX. this does not help performance impact on platforms with cryptographic hardware. Do you think like this: * on the SSL_CTX, make decesion to check if the cryptographic hardware exist(I am not clear how to detect,and I guess this is not a good idea), if true,then trun off compression; if false, then everything keep the same as default. (advantage: auto detect, no need configure step; disadvantage: no freedom to choose; detect methords may be complex.) or * Just move the option to SSL_CTX, do not care using environment variable or other methords. (why) best, Guanjun Thor __ 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
We want to add a switch to openssl's zlib compression methord
Hi, Openssl Developpers: We have a platform with cryptographic hardware,and we try to take advantage of the platform's hardware cryptographic features.But openSSL compresses data before the encryption, having a massive performance impact(throughput decrease, CPU load increase) on platforms with cryptographic hardware. There are probably two methords to work-around it: * environment variable, the attached patch is written for this methord. it's produced against oepnssl version 0.9.8, it other versions also need the patch,we are glad to submit it. * add an item to configure file openssl.cnf. What do you think about this? Thank you very much for your reply. best, Guanjun __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
答复： Re: ??? Re: [PATCH] to add a switch to openssl's compression methords
在 11:15 下午 的 5/25/2011 上，在讯息 20110525151556.ga5...@panix.com 中，Thor Lancelot Simon t...@panix.com 写入： On Tue, May 24, 2011 at 07:45:34PM -0600, Guan Jun He wrote: ? 10:23 ?? ? 5/24/2011 ? 20110524142324.ga29...@panix.com ??Thor Lancelot Simon t...@panix.com ??? On Tue, May 24, 2011 at 05:10:03PM +0800, GuanJun He wrote: Hi, This is a patch to add a switch to openssl's compression methords(if compression methords are configured to compile in, 'config zlib').Add an environment variable to control compression methords on and off.As you know,more and more architectures have hardware compression methords already, to get benifit from the hardware compression, and to get a good performance,we need a switch as this. I don't understand this. Are you suggesting that some hardware mechanism is trying to compress data _after_ OpenSSL handles it? Turning off compression in OpenSSL won't help with this, since the resulting SSL/TLS stream will stil be basically uncompressible. I mean OpenSSL compresses data before the encryption(zlib compiled in), having a massive performance impact (throughput decrease, CPU load increase) on platforms with cryptographic hardware. It seems to me you've said two differnt things, and I don't know which you mean. Do you mean on platforms with hardware compression methods or on platforms with cryptographic hardware? Or do you have a platform with both features, and a version of OpenSSL modified to take advantage of the platform's hardware cryptographic features, but not the platform's hardware compression features? I was in that situation for some time. Yes, I mean this.Have you made any progress on this? Before the engine's enhancements, we probably should also provide users a way to work-around it. For platforms with both features, there is really a performance reduction. Till now, I can think of two methords to work-around it: *#1* environment variable (easiest way) *#2* add an item to configure file openssl.cnf (no essential difference from methord #1) Do you agree this? or what do you think about this? Thanks! I personally think that compression in OpenSSL needs to be made a first-class transform such that it can be handed off to engines. Though of course the engine interface needs other enhancements to deal with platforms that can do fused transforms like compress-then-encrypt-then-MAC, or full-on SSL record handling. But it would be a start. I think it should also be the case that compression (or not) should be selectable via the existing interface for setting options on the SSL_CTX. That would provide a more elegant way of dealing with the issue you're seeing (which I assume is triggered by an increased number of peers who want to do compression at the SSL layer because of the support for this in Chrome and in Google's server software) rather than an environent variable work-around. This is a good idea, make it negotiate-able in SSL session.and the work-around environent variable can also work with it together, and provide users a control to use the compression or not.After the engine is enhanced, we can easily disable the environment variable or remove it. best, Guanjun Thor __ 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
答复： Re: [PATCH] to add a switch to openssl's compression methords
在 10:23 下午 的 5/24/2011 上，在讯息 20110524142324.ga29...@panix.com 中，Thor Lancelot Simon t...@panix.com 写入： On Tue, May 24, 2011 at 05:10:03PM +0800, GuanJun He wrote: Hi, This is a patch to add a switch to openssl's compression methords(if compression methords are configured to compile in, 'config zlib').Add an environment variable to control compression methords on and off.As you know,more and more architectures have hardware compression methords already, to get benifit from the hardware compression, and to get a good performance,we need a switch as this. I don't understand this. Are you suggesting that some hardware mechanism is trying to compress data _after_ OpenSSL handles it? Turning off compression in OpenSSL won't help with this, since the resulting SSL/TLS stream will stil be basically uncompressible. Or, are you suggesting that some hardware mechanism has compressed the application-layer data _before_ OpenSSL sees it, and thus the compression in OpenSSL is just a waste of cycles? thank you very much for your reply! And sorry for my unclear descriptions. I mean OpenSSL compresses data before the encryption(zlib compiled in), having a massive performance impact (throughput decrease, CPU load increase) on platforms with cryptographic hardware.So, when using openssl with zlib compiled in, we expect to have a switch provided to user to configure whether compression is on or off.then, if on platforms with cryptographic hardware, users can simply turn the compression off. Do you have any advice to this? and please feel free to comment. Either way, it might be better to add explicit support for offloading compression to hardware. This can be done through /dev/crypto on NetBSD, for example, but unfortunately OpenSSL's engine for /dev/crypto is old and does not know how to use this feature. This may be another feature I think.And also, I'm interested in it. thanks a lot, Guanjun Thor __ 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
openssl-0.9.8k ./Configure --test-sanity got failed
Dear everyone I got the openssl-0.9.8k package from openssl.org, then I run the command './Configure --test-sanity',and I got the following error, g...@macintyre:~/project/stable/openssl-0.9.8k ./Configure --test-sanity == === SANITY TESTING! === No configuration will be done, all other arguments will be ignored! == SANITY ERROR: 'debug-steve-opt' has the dso_scheme [18] values in the following field SANITY ERROR: 'debug-steve64' has the dso_scheme [18] values in the following field it seems that there is something wrong in the Configure file. is there a patch to fix this? thanks a lot, Guanjun
