On 2015-07-18 3:44 PM, Eric Covener wrote:
On Sat, Jul 18, 2015 at 8:47 AM, Michael Felt wrote:
* 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, ba
On Sat, Jul 18, 2015 at 8:47 AM, Michael Felt wrote:
> * 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 stric
On 2015-07-17 4:44 PM, William A Rowe Jr wrote:
On Fri, Jul 17, 2015 at 9:18 AM, Yann Ylavic 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
On Fri, Jul 17, 2015 at 10:37 AM, Michael Felt wrote:
> On 2015-07-17 5:34 PM, Yann Ylavic wrote:
>
>> On Fri, Jul 17, 2015 at 5:23 PM, Michael Felt wrote:
>>
>>> On 2015-07-17 4:18 PM, Yann Ylavic wrote:
>>>
$ /path/to/libressl/2.2.1/bin/openssl s_client -connect localhost:8532
-state
On 2015-07-17 5:34 PM, Yann Ylavic wrote:
On Fri, Jul 17, 2015 at 5:23 PM, Michael Felt wrote:
Here I can see:
Much more simple: 8352 != 8532 - i.e., typo
On 2015-07-17 5:34 PM, Yann Ylavic wrote:
On Fri, Jul 17, 2015 at 5:23 PM, Michael Felt wrote:
On 2015-07-17 4:18 PM, Yann Ylavic wrote:
$ /path/to/libressl/2.2.1/bin/openssl s_client -connect localhost:8532 -state
What else did you change in your configuration files - to get it to listen
on
On Fri, Jul 17, 2015 at 5:23 PM, Michael Felt wrote:
> On 2015-07-17 4:18 PM, Yann Ylavic wrote:
>>
>> $ /path/to/libressl/2.2.1/bin/openssl s_client -connect localhost:8532 -state
>>
> What else did you change in your configuration files - to get it to listen
> on port 8352? When I run the same c
On 2015-07-17 4:18 PM, Yann Ylavic wrote:
Thanks, I finally managed to build libressl on my system and
httpd-2.4.x linked to it.
However since this isn't the system's native libssl, the perl
framework (libwww-perl/5.836 here) does not use it (but Debian's
libssl-0.9.8o-4squeeze20), so I had to u
On 2015-07-17 12:39 PM, Yann Ylavic wrote:
But possibly "LogLevel trace5" in httpd.conf (or
t/conf/ssl/ssl.conf.in 's VirtualHost) would be enough to see what's
going on. Since the "error" (interruption) seems to be on the client
side though, it may also be interesting to start httpd with a
co
On 2015-07-17 4:18 PM, Yann Ylavic wrote:
On Fri, Jul 17, 2015 at 1:51 PM, Michael Felt wrote:
On 2015-07-17 1:20 PM, Michael Felt wrote:
On 2015-07-17 12:39 PM, Yann Ylavic wrote:
tcpdump -i lo -w dump.pcap -s0 tcp port 8532
Run at a different time, but with trace5 enabled.
Thanks, I fin
On Fri, Jul 17, 2015 at 9:18 AM, Yann Ylavic 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
On Fri, Jul 17, 2015 at 1:51 PM, Michael Felt wrote:
> On 2015-07-17 1:20 PM, Michael Felt wrote:
>>
>> On 2015-07-17 12:39 PM, Yann Ylavic wrote:
>>>
>>> tcpdump -i lo -w dump.pcap -s0 tcp port 8532
>>
>>
> Run at a different time, but with trace5 enabled.
Thanks, I finally managed to build libr
On 2015-07-17 1:20 PM, Michael Felt wrote:
On 2015-07-17 12:39 PM, Yann Ylavic wrote:
tcpdump -i lo -w dump.pcap -s0 tcp port 8532
Run at a different time, but with trace5 enabled.
logs.pr12355.libressl.trace5.tar.bz2
Description: Binary data
On 2015-07-17 12:39 PM, Yann Ylavic wrote:
tcpdump -i lo -w dump.pcap -s0 tcp port 8532
dump.pcap
Description: Binary data
On 2015-07-17 12:39 PM, Yann Ylavic wrote:
Michael Felt wrote:
Yann Ylavic wrote:
So if RC4 was the culprit, the tests (pr12355 and pr43738) should pass
now.
I'll pull ApacheTest and check.
p.s. I have built 2.4.16 now - and did not have to change anything for
it to build against LibreSSL (
On 2015-07-17 12:39 PM, Yann Ylavic wrote:
Michael Felt wrote:
Yann Ylavic wrote:
So if RC4 was the culprit, the tests (pr12355 and pr43738) should pass
now.
I'll pull ApacheTest and check.
I assume the attached logs_pr12355_LibreSSL.zip was with the latest
framework (including r1691419), so
Michael Felt wrote:
> Yann Ylavic wrote:
>>
>> So if RC4 was the culprit, the tests (pr12355 and pr43738) should pass
>> now.
>
> I'll pull ApacheTest and check.
I assume the attached logs_pr12355_LibreSSL.zip was with the latest
framework (including r1691419), so the RC4 => AES changes did not
wo
On 2015-07-16 11:48 PM, Yann Ylavic wrote:
On Thu, Jul 16, 2015 at 7:02 PM, Michael Felt wrote:
A longish read - basically while 2.4.12 had few errors when built against
OpenSSL 0.9.8 LibreSSL has quite a few errors - perhaps because it has
removed many "unsafe" crypto combinations. The root qu
On Thu, Jul 16, 2015 at 7:02 PM, Michael Felt wrote:
>
> A longish read - basically while 2.4.12 had few errors when built against
> OpenSSL 0.9.8 LibreSSL has quite a few errors - perhaps because it has
> removed many "unsafe" crypto combinations. The root question is: is this
> LibreSSL misbehav
I'll look at it and hopefully understand something. but tomorrow.
On Thu, Jul 16, 2015 at 7:56 PM, William A Rowe Jr
wrote:
> On Thu, Jul 16, 2015 at 12:02 PM, Michael Felt wrote:
>
>> Here I have the output of just one test t/ssl/pr12355.t - and note the
>> differences in the ssl_access_log -
On Thu, Jul 16, 2015 at 12:02 PM, Michael Felt wrote:
> Here I have the output of just one test t/ssl/pr12355.t - and note the
> differences in the ssl_access_log - not just the error messages (I have
> removed all "debug" messages from the logs as they were "in the way".
>
> LibreSSL is version
Moving this to a thread with a better title!
A longish read - basically while 2.4.12 had few errors when built
against OpenSSL 0.9.8 LibreSSL has quite a few errors - perhaps because
it has removed many "unsafe" crypto combinations. The root question is:
is this LibreSSL misbehaving, or are th
22 matches
Mail list logo