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