[openssl-users] Authentication over ECDHE

Mon Dec 31 09:12:57 UTC 2018

In message <4d287beb-f79b-5fb8-9a6f-8a612c175474 at gmx.de> on Sun, 30 Dec 2018 16:45:27 +0100, "C.Wehrmeyer" <c.wehrmeyer at gmx.de> said:

> On 30.12.18 00:04, Matt Milosevic wrote:
> > I do not want to complicate matters further, but there needs to be one
> > thing clear here: this library is mainly developed and maintained by
> > /volunteers/.
> 
> For some reason you seem to think this excuses something. I don't.
> 
> Fact is: there are a lot of things that could be improved.

Agreed.

> Fact is: there are a lot of things that aren't improved, however
> there are still features added every now and again. The latest
> things I've seen thus far in the code is TLS 1.3 and kernel TLS.

Yes, it's true, new features are going in.  And it's true that it's
often more exciting to add new features than to do the janitorial
work.

BUT, you also have to appreciate that stuff is happening around us
that affects our focus.  TLS 1.3 happened, and rather than having to
answer the question "why don't you have TLS 1.3 yet?" (there's a LOT
of interest in that version), we decided to add it.

However, your message is clear, we do need to do some cleanup as
well.  More than that, I agree with you that it's needed (I've
screamed out in angst when stumbling upon particularly ugly or
misplaced code, so the feeling is shared, more than you might
believe).

That being said, cleanup happens, and documentation happens, in a
piecemeal fashion, 'cause that's what most people have capacity for.

Now, here's something else that you need to consider: API/ABI
compatibility needs to be preserved.  See, I did see you say something
about all the available SSL_ symbols, and it's true that we have a lot
of them (that includes all the macros):

    : ; grep -E '^([^#].*[^A-Za-z_]|# *define  *)SSL_[A-Za-z0-9_]*\(' include/openssl/* | wc -l
    747

Counting symbols is, however, nothing other than a blunt instrument.
Quite a lot of those symbols are convenience macros and functions that
have accumulated over time.

But nevertheless, I do hear you call for a remake of the SSL API as
well as cleaner internals.  The latter is easier, and I'm sure it will
happen piecemeal as per usual so as to not break something /
inadvertently change a behavior (i.e. break ABI).  The former is a
fairly massive project, and is more of creating a new API and library
rather than a mere cleanup job.  That will be a massive effort, and
you do have to keep in mind how much time all involved can put into
it.

> Turning structures opaque doesn't prevent people from still messing
> with their internal fields.

True.  But it makes for a clear delineation where people are forced to
be aware that they are playing with internal stuff, and that it may
not be a safe thing to do.  When structures weren't opaque, people
*expected* things to stay as they were or be added at the end of the
structure, see API / ABI compatibility.  That took away *all*
possibilities of cleaning them up or enhancing them smoothly without
risking application breakage at every turn.

So basically, the message is that if you want to tinker with stuff
that's essentially internal to the library, do feel free, but do so at
*your* risk, not ours.

(re API / ABI compatibility, I learned the lesson back when I was
fairly new and made my own mistakes...  adding the weak_key field in
struct des_ks_struct back in 0.9.2something deserved me no end of
fairly harsh scolding because it broke ABI for everything that did a
stack allocation of that structure and that used the OpenSSL shared
libraries)

> world - from what I've been told the reason for why those memory
> dumps always looked so juicy was because OpenSSL used its own memory
> pooling.

Uhmmmm....  this is factually incorrect.  OpenSSL doesn't use its own
memory pooling.  We have thin wrappers around the usual malloc() /
realloc() / free(), which allows any application to do its own memory
pooling.

> The point is that those volunteers you mentioned happen to volunteer
> to work on actively bad stuff and/or in an actively bad way.
> Seggelmann was a volunteer, wasn't he, and he did the hithertofore
> greatest damage to OpenSSL and cryptography because of his
> incompetency, whether it was a genuine mistake or intentional.

Wow...

So what you're saying is that one huge enough mistake, and that
cancels out everything else you do or have done?

    : ; git log | grep Seggel | wc -l
    53

Note also that he couldn't commit his contributions directly, they had
to be applied (and implicitly reviewed) by someone in the team, which
was a single underfunded (UNfunded, to tell the truth) individual at
the time.

Wanna assign incompetence for mistakes like this?  In that case,
there's plenty to go around, and there's isn't one single competent
programmer alive.  Errare humanum est 'n all that.

> Genuine mistakes happen, but they *shouldn't* happen in
> infrastructure code

It's easy to say.  Still, humans err...  you can look at any
infrastructure (say, roads) and realise that mistakes are made, and we
try to learn from them.

Speaking of learning, one of the things we did after Heartbleed was to
put a code review process in place.  We do hope that it will help to
keep shitty mistakes out.  It's not an absolute guarantee, but we do
believe it's *better*.

Speaking of which, all our development is available on github in form
of pull requests.  Anyone is welcome to have a look and to comment /
help weed out bad code or help make the code better.  You're welcome
to go in there and help out, and that would probably be more
constructive than a massive continued rant here.

> I also think you're *sorely* underestimating how low people can steep
> just to say "I've been working on OpenSSL" or "I've been working on
> the Linux kernel" or "I've been working on Apache". The Apache FCGI
> module for Perl does not support printing out UTF-8 data to this day -
> in fact there's code that checks if the UTF-8 is set, and implicitly
> downgrades that string to ISO-8859-1 if so. If it can't do so it gobs
> a retarded warning into your server logs. The module's apparently been
> written in 2003 and received an update in 2010. Did this update get
> rid of the warning and/or the downgrade? Nope, neither of those. The
> update merely changed the warning to "[this] will stop wprking [sic!]
> in a future version of FCGI". In 2010. If this wasn't someone who just
> wanted to be able to say that they've been working on Apache FCGI I'm
> going to eat a broomstick, as they say in German.

Not that I would know why we should care about shit in other projects
here, but considering it's open source, you could do the required
modification and contribute there.

> So, no. I will not show respect to bad code just because it's cheap
> or free. My respect goes to people who do good stuff, whether it's
> for free or not. People who just provide shitty things for free
> deserve shitty respect at best. In turn, people who do good stuff
> for free deserve a lot of respect without asking for it. You want
> the same respect? Then maybe not let any volunteer check in code
> just because they can.

I'll gently point out that for non-free / non-open-source code, you
have no idea if the code is shitty or not.  All you have to see is the
API.

> you *never* want to reach a point where your users are brought to
> the point where they start reading your source code, because even
> though that might teach them what to do it makes them unable to
> sleep at night.

I'm sorry if my code causes that level of angst.

However, I disagree with you, we *do* want users to look at our code,
'cause at least some of them will come back and help us improve it.
Or well, we hope they will.

That's the whole idea with an open source project.

To conclude, I have a question for you: are you only willing to rant
(*), or are you willing to help out in another way?  Things that may
have a better outcome and may be energy better spent is to actually
volunteer by going to our github space, review and comment on PRs that
you think are important, raise issues (please, more detailed than a
generic call for cleanup) or contribute code.

    https://github.com/openssl/openssl/

Cheers,
Richard

(*) a word to anyone that wants to scold Herr Wehrmeyer for ranting:
it may be annoying to have to listen to it (no one forces you to), but
it's ALSO a contribution if you're willing to listen, as it helps keep
a focus you may be missing.
Also, I do not want to encourage a rant fest, that's just going to
deteriorate morale, but I do think that the occasional rant is
acceptable and should be appreciated for what it is.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/