[openssl-users] Authentication over ECDHE

Sat Dec 29 21:38:01 UTC 2018

When we're starting to stoop to this level, I think it's time to step
away from the screen and take a few deep breaths...  or maybe even go
away and take a nap, go for a walk, or something else.  Then, perhaps
come back in a better mood.

Cheers,
Richard ( am off to sleep, it's getting late over here )

In message <CAEfnEiA0NLgzsk9iG2mqvOVmuL6EK112m3g8tmR16_bCaXw=QQ at mail.gmail.com> on Sat, 29 Dec 2018 20:39:52 +0000, Filipe Fernandes <filipe.mfgfernandes at gmail.com> said:

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