Re: [vote] release 2.2.15?
On 3/3/2010 4:41 PM, Joe Orton wrote: On Wed, Mar 03, 2010 at 11:21:47PM +0100, Mladen Turk wrote: SSLInsecureRenegotiation off echo R | openssl-0.9.8m s_client .. disconnects echo R | openssl-0.9.8k s_client .. hangs until ServerTimeout Ah, right, hmm. Yes, this is exactly as Bill says, the client is ignoring the alert and then the server is hanging until a read times out. This consumes exactly the same amount of server resources as the client doing nothing with the connection. I'm not sure why the connection is not being forcibly closed by the server in this case, but: a) it's certainly not a security issue b) real clients don't initiate reneg, so it's not a practical issue You were incorrect in your statement b) above; http://marc.info/?l=openssl-devm=125873536926916w=2 suggests real (handheld/phone) implementations that do this (or perhaps it was really their proxy/gateway).
Re: [vote] release 2.2.15?
Coming up on 80 hours I'm +1 Tested on 32 bit versions of Windows 2k, XP, Vista
Re: [vote] release 2.2.15?
On 3/5/2010 9:21 AM, Gregg L. Smith wrote: Coming up on 80 hours I'm +1 Tested on 32 bit versions of Windows 2k, XP, Vista And I'm +1 as well, although my battles with win32 descended into the state of zlib-next which was a significant distraction. [Binaries will be prepared with 0.9.8m, but were also verified against .8k to test compilations]. We don't seem to have a conclusion, but there doesn't seem to be a majority concern about the interop with openssl 0.9.8m clients on client initiated renegotiation. It is unlikely to be encountered in the wild, and eating Timeout periods of time is demonstrably not hard to do. Preparing an announce while staging this for release.
Re: [vote] release 2.2.15?
On Wed, Mar 03, 2010 at 10:40:34PM +, Dr Stephen Henson wrote: Joe Orton wrote: On Wed, Mar 03, 2010 at 06:31:36PM +, Dr Stephen Henson wrote: Note that you don't need to abort if secure renegotiation is supported by the client. Is there any technical need to support client-initiated reneg? It's a bad fit with mod_ssl. It has been reported that some clients (not OpenSSL based unless the application explicitly requests it) do renegotiate periodically. In one case sending back the no renegotiation alert to an unpatched client (*definitely* not OpenSSL based) meant the connection continued correctly. Was this an HTTP client, do you have a reference for that? I was only aware of use of SSL for protocols other than HTTP for which there were known cases of client-initiated reneg. I've no idea how widespread this is though. It's something which just worked before and there'd be no reason to notice it. For mod_ssl, e.g. I don't think things like SSLCipherSuite will be enforced correctly for a client-initated reneg which didn't involve a client cert request; there's no callback into mod_ssl to check it. So I'm fairly happy with refusing client-initiated reneg regardless. Regards, Joe
Re: [vote] release 2.2.15?
On 03/04/2010 12:29 AM, Joe Orton wrote: I'm fairly happy with refusing client-initiated reneg regardless. +1 Explicit OpenSSL option e.g. SSL_OP_DISABLE_CLIENT_INITED_RENEGOTIATION would be helpful and we won't be needing info callback in that case (which doesn't get called from SSL_CB_ACCEPT_LOOP for legacy clients anyhow) Regards -- ^TM
Re: [vote] release 2.2.15?
On Mar 3, 2010, at 9:28 AM, Dan Poirier wrote: [Non-binding] +1 md5sums good sha1sums good pgp sig matches that in http://www.apache.org/dist/httpd/KEYS Mac OS 10.6.2 (Snow Leopard): No regressions from 2.2.14, though you still have to build with CC=cc -m32 to get a working server, and there are still test failures, but the same ones as in 2.2.14. I use -arch i386 which is more wide-ranging and ensures some capability with older libs Linux RHEL-5 x86: Built okay, all tests passed. Dan
Re: [vote] release 2.2.15?
+1 (ugg BOM)
RE: [vote] release 2.2.15?
-Original Message- From: William A. Rowe Jr. [mailto:wr...@rowe-clan.net] Sent: Dienstag, 2. März 2010 07:09 To: Apache HTTP Server Development List Subject: [vote] release 2.2.15? Candidate at the usual /dev/dist/ URL; Your votes please... +/-1 [ ] Release 2.2.15 I'll proceed to fight with win32 tomorrow, fighting with my linux vm was enough fun for one day :) +1 Tested on Solaris 8 / 9 / 10 SPARC RHEL 4 / 5, 32 / 64 Bit Regards Rüdiger
Re: [vote] release 2.2.15?
On Tuesday 02 March 2010 08:09:07 William A. Rowe Jr. wrote: Candidate at the usual /dev/dist/ URL; Your votes please... +/-1 [ ] Release 2.2.15 I'll proceed to fight with win32 tomorrow, fighting with my linux vm was enough fun for one day :) Tested in TFM Linux 32/64 +1 -- Best regards, Mihai Moldovanu TFM Group Software -- Acest document apartine grupului de companii MPI / Pro Tv. Cu toate ca au fost luate masuri pentru a controla raspandirea virusilor, acest mesaj, impreuna cu orice atasament continut, este destinat numai pentru folosinta persoanei / persoanelor carora i se adreseaza si poate contine informatii confidentiale, care sunt supuse dreptului de autor sau constituie secret de marca. Daca nu sunteti destinatarul acestui mesaj, va notificam ca este strict interzisa orice transmitere, copiere sau distribuire a acestuia sau a oricarui atasament continut de acesta. Daca ati primit acest mesaj din greseala, va rugam sa ne anuntati imediat printr-un e-mail trimis la adresa postmas...@protv.ro This document originates from within the MPI/Pro TV group of companies. Whilst we have taken steps to control the spread of viruses, this message together with any associated files, is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient of this communication you are hereby notified that any dissemination, copying or distribution of this message, or any files associated with this message, is strictly prohibited. If you have received this message in error, please notify us at once Mail to: postmas...@protv.ro --
Re: [vote] release 2.2.15?
[+1] Release 2.2.15 Testing looks good on Fedora 12/x86_64. diff vs .14 is fine, sigs good, CHANGES good. Thanks for RM-ing! Minor note: a BOM has mysteriously appeared in CHANGES again :) Regards, Joe
Re: [vote] release 2.2.15?
[Non-binding] +1 md5sums good sha1sums good pgp sig matches that in http://www.apache.org/dist/httpd/KEYS Mac OS 10.6.2 (Snow Leopard): No regressions from 2.2.14, though you still have to build with CC=cc -m32 to get a working server, and there are still test failures, but the same ones as in 2.2.14. Linux RHEL-5 x86: Built okay, all tests passed. Dan
Re: [vote] release 2.2.15?
On 03/02/2010 07:09 AM, William A. Rowe Jr. wrote: Candidate at the usual /dev/dist/ URL; Your votes please... +/-1 [ X] Release 2.2.15 Win32/Win64/Fedora12/Solaris10 I'll proceed to fight with win32 tomorrow, fighting with my linux vm was enough fun for one day :) BTW, I wouldn't recommend to compile against 0.9.8m. openssl s_client 0.9.8m block on renegotiation Regards -- ^TM
Re: [vote] release 2.2.15?
On Wednesday 03 March 2010, Mladen Turk wrote: BTW, I wouldn't recommend to compile against 0.9.8m. openssl s_client 0.9.8m block on renegotiation Have you only tried 0.9.8l as client? It has a known bug with renegotiation that makes it hang instead of fail. I have no problems with 0.9.8c and 0.9.8g (from Debian 4.0 and 5.0). If SSLInsecureRenegotiation is on, it works. If SSLInsecureRenegotiation is off, I get an sslv3 alert handshake failure.
Re: [vote] release 2.2.15?
On 3/3/2010 11:50 AM, Stefan Fritsch wrote: On Wednesday 03 March 2010, Mladen Turk wrote: BTW, I wouldn't recommend to compile against 0.9.8m. openssl s_client 0.9.8m block on renegotiation Have you only tried 0.9.8l as client? It has a known bug with renegotiation that makes it hang instead of fail. I have no problems with 0.9.8c and 0.9.8g (from Debian 4.0 and 5.0). If SSLInsecureRenegotiation is on, it works. If SSLInsecureRenegotiation is off, I get an sslv3 alert handshake failure. And the bug is specific to openssl 0.9.8m mishandling the alert; it will neither abort nor resume the prior session, so it is left to timeout. You may want to contrast this behavior to legacy IE, Firefox, etc. Attached is one suggestion of a workaround. ---BeginMessage--- On Thu, Feb 25, 2010, Victor Duchovni wrote: If I field a patched server, and sufficiently many unpatched pre-0.9.8m OpenSSL clients attempt re-negotiation under normal conditions, I have a resource starvation problem and unhappy users who are more annoyed at stuck connections than failed ones. It would under normal circumstances (for some value of normal) require a specific request to renegotiate from the client code or setting of renegotiation values in an SSL BIO. I don't know how many clients do that: I suspect (and hope!) not many. Thanks for the suggested patch, I'll chat to our web-plant team to find out which of the two non-optimal behaviours they are more comfortably with. An alternative which doesn't require modification of OpenSSL is to make use of the info callback which gets called when an alert is sent. That could be used to either just indicate the connection should be closed or (for example) set a smaller timeout value. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-us...@openssl.org Automated List Manager majord...@openssl.org ---End Message---
Re: [vote] release 2.2.15?
On Tuesday 02 March 2010, William A. Rowe Jr. wrote: Candidate at the usual /dev/dist/ URL; Your votes please... +/-1 [+1] Release 2.2.15 Compiles and works on Debian unstable.
Re: [vote] release 2.2.15?
William A. Rowe Jr. wrote: On 3/3/2010 11:50 AM, Stefan Fritsch wrote: On Wednesday 03 March 2010, Mladen Turk wrote: BTW, I wouldn't recommend to compile against 0.9.8m. openssl s_client 0.9.8m block on renegotiation Have you only tried 0.9.8l as client? It has a known bug with renegotiation that makes it hang instead of fail. I have no problems with 0.9.8c and 0.9.8g (from Debian 4.0 and 5.0). If SSLInsecureRenegotiation is on, it works. If SSLInsecureRenegotiation is off, I get an sslv3 alert handshake failure. And the bug is specific to openssl 0.9.8m mishandling the alert; it will neither abort nor resume the prior session, so it is left to timeout. You may want to contrast this behavior to legacy IE, Firefox, etc. Attached is one suggestion of a workaround. If I understand the code correctly it looks like Apache is already trapping and aborting client initiated renegotiations so this hang situation shouldn't arise. Note that you don't need to abort if secure renegotiation is supported by the client. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: [vote] release 2.2.15?
On 03/03/2010 07:02 PM, William A. Rowe Jr. wrote: On 3/3/2010 11:50 AM, Stefan Fritsch wrote: On Wednesday 03 March 2010, Mladen Turk wrote: BTW, I wouldn't recommend to compile against 0.9.8m. openssl s_client 0.9.8m block on renegotiation Have you only tried 0.9.8l as client? It has a known bug with renegotiation that makes it hang instead of fail. I have no problems with 0.9.8c and 0.9.8g (from Debian 4.0 and 5.0). If SSLInsecureRenegotiation is on, it works. If SSLInsecureRenegotiation is off, I get an sslv3 alert handshake failure. And the bug is specific to openssl 0.9.8m mishandling the alert; it will neither abort nor resume the prior session, so it is left to timeout. You may want to contrast this behavior to legacy IE, Firefox, etc. Right, and I'm afraid if SSLInsecureRenegotiation (default) isn't set while compiled with 0.9.8m one can easily create an DoS attack. I might be wrong, but if the client is 0.9.8k it just stays connected for server timeout. Sure it's disconnected if SSLInsecureRenegotiation is set, but then what's the point? Regards -- ^TM
Re: [vote] release 2.2.15?
On 3/3/2010 2:00 PM, Mladen Turk wrote: Right, and I'm afraid if SSLInsecureRenegotiation (default) isn't set while compiled with 0.9.8m one can easily create an DoS attack. Stop. I can accomplish the same within the confines of the Timeout limitation by connecting to the server, sending an OPTIONS line, and not completing the request headers. The effect is the same. Please don't abuse words like DoS to describe utilization. Of course IE and Firefox, Opera and Safari are all DoS tools. It's called consuming server resources :)
Re: [vote] release 2.2.15?
On Wed, Mar 03, 2010 at 06:31:36PM +, Dr Stephen Henson wrote: If I understand the code correctly it looks like Apache is already trapping and aborting client initiated renegotiations so this hang situation shouldn't arise. This is true for client-initiated reneg, I'm not sure whether Mladen was talking about client- or server- initiated reneg, Mladen can you clarify exactly what problem you're seeing? Note that you don't need to abort if secure renegotiation is supported by the client. Is there any technical need to support client-initiated reneg? It's a bad fit with mod_ssl. Regards, Joe
Re: [vote] release 2.2.15?
On 03/03/2010 10:34 PM, William A. Rowe Jr. wrote: On 3/3/2010 2:00 PM, Mladen Turk wrote: Right, and I'm afraid if SSLInsecureRenegotiation (default) isn't set while compiled with 0.9.8m one can easily create an DoS attack. Stop. Weather I stop or not it will not make that disappear :) Please don't abuse words like DoS to describe utilization. Of course IE and Firefox, Opera and Safari are all DoS tools. It's called consuming server resources :) while [ true ]; do echo R | openssl s_client -connect host:port done Not only it will kill the server, but it will kill your box as well :) Seriously, I was hoping 0.9.8m will reject legacy clients, unless explicitly SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION is set, but it seems that's not the case or we are doing something wrong in mod_ssl. Regards -- ^TM
Re: [vote] release 2.2.15?
On 03/03/2010 11:01 PM, Joe Orton wrote: On Wed, Mar 03, 2010 at 06:31:36PM +, Dr Stephen Henson wrote: If I understand the code correctly it looks like Apache is already trapping and aborting client initiated renegotiations so this hang situation shouldn't arise. This is true for client-initiated reneg, I'm not sure whether Mladen was talking about client- or server- initiated reneg, Mladen can you clarify exactly what problem you're seeing? Very simple to duplicate, just find any = 0.9.8k client mod_ssl + openssl-0.9.8m SSLInsecureRenegotiation on echo R | openssl-0.9.8m s_client .. disconnects echo R | openssl-0.9.8k s_client .. disconnects SSLInsecureRenegotiation off echo R | openssl-0.9.8m s_client .. disconnects echo R | openssl-0.9.8k s_client .. hangs until ServerTimeout Client reneg is rejected by our info callback (which might be good or not, but that's not the point) except with 0.9.8m and legacy clients. Regards -- ^TM
Re: [vote] release 2.2.15?
On 3/3/2010 4:04 PM, Mladen Turk wrote: while [ true ]; do echo R | openssl s_client -connect host:port done Not only it will kill the server, but it will kill your box as well :) That's what IP tables is for. It's no different than while [ true ]; do echo OPTIONS * HTTP/1.1 | openssl s_client -connect host:port done demonstrating that your DoS concern is unfounded. The hang *does* timeout, doesn't it? I'm not arguing against a fix, I'm disputing your allegation of a DoS. Seriously, I was hoping 0.9.8m will reject legacy clients, unless explicitly SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION is set, but it seems that's not the case or we are doing something wrong in mod_ssl. It rejects the renegotation. It is the callers responsibility to continue or die. Dr Henson's suggested approach is that we drop the timeout to some 5 seconds or less, in this case, until they resume the connection. Assorted clients are known to trigger a renegotiation periodically (expired their session?) and to not die but alert-and-continue helps this phone-browser world.
Re: [vote] release 2.2.15?
Joe Orton wrote: On Wed, Mar 03, 2010 at 06:31:36PM +, Dr Stephen Henson wrote: Note that you don't need to abort if secure renegotiation is supported by the client. Is there any technical need to support client-initiated reneg? It's a bad fit with mod_ssl. It has been reported that some clients (not OpenSSL based unless the application explicitly requests it) do renegotiate periodically. In one case sending back the no renegotiation alert to an unpatched client (*definitely* not OpenSSL based) meant the connection continued correctly. I've no idea how widespread this is though. It's something which just worked before and there'd be no reason to notice it. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
Re: [vote] release 2.2.15?
On Wed, Mar 03, 2010 at 11:21:47PM +0100, Mladen Turk wrote: SSLInsecureRenegotiation off echo R | openssl-0.9.8m s_client .. disconnects echo R | openssl-0.9.8k s_client .. hangs until ServerTimeout Ah, right, hmm. Yes, this is exactly as Bill says, the client is ignoring the alert and then the server is hanging until a read times out. This consumes exactly the same amount of server resources as the client doing nothing with the connection. I'm not sure why the connection is not being forcibly closed by the server in this case, but: a) it's certainly not a security issue b) real clients don't initiate reneg, so it's not a practical issue Regards, Joe
Re: [vote] release 2.2.15?
On 03/03/2010 11:33 PM, William A. Rowe Jr. wrote: Seriously, I was hoping 0.9.8m will reject legacy clients, unless explicitly SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION is set, but it seems that's not the case or we are doing something wrong in mod_ssl. It rejects the renegotation. It is the callers responsibility to continue or die. Dr Henson's suggested approach is that we drop the timeout to some 5 seconds or less, in this case, until they resume the connection. Sure that could be the solution if there is no option to tell the server to make that decision. Regards -- ^TM
Re: [vote] release 2.2.15?
On 3/3/2010 4:41 PM, Joe Orton wrote: b) real clients don't initiate reneg, so it's not a practical issue ^ OpenSSL Note that other real clients based on other libraries aren't likely to share the exact same flaw as OpenSSL in accepting the renegotiation failure or terminating the connection if that wasn't an acceptable answer.
Re: [vote] release 2.2.15?
On 3/3/2010 4:44 PM, Mladen Turk wrote: Sure that could be the solution if there is no option to tell the server to make that decision. It's not the server's to make, this alert follows the TLS specification.
Re: [vote] release 2.2.15?
On 03/03/2010 11:45 PM, William A. Rowe Jr. wrote: On 3/3/2010 4:44 PM, Mladen Turk wrote: Sure that could be the solution if there is no option to tell the server to make that decision. It's not the server's to make, this alert follows the TLS specification. Didn't meant that, but anyhow... Still doesn't smell clean, but seems everyone else think this is not an issue, so fine with me. Regards -- ^TM
Re: [vote] release 2.2.15?
On 3/3/2010 4:52 PM, Mladen Turk wrote: On 03/03/2010 11:45 PM, William A. Rowe Jr. wrote: On 3/3/2010 4:44 PM, Mladen Turk wrote: Sure that could be the solution if there is no option to tell the server to make that decision. It's not the server's to make, this alert follows the TLS specification. Didn't meant that, but anyhow... Still doesn't smell clean, but seems everyone else think this is not an issue, so fine with me. If you want a workaround that is, in absolute terms, a server decision, then we just ensure that an 'SSLAlertTimeout nnn' directive will accept an argument of 0, timeout immediately.
Re: [vote] release 2.2.15?
On 04 Mar 2010, at 12:04 AM, Mladen Turk wrote: while [ true ]; do echo R | openssl s_client -connect host:port done Not only it will kill the server, but it will kill your box as well :) If it causes the connection to hang, it is no different to just telnetting to the server and talking enough of the protocol to keep the connection open for the full Timeout. That doesn't fit the definition of kill the server. If httpd/openssl/whatever started spinning, then it would be a whole different matter, but I am assuming that isn't the case here. Regards, Graham --
Re: [vote] release 2.2.15?
On 3/3/2010 5:36 PM, Graham Leggett wrote: On 04 Mar 2010, at 12:04 AM, Mladen Turk wrote: while [ true ]; do echo R | openssl s_client -connect host:port done Not only it will kill the server, but it will kill your box as well :) If it causes the connection to hang, it is no different to just telnetting to the server and talking enough of the protocol to keep the connection open for the full Timeout. Oh no - this is far more intensive; due to the cpu overhead of SSL handshaking. But as long as your server is accepting https: connections...
Re: [vote] release 2.2.15?
On Tue, Mar 2, 2010 at 1:09 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Candidate at the usual /dev/dist/ URL; Your votes please... It is worth pointing out that * httpd 2.2.15 bundles APR 1.4.2 but continues to support APR 1.3.x. * Solaris users of httpd with unbundled APR 1.3.9 should upgrade APR to 1.3.12 or 1.4.2.
Re: [vote] release 2.2.15?
On 3/2/2010 5:38 AM, Jeff Trawick wrote: On Tue, Mar 2, 2010 at 1:09 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Candidate at the usual /dev/dist/ URL; Your votes please... It is worth pointing out that * httpd 2.2.15 bundles APR 1.4.2 but continues to support APR 1.3.x. * Solaris users of httpd with unbundled APR 1.3.9 should upgrade APR to 1.3.12 or 1.4.2. We will advise this in the announce; good point Jeff.
Re: [vote] release 2.2.15?
On Tue, Mar 2, 2010 at 1:09 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Candidate at the usual /dev/dist/ URL; Your votes please... +/-1 [+1] Release 2.2.15 Solaris 10 U5/x86, Sun Studio, 32-bit and 64-bit builds, latest httpd test suite successful (skipped tests for case_filter[_in], bucketeer, echo, PHP) Thanks!
Re: [vote] release 2.2.15?
On 02 Mar 2010, at 7:50 PM, William A. Rowe Jr. wrote: Candidate at the usual /dev/dist/ URL; Your votes please... Tested ok on MacOSX v10.5, Centos 5.4 and RHEL 5.3. +1. Regards, Graham --
Re: [vote] release 2.2.15?
good news! 2010/3/2 William A. Rowe Jr. wr...@rowe-clan.net Candidate at the usual /dev/dist/ URL; Your votes please... +/-1 [ ] Release 2.2.15 I'll proceed to fight with win32 tomorrow, fighting with my linux vm was enough fun for one day :)
