Forum Discussion
SSL Handshake failed
We noticed that we have a lot more SSLv3 traffic than we would expect. We want to phase out SSLv3 and we're looking at the SSLClient profile metrics and found ~12% of our users are on SSLv3 which is nuts. In digging a bit more we're finding
tmm2[16184]: 01260013:6: SSL Handshake failed for TCP 1.2.3.4:1234 -> 10.1.1.1:443
errors in /var/log/ltm
My initial thought was perhaps this is an unclean shutdown issue. I enabled strict resume and there was no improvement.
Another curious piece is that from our Apache logs, it appears those using SSLv3 and having handshake error have a user-agent string from Linux hosts. Example:
"Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Firefox/38.0"
Handshake errors may be unrelated. But Firefox 38 should have no issue connecting via TLS. Anyone have any ideas?
If you use server ssl profiles you might want to check out the cipher strings on those too.
Also, I'd check out this article:
https://support.f5.com/kb/en-us/solutions/public/15000/200/sol15292.html
/Patrik
- Bubbagump_12531
Nimbostratus
I have been through that article several times and it isn't much help. From what I can tell in my TCPdumps is that the Client Hello comes in, the Server Hello goes out, and immediately afterwards a RST ACK comes from the client. The handshakes errors may indeed be a red herring.
Again, the issue I am chasing is how in the world 10% of our traffic is still SSLv3 when our user-agent logs would lead us to believe our customers should be able to use TLS. So the question is, why are they negotiating SSLv3 and why does this seem to be limited to Linux clients?
What's your cipher string?
The client suggests the cipher list, but the server chooses (according to the order of your cipher string).
This page has great information about the cipher strings:
https://support.f5.com/kb/en-us/solutions/public/13000/100/sol13171.html
User agent could possibly be taken with a grain of salt too as it could be easily faked. Have you checked if a majority of the clients comes from the same IP? Could be a scraper posing as FF.
Best way to really check it out could be to install the same version of FF yourself and check out the cipher negotiation. :)
/Patrik
- Bubbagump_12531
Nimbostratus
This is 11.5.3 and the string is DEFAULT:@STRONG:SSLv3. I would expect this to shove everyone towards TLS. Am I wrong in my interpretation?
I agree, it should.
I'm also running 11.5.3. Here's my default ciphers:
user@LB: tmm --clientciphers DEFAULT ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 61 AES256-SHA256 256 TLS1.2 Native AES SHA256 RSA 1: 53 AES256-SHA 256 TLS1 Native AES SHA RSA 2: 53 AES256-SHA 256 TLS1.1 Native AES SHA RSA 3: 53 AES256-SHA 256 TLS1.2 Native AES SHA RSA 4: 53 AES256-SHA 256 DTLS1 Native AES SHA RSA 5: 60 AES128-SHA256 128 TLS1.2 Native AES SHA256 RSA 6: 47 AES128-SHA 128 TLS1 Native AES SHA RSA 7: 47 AES128-SHA 128 TLS1.1 Native AES SHA RSA 8: 47 AES128-SHA 128 TLS1.2 Native AES SHA RSA 9: 47 AES128-SHA 128 DTLS1 Native AES SHA RSA 10: 10 DES-CBC3-SHA 192 TLS1 Native DES SHA RSA 11: 10 DES-CBC3-SHA 192 TLS1.1 Native DES SHA RSA 12: 10 DES-CBC3-SHA 192 TLS1.2 Native DES SHA RSA 13: 10 DES-CBC3-SHA 192 DTLS1 Native DES SHA RSA 14: 5 RC4-SHA 128 TLS1 Native RC4 SHA RSA 15: 5 RC4-SHA 128 TLS1.1 Native RC4 SHA RSA 16: 5 RC4-SHA 128 TLS1.2 Native RC4 SHA RSA 17: 49192 ECDHE-RSA-AES256-SHA384 256 TLS1.2 Native AES SHA384 ECDHE_RSA 18: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1 Native AES SHA ECDHE_RSA 19: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1.1 Native AES SHA ECDHE_RSA 20: 49172 ECDHE-RSA-AES256-CBC-SHA 256 TLS1.2 Native AES SHA ECDHE_RSA 21: 49191 ECDHE-RSA-AES128-SHA256 128 TLS1.2 Native AES SHA256 ECDHE_RSA 22: 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1 Native AES SHA ECDHE_RSA 23: 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1.1 Native AES SHA ECDHE_RSA 24: 49171 ECDHE-RSA-AES128-CBC-SHA 128 TLS1.2 Native AES SHA ECDHE_RSA 25: 49170 ECDHE-RSA-DES-CBC3-SHA 192 TLS1 Native DES SHA ECDHE_RSA 26: 49170 ECDHE-RSA-DES-CBC3-SHA 192 TLS1.1 Native DES SHA ECDHE_RSA 27: 49170 ECDHE-RSA-DES-CBC3-SHA 192 TLS1.2 Native DES SHA ECDHE_RSA
Looking at the article previously mentioned that would make your list:
!SSLv2:!SSLv3:!MD5:!EXPORT:RSA+AES:RSA+3DES:RSA+RC4:ECDHE+AES:ECDHE+3DES:ECDHE+RC4:@STRONG:SSLV3
The article says:
Note: When you use the ! symbol preceding a cipher, the SSL profile permanently removes the cipher from the cipher list, even if it is explicitly stated later in the cipher string. When you use the - symbol preceding a cipher, the SSL profile removes the cipher from the cipher list, but it can be added back to the cipher list if there are later options that allow it.
That would indicate that SSLv3 is not allowed at all. Have you looked around for other profiles with custom cipher strings?
/Patrik
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com