[openssl-users] Authentication over ECDHE

[C.Wehrmeyer]

On 31.12.18 10:12, Richard Levitte wrote:
> 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.

You realised what I have left unspoken thus far, which is this almost 
obsession-like preference of OSS coders to add new features rather than 
improving the old, boring codebase. However, there's a reason why it's 
still called code*base*. It's the base of everything. And adding more 
and more features to that base is going to make ripping off the band-aid 
more painful in the long run.

Also, infrastructure again. I, as a user, don't care if the kernel gets 
a new feature that makes some black magic happening. What I care about 
is that the kernel doesn't throw away my writes (which has happened in 
May of 2018, see):

 > 
https://www.postgresql.org/message-id/flat/CAMsr%2BYE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG%2BvzHun1EqMxyQg%40mail.gmail.com#CAMsr+YE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG+vzHun1EqMxyQg@mail.gmail.com)

Cryptography libs should be equally conservative, considering that 
cryptography is conservative to begin with. I don't care if TLS 1.3 lets 
me use new exiting ciphers and handshakes when it unreasonably bogs down 
my server code.

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

Sure, but didn't Matt just say that there are a lot of volunteers 
working on that library? The disadvantage here is that quality assurance 
is barely a thing - however, the *advantage* of this is that OpenSSL 
does not have to follow commercial interests. If we look at this at face 
value you could just say "No, people, it's high time we streamline some 
of the internal aspects of the library, TLS 1.3 will have to wait. You 
can't wait that long? Well, sorry".

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

But what does "cleanup" entail? That's the hot-button question here. 
I've already made a suggestion, that is to say, getting rid of opaque 
structures. If that is deemed too insecure (for whatever reasons), 
export symbols that allow programmers to query the size of structures, 
and provide two versions of functions: one function expects the caller 
to pass an object to which the changes are to be made, and the other one 
allocates the necessary memory dynamically and then calls the first 
version. Or just don't allocate my object memory dynamically anymore.

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

So, what you're effectively saying is that I'm the first one who ever 
asked for SSL object reuse, right? Because if piecemeal work happens on 
the documentation, and Viktor says that it's possible, then surely no 
one would have ever answered that question on the mailing list and *not* 
put it piecemeal-ly in the OpenSSL documentation, right?

> Now, here's something else that you need to consider: API/ABI
> compatibility needs to be preserved.

No it doesn't. We *know* it doesn't. When OpenSSL 1.1 was released it 
broke all *sorts* of applications out there, because all sorts of 
applications used struct fields rather than accessors. wget, mutt, neon, 
python, you name it, you broke it.

 > https://breakpoint.cc/openssl-1.1-rebuild-2016-08-26/

So since when do we need to consider API/ABI compatibility? Did we grow 
up recently?

Or maybe OpenSSL should have switched the language. The point of C is 
that structures are public. And if I'm going to be honest that approach 
saved my sorry arse more than a couple times. When zlib choked because 
it couldn't go past 4 GiBs of data since its fields were uint32_ts, I 
was able to easily workaround this problem. But what do I know.

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

You're taking my statement out of context. Counting the symbols wasn't 
supposed to suggest that there are too *many* of them. I'm in no 
position to say that, seeing as the original context in which my 
statement was put is that *I'm not familiar enough with the library*.

What I said was that reading the code is easy. Learning what the library 
provides is hard, and that you won't learn much just by looking at the 
symbols because there's so many of them.

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

I'm not saying it needs to be done right now. I'm merely suggesting that 
it might be a good goal post for OpenSSL 2.0.

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

Then why not provide small helper functions for covering the "playing 
with internal stuff" part? That way it's still controlled, and 
documented, and unified. You guys must've had some examples to show off 
in order to justify the process, so surely you know what it is that 
people do when they use internal stuff. Make functions for those. Don't 
give them any reason to continue playing with internal stuff.

I don't like code that tries to protect programmers from themselves. I 
like code that lets good programmers do smart things. And if bad 
programmers use that freedom to do bad stuff, then doesn't that mean 
your API simply didn't support this, and they had to make it work 
somehow else? Again, helper functions.

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

 > 
