<div dir="auto"><div>You really have no idea how to code. You look like one of those junior engineers that think they know it all.<div dir="auto"><br></div><div dir="auto">I won't be replying again, so don't need to get your hopes up. </div><br><br><div class="gmail_quote"><div dir="ltr">Na(o) sábado, 29 de dez de 2018, 17:19, C.Wehrmeyer <<a href="mailto:c.wehrmeyer@gmx.de">c.wehrmeyer@gmx.de</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 29.12.18 16:53, Jakob Bohm via openssl-users wrote:<br>
> The session caching in the SSL and TLS protocols is to skip the<br>
> expensive key exchange when reconnecting within a few seconds,<br>
> as is extremely common with web browsers opening up to 8 parallel<br>
> connections to each server.<br>
<br>
My outburst was somewhat out of line. SSL_clear() is not *completely* <br>
superfluous, you're right, but it's incredibly limited.<br>
<br>
> There is hopefully a configuration option to tell the OpenSSL server<br>
> end SSL_CTX to not do this, just as there should (for multi-process<br>
> web servers) be an option to hand the state storage over to the web<br>
> server application for inter-process sharing in whatever the web<br>
> server application (and its configuration) deems secure.<br>
<br>
Then why doesn't the documentation page of SSL_clear() mention this <br>
directly? "If you want to reuse an SSL object, use this function to set <br>
some option on the SSL_CTX object".<br>
<br>
On 29.12.18 17:08, Richard Levitte wrote:<br>
> ... I'm not sure about you, but I have a hard time seeing how one<br>
> would trim off fat from *public* structures that everyone and their<br>
> stray cat might be tinkering in. Trimming off fat usually means<br>
> restructuring the structures, and unless they're opaque, the freedom<br>
> to do so is severily limited.<br>
<br>
You're implying that people can't do that anymore. Let me assure you <br>
that they still can, you just made it a little harder for people who're <br>
really determined to walk outside of the API bounds.<br>
<br>
On the other hand you've made the normal applications programmers job - <br>
which is to know where and when to allocate and free memory - a lot <br>
harder. Here I am, having a bunch of objects all sitting in a designated <br>
memory area of mine - which I can initialise, reset, and reuse just how <br>
I seem fit (not that I want to horribly break SSL objects, I just want <br>
to determine where they are stored) - and I can't use them because the <br>
OpenSSL devs are working on taking a little bit of power from me that I <br>
need in order to help the library do smart things.<br>
<br>
Like, imagine that I know I'll need:<br>
<br>
- a context object<br>
- a connection object<br>
- a BIO object<br>
- some X.509 cert object/memory/whatever<br>
- and so forth and so on<br>
<br>
And that not just once, but for a thousand connections. As an <br>
application programmer who knows a thing or two about scalable <br>
programming I'd be like: OK, that's fantastic. I can mmap the necessary <br>
memory, use hugepages, reduce the TLB, and just have all that stuff <br>
written on the same chunk without metadata or padding inbetween, which <br>
doesn't bloat our D$. Sweet money!<br>
<br>
And now I can't do that because the devs want me to use their <br>
single-object-only creation functions who return already allocated <br>
memory to me. I don't get to decide anymore where my objects are <br>
written, I don't get to decide what caching objects are used (maybe I <br>
don't WANT an X.509 cert object, so I could pass NULL to the function <br>
that creates it, or maybe I already HAVE a couple hundred of those lying <br>
here, so you can have them ... no? You prefer your structures to be <br>
opaque? Oh well).<br>
<br>
But, you know, it could still be argued that this is safer somehow. <br>
*Somehow*. If not ... for the fact that I don't even seem to be able to <br>
KEEP the objects OpenSSL created for me quite elaborately.<br>
<br>
> You do know that your string insert NUL bytes, right? If you have a<br>
> look at how they're used, you might see why those stray NUL bytes<br>
> aren't a good thing.<br>
<br>
Yes, I do. See below, I wrote the last part first.<br>
<br>
(Also, what? Please have a look again, those stray NUL bytes wouldn't <br>
have ANY effect, at least not that I see it. One memcpy(), two <br>
EVP_DigestUpdate(), and it's always a separately calculated length).<br>
<br>
> P.S. as a side note, your message triggered profanity filters. I<br>
> don't really care, it's not our filters, but this is just to inform<br>
> you that your rant didn't quite reach everyone (those with profanity<br>
> filters in place)<br>
> /postmaster<br>
<br>
It's just that this is so stupid to me. I'm no crypto master, I know <br>
that. But I constantly hear about timing attacks and side channels and <br>
all that, so I tried to avoid stepping into the pitfalls that other <br>
people would do - and then I'm being told it's SUPPOSED to be like that. <br>
Come on, please! It's almost as if the devs aren't even trying.<br>
<br>
On 29.12.18 17:21, J. J. Farrell wrote:> So instead of correct portable <br>
code which derives obviously and<br>
> straightforwardly from the specification, you'd write arrays of a<br>
> different length from the original, the first 48 bytes of which would<br>
> only be correct in some compilation environments, and even in the cases<br>
> where those 48 bytes end up correct they have no obvious relationship to<br>
> the specification they are implementing (your obfuscation making the<br>
> code much more difficult to review). How are these changes improvements?<br>
Another implication, this time that my code isn't perfectly portable <br>
code. There is *one* environment I could think of where this wouldn't be <br>
the case - that being Shift JIS environments that tinker with ASCII <br>
standard by replacing a backslash with a Japanese half-width Yen sign - <br>
however:<br>
<br>
1. we'll already have much, MUCH bigger problems if ASCII isn't the<br>
encoding the compiler is expecting here, so exchanging 0x5c for '\' is <br>
not going to ruin much more here. And it doesn't even matter anyway <br>
because any Shift JIS editor would display this as the half-width Yen <br>
sign *anyways*. (And that being said, since the main criticism of the <br>
Han unification of the Unicode consortium came from the Japanese, I <br>
don't care if they're going to throw another fit. They can't even <br>
prevent mojibake between mainly Japanese character encodings. At least <br>
ISO-8859-1/CP1252 has the excuse of being the most popular encoding in <br>
the entire west, so ... whatever. Just let them rail.)<br>
2. to be honest I wouldn't have have this be a static array at all, but <br>
rather an exportable pointer and an exportable variable that would hold <br>
the string's size minus one. However, if you actually HAD looked at the <br>
code as is - which you obviously haven't because you wouldn't have even <br>
brought it up then - the size of the array is completely inconsequential <br>
in that particular code. That's right: they don't even derive the <br>
amounts of bytes to copy from the string directly, but rather just use a <br>
constant:<br>
<br>
> npad = (48 / md_size) * md_size;<br>
<br>
Oh, you want me to change that? No problem:<br>
<br>
> #define STRING \<br>
> "xxxxxxxx" \<br>
> "xxxxxxxx" \<br>
> "xxxxxxxx" \<br>
> "xxxxxxxx" \<br>
> "xxxxxxxx" \<br>
> "xxxxxxxx"<br>
><br>
> const unsigned char string_length = sizeof(STRING) - 1;<br>
> const char*string = STRING;<br>
><br>
> npad = (string_length / md_size) * md_size;<br>
<br>
Hell, I could even create a macro for this so that I don't even need the <br>
explicit definition of STRING here. It's not as if OpenSSL shies away <br>
from the concept of using macros to auto-generate a plethora of symbols <br>
(I'm looking at include/openssl/crypto.h right now).<br>
<br>
> I'd walk you out of an interview if you offered this as an<br>
> implementation, let alone as an improvement.<br>
<br>
Don't worry, I'd fire you on the spot if you had checked in the existing <br>
code, so I'll call it quits.<br>
-- <br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
</blockquote></div></div></div>