[Bug 986147] Re: openssl 1.0.1-4ubuntu2 breaks a bunch of ciphers
Thomas Bushnell, BSG
986147 at bugs.launchpad.net
Mon Apr 23 18:50:22 UTC 2012
Colin, I hope you'll reconsider this change and revert it.
I understand that there are buggy servers which fail when they get
offered too many ciphers by clients, but they *always* failed; that's
nothing new. So in order to expand the use cases for the library, this
change has caused a regression. It's much worse to take correctly-
working server/client pairs and deliberately break them than to fail to
support incorrectly-working server/client pairs.
It's not just us; Jordon Bedwell above had the same problem. It's going
to break a *lot* of people.
Moreover, it is really an important security issue as well as an
interoperability one. I have a right to expect that I will get the most
secure cipher from the set formed by the intersection of the client's
and the server's supported sets; with this change, I do not, because the
client has artificially eliminated some of its supported set.
This is a serious, serious regression, both in security and in
interoperability.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/986147
Title:
openssl 1.0.1-4ubuntu2 breaks a bunch of ciphers
Status in “openssl” package in Ubuntu:
Confirmed
Bug description:
in version 1.0.1-4ubuntu2, we see:
openssl (1.0.1-4ubuntu2) precise-proposed; urgency=low
* Backport more upstream patches to work around TLS 1.2 failures
(LP #965371):
...
- Truncate the number of ciphers sent in the client hello to 50. Most
broken servers should now work.
...
-- Colin Watson <cjwatson at ubuntu.com> Wed, 18 Apr 2012 15:03:56
+0100
We have a server which offers a very small number of ciphers. When
this change hit, suddenly our hosts could no longer contact this
server, getting the error:
$ openssl s_client -connect HOSTNAME:9140
CONNECTED(00000003)
139736292189856:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:724:
The problem here was tracked down to a failure to find a matching
cipher. If we specify -cipher RC4-SSH (the only one essentially which
the server permits) or -ssl3, the connection succeeds.
The problem is this truncation of the number of ciphers sent. RC4-SSH
shows up at something like #74 on our list, so it is getting
truncated. When we specify exactly the cipher to use, of course it
works, and if we say -ssl3, then that also reduces the number which
would be sent, and now RC4-SSH is in the top fifty again.
This is a pretty disastrous change, in fact; it means that openssl
basically now supports only fifty ciphers at a time, and then an
essentially random and unpredictable set. Not only does this mean a
loss of functionality, it could be a loss in security if clients get
pushed to less secure ciphers because the more secure ones happened to
be after number fifty in the list.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/986147/+subscriptions
More information about the foundations-bugs
mailing list