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 Bi
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
Coming up on 80 hours I'm +1
Tested on 32 bit versions of Windows 2k, XP, Vista
+1 (ugg BOM)
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 workin
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_ACCE
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
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
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: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 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
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 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
--
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,
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
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.
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 :)
>
>
37 matches
Mail list logo
