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

[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.  It's not a normal
expected config.  As such the severity should be lower than
serious.

I have no opinion on normal / important.

> >   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.  People always think more is better,
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.  And you can argue about what that limit should be,
and it might need adjustment over time.

> >   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.  I have to guess it's a self signed certificate.  I've
seen recommendations to turn off checking of the certificates.
I would argue that this is a much worse problem than 1024 bit
certificates.

> 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.


> Thus to get back to your statement:
> 1. Yes, you SHOULD argue this is a security hole

It's not.  I will accept that it might need modification,
and maybe even remove that check.

> 2. Yes, there is reason to use such large keys.

There might be, but I doubt it.  I think it would be better to
look at alternatives like ed25519 instead.


Kurt