[openssl-users] Authentication over ECDHE

[C.Wehrmeyer]

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.
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. That's nice to 
have, don't get me wrong, but the base here has been broken for years, 
and is even made *worse* over time. Opaquing structures so that people 
cannot know how big they are anymore, which is required for determining 
the amount of memory such an object needs, has been done in 2016. So, 
apparently people are *willing* to do wide-spread rewrites of things and 
are even willing to break existing applications for newer versions 
(which is brave, again, don't get me wrong here), but ... seemingly not 
in what I'd call a positive direction.

Turning structures opaque doesn't prevent people from still messing with 
their internal fields. We know that because people have been doing that 
on Windows handles for ages, so it only makes their jobs a little harder 
on that field. On the other hand, turning structures opaque for people 
who want to *work* with the library, to want to do smart things because 
they know the requirements of the applications, are actively being 
hindered by this approach. It adds a lot of code and complexity to the 
library side, which already *has* a lot of code and complexity by its 
nature of being a *crypto* library. And it does not even make memory 
contents more secure, as Heartbleed has shown the 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. So what is even the 
point of opaquing here? And yet there's been put a lot of time and 
effort into this mechanic.

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. I see a lack of *respect* for OpenSSL in 
that people who probably *shouldn't* be working on it still work on it 
as volunteers, because it looks nice on the résumé, and check in shoddy 
code. Genuine mistakes happen, but they *shouldn't* happen in 
infrastructure code - and I think I've made myself already clear that I 
view cryptography as infrastructure. Saying "yeah, well, they 
volunteered, they put in the time and effort, we should be thankful for 
that" is not enough. I don't care if the engineer who's building the 
bridge is being paid or not (he should be, though); what I care about is 
that the bridge doesn't collapse when a stronger wind appears. Same with 
code: I don't care if you volunteered to work on SSL or if you're being 
paid for it, what I care about is the quality of your work. I'd rather 
have no work at all from you than work that is just bull. I'd rather 
have no encryption at all than so-called "export encryption" that's been 
lobotomised for commercial use. And I'd rather walk those 300 meters 
using a mountain path than using a bridge that didn't cost anything and 
doesn't look very stable. /At the very least I'll have some sort of 
security, may it be that we need a dedicated secure channel rather than 
cryptography, or maybe adding a rail to the mountain path/. And in that 
sense not having or not wanting to have some sort of leverage against 
someone who repeatedly sends in shit code is a negative - not a positive.

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.

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.

And more often than you'd think "no deal" can still be the best deal if 
the seemingly only other best deal is still a shit deal. I've been told 
a lot of Brits are learning that lesson these days.

On 30.12.18 03:40, tincanteksup wrote:
> On 29/12/2018 22:08, C.Wehrmeyer wrote:
> 
>> How am I supposed to get more adept when the documentation is a 
>> literal mess?
> 
>> Let me reverse that: What is the *point* of getting more adept with 
>> the API when I feel more and more disgusted by learning how it's 
>> working internally?
> 
> Welcome to The Jungle ..

I don't get the message. Care to elaborate?

Getting a feeling for the tidiness of the source code isn't a hard 
problem. If I want to look at the source code of SSL_new() that's not 
terribly hard. One fgrep through the source directory lists 
"ssl/ssl_lib.c" amongst other hits, and unlike those other hits this one 
shows the type it returns (SSL *) and doesn't end in a semicolon. Then 
just search for SSL_new() until you find it, and then start reading away.

Getting more adept with the library in general? That's hard. There's 280 
symbols just starting with "SSL_" in 1.0.0 alone:

$ nm libssl.so.1.0.0 | grep ' SSL_' | wc -l
280

I'm not going to drop all those symbols on you, but how is one to know 
which function or macro or whatever is the ticket here? The 
documentation barely helps, we've already established that. Source code 
reading? That reveals the things that I *do not* want to know too, 
because it makes me feel uneasy - which really is the point here: 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've 
had that problem with the nouveau driver, which wrote random numbers to 
random hardware registers without even trying to make some sense of it, 
in other words it was completely undebuggable; I've had that problem 
with freetype, whose API was even worse than OpenSSLs because they 
didn't even *attempt* to give higher-levels the option to pass pointers 
to cached objects, so they'd constantly allocate and free subobjects via 
malloc() and free() every time an object was created; and I've had that 
problem with PCSX2, which, at least the last time I checked, doesn't 
support x64 builds and is as such limited to a reduced amount of virtual 
memory space, which it actually sorely needs for image file mappings and 
random access therein. Well, that, and the fact that instead of using a 
static buffer with static size for the window title update function 
they're using lots of dynamic buffers and reallocations each time the 
function is called.

Why do I mention all of this? Because in all those cases I didn't have 
to know exactly what those functions and programs did for me to be able 
to tell that things were messy.