Hi, since I couldn't find a better place I'm sending a simple patch that allows to disable SSL renegotiation here. Possible reasons for this: - famous renegotiation SSL flaw, patched in OpenSSL a long time ago, but not everyone can or want to upgrade OpenSSL - renegotiation makes some DoS attacks much easier (see http://www.thc.org/thc-ssl-dos/), regardless of it being a secure one or not - it is really not needed in many cases
The approach is based on what is being done in Apache. The default is to allow renegotation, so there should be no surprises for anyone after upgrade. Patch applies on latest (4.54b4) stunnel beta. Feel free to comment:)
2012/6/27 Janusz Dziemidowicz [email protected]:
Hi, since I couldn't find a better place I'm sending a simple patch that allows to disable SSL renegotiation here. Possible reasons for this:
- famous renegotiation SSL flaw, patched in OpenSSL a long time ago,
but not everyone can or want to upgrade OpenSSL
- renegotiation makes some DoS attacks much easier (see
http://www.thc.org/thc-ssl-dos/), regardless of it being a secure one or not
- it is really not needed in many cases
The approach is based on what is being done in Apache. The default is to allow renegotation, so there should be no surprises for anyone after upgrade. Patch applies on latest (4.54b4) stunnel beta. Feel free to comment:)
I was kinda hoping for some feedback and maybe inclusion of the patch in the next stunnel release;) Or should I send it elsewhere?
On 2012-08-02 21:01, Janusz Dziemidowicz wrote:
I was kinda hoping for some feedback and maybe inclusion of the patch in the next stunnel release;) Or should I send it elsewhere?
I have uploaded your patch to: ftp://ftp.stunnel.org/stunnel/contrib/stunnel-4.54b4-renegotiation.diff
There are two reasons your patch won't be included in stunnel: 1. I refuse to include workarounds for issues (to be) fixed in OpenSSL. Using an outdated OpenSSL is a very bad idea. 2. Licensing: http://www.stunnel.org/pipermail/stunnel-announce/2011-January/000050.html
Mike
2012/8/2 Michal Trojnara [email protected]:
On 2012-08-02 21:01, Janusz Dziemidowicz wrote:
I was kinda hoping for some feedback and maybe inclusion of the patch in the next stunnel release;) Or should I send it elsewhere?
I have uploaded your patch to: ftp://ftp.stunnel.org/stunnel/contrib/stunnel-4.54b4-renegotiation.diff
There are two reasons your patch won't be included in stunnel:
- I refuse to include workarounds for issues (to be) fixed in OpenSSL.
Using an outdated OpenSSL is a very bad idea. 2. Licensing: http://www.stunnel.org/pipermail/stunnel-announce/2011-January/000050.html
Thanks for your feedback. However, the first point is not what this patch is about. The main reason for this patch was to make DoS attacks, using renegotiation, on SSL services harder (as is explained in provided link). Renegotiation support has nothing to do with OpenSSL and is a feature of SSL/TLS protocol itself (it really doesn't matter what kind of renegotiation is used, insecure or secure). Renegotiation is used sometimes (it is present in SSL/TLS for a reason), but in many cases it is completely unnecessary (HTTP doesn't need this), so this patch makes it possible to disable it. It is not about insecure renegotiation flaw (but it can prevent this too, as a side effect, hence my note about this).
I'm not sure what I'am supposed to do with the licensing. From my point of view I can release it as public domain (whatever that requires).
On 2012-08-03 17:53, Janusz Dziemidowicz wrote:
I'm not sure what I'am supposed to do with the licensing. From my point of view I can release it as public domain (whatever that requires).
Thank you. I can reconsider your patch if you declare you patch public domain.
In the mean time these links may be interesting to you:
* http://vincent.bernat.im/en/blog/2011-ssl-dos-mitigation.html * ftp://ftp.stunnel.org/sslsqueeze/
Mike
2012/8/5 Michal Trojnara [email protected]:
On 2012-08-03 17:53, Janusz Dziemidowicz wrote:
I'm not sure what I'am supposed to do with the licensing. From my point of view I can release it as public domain (whatever that requires).
Thank you. I can reconsider your patch if you declare you patch public domain.
Then I declare that the SSL renegotiation stunnel patch, attached to the beginning of this thread, is hereby released into the public domain, with no rights reserved.
In the mean time these links may be interesting to you:
http://vincent.bernat.im/en/blog/2011-ssl-dos-mitigation.html ftp://ftp.stunnel.org/sslsqueeze/
Nice idea with iptables magic. However, as the author points, bypassing it should be quite simple (splitting SSL handshake across packet boundary should be even simpler than IP fragmentation). People usually are caught off-hand with DoS attacks, and disabling renegotiation with TCP rate limiting is a much cleaner solution (but obviously not perfect).
On 2012-08-07 23:28, Janusz Dziemidowicz wrote:
Then I declare that the SSL renegotiation stunnel patch, attached to the beginning of this thread, is hereby released into the public domain, with no rights reserved.
The patch is integrated into: http://www.stunnel.org/downloads/beta/stunnel-4.54b7.tar.gz http://www.stunnel.org/sdf_ChangeLog.html
Mike
On Wed, Jun 27, 2012 at 11:42 PM, Janusz Dziemidowicz [email protected] wrote:
Hi,
The approach is based on what is being done in Apache. The default is to allow renegotation, so there should be no surprises for anyone after upgrade. Patch applies on latest (4.54b4) stunnel beta. Feel free to comment:)
sorry for not noticing this patch earlier, what is the best way the test the effects of this patch. i.e. what test client did you use?
Thanks, Henrik
2012/9/18 Henrik Riomar [email protected]:
On Wed, Jun 27, 2012 at 11:42 PM, Janusz Dziemidowicz [email protected] wrote:
Hi,
The approach is based on what is being done in Apache. The default is to allow renegotation, so there should be no surprises for anyone after upgrade. Patch applies on latest (4.54b4) stunnel beta. Feel free to comment:)
sorry for not noticing this patch earlier, what is the best way the test the effects of this patch. i.e. what test client did you use?
You can use gnutls-cli: gnutls-cli --insecure --port 8443 localhost -e or s_client from stunnel: openssl s_client -host localhost -port 8443 -tls1 With s_client, you have to input R and press Enter, it will try to renegotiate then (awesome hack). Also, note that s_client has problems while renegotiating with TLS1.2 (that's why I've added -tls1 option).
With renegotiation set to yes (default), both of the above should succeed. With set to no, the client will be disconnected as soon as i tries to renegotiate.
You can also use online scanner like https://www.ssllabs.com/ssltest/index.html to verify this, if your stunnel instance is available from the Internet.
On Wed, Sep 19, 2012 at 1:57 PM, Janusz Dziemidowicz [email protected] wrote:
2012/9/18 Henrik Riomar [email protected]:
On Wed, Jun 27, 2012 at 11:42 PM, Janusz Dziemidowicz [email protected] wrote:
Hi,
The approach is based on what is being done in Apache. The default is to allow renegotation, so there should be no surprises for anyone after upgrade. Patch applies on latest (4.54b4) stunnel beta. Feel free to comment:)
sorry for not noticing this patch earlier, what is the best way the test the effects of this patch. i.e. what test client did you use?
You can use gnutls-cli: gnutls-cli --insecure --port 8443 localhost -e or s_client from stunnel: openssl s_client -host localhost -port 8443 -tls1 With s_client, you have to input R and press Enter, it will try to renegotiate then (awesome hack). Also, note that s_client has problems while renegotiating with TLS1.2 (that's why I've added -tls1 option).
OK, I tried with gnutls-cli-debug -p 1443 127.0.0.1
...snip... Checking for Safe renegotiation support... yes Checking for Safe renegotiation support (SCSV)... yes ...snip...
The above is towards a build of stunnel-4.54b8.tar.gz with "renegotiation = no" in the config.
On Wed, Sep 19, 2012 at 1:57 PM, Janusz Dziemidowicz
or s_client from stunnel: openssl s_client -host localhost -port 8443 -tls1 With s_client, you have to input R and press Enter, it will try to renegotiate then (awesome hack). Also, note that s_client has problems while renegotiating with TLS1.2 (that's why I've added -tls1 option).
Tried this and got this printout; New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 1024 bit Secure Renegotiation IS supported
Sure enough I get connection close when I send 'R' but why are is stunnel "reporting" that it IS supported?
2012/9/19 Henrik Riomar [email protected]:
On Wed, Sep 19, 2012 at 1:57 PM, Janusz Dziemidowicz
or s_client from stunnel: openssl s_client -host localhost -port 8443 -tls1 With s_client, you have to input R and press Enter, it will try to renegotiate then (awesome hack). Also, note that s_client has problems while renegotiating with TLS1.2 (that's why I've added -tls1 option).
Tried this and got this printout; New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 1024 bit Secure Renegotiation IS supported
This is the same as in gnutls-cli-debug case. It only tells the client that the server understands a secure renegotiation protocol (as opposed to older, insecure renegotiation method). It has nothing to do with the fact that the server will not accept renegotiations (and renegotiations can also be started by the server itself). SSL protocol does not have any way to indicate that a server will not accept renegotiations. It is also not possible to reject them in other way than disconnection. That is why renegotiations are enabled by default. You can disable them if you are confident that they won't be used (which is true in some common cases like most HTTPS scenarios).
On Wed, Sep 19, 2012 at 3:23 PM, Janusz Dziemidowicz [email protected] wrote:
This is the same as in gnutls-cli-debug case. It only tells the client that the server understands a secure renegotiation protocol (as opposed to older, insecure renegotiation method). It has nothing to do with the fact that the server will not accept renegotiations (and renegotiations can also be started by the server itself). SSL protocol does not have any way to indicate that a server will not accept renegotiations. It is also not possible to reject them in other way than disconnection. That is why renegotiations are enabled by default. You can disable them if you are confident that they won't be used (which is true in some common cases like most HTTPS scenarios).
Ahh OK that explains, thanks!
/ Henrik
2012/9/19 Henrik Riomar [email protected]:
OK, I tried with gnutls-cli-debug -p 1443 127.0.0.1
...snip... Checking for Safe renegotiation support... yes Checking for Safe renegotiation support (SCSV)... yes ...snip...
The above is towards a build of stunnel-4.54b8.tar.gz with "renegotiation = no" in the config.
The above is totally unrelated to this patch. It only reports if the server indicates that it supports secure renegotiation (as opposed to older, insecure method of renegotiation). It does not tell you if the server will accept renegotiation request from the client (and the renegotiation can be started by a server, so the indication is in fact correct). If a client actually tries to start renegotiation with "renegotiation =no" it will fail. I've described how to do it in my previous e-mail.
-
Henrik Riomar -
Janusz Dziemidowicz -
Michal Trojnara