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@xxxxxxxxxxxxxx> on Sat, 29 Dec 2018 20:39:52 +0000, Filipe Fernandes <filipe.mfgfernandes@xxxxxxxxx> 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@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
