[Pkg-openssl-devel] Bug#747453: Arbitrary key size limitations causing hard-to-diagnose problems when establishing a connection

[Benny Baumann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

tags 747453 + security
thanks

Hi Kurt,

Am 09.05.2014 18:51, schrieb Kurt Roeckx:
> On Fri, May 09, 2014 at 09:08:37AM +0200, Benny Baumann wrote:
>> Hi Kurt,
>>
>> Am 09.05.2014 08:42, schrieb Kurt Roeckx:
>>> On Fri, May 09, 2014 at 03:32:25AM +0200, Wilfried Klaebe wrote:
>>>> Kurt Roeckx wrote:
>>>>> I don't see how the severity of this is critical.
>>>> The severity level "critical" is defined as: "makes unrelated software
>>>> on the system (or the whole system) break, or causes serious data loss,
>>>> or introduces a security hole on systems where you install the
package."
>>>> <https://www.debian.org/Bugs/Developer>
>>> Exactly.
>> Happens when you quote correctly ;-)
>>>> This bug makes unrelated software on the system break (e.g.
ejabberd, no
>>>> communication was possible until _both_ sides had the supplied patch
>>>> applied),
>>> ejabberd is not unrelated since it makes use of openssl.
>> Could we than please get a new severity level "breaks software which
>> depends on it". That's what I usually call critical, especially combined
>> with the next step.
>
> Critical would be that every system you install this on would
> stop working properly, like not booting.  Or would allow an
> unauthenticated remote user root access.  That sort of things.
>
> It does not "break software which depends on it".   Installing
> openssl does not break ejabberd all the time.  It only stops
> working as expected in certain circumstances.
And a quite bad failure to do so. While ejabberd only stops responding
to connections and fails with "host-not-found" other services like
Postfix confronted with this situation fallback to plaintext --> nice
security issue you've got.
> It's not a normal
> expected config.
May I quote RFC 4880, section 14 item 8 on that list:

   * As [crypto tool] combines many different asymmetric, symmetric, and
hash
     algorithms, each with different measures of strength, care should
     be taken that the weakest element of an OpenPGP message is still
     sufficiently strong for the purpose at hand.  While consensus about
     the strength of a given algorithm may evolve, NIST Special
     Publication 800-57 [SP800-57
<https://tools.ietf.org/html/rfc4880#ref-SP800-57>] recommends the
following list of
     equivalent strengths:

           Asymmetric  |  Hash  |  Symmetric
            key size   |  size  |   key size
           ------------+--------+-----------
              1024        160         80
              2048        224        112
              3072        256        128
              7680        384        192
             15360        512        256

- --> I'd call even 16384 bit RSA when using AES256 a sane and expected
configuration.

Unfortunately many in security do only what others in security do.
> As such the severity should be lower than
> serious.
>
> I have no opinion on normal / important.
Okay, let's settle in the middle at grave, shall we?
>>> It's also
>>> not totally broken that it can't be used, communication can be done
>>> under normal conditions.
>> Nope. It even breaks when the opposite server uses shorter keys and only
>> one party uses the larger key size.
>>>> and also could introduce security holes, as clients might fall
>>>> back to unencrypted communication.
>>> You can argue that this is a security hole or not.
>> As stated in the initial report you MUST never place arbitrary limits on
>> the size of cryptographic keys which is this bug is doing in the first
>> place. That it horribly breaks for software relying on the behaviour of
>> the backend library to "just do the right thing" is just another point.
> I do think limits make sense.
Only if you update them. Which both the limits here never got. Or when
they were set people weren't reading official recommendations (see
above). Thus even while completely removing the DH/DSA size limit might
be over-the-edge, you should keep it in line with what recommendations
say. Thus DH parameters of 16384 bit are quite legit when exchanging a
key for AES256 using SHA-384 (or actually SHA512 to be consistent).

The DSA limit by the way doesn't even make sense when comparing it with
RSA: RSA and DSA are assumed to be roughly equal in strength when
measured in bits of key size used (putting away some flaws of DSA for a
moment). Given this assumption it's illogical to limit RSA at 4096 bit
while keeping DSA open up to 10000 bit.
> People always think more is better,
Counterproof: I think OpenSSL is better WITHOUT the fewer such
limitations it has. ;-)
> which is not always the case.  At a certain point it will stop
> making sense to increase the size and other things become more
> important.
I know. That's why I wrote in my initial report that performance with
large keys MIGHT become an issue for certain environments. I'm not
asking that everybody should use 1Mbit RSA keys because they can, but to
allow those that see need to do so without being artificially limited.
> And you can argue about what that limit should be,
> and it might need adjustment over time.
Okay, let's get technical:
https://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=319

