httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Felt <mamf...@gmail.com>
Subject Re: Comparing LibreSSL and OpenSSL based on ApacheTest t/ssl results
Date Sat, 18 Jul 2015 12:47:33 GMT
On 2015-07-17 4:44 PM, William A Rowe Jr wrote:
> On Fri, Jul 17, 2015 at 9:18 AM, Yann Ylavic<ylavic.dev@gmail.com>  wrote:
>
>> Attached are the logs from both httpd and s_client, where we can see
>> that httpd somehow expects a client certificate during the
>> renegotiation (without sending any certificate request...), while
>> s_client obviously does not send anything like that (but its key
>> exchange).
>>
>> I can't explain that... I'd need to debug.
>> Does this ring someone's bell?
>>
> Sure.  AIUI, LibreSSL stripped out TLS renegotiation as an 'unsafe thing'.
>
> Some of our tests demonstrate per-dir renegotiation for stricter SSL
> ciphers or client certs in specific contexts, but this would not be
> a supported feature under LibreSSL if I understood their scope changes
> correctly.  The test is right, IMHO.
Except these tests are going - atm - from more strict to less strict - 
if I understand the error_log output from "OpenSSL" - when the tests do 
not fail.

[Thu Jul 16 12:10:47.979101 2015] [ssl:info] [pid 385024:tid 515] 
[client 127.0.0.1:39154] AH01964: Connection to child 0 established 
(server loopback:8532)
[Thu Jul 16 12:10:47.979609 2015] [ssl:debug] [pid 385024:tid 515] 
ssl_engine_kernel.c(1936): [client 127.0.0.1:39154] AH02645: Server name 
not provided via TLS extension (using default/first virtual host)
[Thu Jul 16 12:10:48.043295 2015] [ssl:debug] [pid 385024:tid 515] 
ssl_engine_kernel.c(1841): [client 127.0.0.1:39154] AH02041: Protocol: 
TLSv1, Cipher: DHE-RSA-AES256-SHA (256/256 bits)
[Thu Jul 16 12:10:48.107123 2015] [mpm_worker:error] [pid 467080:tid 1] 
AH00287: server is within MinSpareThreads of MaxRequestWorkers, consider 
raising the MaxRequestWorkers setting
[Thu Jul 16 12:10:48.107283 2015] [ssl:debug] [pid 385024:tid 515] 
ssl_engine_kernel.c(243): [client 127.0.0.1:39154] AH02034: Initial 
(No.1) HTTPS request received for child 0 (server loopback:8532)
[Thu Jul 16 12:10:48.107746 2015] [ssl:debug] [pid 385024:tid 515] 
ssl_engine_kernel.c(500): [client 127.0.0.1:39154] AH02220: Reconfigured 
cipher suite will force renegotiation
[Thu Jul 16 12:10:48.107774 2015] [ssl:info] [pid 385024:tid 515] 
[client 127.0.0.1:39154] AH02221: Requesting connection re-negotiation
...
[Thu Jul 16 12:10:48.107868 2015] [ssl:info] [pid 385024:tid 515] 
[client 127.0.0.1:39154] AH02226: Awaiting re-negotiation handshake
[Thu Jul 16 12:10:48.108182 2015] [ssl:debug] [pid 385024:tid 515] 
ssl_engine_kernel.c(1936): [client 127.0.0.1:39154] AH02645: Server name 
not provided via TLS extension (using default/first virtual host)
[Thu Jul 16 12:10:48.114668 2015] [ssl:debug] [pid 385024:tid 515] 
ssl_engine_kernel.c(1841): [client 127.0.0.1:39154] AH02041: Protocol: 
TLSv1, Cipher: RC4-SHA (128/128 bits)
[Thu Jul 16 12:10:48.114708 2015] [authz_core:debug] [pid 385024:tid 
515] mod_authz_core.c(835): [client 127.0.0.1:39154] AH01628: 
authorization result: granted (no directives)

My understanding:

ssl_engine_kernel.c(1841): [client 127.0.0.1:39154] AH02041: Protocol: 
TLSv1, Cipher: DHE-RSA-AES256-SHA (256/256 bits)
is more strict/secure than

ssl_engine_kernel.c(1841): [client 127.0.0.1:39154] AH02041: Protocol: 
TLSv1, Cipher: RC4-SHA (128/128 bits)

(The cipher used in the test has been upgraded since, but still at 128 
bits if I recall correctly).

If I understand your comment "

"Some of our tests demonstrate per-dir renegotiation for stricter SSL
ciphers or client certs in specific contexts"

This does not appear to me to be what is being tested now. I think the 
test need to start, somehow, at - let's say 128-bit- but goes to 256 bit 
when a different directory is requested.

>
> Bill
>
More in general though - trying to think as OpenBSD might have been 
thinking re:
"Stricter SSL ciphers than original" connection.

I had the assumption (which is always dangerous)
that default behavior of servers and clients was to negotiate the 
strictest combination that
both supported. Key phrase: "assume default behavior".

I do not memorize CVE numbers, or even text - but renegotiate DOWN has 
become popular to attempt to lessen (break) security - such as logjam -

 From https://access.redhat.com/articles/1456263
in which a man-in-the-middle attacker could downgrade vulnerable TLS 
connections to 512-bit export-grade cryptography. The attack affects any 
server that supports DHE_EXPORT ciphers. This attack can be conduted by 
pre-computation of the 512-bit primes given in two popular sets of weak 
Diffie-Hellman parameters, namely Apache's /httpd/ versions 2.1.5 to 
2.4.7, and all versions of OpenSSL.

 From above quote it seems that this has already been addressed in 2.4.8 
and later, and maybe even in the 2.2.31 - but it "feels" as if the 
LibreSSL approach (no renegotiate) cuts off a line of attack - and, 
properly configured - a client-server should always be connecting at the 
most secure cipher possible.

Special situations:
"Beliefs" - the server should always determine the minimum level of 
ciphers "acceptable", and the highest that the client says to support 
should be used. There should never be a reason to go to a lower quality 
- hence, renegotiation at the request of the client should never be 
accepted.
* Should the server determine that for a specific "Location"/"Directory" 
more strict levels
are needed then a new handshake (renegotiate if you prefer) for a 
stricter cipher should start. However, based on the assumption above 
(the strictest cipher that the client has is already being used) - this 
should always fail because the client is not already at that level.

Mime
View raw message