[openssl-users] Authentication over ECDHE

Sat Dec 29 20:39:52 UTC 2018

You really have no idea how to code. You look like one of those junior
engineers that think they know it all.

I won't be replying again, so don't need to get your hopes up.

Na(o) sábado, 29 de dez de 2018, 17:19, C.Wehrmeyer <c.wehrmeyer at gmx.de>
escreveu:

> 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.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181229/8cf5f3de/attachment.html>