That's a official bug report from OpenSSL. From the year 2002. OpenSSL
seems to have taken more than 2 years to fix this. Oh ups, my bad: It's
still open even though they already changed that constant in the mean
time. Oh, and they barely changed it enough to get mainstream working
again. Phantastic.

Now what. Well, we COULD wait another 2 years (which fits kinda nicely
with Debian release cicles BTW) and have it barely be enough by than
oropen it up for people who actually read the NIST recommendations and
thus decide to use 8192 bit RSA keys for a reason; or even those that go
one step further. Modern hardware isn't bound so much for performance
here that we can't affort to let people use 65536 bit keys if they
really see need for them. And that's why the patch uses 8200 instead of
simply upping it to roughtly work for my setup. Or that of a friend.
>>>   I see no
>>> reason to use such large keys in the first place.
>> Two people independently choose to use such large keys. And are using
>> such large keys on a regular basis. And have little issues with them.
>> Furthermore I've seen several other occasions with such keys in the wild
>> already - interestingly in the same context as we found the
>> ejabberd/openssl certificate issue.
>
> It seems to me that most xmpp servers are actually really badily
> configured.
That's a different story altogether as most XMPP server software doesn't
even properly allow to setup cipher strings or accepted TLS versions
(BTW: ejabberd in Debian supports neither, just BTW). Thus if you want
to fix this as an admin of a XMPP server you'd probably have to resort
to things like https://github.com/ultramancool/ecdhforce - good luck
explaining to your average admin how to use this properly.
> I have to guess it's a self signed certificate.
You are wrong on that guess: Properly signed by a CA. Using
SHA512withRSAEncryption for the signature.

(Which breaks other things in Debian, but yeah, the report for that
breakage hasn't been handled yet either).
> I've
> seen recommendations to turn off checking of the certificates.
Won't help when the TLS layer terminates the connection without even
sending a SSL fatal error alert message.
> I would argue that this is a much worse problem than 1024 bit
> certificates.
There are test tools available and bad behaviour mostly is reflected
there already by a bad rating.
>> Furthermore: RSA 8192 corresponds to roughly AES192 thus 8192 bit is
>> still quite conservative if you do not want your certificate or key
>> exchange be the weakest link.
>
> And AES128 really is all you need.
Says who? And BTW: Could I please do MY risk assessment myself? Thanks.
>> Thus to get back to your statement:
>> 1. Yes, you SHOULD argue this is a security hole
> It's not.
It easily becomes one when fallback behaviour is using plaintext instead
of encryption like Postfix does for example.
> I will accept that it might need modification,
> and maybe even remove that check.
Okay. ACK on that point at least.
>> 2. Yes, there is reason to use such large keys.
> There might be, but I doubt it.
Your decision, but when assessing the situation you might want to
consider people with your needs - or totally different ones - and
increase the upper bounds by some margin.
> I think it would be better to
> look at alternatives like ed25519 instead.
Granted.

Than how do I configure ed25519 in stable? Oh? What? Not supported by
anything? Ineresting. Then at least stick to something that all world
supports and up the margin until alternatives are deployed.
> Kurt
Kind regards,
Benny Baumann.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJTbRaTAAoJEPHTXLno4S6t6MEP/iR9pn9bUnz65C4AsN6l8Bj5
hnCeGCfYJjl1Nl6owB04sbJjfAq5S1j1QQ3UVDE5OJYvU84oTvvsEGza/1ZGl2sL
Byn3cPAJl046uoW+jsviNlRpZZF95ixFQIP6b+WbyI0NmHwhm5HC5VwsOJz9d5cz
z28JLtU48Uh3kxBrUWicqdjQ9S/IknY0Up47Cra53IGnH+MINVls+DqfWhJQmWby
nvibSCqYzVEn9Umc3tNMA4TrM/5E7HAzqYQHl4JvAzFjlsnUeSzOCYTKxlQkVNUT
g22htC1RQQvYcJiZRhZ4F0rnaMlmTo5oNfj6EzWeo/GAsTM/aXFaAO+9j59H8J0b
PN3uWR02xbLNy/EFQLTk6aks/N7UpdcXetOK2iQvQ/YPmBndxHIi7JoOB1sg0MNP
+X+VpxFAgxW5G8QFWGVOB5Z8eCjYR8d7NlNcG3W77CYlE8bjyN9yKKNHdLCfcWNu
qhqL+mA2y+vIbI7+7s0uBf3i2YnG6WHXV4Rma7L6+4MN2+J+ll0YljiHU2oOyN9C
mDNqgJKHR4bsOQIoDKiveh46fbqJV7wJtjaHNeBtkeqbIcofeq6Ygoo9uAd8A80k
K6pc15iyuy4iIDjJU2tduisf2wkrb6xNt2ahW5Cm6Vc3qqyD/jlCZfZocf+mdTGy
GYviieRh4r82mmyd7ety
=D4ni
-----END PGP SIGNATURE-----