[openssl-users] Authentication over ECDHE

[C.Wehrmeyer]

On 29.12.18 16:53, Jakob Bohm via openssl-users wrote:
 > The session caching in the SSL and TLS protocols is to skip the
 > expensive key exchange when reconnecting within a few seconds,
 > as is extremely common with web browsers opening up to 8 parallel
 > connections to each server.

My outburst was somewhat out of line. SSL_clear() is not *completely* 
superfluous, you're right, but it's incredibly limited.

 > There is hopefully a configuration option to tell the OpenSSL server
 > end SSL_CTX to not do this, just as there should (for multi-process
 > web servers) be an option to hand the state storage over to the web
 > server application for inter-process sharing in whatever the web
 > server application (and its configuration) deems secure.

Then why doesn't the documentation page of SSL_clear() mention this 
directly? "If you want to reuse an SSL object, use this function to set 
some option on the SSL_CTX object".

On 29.12.18 17:08, Richard Levitte wrote:
 > ...  I'm not sure about you, but I have a hard time seeing how one
 > would trim off fat from *public* structures that everyone and their
 > stray cat might be tinkering in.  Trimming off fat usually means
 > restructuring the structures, and unless they're opaque, the freedom
 > to do so is severily limited.

You're implying that people can't do that anymore. Let me assure you 
that they still can, you just made it a little harder for people who're 
really determined to walk outside of the API bounds.

On the other hand you've made the normal applications programmers job - 
which is to know where and when to allocate and free memory - a lot 
harder. Here I am, having a bunch of objects all sitting in a designated 
memory area of mine - which I can initialise, reset, and reuse just how 
I seem fit (not that I want to horribly break SSL objects, I just want 
to determine where they are stored) - and I can't use them because the 
OpenSSL devs are working on taking a little bit of power from me that I 
need in order to help the library do smart things.

Like, imagine that I know I'll need:

- a context object
- a connection object
- a BIO object
- some X.509 cert object/memory/whatever
- and so forth and so on

And that not just once, but for a thousand connections. As an 
application programmer who knows a thing or two about scalable 
programming I'd be like: OK, that's fantastic. I can mmap the necessary 
memory, use hugepages, reduce the TLB, and just have all that stuff 
written on the same chunk without metadata or padding inbetween, which 
doesn't bloat our D$. Sweet money!

And now I can't do that because the devs want me to use their 
single-object-only creation functions who return already allocated 
memory to me. I don't get to decide anymore where my objects are 
written, I don't get to decide what caching objects are used (maybe I 
don't WANT an X.509 cert object, so I could pass NULL to the function 
that creates it, or maybe I already HAVE a couple hundred of those lying 
here, so you can have them ... no? You prefer your structures to be 
opaque? Oh well).

But, you know, it could still be argued that this is safer somehow. 
*Somehow*. If not ... for the fact that I don't even seem to be able to 
KEEP the objects OpenSSL created for me quite elaborately.

 > You do know that your string insert NUL bytes, right?  If you have a
 > look at how they're used, you might see why those stray NUL bytes
 > aren't a good thing.

Yes, I do. See below, I wrote the last part first.

(Also, what? Please have a look again, those stray NUL bytes wouldn't 
have ANY effect, at least not that I see it. One memcpy(), two 
EVP_DigestUpdate(), and it's always a separately calculated length).

 > P.S. as a side note, your message triggered profanity filters.  I
 > don't really care, it's not our filters, but this is just to inform
 > you that your rant didn't quite reach everyone (those with profanity
 > filters in place)
 > /postmaster

It's just that this is so stupid to me. I'm no crypto master, I know 
that. But I constantly hear about timing attacks and side channels and 
all that, so I tried to avoid stepping into the pitfalls that other 
people would do - and then I'm being told it's SUPPOSED to be like that. 
Come on, please! It's almost as if the devs aren't even trying.

On 29.12.18 17:21, J. J. Farrell wrote:> So instead of correct portable 
code which derives obviously and
 > straightforwardly from the specification, you'd write arrays of a
 > different length from the original, the first 48 bytes of which would
 > only be correct in some compilation environments, and even in the cases
 > where those 48 bytes end up correct they have no obvious relationship to
 > the specification they are implementing (your obfuscation making the
 > code much more difficult to review). How are these changes improvements?
Another implication, this time that my code isn't perfectly portable 
code. There is *one* environment I could think of where this wouldn't be 
the case - that being Shift JIS environments that tinker with ASCII 
standard by replacing a backslash with a Japanese half-width Yen sign - 
however:

1. we'll already have much, MUCH bigger problems if ASCII isn't the
encoding the compiler is expecting here, so exchanging 0x5c for '\' is 
not going to ruin much more here. And it doesn't even matter anyway 
because any Shift JIS editor would display this as the half-width Yen 
sign *anyways*. (And that being said, since the main criticism of the 
Han unification of the Unicode consortium came from the Japanese, I 
don't care if they're going to throw another fit. They can't even 
prevent mojibake between mainly Japanese character encodings. At least 
ISO-8859-1/CP1252 has the excuse of being the most popular encoding in 
the entire west, so ... whatever. Just let them rail.)
2. to be honest I wouldn't have have this be a static array at all, but 
rather an exportable pointer and an exportable variable that would hold 
the string's size minus one. However, if you actually HAD looked at the 
code as is - which you obviously haven't because you wouldn't have even 
brought it up then - the size of the array is completely inconsequential 
in that particular code. That's right: they don't even derive the 
amounts of bytes to copy from the string directly, but rather just use a 
constant:

 > npad = (48 / md_size) * md_size;

Oh, you want me to change that? No problem:

 > #define STRING \
 >         "xxxxxxxx" \
 >         "xxxxxxxx" \
 >         "xxxxxxxx" \
 >         "xxxxxxxx" \
 >         "xxxxxxxx" \
 >         "xxxxxxxx"
 >
 > const unsigned char string_length = sizeof(STRING) - 1;
 > const char*string = STRING;
 >
 > npad = (string_length / md_size) * md_size;

Hell, I could even create a macro for this so that I don't even need the 
explicit definition of STRING here. It's not as if OpenSSL shies away 
from the concept of using macros to auto-generate a plethora of symbols 
(I'm looking at include/openssl/crypto.h right now).

 > I'd walk you out of an interview if you offered this as an
 > implementation, let alone as an improvement.

Don't worry, I'd fire you on the spot if you had checked in the existing 
code, so I'll call it quits.