© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
I've also slammed headlong into this one.
The clue is "SSL handshake has read 0 bytes and written 317 bytes"
What the openssl v1.0.1f client side is doing is sending a clienthello packet larger than 255 bytes to a broken SSL implementation, which slams the phone down on you, thus "read 0 bytes".
The openssl client side errors handling is currently broken, and does not clearly indicate that the connection was dropped, just the vague message that a handshake failure occurred (I've logged this bug here: https:/
The suggestion to limit the list of ciphers to just two works around the problem because the clienthello is vastly reduced in size. Obviously this works where your chosen ciphers are accepted by the server, but won't work with the same confusingly identical error message when the ciphers are not supported by the server.
The tangent about MD5 above, while true, has nothing whatsoever to do with this bug.
It looks like the default cipher list on the client side has grown way too long, and when an application offers no control over the cipher list this breaks connections to buggy SSL servers.
Turns out one such buggy SSL server implementation is openssl v1.0.1f as supplied by Ubuntu Xenial, that is covered here: https:/
As to this client side bug, we need to figure out how to ensure the default cipher list stays well below the 255 byte limit, especially since the SNI header has to fit inside 255 bytes too.