Re: HTTP Streaming with Apache 1
I wonder if it's possible with Apache 2? To get hold of the client socket, so that I can poll() or select() it and implement server push aka Comet r-connection-cs-pfd.desc.s-socketdes if I'm not mistaken. Check out apr_pollset_create() if you are going to do polling inside Apache or sendmsg(2) if you want to pass the fd to another process.
X.509 certificate against LDAP authentication
Looking at some of the prior work in this area. It appears that one of the big challenges in cert-based authentication is in the mapping between the certificate subject and the directory entry. If I'm creating something for general consumption, I want to make it generalizable to multiple environments. In looking at the other people that have implemented this with hooks and shim modules, I've seen several different techniques for certificate mapping authentication. I'd like my proposed enhancement to be as widely usable as possible. Looking at the code, I think the greatest opportunity for reuse of existing code and consistency with the architecture lies in creating support for the certificate authentication type within the current modules, starting with mod_authnz_ldap. With respect to mapping authentication, the approaches I'm considering are to allow one or more of the following: 1) Authenticate a user by the full binary certificate, assuming that each user will have one or more valid certificates stored in the directory in an attribute such as usercertificate;binary 2) Authenticate a user by mapping the certificate subject to a DN [How?] 3) Authenticate a user by some combination of elements such as subject CN and issuer CN against a directory of certificates? I saw one case in my research where only groups existed in LDAP--no users entries.To address that, it occurs to me that there might also be an option 0: 0) Authenticate a user by the presence of an accepted certificate, without reference to a specific entry in the directory--i.e. any valid certificate that comes out of mod_ssl is treated as an authenticated user.] This would let one authorize a user based on membership in a group when only groups are populated. Looking at mod_auth_basic and mod_auth_digest, it looks like I need to come up with a user name fairly early on. I intend to hook the handler with mod_ssl.c as a predecessor. Any thoughts on the most appropriate way to pull the peer certificate out of the connection and then map it to a user name? I'm trying to avoid using SSLUserName from mod_ssl, because we might need the certificate--but I don't want to set the username to be the client certificate. That makes for unfriendly reading in logs. Rather, I want to have some mapping [such as in option 2 above] from the certificate to the user name. In my ideal world, I would meet this goal with an absolute minimal change to the code-base: 1) add a new file modules/aaa/mod_auth_cert.c to support AuthType certificate 2) add a check_certificate method to mod_authnz_ldap.c that maps from a certificate to a user search and succeeds if the criteria for existence of a user is met 3) Reconcile any explicit or implicit assumptions that we are using AuthType basic. I appreciate any thoughts and pointers. --Pete --- Peter L. Thomas, ptho...@hpti.com (w) 703-682-5308 (c) 703-615-7806 (pgr) 877-383-8910 Thomas, Peter L. (ptho...@hpti.com).vcf
Re: svn commit: r917867 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS server/protocol.c
On Tue, Mar 02, 2010 at 04:01:29AM -, William Rowe wrote: Author: wrowe Date: Tue Mar 2 04:01:29 2010 New Revision: 917867 URL: http://svn.apache.org/viewvc?rev=917867view=rev Log: Ensure each subrequest has a shallow copy of headers_in so that the parent request headers are not corrupted. Eliminates a problematic optimization in the case of no request body. PR: 48359 Submitted by: Jake Scott, wrowe, rpluem Backports: server/protocol.c r901578 Reviewed by: minfrin There is some discussion on the PR (and previously on security@) about the potential security impact to this - the argument being that in a threaded server, memory re-use could lead to an information leak of request/response data from another thread. This seems like a borderline case, but we should assign a CVE name - Mark, can you assign one? Regards, Joe
Re: svn commit: r917867 - in /httpd/httpd/branches/2.2.x: CHANGES STATUS server/protocol.c
On Wed, Mar 03, 2010 at 10:12:55AM +, Mark J Cox wrote: This seems like a borderline case, but we should assign a CVE name - Mark, can you assign one? It's low severity, but it probably should have got one earlier, yes. Use CVE-2010-0434. Thanks a lot. Joe
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: svn commit: r918665 - /httpd/httpd/trunk/modules/arch/win32/mod_isapi.c
On 3/3/2010 1:49 PM, traw...@apache.org wrote: Author: trawick Date: Wed Mar 3 19:49:41 2010 New Revision: 918665 URL: http://svn.apache.org/viewvc?rev=918665view=rev Log: fix these warnings: mod_isapi.c:488: warning: no previous prototype for ‘GetServerVariable’ mod_isapi.c:590: warning: no previous prototype for ‘ReadClient’ mod_isapi.c:807: warning: no previous prototype for ‘WriteClient’ mod_isapi.c:863: warning: no previous prototype for ‘ServerSupportFunction’ These must all be exported, that is the ISAPI API; please revert. mod_isapi.c:1407: warning: no previous prototype for ‘isapi_handler’ that one looks good :)
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: svn commit: r918665 - /httpd/httpd/trunk/modules/arch/win32/mod_isapi.c
On Wed, Mar 3, 2010 at 2:58 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 3/3/2010 1:49 PM, traw...@apache.org wrote: Author: trawick Date: Wed Mar 3 19:49:41 2010 New Revision: 918665 URL: http://svn.apache.org/viewvc?rev=918665view=rev Log: fix these warnings: mod_isapi.c:488: warning: no previous prototype for ‘GetServerVariable’ mod_isapi.c:590: warning: no previous prototype for ‘ReadClient’ mod_isapi.c:807: warning: no previous prototype for ‘WriteClient’ mod_isapi.c:863: warning: no previous prototype for ‘ServerSupportFunction’ These must all be exported, that is the ISAPI API; please revert. I guess filling in the EXTENSION_CONTROL_BLOCK with their addresses is not the only way an app gets addressibility .../?
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: svn commit: r918665 - /httpd/httpd/trunk/modules/arch/win32/mod_isapi.c
On 3/3/2010 2:03 PM, Jeff Trawick wrote: I guess filling in the EXTENSION_CONTROL_BLOCK with their addresses is not the only way an app gets addressibility .../? Oh, hold up. I think you are right on this, that these aren't expected to be available in the namespace by name :)
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: X.509 certificate against LDAP authentication
I found ssl_list_ext(...) -- used, for example, in mod_setenvif.c -- which looked really promising for generalized access to the client certificate elements without depending on whether mod_ssl.c configuration options as +StdEnvVars or SSLUserName had been set. I'm still wrangling with how to handle the mapping of the certificate subject into an LDAP query in a generalizable way. RFC-2252 and RFC-2253 offer some tantalizing hints...as well as the caveat that there is not a deterministic reversal from an X.500 subject to an LDAP DN. We knew that already, right? --Pete _ From: Thomas, Peter Sent: Wednesday, March 03, 2010 4:20 PM To: 'modules-...@httpd.apache.org' Subject: X.509 certificate against LDAP authentication Looking at some of the prior work in this area. It appears that one of the big challenges in cert-based authentication is in the mapping between the certificate subject and the directory entry. If I'm creating something for general consumption, I want to make it generalizable to multiple environments. In looking at the other people that have implemented this with hooks and shim modules, I've seen several different techniques for certificate mapping authentication. I'd like my proposed enhancement to be as widely usable as possible. Looking at the code, I think the greatest opportunity for reuse of existing code and consistency with the architecture lies in creating support for the certificate authentication type within the current modules, starting with mod_authnz_ldap. With respect to mapping authentication, the approaches I'm considering are to allow one or more of the following: 1) Authenticate a user by the full binary certificate, assuming that each user will have one or more valid certificates stored in the directory in an attribute such as usercertificate;binary 2) Authenticate a user by mapping the certificate subject to a DN [How?] 3) Authenticate a user by some combination of elements such as subject CN and issuer CN against a directory of certificates? I saw one case in my research where only groups existed in LDAP--no users entries.To address that, it occurs to me that there might also be an option 0: 0) Authenticate a user by the presence of an accepted certificate, without reference to a specific entry in the directory--i.e. any valid certificate that comes out of mod_ssl is treated as an authenticated user.] This would let one authorize a user based on membership in a group when only groups are populated. Looking at mod_auth_basic and mod_auth_digest, it looks like I need to come up with a user name fairly early on. I intend to hook the handler with mod_ssl.c as a predecessor. Any thoughts on the most appropriate way to pull the peer certificate out of the connection and then map it to a user name? I'm trying to avoid using SSLUserName from mod_ssl, because we might need the certificate--but I don't want to set the username to be the client certificate. That makes for unfriendly reading in logs. Rather, I want to have some mapping [such as in option 2 above] from the certificate to the user name. In my ideal world, I would meet this goal with an absolute minimal change to the code-base: 1) add a new file modules/aaa/mod_auth_cert.c to support AuthType certificate 2) add a check_certificate method to mod_authnz_ldap.c that maps from a certificate to a user search and succeeds if the criteria for existence of a user is met 3) Reconcile any explicit or implicit assumptions that we are using AuthType basic. I appreciate any thoughts and pointers. --Pete --- Peter L. Thomas, ptho...@hpti.com (w) 703-682-5308 (c) 703-615-7806 (pgr) 877-383-8910 File: Thomas, Peter L. (ptho...@hpti.com).vcf
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...
