On 2015-07-17 4:44 PM, William A Rowe Jr wrote:
On Fri, Jul 17, 2015 at 9:18 AM, Yann Ylavic<[email protected]> 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.
