# Steps to reproduce 1. Copy the attached `pound.cfg` to `/etc/pound/` 2. Copy the attached `pound-test-cert.pem` to `/etc/ssl/private/` 3. Open a TCP port on port 8080: `netcat -t -l -p 8080` 4. `service pound start` 5. Make a TLS (not SSL!) request: `curl --tlsv1 --ciphers 'AES128-SHA' -k https://127.0.0.1:8443/` 6. Look at the stdout of netcat, and see the value of HTTP request header X-SSL-cipher that pound has injected into the request
## Expected The connection is reported to be TLS ## Actual The connection is reported to be SSLv3: "AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1" Wireshark debugging confirms that the curl connection is indeed a TLS connection, rather than a SSLv3 connection. # Impact When trying to determine the impact of disabling SSLv3 (re POODLE), we searched our logs for how many clients used SSLv3, and this bug caused us to believe we had more SSLv3 traffic than we actually did. # Why this is reported to be SSLv3 Looking into the pound code[0], X-SSL-cipher is populated with the result of SSL_CIPHER_description(). In SSL_CIPHER_description() "The TLSv1.0 ciphers are flagged with SSLv3."[1]. The AES ciphers are TLSv1 ciphers, and hence are reported as SSLv3 by pound/openssl. # Proposed fix Add a X-SSL-version header, using SSL_get_version()[2]. I can produce a patch for this, if it is considered an acceptable change. I originally raised this against Ubuntu's bug tracker[3], but have since found this mailing list, so am posting it here. 0. https://github.com/mandiant/pound/blob/a3705bc06e44ec4a229fd38760d6c04c43ced6b6/http.c#L943 1. https://www.openssl.org/docs/ssl/SSL_CIPHER_get_name.html 2. https://www.openssl.org/docs/ssl/SSL_get_version.html 3. https://bugs.launchpad.net/ubuntu/+source/pound/+bug/1398007 -- Tom Fitzhenry
pound.cfg
Description: Binary data
pound-test-cert.pem
Description: application/x509-ca-cert
