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-dev&m=125873536926916&w=2 suggests real (handheld/phone) implementations that do this (or perhaps it was really their proxy/gateway).
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?
Coming up on 80 hours I'm +1 Tested on 32 bit versions of Windows 2k, XP, Vista
Re: [vote] release 2.2.15?
+1 (ugg BOM)
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?
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 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 04 Mar 2010, at 2:02 AM, William A. Rowe Jr. wrote: 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... And the only way such a connection is possible is if the admin has explicitly enabled https connections, in which case there is no additional risk over the risk the admin already faces by virtue of simply being plugged into the net. 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 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 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 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: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 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 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 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?
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 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?
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 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 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 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 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?
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 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?
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. --- Begin Message --- 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 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 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?
[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?
[+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?
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?
> -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 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?
On Tue, Mar 2, 2010 at 1:09 AM, William A. Rowe Jr. 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 3/2/2010 5:38 AM, Jeff Trawick wrote: > On Tue, Mar 2, 2010 at 1:09 AM, William A. Rowe Jr. > 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. 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?
good news! 2010/3/2 William A. Rowe Jr. > 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 :) > >
[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 :)