https://web.archive.org/web/20150207180717/http://article.gmane.org/gmane.os.openbsd.misc/211963

If you don't wanna read too much:

 > https://xkcd.com/1353/

Read the mouse-hover text.

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

If it only was one mistake. I read in June 2014 that Seggelmann was 
*also* responsible for the DTLS code:

https://www.openssl.org/news/secadv/20140605.txt

And Thor knows how many others that we aren't aware of.

And just in case you don't get this: this has caused *massive* damage. 
It's not just *one* mistake. Heartbleed was caused by input validation 
screwups. We've been known since at least the 80s that this causes 
widespread issues. For f*cks sake, this November we were informed that 
FreeBSD could be pinged to death.

And not only Seggelmann f*cked up. Also the guy who went over his code. 
On New Year's morning, no less, where it should have been *clear* that 
no one is in the right mental state of mind for that. For instance I 
don't do any coding in the evening because I know myself enough to know 
that my brain is mush and that whatever I'll produce is equivalent with 
horse barf.

So, no, this isn't just *one mistake*. This is "I have no idea what I'm 
doing, in a field where certified security experts f*ck up things every 
now and then, but I'm doing it anyway for my dissertation" while 
everyone was looking away.

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

Only there's a difference between a mistake and dabbling in forces you 
shouldn't dabble in. But again, it looks nice on the résumé.

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

WE HAVE HAD INPUT VALIDATION PROBLEMS SINCE THE 80S. SO WHAT HAVE WE 
LEARNT, HUH? WHAT HAVE WE LEARNT? WE HAVE LEARNT JACK-EFFING-SHTIE. 
Decades went by, but we're as arrogant as ever.

I HATE this approach. "Programmers shouldn't be held accountable for 
their screw-ups because to err is human" is what it effectively says. 
Did this story have ANY consequences for Seggelmann? Not that I'm aware 
of. Only when people began to suggest that this may be a backdoor he 
felt the need to save face. And as far as I'm aware he hasn't even 
apologised once.

But that's what you get when you prefer to add features over a solid 
codebase.

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

It certainly didn't help against:

 > npad = (48 / md_size) * md_size

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

You're just a bigger target than Apache FCGI. This heartbleed stuff was 
pretty much only for Seggelmann's career. And look what kind of example 
he set, seeing as I don't see him suffering consequences for that.

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

Unfortunately I never said that I have an idea about whether or not 
non-open-source code is good or bad. What I actually said was that 
people who do good work should be paid for that, and if they do that for 
free that's even more admirable.

(I'm not going to discuss business models on how people can make money 
with cryptography code while it still being Open-Source.)

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

Not the code per se. However I (and several other people I know) have 
given up on reading code they weren't paid for. Otherwise they see 
things that makes them want to throw it away in disgust, and if that 
happens a couple times they're left there with their kernel and a text 
editor. It's a self-preservation policy.

So, no, it's *reading* your code that causes ... angst? You used that 
word twice now. I don't know what it has evolved into in English, seeing 
as I only ever see people accusing others of "being angsty", but just 
for the record: in German "Angst" ("a" somewhat like the "u" in "hunt") 
means genuine fear and fright. "Angst" and "anxiety" share the same 
roots, but "anxiety" is usually more mellow. Not that "anxiety" is the 
right word here, again - "disgust" fits better.

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

I know enough people who wouldn't, and that's all I'm gonna say about this.

> To conclude, I have a question for you: are you only willing to rant
> (*), or are you willing to help out in another way?

This is not the question I feel you should ask because we haven't even 
established if I *could* make contributions to the project, as my 
mindset appears to be so much more different. Especially the idea of not 
wanting to break APIs/ABIs is a huge limitation - just looking at 
SSL_new() made me give up hope here.

I'm no cryptography expert, I've made that clear from mail one, and my 
cleanup jobs would be more widespread than what seems to be deemed 
acceptable right now. I can read and write scalable C code, otherwise I 
wouldn't even have tried to reuse that SSL object from the beginning.

So, I ask a question in return: what do you think I *could* be helping with?

Also, a happy new year to all.