----- Original Message ----- > From: "Conor McCarthy" <[email protected]> > To: [email protected] > Sent: Thursday, 25 July, 2013 6:58:47 PM > Subject: Re: [Pound Mailing List] SSL Read Error > > On 25 July 2013 15:02, Kieran Reynolds <[email protected]> > wrote: > > Snipping quite a lot of stuff.. > > I wanted to eliminate a problem with the cipher suite, which might arise from > different versions of ssl, e.g. lack of common ciphers or protocol version. > > > Snippet from an "ab -c 1 -n1 -r -v5 https://192.168.156.138/"; > > > > I've removed Varnish from the equation temporarily, and jsut got a flat > > file behind apache, it looks likes it's hitting the backend all ok, and > > serving up my content - but... > > something is going badly wrong - > > > > Is the fact that I am getting > > > > read from 0x7ff136cf1300 [0x7ff136cf6c93] (5 bytes => 0 (0x0)) > > > > The fact that 5 bytes is greater than 0 - meaning that I am getting the SSL > > read Error ??? > > > > And if so - why would that be ? > > Each SSL record has a 3 byte header + 2 byte payload length (hence 5), > 0 bytes is the size of the payload, which is why you're getting a read error > -- > no data. Possibly the previous read was short. > > https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_record_protocol > > As to why... > The chosen cipher and protocol version are the shiny new > TLS/1.2 DHE-RSA-AES256-GCM-SHA38 > so it's possible that ab is dropping the ball. > > Start an s_server running exactly that cipher/version, and see if ab > works without error: > > openssl s_server -www -tls1_2 -cipher DHE-RSA-AES256-GCM-SHA384 \ > -cert server.crt -key server.key -accept 8443 > > ab [...] https://127.0.0.1:8443/ >
So - no, doesn't appear ab (2.3) is working without error... Window#1 openssl s_server -www -tls1 -cipher DHE-RSA-AES256-GCM-SHA384 -cert ./frameworks.wotsit2 -key ./frameworks.wotsit1 -accept 9192 Using default temp DH parameters Using default temp ECDH parameters ACCEPT 140167397615272:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1355: ACCEPT 140167397615272:error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure:s3_pkt.c:989: ACCEPT Window#2 root@sound:/etc/pound# ab -c 1 -n 1 https://127.0.0.1:9192/ This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 127.0.0.1 (be patient)...SSL handshake failed (1). 140016981235432:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:741: ..done > The way it (usually) works is: > - client sends its list of supported ciphers to server > - server picks the "best" one, and tells the client to use that > > In the absence of SSLHonorCipherOrder or equivalent, "best" usually > means largest > key size. > > If your "ab" is new enough (2.4.x) then you can tweak the available proto/ > ciphers with the -f and -Z options respectively to see if that helps identify > or eliminate specific ciphers as the cause. > If you're using the "ab" from Debian's Apache (2.2.22) you might build > your own from > 2.4 for this. > Yeah - building(rebuilding) stuff, either ab/OpenSSL/Pound really isn't on my list of things - unless I am going to have absolutely zero choice :-( The only thing I need to do is to prove that the application of Pound/Varnish in front of a SSL required site has given the ability to run more req/s. And then once done - as soon as I can get my hands on a shiny new Intel CPU with AES-NI built-in - show that performance is better still. Cheers KR > Otherwise I suspect SSL compression, you could recompile OpenSSL without > zlib support, or better still, just patch one line to ab.c and rebuild it: > > SSL_CTX_set_options(ssl_ctx, SSL_OP_ALL|SSL_OP_NO_COMPRESSION); > > Or, do similar to pound: > > http://www.apsis.ch/pound/pound_list/archive/2012/2012-10/1349447985000/index_html?fullMode=1 > > The tshark trace should then show "Compression Method: null" > instead of "DEFLATE". > > C. > > -- > To unsubscribe send an email with subject unsubscribe to [email protected]. > Please contact [email protected] for questions. > -- To unsubscribe send an email with subject unsubscribe to [email protected]. Please contact [email protected] for questions.
