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
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, i
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
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
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.
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.
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 conne
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
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
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
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
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
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 hand
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 :)
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 whethe
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 :)
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 a
On Wed, Mar 3, 2010 at 2:58 PM, William A. Rowe Jr. 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=918665&view=rev
>> Log:
>> fix these warnings:
>>
>> mod_isapi.c:488:
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 kn
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=918665&view=rev
> Log:
> fix these warnings:
>
> mod_isapi.c:488: warning: no previous prototype for ‘GetServerVariable’
> mod_isapi.c
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
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.
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
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
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
[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 i
[+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
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
> -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.
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
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=917867&view=rev
> Log:
> Ensure each subrequest has a shallow copy of headers_in so that the
> parent request headers are
31 matches
Mail list logo
