Closed GoogleCodeExporter closed 9 years ago
I can reproduce this issue with:
apache 2.2.22 on Ubuntu 13.03
svn trunk + serf trunk@2074
Relevant part of the apache config:
<VirtualHost *:443>
ServerName lgo-ubuntu1
SSLEngine on
SSLCertificateKeyFile /etc/apache2/certs/serfserverkey.pem
SSLCertificateFile /etc/apache2/certs/serfservercert.pem
SSLCertificateChainFile /etc/apache2/certs/serfcacerts.pem
<Location "/basicsvn">
DAV svn
SVNParentPath "/mnt/share/dev/svn"
SSLVerifyClient Require
...
Important here is that the SSLVerifyClient directive should be inside the
Location, not directly under VirtualHost. This will ensure that the ssl
handshake will trigger a renegotiation.
--------------------------------------------------
This extract of the serf log shows that the renegotiate alert is received and
read by serf+OpenSSL (1st <<<--------). OpenSSL then responds by writing 620
bytes to the bio layer.
Then nothing happens and after 10 seconds the server kills the connection (2nd
<<<--------------)
[2013-07-25T23:05:34.876972+02] [l:192.168.1.113:57008 r:192.168.1.112:443]
outgoing.c: --- socket_sendv: 543 bytes. --
[2013-07-25T23:05:34.879514+02] buckets/ssl_buckets.c: ssl_decrypt: begin 8000
[2013-07-25T23:05:34.879541+02] buckets/ssl_buckets.c: bio_bucket_read called
for 5 bytes
[2013-07-25T23:05:34.879552+02] buckets/ssl_buckets.c: bio_bucket_read received
0 bytes (70014)
[2013-07-25T23:05:34.879573+02] [l:192.168.1.113:57008 r:192.168.1.112:443]
buckets/socket_buckets.c: --- socket_recv: 33 bytes. --
[2013-07-25T23:05:34.879585+02] buckets/ssl_buckets.c: ssl_decrypt: read 33
bytes (8000); status: 0
[2013-07-25T23:05:34.879591+02] buckets/ssl_buckets.c: bio_bucket_read called
for 5 bytes
[2013-07-25T23:05:34.879596+02] buckets/ssl_buckets.c: bio_bucket_read received
5 bytes (0)
[2013-07-25T23:05:34.879601+02] buckets/ssl_buckets.c: bio_bucket_read called
for 28 bytes
[2013-07-25T23:05:34.879605+02] buckets/ssl_buckets.c: bio_bucket_read received
28 bytes (70014)
[2013-07-25T23:05:34.879627+02] buckets/ssl_buckets.c: SSL_connect:SSL
renegotiate ciphers <<<-----------
[2013-07-25T23:05:34.879646+02] buckets/ssl_buckets.c: bio_bucket_write called
for 620 bytes
[2013-07-25T23:05:34.879654+02] buckets/ssl_buckets.c: SSL_connect:SSLv3 write
client hello A
[2013-07-25T23:05:34.879659+02] buckets/ssl_buckets.c: bio_bucket_read called
for 5 bytes
[2013-07-25T23:05:34.879664+02] buckets/ssl_buckets.c: bio_bucket_read received
0 bytes (70014)
[2013-07-25T23:05:34.879673+02] buckets/ssl_buckets.c: SSL_connect:error in
SSLv3 read server hello A
[2013-07-25T23:05:34.879678+02] buckets/ssl_buckets.c: ssl_decrypt: 35 0 9
<<<------------
[2013-07-25T23:05:44.947063+02] buckets/ssl_buckets.c: ssl_decrypt: begin 8000
[2013-07-25T23:05:44.947116+02] buckets/ssl_buckets.c: bio_bucket_read called
for 5 bytes
[2013-07-25T23:05:44.947128+02] buckets/ssl_buckets.c: bio_bucket_read received
0 bytes (70014)
[2013-07-25T23:05:44.947143+02] buckets/ssl_buckets.c: SSL_connect:error in
SSLv3 read server hello A
[2013-07-25T23:05:44.947153+02] [l:192.168.1.113:57008 r:192.168.1.112:443]
buckets/socket_buckets.c: socket_recv error 70014
What is strange, and I assume the root cause of this problem, is that the 620
bytes sent to the bio layer are never written to the network. There should be a
line "outgoing.c: --- socket_sendv: 620 bytes." somewhere.
The investigation continues.
Original comment by lieven.govaerts@gmail.com
on 25 Jul 2013 at 9:14
Scenario: the server triggers a ssl/tls renegotiation after receiving a request
but before writing a response.
Issue: The renegotiation request arrives in the ssl layer, and while reading
that data OpenSSL will write a response.
If the request was the only request pending on the connection (say one opening
non-pipelined request), serf will have no more requests to send, and won't
check for socket writability. So the data that OpenSSL has add to the outgoing
stream will never be written on the socket, and after a timeout the server will
abort the connection.
The fix check for socket writability not only if there are requests pending,
but also when the outgoing stream has data pending.
This issue is fixed in r2078.
Original comment by lieven.govaerts@gmail.com
on 26 Jul 2013 at 9:10
Original issue reported on code.google.com by
e...@cs.tu-berlin.de
on 25 Jul 2013 at 8:47