Re: Authentication over ECDHE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx)

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.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux