Authentication over ECDHE

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

Jeremy Farrell
On 29/12/2018 17:18, C.Wehrmeyer wrote:

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

You don't explain the benefits of coding a requirement for "the byte
0x5C repeated 48 times" as a string of back-slash characters instead of,
well, the byte 0x5C repeated 48 times. What are the benefits, and how do
they outweigh the ability to compare more easily against the requirement?

You don't explain the benefits of writing non-portable code where that
code is very widely deployed in environments of which you have no
knowledge (and which don't even exist at the time of writing it),
without even a comment specifying the portability restrictions you are
imposing, when it's just as easy to write the code portably and not need
to think about such restrictions. What are the benefits, and how do they
outweigh the obvious disadvantages?

--
J. J. Farrell
Not speaking for Oracle

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

Viktor Dukhovni
In reply to this post by C.Wehrmeyer
> On Dec 29, 2018, at 8:19 AM, C.Wehrmeyer <[hidden email]> wrote:
>
> OK, so I've been reading the mails before going to sleep and spent some time thinking and researching about this, and I've come to a conclusion: OpenSSL is a goddamn mess, SSL_clear() is pretty much superfluous, and as such shouldn't exist.
>
> Why? Well, to quote Viktor here:
>
> > DO NOT reuse the same SSL handle for multiple connections,

I said it, neither because it can't be done, nor because it is
incompatible with session caching, or has anything to do with
ephemeral key agreement (which works just fine even with
session resumption), but simply because it is easier for a
beginner to get the code working without SSL handle re-use.

Once you have you everything else working, and have become
more adept with use of the library, you can add connection
handle re-use and measure the performance impact.  If it
makes a significant difference, then invest in maintaining
slightly more complex code to get the advantage.

That's all I can offer in light of the bellicose rant, ... :-(
Good luck.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

Filipe Fernandes
In reply to this post by C.Wehrmeyer
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

OpenSSL - User mailing list
In reply to this post by OpenSSL - User mailing list
    > I didn't bother looking up what freeing entails - it's obvious to
    > anyone at this point that OpenSSL is a severe victim of feature creep,
    > that its memory allocation scheme is a mess, and long story short: I
    > will NOT free a perfectly fine object just because of incompetent
    > devs' chutzpah expecting their users to allocate memory dynamically en
    > mass for no goddamn reason whenever a new connection comes in. Fix
    > your goddamn code.

Might I suggest that you fix your attitude?  An insult and invective-filled polemic does no good.

Perhaps you might find another library more to your liking; there are many available now.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

Richard Levitte - VMS Whacker-2
In reply to this post by Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Sat, 29 Dec 2018 17:08:46 +0100 (CET), Richard Levitte <[hidden email]> said:

> In message <[hidden email]> on Sat, 29 Dec 2018 14:19:47 +0100, "C.Wehrmeyer" <[hidden email]> said:
>
...

> > What's wrong with that, you ask? Let me show you how I'd have done
> > that:
> >
> > > static const unsigned char ssl3_pad_1[] =
> > > {
> > >     "66666666"
> > >     "66666666"
> > >     "66666666"
> > >     "66666666"
> > >     "66666666"
> > >     "66666666"
> > > };
> > >
> > > static const unsigned char*ssl3_pad_2[] =
> > > {
> > >     "\\\\\\\\\\\\\\\\"
> > >     "\\\\\\\\\\\\\\\\"
> > >     "\\\\\\\\\\\\\\\\"
> > >     "\\\\\\\\\\\\\\\\"
> > >     "\\\\\\\\\\\\\\\\"
> > >     "\\\\\\\\\\\\\\\\"
> > > };
> >
> > So, no. I don't trust anyone. Especially not this mess of a code.
>
> 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.

Never mind this remark...  For some reason, my brain added commas
after each partial string.  Meh...

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

Richard Levitte - VMS Whacker-2
In reply to this post by Filipe Fernandes
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=[hidden email]> on Sat, 29 Dec 2018 20:39:52 +0000, Filipe Fernandes <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

C.Wehrmeyer
In reply to this post by Filipe Fernandes
On 29.12.18 21:32, Viktor Dukhovni wrote:
 > I said it, neither because it can't be done, nor because it is
 > incompatible with session caching, or has anything to do with
 > ephemeral key agreement (which works just fine even with
 > session resumption), but simply because it is easier for a
 > beginner to get the code working without SSL handle re-use.

OK, now just hold on a sec here.

1. Your complete statement was:
 > DO NOT reuse the same SSL handle for multiple connections, create a
 > new one for subsequent connections, but you can and generally should
 > reuse the SSL_CTX.

Previously I had stated that client and server already stand pretty
much, and that this is about the finishing touches. Like in, the
finishing touches where I'd test what happens if the PSKs mismatch, and
see the result of what's happening there. I had already established at
this point that my code works if the PSKs DO match.

Why is that important? Well, because that would've been a *perfect point
in time* for you to mention that it's indeed possible to reuse a handle
without recreation. Hell, such a thing would've been perfect *in the
documentation page of SSL_clear(), where people would first go to read
up on that*. I'd know they do. I did so.

2. I never said ephemeral key agreement would NOT work with session
resumption. To quote the documentation of SSL_clear() again:

 > The reset operation however keeps several settings of the last
 > sessions (some of these settings were made automatically during the
 > last handshake).

And when I hear TLS resumption, then I don't just hear this:

 >
https://svs.informatik.uni-hamburg.de/publications/2018/2018-12-06-Sy-ACSAC-Tracking_Users_across_the_Web_via_TLS_Session_Resumption.pdf

No, I also hear "My keys are not being renegotiated". Not the case? Then
this is a thing that belongs into the documentation of SSL_clear(): "For
ephemeral key ciphers renegotiates those, so that a different key is
being used henceforth". I mean, come on. This is what documentation is
supposed to be made for, isn't it?

 > Once you have you everything else working

Well, what else could I have left working on that doesn't involve the
transport layer? Because that's the main issue right now. Application
protocol isn't a problem. Connection to the database server isn't a
problem. Loading a 4096-bit Diffie-Hellman prime in order to prevent
Logjam isn't a problem (also the API to make OpenSSL use that one is
from the same universe in which Spock has a beard).

 > and have become more adept with use of the library

How am I supposed to get more adept when the documentation is a literal
mess? SSL_clear() doesn't mention stuff it's supposed to mention.
BIO_new_socket has had a "TBA" in its "SEE ALSO" block seemingly ever
since 1.0.2 came out, which was January 2015.

Let me reverse that: What is the *point* of getting more adept with the
API when I feel more and more disgusted by learning how it's working
internally? Why should I bother? The more *adept* I become the more I
want to switch to something else, I can tell you that.

 > If it makes a significant difference, then invest in maintaining
 > slightly more complex code to get the advantage.

Why don't you make it easy for people to use your API correctly right
from the start, then? And that includes, and is not exclusive, to
startup code as well. Do you know how often I've seen people out there
use ERR_load_crypto_strings(), ERR_load_SSL_strings(),
OpenSSL_add_all_algorithms(), or SSL_library_init()?

And that's also including SSL object reuse. You cannot tell me I'm the
first one who, in wise precognition of how ugly object initialisation
and release code can be, thought of reusing their SSL objects? And that
the devs never said at one point: "You know what, we'll make this black
magic *easy* to use! Like SSL_clear(), but properly!"?

And of course you're not giving any hints as to WHAT I could look up.
Are there references, example codes, anything I could read up on?
Specific google search words? Links?

Nah. Nothing. It's weekend, let's go shopping!

 > That's all I can offer in light of the bellicose rant

You're not getting the point, are you?

I've been trying to do my homework, *much* more than what most of the
people I know and work with would have considered acceptable. I've read
about ciphers, their advantages and disadvantages, key exchange crypto.
I got some things wrong. I learnt about them. I tried to implement them.

If someone goes out of their *way* to spend their time familiarising
themselves with the library, the documentation, the very code that runs
things - do you think I pulled that list of stuff SSL_new() does out of
my rectum? - and you do not tell them "Don't do X even though X is
possible, and I could've told you a couple times now that X is possible
even though our documentation is mute about this" - then what you're
basically saying is "F*ck you and your face".

Try to understand me here. I'm trying to get this done, trying to
improve here. I've said several times I ain't got no clue about crypto,
but apparently I'm still trying, aren't I?

On 29.12.18 22:33, Richard Levitte wrote:
 > Never mind this remark...  For some reason, my brain added commas
 > after each partial string.  Meh...

Already forgiven.

On 29.12.18 22:27, Salz, Rich via openssl-users wrote:
 > Might I suggest that you fix your attitude?

Might I suggest to focus your attention to something that can still be
fixed (and that is arguably much more important), rather than a
personality that everyone thus far has given up on? Good crypto is
infrastructure, and the envelope of the message shouldn't deter anyone
from the actual message - that there is something rotten in the state of
Denmark. And if I may say so - there's a lot more message to ponder
about than envelope.

 > An insult and invective-filled polemic does no good.

I was not aware of insults. I used strong adjectives and called people
incompetent, although I find it hard to call it *polemic* seeing at my
arguments far outdid my ranting. It was not my intent to insult anyone
specifically.

 > Perhaps you might find another library more to your liking; there are
 > many available now.

So there are other libs that are:

- receiving frequent updates
- already somewhat old, and as such, well-hung
- are being wildly used
- support all sorts of ciphers (interesting for later projects)
- are written in C (compatibility, and better control against timing
attacks)

? I mean, the first other library that comes to my mind is BoringSSL,
and they even state in their second paragraph of their project side:

 > Although BoringSSL is an open source project, it is not intended for
 > general use, as OpenSSL is. We don't recommend that third parties
 > depend upon it. Doing so is likely to be frustrating because there are
 > no guarantees of API or ABI stability.

On 29.12.18 21:39, Filipe Fernandes wrote:
> You really have no idea how to code. You look like one of those junior
> engineers that think they know it all.

- writes to the topic for the first time
- has shown no code
- has shown no sign that he knows what is being discussed
- has shown no argument against my points
- literally only pops in once in order to shoot an ad hominem attack
without further explanation, without any substance, without anything

It kind of makes one wonder why you felt the need to get this off your
chest - I mean, you could've addressed any of the arguments I've made,
but instead you did ... whatever this is supposed to be ... and then ran
away because you can't stand the echo:

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

Oh, no. I will not receive another trivial attack against my personality
without any arguments to back them up other than "But I don't like your
tone"? What ever will I do now? How will I keep on going?

In all seriousness, you make it sound as if you should be too old for
this kind of behaviour, and then you show *exactly* that kind of
behaviour. Which makes me wonder if you're not too old for this BS.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

Matt Milosevic
I do not want to complicate matters further, but there needs to be one thing clear here: this library is mainly developed and maintained by /volunteers/. They're putting in time and effort to improve the state of the crypto ecosystem, and they seem to be doing a damn good job at it, as even you, yourself, said that (paraphrasing massively) this is the best choice of crypto library out there.

I am not one of those "it doesn't matter what you say, but how you say it" people, but the way you have presented your (valid or invalid; I am not one to say) arguments has changed the perception of yourself in the eyes of quite a few people (by mailing list metrics) thus far. I'd bet that you'd have a much better time getting your points across if you at least tried to be more civil in your arguments, and that you'd attract many more useful and free replies, as opposed to the ones trying to avoid further conflict you're getting now.

Lastly, you are definitely free to submit patches and file issues for anything you deem wrong, bad, insecure or unacceptable in the codebase; it is a much more constructive way of helping both yourself and people who might run into the same problems later down the line. 

Regards, 
Matt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

JordanBrown
In reply to this post by OpenSSL - User mailing list
On 12/29/2018 7:53 AM, Jakob Bohm via openssl-users wrote:
Well, these two latter arrays look like a stray copy of the HMAC
constants "ipad" and "opad", which (while looking like ASCII), are
defined as exact hex constants even on a non-ASCII machine, such
as PDP-11 or an IBM mainframe.


PDP-11 used ASCII.  So did all of the PDP series, though some used a six-bit (no lowercase) variant for some purposes.

-- 
Jordan Brown, Oracle Solaris

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

tincanteksup
In reply to this post by C.Wehrmeyer


On 29/12/2018 22:08, C.Wehrmeyer wrote:

> How am I supposed to get more adept when the documentation is a literal
> mess?

> Let me reverse that: What is the *point* of getting more adept with the
> API when I feel more and more disgusted by learning how it's working
> internally?

Welcome to The Jungle ..


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

C.Wehrmeyer
On 30.12.18 00:04, Matt Milosevic wrote:
 > I do not want to complicate matters further, but there needs to be one
 > thing clear here: this library is mainly developed and maintained by
 > /volunteers/.

For some reason you seem to think this excuses something. I don't.

Fact is: there are a lot of things that could be improved.
Fact is: there are a lot of things that aren't improved, however there
are still features added every now and again. The latest things I've
seen thus far in the code is TLS 1.3 and kernel TLS. That's nice to
have, don't get me wrong, but the base here has been broken for years,
and is even made *worse* over time. Opaquing structures so that people
cannot know how big they are anymore, which is required for determining
the amount of memory such an object needs, has been done in 2016. So,
apparently people are *willing* to do wide-spread rewrites of things and
are even willing to break existing applications for newer versions
(which is brave, again, don't get me wrong here), but ... seemingly not
in what I'd call a positive direction.

Turning structures opaque doesn't prevent people from still messing with
their internal fields. We know that because people have been doing that
on Windows handles for ages, so it only makes their jobs a little harder
on that field. On the other hand, turning structures opaque for people
who want to *work* with the library, to want to do smart things because
they know the requirements of the applications, are actively being
hindered by this approach. It adds a lot of code and complexity to the
library side, which already *has* a lot of code and complexity by its
nature of being a *crypto* library. And it does not even make memory
contents more secure, as Heartbleed has shown the world - from what I've
been told the reason for why those memory dumps always looked so juicy
was because OpenSSL used its own memory pooling. So what is even the
point of opaquing here? And yet there's been put a lot of time and
effort into this mechanic.

The point is that those volunteers you mentioned happen to volunteer to
work on actively bad stuff and/or in an actively bad way. Seggelmann was
a volunteer, wasn't he, and he did the hithertofore greatest damage to
OpenSSL and cryptography because of his incompetency, whether it was a
genuine mistake or intentional. I see a lack of *respect* for OpenSSL in
that people who probably *shouldn't* be working on it still work on it
as volunteers, because it looks nice on the résumé, and check in shoddy
code. Genuine mistakes happen, but they *shouldn't* happen in
infrastructure code - and I think I've made myself already clear that I
view cryptography as infrastructure. Saying "yeah, well, they
volunteered, they put in the time and effort, we should be thankful for
that" is not enough. I don't care if the engineer who's building the
bridge is being paid or not (he should be, though); what I care about is
that the bridge doesn't collapse when a stronger wind appears. Same with
code: I don't care if you volunteered to work on SSL or if you're being
paid for it, what I care about is the quality of your work. I'd rather
have no work at all from you than work that is just bull. I'd rather
have no encryption at all than so-called "export encryption" that's been
lobotomised for commercial use. And I'd rather walk those 300 meters
using a mountain path than using a bridge that didn't cost anything and
doesn't look very stable. /At the very least I'll have some sort of
security, may it be that we need a dedicated secure channel rather than
cryptography, or maybe adding a rail to the mountain path/. And in that
sense not having or not wanting to have some sort of leverage against
someone who repeatedly sends in shit code is a negative - not a positive.

I also think you're *sorely* underestimating how low people can steep
just to say "I've been working on OpenSSL" or "I've been working on the
Linux kernel" or "I've been working on Apache". The Apache FCGI module
for Perl does not support printing out UTF-8 data to this day - in fact
there's code that checks if the UTF-8 is set, and implicitly downgrades
that string to ISO-8859-1 if so. If it can't do so it gobs a retarded
warning into your server logs. The module's apparently been written in
2003 and received an update in 2010. Did this update get rid of the
warning and/or the downgrade? Nope, neither of those. The update merely
changed the warning to "[this] will stop wprking [sic!] in a future
version of FCGI". In 2010. If this wasn't someone who just wanted to be
able to say that they've been working on Apache FCGI I'm going to eat a
broomstick, as they say in German.

So, no. I will not show respect to bad code just because it's cheap or
free. My respect goes to people who do good stuff, whether it's for free
or not. People who just provide shitty things for free deserve shitty
respect at best. In turn, people who do good stuff for free deserve a
lot of respect without asking for it. You want the same respect? Then
maybe not let any volunteer check in code just because they can.

And more often than you'd think "no deal" can still be the best deal if
the seemingly only other best deal is still a shit deal. I've been told
a lot of Brits are learning that lesson these days.

On 30.12.18 03:40, tincanteksup wrote:

> On 29/12/2018 22:08, C.Wehrmeyer wrote:
>
>> How am I supposed to get more adept when the documentation is a
>> literal mess?
>
>> Let me reverse that: What is the *point* of getting more adept with
>> the API when I feel more and more disgusted by learning how it's
>> working internally?
>
> Welcome to The Jungle ..

I don't get the message. Care to elaborate?

Getting a feeling for the tidiness of the source code isn't a hard
problem. If I want to look at the source code of SSL_new() that's not
terribly hard. One fgrep through the source directory lists
"ssl/ssl_lib.c" amongst other hits, and unlike those other hits this one
shows the type it returns (SSL *) and doesn't end in a semicolon. Then
just search for SSL_new() until you find it, and then start reading away.

Getting more adept with the library in general? That's hard. There's 280
symbols just starting with "SSL_" in 1.0.0 alone:

$ nm libssl.so.1.0.0 | grep ' SSL_' | wc -l
280

I'm not going to drop all those symbols on you, but how is one to know
which function or macro or whatever is the ticket here? The
documentation barely helps, we've already established that. Source code
reading? That reveals the things that I *do not* want to know too,
because it makes me feel uneasy - which really is the point here: you
*never* want to reach a point where your users are brought to the point
where they start reading your source code, because even though that
might teach them what to do it makes them unable to sleep at night. I've
had that problem with the nouveau driver, which wrote random numbers to
random hardware registers without even trying to make some sense of it,
in other words it was completely undebuggable; I've had that problem
with freetype, whose API was even worse than OpenSSLs because they
didn't even *attempt* to give higher-levels the option to pass pointers
to cached objects, so they'd constantly allocate and free subobjects via
malloc() and free() every time an object was created; and I've had that
problem with PCSX2, which, at least the last time I checked, doesn't
support x64 builds and is as such limited to a reduced amount of virtual
memory space, which it actually sorely needs for image file mappings and
random access therein. Well, that, and the fact that instead of using a
static buffer with static size for the window title update function
they're using lots of dynamic buffers and reallocations each time the
function is called.

Why do I mention all of this? Because in all those cases I didn't have
to know exactly what those functions and programs did for me to be able
to tell that things were messy.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Sun, 30 Dec 2018 16:45:27 +0100, "C.Wehrmeyer" <[hidden email]> said:

> On 30.12.18 00:04, Matt Milosevic wrote:
> > I do not want to complicate matters further, but there needs to be one
> > thing clear here: this library is mainly developed and maintained by
> > /volunteers/.
>
> For some reason you seem to think this excuses something. I don't.
>
> Fact is: there are a lot of things that could be improved.

Agreed.

> Fact is: there are a lot of things that aren't improved, however
> there are still features added every now and again. The latest
> things I've seen thus far in the code is TLS 1.3 and kernel TLS.

Yes, it's true, new features are going in.  And it's true that it's
often more exciting to add new features than to do the janitorial
work.

BUT, you also have to appreciate that stuff is happening around us
that affects our focus.  TLS 1.3 happened, and rather than having to
answer the question "why don't you have TLS 1.3 yet?" (there's a LOT
of interest in that version), we decided to add it.

However, your message is clear, we do need to do some cleanup as
well.  More than that, I agree with you that it's needed (I've
screamed out in angst when stumbling upon particularly ugly or
misplaced code, so the feeling is shared, more than you might
believe).

That being said, cleanup happens, and documentation happens, in a
piecemeal fashion, 'cause that's what most people have capacity for.

Now, here's something else that you need to consider: API/ABI
compatibility needs to be preserved.  See, I did see you say something
about all the available SSL_ symbols, and it's true that we have a lot
of them (that includes all the macros):

    : ; grep -E '^([^#].*[^A-Za-z_]|# *define  *)SSL_[A-Za-z0-9_]*\(' include/openssl/* | wc -l
    747

Counting symbols is, however, nothing other than a blunt instrument.
Quite a lot of those symbols are convenience macros and functions that
have accumulated over time.

But nevertheless, I do hear you call for a remake of the SSL API as
well as cleaner internals.  The latter is easier, and I'm sure it will
happen piecemeal as per usual so as to not break something /
inadvertently change a behavior (i.e. break ABI).  The former is a
fairly massive project, and is more of creating a new API and library
rather than a mere cleanup job.  That will be a massive effort, and
you do have to keep in mind how much time all involved can put into
it.

> Turning structures opaque doesn't prevent people from still messing
> with their internal fields.

True.  But it makes for a clear delineation where people are forced to
be aware that they are playing with internal stuff, and that it may
not be a safe thing to do.  When structures weren't opaque, people
*expected* things to stay as they were or be added at the end of the
structure, see API / ABI compatibility.  That took away *all*
possibilities of cleaning them up or enhancing them smoothly without
risking application breakage at every turn.

So basically, the message is that if you want to tinker with stuff
that's essentially internal to the library, do feel free, but do so at
*your* risk, not ours.

(re API / ABI compatibility, I learned the lesson back when I was
fairly new and made my own mistakes...  adding the weak_key field in
struct des_ks_struct back in 0.9.2something deserved me no end of
fairly harsh scolding because it broke ABI for everything that did a
stack allocation of that structure and that used the OpenSSL shared
libraries)

> world - from what I've been told the reason for why those memory
> dumps always looked so juicy was because OpenSSL used its own memory
> pooling.

Uhmmmm....  this is factually incorrect.  OpenSSL doesn't use its own
memory pooling.  We have thin wrappers around the usual malloc() /
realloc() / free(), which allows any application to do its own memory
pooling.

> The point is that those volunteers you mentioned happen to volunteer
> to work on actively bad stuff and/or in an actively bad way.
> Seggelmann was a volunteer, wasn't he, and he did the hithertofore
> greatest damage to OpenSSL and cryptography because of his
> incompetency, whether it was a genuine mistake or intentional.

Wow...

So what you're saying is that one huge enough mistake, and that
cancels out everything else you do or have done?

    : ; git log | grep Seggel | wc -l
    53

Note also that he couldn't commit his contributions directly, they had
to be applied (and implicitly reviewed) by someone in the team, which
was a single underfunded (UNfunded, to tell the truth) individual at
the time.

Wanna assign incompetence for mistakes like this?  In that case,
there's plenty to go around, and there's isn't one single competent
programmer alive.  Errare humanum est 'n all that.

> Genuine mistakes happen, but they *shouldn't* happen in
> infrastructure code

It's easy to say.  Still, humans err...  you can look at any
infrastructure (say, roads) and realise that mistakes are made, and we
try to learn from them.

Speaking of learning, one of the things we did after Heartbleed was to
put a code review process in place.  We do hope that it will help to
keep shitty mistakes out.  It's not an absolute guarantee, but we do
believe it's *better*.

Speaking of which, all our development is available on github in form
of pull requests.  Anyone is welcome to have a look and to comment /
help weed out bad code or help make the code better.  You're welcome
to go in there and help out, and that would probably be more
constructive than a massive continued rant here.

> I also think you're *sorely* underestimating how low people can steep
> just to say "I've been working on OpenSSL" or "I've been working on
> the Linux kernel" or "I've been working on Apache". The Apache FCGI
> module for Perl does not support printing out UTF-8 data to this day -
> in fact there's code that checks if the UTF-8 is set, and implicitly
> downgrades that string to ISO-8859-1 if so. If it can't do so it gobs
> a retarded warning into your server logs. The module's apparently been
> written in 2003 and received an update in 2010. Did this update get
> rid of the warning and/or the downgrade? Nope, neither of those. The
> update merely changed the warning to "[this] will stop wprking [sic!]
> in a future version of FCGI". In 2010. If this wasn't someone who just
> wanted to be able to say that they've been working on Apache FCGI I'm
> going to eat a broomstick, as they say in German.

Not that I would know why we should care about shit in other projects
here, but considering it's open source, you could do the required
modification and contribute there.

> So, no. I will not show respect to bad code just because it's cheap
> or free. My respect goes to people who do good stuff, whether it's
> for free or not. People who just provide shitty things for free
> deserve shitty respect at best. In turn, people who do good stuff
> for free deserve a lot of respect without asking for it. You want
> the same respect? Then maybe not let any volunteer check in code
> just because they can.

I'll gently point out that for non-free / non-open-source code, you
have no idea if the code is shitty or not.  All you have to see is the
API.

> you *never* want to reach a point where your users are brought to
> the point where they start reading your source code, because even
> though that might teach them what to do it makes them unable to
> sleep at night.

I'm sorry if my code causes that level of angst.

However, I disagree with you, we *do* want users to look at our code,
'cause at least some of them will come back and help us improve it.
Or well, we hope they will.

That's the whole idea with an open source project.


To conclude, I have a question for you: are you only willing to rant
(*), or are you willing to help out in another way?  Things that may
have a better outcome and may be energy better spent is to actually
volunteer by going to our github space, review and comment on PRs that
you think are important, raise issues (please, more detailed than a
generic call for cleanup) or contribute code.

    https://github.com/openssl/openssl/

Cheers,
Richard

(*) a word to anyone that wants to scold Herr Wehrmeyer for ranting:
it may be annoying to have to listen to it (no one forces you to), but
it's ALSO a contribution if you're willing to listen, as it helps keep
a focus you may be missing.
Also, I do not want to encourage a rant fest, that's just going to
deteriorate morale, but I do think that the occasional rant is
acceptable and should be appreciated for what it is.

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

Johann v. Preußen
kudos, matt milosevic. you have not complicated matters but rightly
reminded us of the need for civility and the benefits that accrue from
such an approach in opposition to merely railing while offering little
in the way of a path towards problem resolution. also, appreciation to
richard levitte for his balanced response and patience when many would
have none. one would also hope — as you two and others have suggested —
that everyone understands that the best channel of outlet for someone
"fired-up" over something leads to actually contributing what it takes
to make the fix.

it can be said in different ways amongst all languages, but one's own
value boils down to 'words are cheap and deeds are dear'. while
probably not exactly the watch-words of this news-letter, they
certainly represent the mindset of the many, many highly-competent
contributors whose goal is to make openssl the best crypto
application/library available. not to be forgotten are the many firms
that contribute funds and/or their employee's time on the project as
well as the contributions of funds by individuals.

there is no question that soft-ware that is encumbered with a dual
responsibility for simultaneously affording continuity and adopting
innovation will suffer from bloat. while coders are intent on patching
what is amiss and making new things work, paring back the old often
takes a back seat and openssl fits this mold. moreover, documentation
has been a problem since the "programming" of NCR machine wiring in the
1930's. additionally, i think it is safe to say than no piece of
soft-ware has ever been cited as "over documented". openssl's
stream-lining and documentation will improve, but there are bound to be
those unhappy with the time-line.

i am from the sysadmin side and feel deeply indebted to the wealth of
effort put forth by so many to make openssl what it is today and will
be tomorrow.


--
Thank you,

Johann
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

C.Wehrmeyer
In reply to this post by Richard Levitte - VMS Whacker-2
On 31.12.18 10:12, Richard Levitte wrote:
> Yes, it's true, new features are going in.  And it's true that it's
> often more exciting to add new features than to do the janitorial
> work.

You realised what I have left unspoken thus far, which is this almost
obsession-like preference of OSS coders to add new features rather than
improving the old, boring codebase. However, there's a reason why it's
still called code*base*. It's the base of everything. And adding more
and more features to that base is going to make ripping off the band-aid
more painful in the long run.

Also, infrastructure again. I, as a user, don't care if the kernel gets
a new feature that makes some black magic happening. What I care about
is that the kernel doesn't throw away my writes (which has happened in
May of 2018, see):

 >
https://www.postgresql.org/message-id/flat/CAMsr%2BYE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG%2BvzHun1EqMxyQg%40mail.gmail.com#CAMsr+YE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG+vzHun1EqMxyQg@...)

Cryptography libs should be equally conservative, considering that
cryptography is conservative to begin with. I don't care if TLS 1.3 lets
me use new exiting ciphers and handshakes when it unreasonably bogs down
my server code.

> BUT, you also have to appreciate that stuff is happening around us
> that affects our focus.  TLS 1.3 happened, and rather than having to
> answer the question "why don't you have TLS 1.3 yet?" (there's a LOT
> of interest in that version), we decided to add it.

Sure, but didn't Matt just say that there are a lot of volunteers
working on that library? The disadvantage here is that quality assurance
is barely a thing - however, the *advantage* of this is that OpenSSL
does not have to follow commercial interests. If we look at this at face
value you could just say "No, people, it's high time we streamline some
of the internal aspects of the library, TLS 1.3 will have to wait. You
can't wait that long? Well, sorry".

> However, your message is clear, we do need to do some cleanup as
> well.  More than that, I agree with you that it's needed (I've
> screamed out in angst when stumbling upon particularly ugly or
> misplaced code, so the feeling is shared, more than you might
> believe).

But what does "cleanup" entail? That's the hot-button question here.
I've already made a suggestion, that is to say, getting rid of opaque
structures. If that is deemed too insecure (for whatever reasons),
export symbols that allow programmers to query the size of structures,
and provide two versions of functions: one function expects the caller
to pass an object to which the changes are to be made, and the other one
allocates the necessary memory dynamically and then calls the first
version. Or just don't allocate my object memory dynamically anymore.

> That being said, cleanup happens, and documentation happens, in a
> piecemeal fashion, 'cause that's what most people have capacity for.

So, what you're effectively saying is that I'm the first one who ever
asked for SSL object reuse, right? Because if piecemeal work happens on
the documentation, and Viktor says that it's possible, then surely no
one would have ever answered that question on the mailing list and *not*
put it piecemeal-ly in the OpenSSL documentation, right?

> Now, here's something else that you need to consider: API/ABI
> compatibility needs to be preserved.

No it doesn't. We *know* it doesn't. When OpenSSL 1.1 was released it
broke all *sorts* of applications out there, because all sorts of
applications used struct fields rather than accessors. wget, mutt, neon,
python, you name it, you broke it.

 > https://breakpoint.cc/openssl-1.1-rebuild-2016-08-26/

So since when do we need to consider API/ABI compatibility? Did we grow
up recently?

Or maybe OpenSSL should have switched the language. The point of C is
that structures are public. And if I'm going to be honest that approach
saved my sorry arse more than a couple times. When zlib choked because
it couldn't go past 4 GiBs of data since its fields were uint32_ts, I
was able to easily workaround this problem. But what do I know.

> Counting symbols is, however, nothing other than a blunt instrument.
> Quite a lot of those symbols are convenience macros and functions that
> have accumulated over time.

You're taking my statement out of context. Counting the symbols wasn't
supposed to suggest that there are too *many* of them. I'm in no
position to say that, seeing as the original context in which my
statement was put is that *I'm not familiar enough with the library*.

What I said was that reading the code is easy. Learning what the library
provides is hard, and that you won't learn much just by looking at the
symbols because there's so many of them.

> But nevertheless, I do hear you call for a remake of the SSL API as
> well as cleaner internals.  The latter is easier, and I'm sure it will
> happen piecemeal as per usual so as to not break something /
> inadvertently change a behavior (i.e. break ABI).  The former is a
> fairly massive project, and is more of creating a new API and library
> rather than a mere cleanup job.  That will be a massive effort, and
> you do have to keep in mind how much time all involved can put into
> it.

I'm not saying it needs to be done right now. I'm merely suggesting that
it might be a good goal post for OpenSSL 2.0.

>> Turning structures opaque doesn't prevent people from still messing
>> with their internal fields.
>
> True.  But it makes for a clear delineation where people are forced to
> be aware that they are playing with internal stuff, and that it may
> not be a safe thing to do.

Then why not provide small helper functions for covering the "playing
with internal stuff" part? That way it's still controlled, and
documented, and unified. You guys must've had some examples to show off
in order to justify the process, so surely you know what it is that
people do when they use internal stuff. Make functions for those. Don't
give them any reason to continue playing with internal stuff.

I don't like code that tries to protect programmers from themselves. I
like code that lets good programmers do smart things. And if bad
programmers use that freedom to do bad stuff, then doesn't that mean
your API simply didn't support this, and they had to make it work
somehow else? Again, helper functions.

> Uhmmmm....  this is factually incorrect.  OpenSSL doesn't use its own
> memory pooling.  We have thin wrappers around the usual malloc() /
> realloc() / free(), which allows any application to do its own memory
> pooling.

 >
https://web.archive.org/web/20150207180717/http://article.gmane.org/gmane.os.openbsd.misc/211963

If you don't wanna read too much:

 > https://xkcd.com/1353/

Read the mouse-hover text.

>> The point is that those volunteers you mentioned happen to volunteer
>> to work on actively bad stuff and/or in an actively bad way.
>> Seggelmann was a volunteer, wasn't he, and he did the hithertofore
>> greatest damage to OpenSSL and cryptography because of his
>> incompetency, whether it was a genuine mistake or intentional.
>
> Wow...
>
> So what you're saying is that one huge enough mistake, and that
> cancels out everything else you do or have done?

If it only was one mistake. I read in June 2014 that Seggelmann was
*also* responsible for the DTLS code:

https://www.openssl.org/news/secadv/20140605.txt

And Thor knows how many others that we aren't aware of.

And just in case you don't get this: this has caused *massive* damage.
It's not just *one* mistake. Heartbleed was caused by input validation
screwups. We've been known since at least the 80s that this causes
widespread issues. For f*cks sake, this November we were informed that
FreeBSD could be pinged to death.

And not only Seggelmann f*cked up. Also the guy who went over his code.
On New Year's morning, no less, where it should have been *clear* that
no one is in the right mental state of mind for that. For instance I
don't do any coding in the evening because I know myself enough to know
that my brain is mush and that whatever I'll produce is equivalent with
horse barf.

So, no, this isn't just *one mistake*. This is "I have no idea what I'm
doing, in a field where certified security experts f*ck up things every
now and then, but I'm doing it anyway for my dissertation" while
everyone was looking away.

> Wanna assign incompetence for mistakes like this?  In that case,
> there's plenty to go around, and there's isn't one single competent
> programmer alive.  Errare humanum est 'n all that.

Only there's a difference between a mistake and dabbling in forces you
shouldn't dabble in. But again, it looks nice on the résumé.

>> Genuine mistakes happen, but they *shouldn't* happen in
>> infrastructure code
>
> It's easy to say.  Still, humans err...  you can look at any
> infrastructure (say, roads) and realise that mistakes are made, and we
> try to learn from them.

WE HAVE HAD INPUT VALIDATION PROBLEMS SINCE THE 80S. SO WHAT HAVE WE
LEARNT, HUH? WHAT HAVE WE LEARNT? WE HAVE LEARNT JACK-EFFING-SHTIE.
Decades went by, but we're as arrogant as ever.

I HATE this approach. "Programmers shouldn't be held accountable for
their screw-ups because to err is human" is what it effectively says.
Did this story have ANY consequences for Seggelmann? Not that I'm aware
of. Only when people began to suggest that this may be a backdoor he
felt the need to save face. And as far as I'm aware he hasn't even
apologised once.

But that's what you get when you prefer to add features over a solid
codebase.

> Speaking of learning, one of the things we did after Heartbleed was to
> put a code review process in place.  We do hope that it will help to
> keep shitty mistakes out.  It's not an absolute guarantee, but we do
> believe it's *better*.

It certainly didn't help against:

 > npad = (48 / md_size) * md_size

>> I also think you're *sorely* underestimating how low people can steep
>> just to say "I've been working on OpenSSL" or "I've been working on
>> the Linux kernel" or "I've been working on Apache". The Apache FCGI
>> module for Perl does not support printing out UTF-8 data to this day -
>> in fact there's code that checks if the UTF-8 is set, and implicitly
>> downgrades that string to ISO-8859-1 if so. If it can't do so it gobs
>> a retarded warning into your server logs. The module's apparently been
>> written in 2003 and received an update in 2010. Did this update get
>> rid of the warning and/or the downgrade? Nope, neither of those. The
>> update merely changed the warning to "[this] will stop wprking [sic!]
>> in a future version of FCGI". In 2010. If this wasn't someone who just
>> wanted to be able to say that they've been working on Apache FCGI I'm
>> going to eat a broomstick, as they say in German.
>
> Not that I would know why we should care about shit in other projects
> here, but considering it's open source, you could do the required
> modification and contribute there.

You're just a bigger target than Apache FCGI. This heartbleed stuff was
pretty much only for Seggelmann's career. And look what kind of example
he set, seeing as I don't see him suffering consequences for that.

>> So, no. I will not show respect to bad code just because it's cheap
>> or free. My respect goes to people who do good stuff, whether it's
>> for free or not. People who just provide shitty things for free
>> deserve shitty respect at best. In turn, people who do good stuff
>> for free deserve a lot of respect without asking for it. You want
>> the same respect? Then maybe not let any volunteer check in code
>> just because they can.
>
> I'll gently point out that for non-free / non-open-source code, you
> have no idea if the code is shitty or not.  All you have to see is the
> API.

Unfortunately I never said that I have an idea about whether or not
non-open-source code is good or bad. What I actually said was that
people who do good work should be paid for that, and if they do that for
free that's even more admirable.

(I'm not going to discuss business models on how people can make money
with cryptography code while it still being Open-Source.)

>> you *never* want to reach a point where your users are brought to
>> the point where they start reading your source code, because even
>> though that might teach them what to do it makes them unable to
>> sleep at night.
>
> I'm sorry if my code causes that level of angst.

Not the code per se. However I (and several other people I know) have
given up on reading code they weren't paid for. Otherwise they see
things that makes them want to throw it away in disgust, and if that
happens a couple times they're left there with their kernel and a text
editor. It's a self-preservation policy.

So, no, it's *reading* your code that causes ... angst? You used that
word twice now. I don't know what it has evolved into in English, seeing
as I only ever see people accusing others of "being angsty", but just
for the record: in German "Angst" ("a" somewhat like the "u" in "hunt")
means genuine fear and fright. "Angst" and "anxiety" share the same
roots, but "anxiety" is usually more mellow. Not that "anxiety" is the
right word here, again - "disgust" fits better.

> However, I disagree with you, we *do* want users to look at our code,
> 'cause at least some of them will come back and help us improve it.
> Or well, we hope they will.

I know enough people who wouldn't, and that's all I'm gonna say about this.

> To conclude, I have a question for you: are you only willing to rant
> (*), or are you willing to help out in another way?

This is not the question I feel you should ask because we haven't even
established if I *could* make contributions to the project, as my
mindset appears to be so much more different. Especially the idea of not
wanting to break APIs/ABIs is a huge limitation - just looking at
SSL_new() made me give up hope here.

I'm no cryptography expert, I've made that clear from mail one, and my
cleanup jobs would be more widespread than what seems to be deemed
acceptable right now. I can read and write scalable C code, otherwise I
wouldn't even have tried to reuse that SSL object from the beginning.

So, I ask a question in return: what do you think I *could* be helping with?

Also, a happy new year to all.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

Matt Caswell-2


On 31/12/2018 11:36, C.Wehrmeyer wrote:

> On 31.12.18 10:12, Richard Levitte wrote:
>> Yes, it's true, new features are going in.  And it's true that it's
>> often more exciting to add new features than to do the janitorial
>> work.
>
> You realised what I have left unspoken thus far, which is this almost
> obsession-like preference of OSS coders to add new features rather than
> improving the old, boring codebase. However, there's a reason why it's still
> called code*base*. It's the base of everything. And adding more and more
> features to that base is going to make ripping off the band-aid more painful in
> the long run.

There has been a huge amount of effort put in over the last few years to improve
the codebase. Things that immediately spring to mind (and there's probably a
whole load more):

- Rewrite of the state machine
- libssl record layer refactor
- Implementation of the PACKET and WPACKET abstractions in libssl
- Rewrite of the rand code
- Implementation of the new test harness
- Significant effort into developing tests
- Implementation of the coding style and reformat of the codebase to meet it
- Opaque many of the structures (which I know you don't see as an improvement,
but I'll answer that point separately)
- Implementation of continuous fuzzing
- Significant expansion of the documentation coverage

It is simply not true to claim that we have "an obsession-like preference...to
add new features rather than improving the old, boring codebase". None of the
above things resulted in or were motivated by user visible features. They were
all about improving the codebase.

>
> Also, infrastructure again. I, as a user, don't care if the kernel gets a new
> feature that makes some black magic happening. What I care about is that the
> kernel doesn't throw away my writes (which has happened in May of 2018, see):
>
>>
> https://www.postgresql.org/message-id/flat/CAMsr%2BYE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG%2BvzHun1EqMxyQg%40mail.gmail.com#CAMsr+YE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG+vzHun1EqMxyQg@...)
>
>
> Cryptography libs should be equally conservative, considering that cryptography
> is conservative to begin with. I don't care if TLS 1.3 lets me use new exiting
> ciphers and handshakes when it unreasonably bogs down my server code.
>
>> BUT, you also have to appreciate that stuff is happening around us
>> that affects our focus.  TLS 1.3 happened, and rather than having to
>> answer the question "why don't you have TLS 1.3 yet?" (there's a LOT
>> of interest in that version), we decided to add it.
>
> Sure, but didn't Matt just say that there are a lot of volunteers working on
> that library? The disadvantage here is that quality assurance is barely a thing
> - however, the *advantage* of this is that OpenSSL does not have to follow
> commercial interests. If we look at this at face value you could just say "No,
> people, it's high time we streamline some of the internal aspects of the
> library, TLS 1.3 will have to wait. You can't wait that long? Well, sorry".
>
>> However, your message is clear, we do need to do some cleanup as
>> well.  More than that, I agree with you that it's needed (I've
>> screamed out in angst when stumbling upon particularly ugly or
>> misplaced code, so the feeling is shared, more than you might
>> believe).
>
> But what does "cleanup" entail? That's the hot-button question here. I've
> already made a suggestion, that is to say, getting rid of opaque structures. If
> that is deemed too insecure (for whatever reasons), export symbols that allow
> programmers to query the size of structures, and provide two versions of
> functions: one function expects the caller to pass an object to which the
> changes are to be made, and the other one allocates the necessary memory
> dynamically and then calls the first version. Or just don't allocate my object
> memory dynamically anymore.
>
>> That being said, cleanup happens, and documentation happens, in a
>> piecemeal fashion, 'cause that's what most people have capacity for.
>
> So, what you're effectively saying is that I'm the first one who ever asked for
> SSL object reuse, right? Because if piecemeal work happens on the documentation,
> and Viktor says that it's possible, then surely no one would have ever answered
> that question on the mailing list and *not* put it piecemeal-ly in the OpenSSL
> documentation, right?
>
>> Now, here's something else that you need to consider: API/ABI
>> compatibility needs to be preserved.
>
> No it doesn't. We *know* it doesn't. When OpenSSL 1.1 was released it broke all
> *sorts* of applications out there, because all sorts of applications used struct
> fields rather than accessors. wget, mutt, neon, python, you name it, you broke it.

API/ABI stability is absolutely required. Every time we make a breaking change
it is painful for our users - and more pain is felt the bigger the scale of the
break. We simply cannot go around making wholesale breaks on an ongoing basis.
If we did so then OpenSSL would be a lot less useful to our users.

This is not to say that we can *never* make breaking changes. Only that when we
do so it must be strongly justified and only done relatively infrequently. We
made such a decision when we decided to make the structures opaque. It's not a
decision we are likely to repeat anytime soon IMO. We are still feeling the pain
of that now (and will continue to do so for at least the next year until 1.0.2
goes out of support - and probably beyond that).

Which brings me onto why structures were made opaque in the first place. A
significant driver for this (probably *the* most important one) was to improve
the codebase. I have witnessed first hand the harm that non-opaque structures
did to OpenSSL. We will be fixing the fallout from them for years to come.
Non-opaque structures combined with the requirements for stable API/ABI means
you cannot change anything in those structures. Renaming or deleting structure
members constitutes an API break. Even *adding* structure members constitutes an
ABI break (due to the changed size of the structure). This means the code
ossifies over time and cannot easily be refactored. Much of OpenSSL's internal
"quirkiness" results from attempting to work around this restriction.

Things like the state machine refactor and the record layer refactor would not
have been possible without opaque structures. In my mind making the structures
opaque was one of the best things that ever happened to OpenSSL.


>
>> https://breakpoint.cc/openssl-1.1-rebuild-2016-08-26/
>
> So since when do we need to consider API/ABI compatibility? Did we grow up
> recently?
>
> Or maybe OpenSSL should have switched the language. The point of C is that
> structures are public. And if I'm going to be honest that approach saved my
> sorry arse more than a couple times. When zlib choked because it couldn't go
> past 4 GiBs of data since its fields were uint32_ts, I was able to easily
> workaround this problem. But what do I know.

If you really want to fiddle with OpenSSL internal structures - feel free. Just
include the OpenSSL internal header files and away you go. Just do so in the
knowledge that they could be changed at any time, and your code might break. If
this isn't a concern to you then - no problem. If it is a concern to you - then
actually you *do* care about API/ABI stability after all.


>
>> Counting symbols is, however, nothing other than a blunt instrument.
>> Quite a lot of those symbols are convenience macros and functions that
>> have accumulated over time.
>
> You're taking my statement out of context. Counting the symbols wasn't supposed
> to suggest that there are too *many* of them. I'm in no position to say that,
> seeing as the original context in which my statement was put is that *I'm not
> familiar enough with the library*.
>
> What I said was that reading the code is easy. Learning what the library
> provides is hard, and that you won't learn much just by looking at the symbols
> because there's so many of them.
>
>> But nevertheless, I do hear you call for a remake of the SSL API as
>> well as cleaner internals.  The latter is easier, and I'm sure it will
>> happen piecemeal as per usual so as to not break something /
>> inadvertently change a behavior (i.e. break ABI).  The former is a
>> fairly massive project, and is more of creating a new API and library
>> rather than a mere cleanup job.  That will be a massive effort, and
>> you do have to keep in mind how much time all involved can put into
>> it.
>
> I'm not saying it needs to be done right now. I'm merely suggesting that it
> might be a good goal post for OpenSSL 2.0.
>
>>> Turning structures opaque doesn't prevent people from still messing
>>> with their internal fields.
>>
>> True.  But it makes for a clear delineation where people are forced to
>> be aware that they are playing with internal stuff, and that it may
>> not be a safe thing to do.
>
> Then why not provide small helper functions for covering the "playing with
> internal stuff" part? That way it's still controlled, and documented, and
> unified. You guys must've had some examples to show off in order to justify the
> process, so surely you know what it is that people do when they use internal
> stuff. Make functions for those. Don't give them any reason to continue playing
> with internal stuff.
>
> I don't like code that tries to protect programmers from themselves. I like code
> that lets good programmers do smart things. And if bad programmers use that
> freedom to do bad stuff, then doesn't that mean your API simply didn't support
> this, and they had to make it work somehow else? Again, helper functions.
>
>> Uhmmmm....  this is factually incorrect.  OpenSSL doesn't use its own
>> memory pooling.  We have thin wrappers around the usual malloc() /
>> realloc() / free(), which allows any application to do its own memory
>> pooling.
>
>>
> https://web.archive.org/web/20150207180717/http://article.gmane.org/gmane.os.openbsd.misc/211963

The BUF_FREELISTS code that this post references was ripped out years ago. This
no longer represents the current state of OpenSSL in any supported version.

>> To conclude, I have a question for you: are you only willing to rant
>> (*), or are you willing to help out in another way?
>
> This is not the question I feel you should ask because we haven't even
> established if I *could* make contributions to the project, as my mindset
> appears to be so much more different. Especially the idea of not wanting to
> break APIs/ABIs is a huge limitation - just looking at SSL_new() made me give up
> hope here.

Yes - not breaking APIs/ABIs is a huge limitation. BoringSSL is not suitable for
general purpose use precisely because of this. The only users BoringSSL cares
about whether they break or not are Google users. As soon as you have a library
that wants to cater for large numbers of users (which we do) then you have to
accept that limitation.

As to whether or not we have established whether you *could* make such
contributions - I think you are missing the point. We cannot know whether you
are capable or not until you try. It is on the basis of your code that we would
make such a judgement. In order for your code to get into OpenSSL it must have
been reviewed and approved by two current OpenSSL committers (one of whom must
be on the OpenSSL Management Committee). We invite anyone to contribute. In
order for this to be a healthy open-source community we *need* those
contributions. Only those that make the grade will make it in.

Note - this review process wasn't always the case. Things used to be much more
informal in pre-heartbleed days. This is no longer the case.

>
> I'm no cryptography expert, I've made that clear from mail one, and my cleanup
> jobs would be more widespread than what seems to be deemed acceptable right now.
> I can read and write scalable C code, otherwise I wouldn't even have tried to
> reuse that SSL object from the beginning.
>
> So, I ask a question in return: what do you think I *could* be helping with?

Well, you have vocally complained about the state of the documentation. You have
the benefit of being a new OpenSSL user. You know what things were confusing or
unclear in the documentation. More experienced OpenSSL coders often don't have
the perspective - because some things are just "obvious" to them. So help with
pull requests to improve the documentation.

Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

FooCrypt
Matt et al

'been reviewed and approved by two current OpenSSL committers (one of whom must
be on the OpenSSL Management Committee).’

Due to the recent legislative changes here in Australia around the T.O.L.A. Act, can a change be made to the OpenSSL  policy so that the 2 reviewers, don’t reside in Australia, or are Australian citizens ?

ABI/API changes -> breaks -> back door requests….




-- 

Regards,

Mark A. Lane   

Cryptopocalypse NOW 01 04 2016

Volumes 0.0 -> 10.0 Now available through iTunes - iBooks @ https://itunes.apple.com/au/author/mark-a.-lane/id1100062966?mt=11

© Mark A. Lane 1980 - 2019, All Rights Reserved.
© FooCrypt 1980 - 2019, All Rights Reserved.
© FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2019, All Rights Reserved.
© Cryptopocalypse 1980 - 2019, All Rights Reserved.






On 1 Jan 2019, at 01:11, Matt Caswell <[hidden email]> wrote:



On 31/12/2018 11:36, C.Wehrmeyer wrote:
On 31.12.18 10:12, Richard Levitte wrote:
Yes, it's true, new features are going in.  And it's true that it's
often more exciting to add new features than to do the janitorial
work.

You realised what I have left unspoken thus far, which is this almost
obsession-like preference of OSS coders to add new features rather than
improving the old, boring codebase. However, there's a reason why it's still
called code*base*. It's the base of everything. And adding more and more
features to that base is going to make ripping off the band-aid more painful in
the long run.

There has been a huge amount of effort put in over the last few years to improve
the codebase. Things that immediately spring to mind (and there's probably a
whole load more):

- Rewrite of the state machine
- libssl record layer refactor
- Implementation of the PACKET and WPACKET abstractions in libssl
- Rewrite of the rand code
- Implementation of the new test harness
- Significant effort into developing tests
- Implementation of the coding style and reformat of the codebase to meet it
- Opaque many of the structures (which I know you don't see as an improvement,
but I'll answer that point separately)
- Implementation of continuous fuzzing
- Significant expansion of the documentation coverage

It is simply not true to claim that we have "an obsession-like preference...to
add new features rather than improving the old, boring codebase". None of the
above things resulted in or were motivated by user visible features. They were
all about improving the codebase.


Also, infrastructure again. I, as a user, don't care if the kernel gets a new
feature that makes some black magic happening. What I care about is that the
kernel doesn't throw away my writes (which has happened in May of 2018, see):


https://www.postgresql.org/message-id/flat/CAMsr%2BYE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG%2BvzHun1EqMxyQg%40mail.gmail.com#CAMsr+YE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG+vzHun1EqMxyQg@...)


Cryptography libs should be equally conservative, considering that cryptography
is conservative to begin with. I don't care if TLS 1.3 lets me use new exiting
ciphers and handshakes when it unreasonably bogs down my server code.

BUT, you also have to appreciate that stuff is happening around us
that affects our focus.  TLS 1.3 happened, and rather than having to
answer the question "why don't you have TLS 1.3 yet?" (there's a LOT
of interest in that version), we decided to add it.

Sure, but didn't Matt just say that there are a lot of volunteers working on
that library? The disadvantage here is that quality assurance is barely a thing
- however, the *advantage* of this is that OpenSSL does not have to follow
commercial interests. If we look at this at face value you could just say "No,
people, it's high time we streamline some of the internal aspects of the
library, TLS 1.3 will have to wait. You can't wait that long? Well, sorry".

However, your message is clear, we do need to do some cleanup as
well.  More than that, I agree with you that it's needed (I've
screamed out in angst when stumbling upon particularly ugly or
misplaced code, so the feeling is shared, more than you might
believe).

But what does "cleanup" entail? That's the hot-button question here. I've
already made a suggestion, that is to say, getting rid of opaque structures. If
that is deemed too insecure (for whatever reasons), export symbols that allow
programmers to query the size of structures, and provide two versions of
functions: one function expects the caller to pass an object to which the
changes are to be made, and the other one allocates the necessary memory
dynamically and then calls the first version. Or just don't allocate my object
memory dynamically anymore.

That being said, cleanup happens, and documentation happens, in a
piecemeal fashion, 'cause that's what most people have capacity for.

So, what you're effectively saying is that I'm the first one who ever asked for
SSL object reuse, right? Because if piecemeal work happens on the documentation,
and Viktor says that it's possible, then surely no one would have ever answered
that question on the mailing list and *not* put it piecemeal-ly in the OpenSSL
documentation, right?

Now, here's something else that you need to consider: API/ABI
compatibility needs to be preserved.

No it doesn't. We *know* it doesn't. When OpenSSL 1.1 was released it broke all
*sorts* of applications out there, because all sorts of applications used struct
fields rather than accessors. wget, mutt, neon, python, you name it, you broke it.

API/ABI stability is absolutely required. Every time we make a breaking change
it is painful for our users - and more pain is felt the bigger the scale of the
break. We simply cannot go around making wholesale breaks on an ongoing basis.
If we did so then OpenSSL would be a lot less useful to our users.

This is not to say that we can *never* make breaking changes. Only that when we
do so it must be strongly justified and only done relatively infrequently. We
made such a decision when we decided to make the structures opaque. It's not a
decision we are likely to repeat anytime soon IMO. We are still feeling the pain
of that now (and will continue to do so for at least the next year until 1.0.2
goes out of support - and probably beyond that).

Which brings me onto why structures were made opaque in the first place. A
significant driver for this (probably *the* most important one) was to improve
the codebase. I have witnessed first hand the harm that non-opaque structures
did to OpenSSL. We will be fixing the fallout from them for years to come.
Non-opaque structures combined with the requirements for stable API/ABI means
you cannot change anything in those structures. Renaming or deleting structure
members constitutes an API break. Even *adding* structure members constitutes an
ABI break (due to the changed size of the structure). This means the code
ossifies over time and cannot easily be refactored. Much of OpenSSL's internal
"quirkiness" results from attempting to work around this restriction.

Things like the state machine refactor and the record layer refactor would not
have been possible without opaque structures. In my mind making the structures
opaque was one of the best things that ever happened to OpenSSL.



https://breakpoint.cc/openssl-1.1-rebuild-2016-08-26/

So since when do we need to consider API/ABI compatibility? Did we grow up
recently?

Or maybe OpenSSL should have switched the language. The point of C is that
structures are public. And if I'm going to be honest that approach saved my
sorry arse more than a couple times. When zlib choked because it couldn't go
past 4 GiBs of data since its fields were uint32_ts, I was able to easily
workaround this problem. But what do I know.

If you really want to fiddle with OpenSSL internal structures - feel free. Just
include the OpenSSL internal header files and away you go. Just do so in the
knowledge that they could be changed at any time, and your code might break. If
this isn't a concern to you then - no problem. If it is a concern to you - then
actually you *do* care about API/ABI stability after all.



Counting symbols is, however, nothing other than a blunt instrument.
Quite a lot of those symbols are convenience macros and functions that
have accumulated over time.

You're taking my statement out of context. Counting the symbols wasn't supposed
to suggest that there are too *many* of them. I'm in no position to say that,
seeing as the original context in which my statement was put is that *I'm not
familiar enough with the library*.

What I said was that reading the code is easy. Learning what the library
provides is hard, and that you won't learn much just by looking at the symbols
because there's so many of them.

But nevertheless, I do hear you call for a remake of the SSL API as
well as cleaner internals.  The latter is easier, and I'm sure it will
happen piecemeal as per usual so as to not break something /
inadvertently change a behavior (i.e. break ABI).  The former is a
fairly massive project, and is more of creating a new API and library
rather than a mere cleanup job.  That will be a massive effort, and
you do have to keep in mind how much time all involved can put into
it.

I'm not saying it needs to be done right now. I'm merely suggesting that it
might be a good goal post for OpenSSL 2.0.

Turning structures opaque doesn't prevent people from still messing
with their internal fields.

True.  But it makes for a clear delineation where people are forced to
be aware that they are playing with internal stuff, and that it may
not be a safe thing to do.

Then why not provide small helper functions for covering the "playing with
internal stuff" part? That way it's still controlled, and documented, and
unified. You guys must've had some examples to show off in order to justify the
process, so surely you know what it is that people do when they use internal
stuff. Make functions for those. Don't give them any reason to continue playing
with internal stuff.

I don't like code that tries to protect programmers from themselves. I like code
that lets good programmers do smart things. And if bad programmers use that
freedom to do bad stuff, then doesn't that mean your API simply didn't support
this, and they had to make it work somehow else? Again, helper functions.

Uhmmmm....  this is factually incorrect.  OpenSSL doesn't use its own
memory pooling.  We have thin wrappers around the usual malloc() /
realloc() / free(), which allows any application to do its own memory
pooling.


https://web.archive.org/web/20150207180717/http://article.gmane.org/gmane.os.openbsd.misc/211963

The BUF_FREELISTS code that this post references was ripped out years ago. This
no longer represents the current state of OpenSSL in any supported version.

To conclude, I have a question for you: are you only willing to rant
(*), or are you willing to help out in another way?

This is not the question I feel you should ask because we haven't even
established if I *could* make contributions to the project, as my mindset
appears to be so much more different. Especially the idea of not wanting to
break APIs/ABIs is a huge limitation - just looking at SSL_new() made me give up
hope here.

Yes - not breaking APIs/ABIs is a huge limitation. BoringSSL is not suitable for
general purpose use precisely because of this. The only users BoringSSL cares
about whether they break or not are Google users. As soon as you have a library
that wants to cater for large numbers of users (which we do) then you have to
accept that limitation.

As to whether or not we have established whether you *could* make such
contributions - I think you are missing the point. We cannot know whether you
are capable or not until you try. It is on the basis of your code that we would
make such a judgement. In order for your code to get into OpenSSL it must have
been reviewed and approved by two current OpenSSL committers (one of whom must
be on the OpenSSL Management Committee). We invite anyone to contribute. In
order for this to be a healthy open-source community we *need* those
contributions. Only those that make the grade will make it in.

Note - this review process wasn't always the case. Things used to be much more
informal in pre-heartbleed days. This is no longer the case.


I'm no cryptography expert, I've made that clear from mail one, and my cleanup
jobs would be more widespread than what seems to be deemed acceptable right now.
I can read and write scalable C code, otherwise I wouldn't even have tried to
reuse that SSL object from the beginning.

So, I ask a question in return: what do you think I *could* be helping with?

Well, you have vocally complained about the state of the documentation. You have
the benefit of being a new OpenSSL user. You know what things were confusing or
unclear in the documentation. More experienced OpenSSL coders often don't have
the perspective - because some things are just "obvious" to them. So help with
pull requests to improve the documentation.

Matt
-- 
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
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

Richard Levitte - VMS Whacker-2
I'll go ahead and ask, how long do you think such a back door would
stay unnoticed, let alone survive?  I'm considering the fact that we
have a lot of people looking at our code, just judging from the issues
and pull requests raised on github.

I can't say that I have an actual answer, but it's a question worth
asking as well, to see if the T.O.L.A. Act is worth a state of panic
or not.

Cheers,
Richard ( who's on vacation and should stop reading these mails )

In message <[hidden email]> on Tue, 1 Jan 2019 01:27:53 +1100, "[hidden email]" <[hidden email]> said:

> Matt et al
>
> 'been reviewed and approved by two current OpenSSL committers (one of whom must
> be on the OpenSSL Management Committee).’
>
> Due to the recent legislative changes here in Australia around the T.O.L.A. Act, can a change be
> made to the OpenSSL policy so that the 2 reviewers, don’t reside in Australia, or are Australian
> citizens ?
>
> ABI/API changes -> breaks -> back door requests….
>
> --
>
> Regards,
>
> Mark A. Lane
>
> Cryptopocalypse NOW 01 04 2016
>
> Volumes 0.0 -> 10.0 Now available through iTunes - iBooks @
> https://itunes.apple.com/au/author/mark-a.-lane/id1100062966?mt=11
>
> © Mark A. Lane 1980 - 2019, All Rights Reserved.
> © FooCrypt 1980 - 2019, All Rights Reserved.
> © FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2019, All Rights Reserved.
> © Cryptopocalypse 1980 - 2019, All Rights Reserved.
>
>  On 1 Jan 2019, at 01:11, Matt Caswell <[hidden email]> wrote:
>
>  On 31/12/2018 11:36, C.Wehrmeyer wrote:
>
>  On 31.12.18 10:12, Richard Levitte wrote:
>
>  Yes, it's true, new features are going in. And it's true that it's
>  often more exciting to add new features than to do the janitorial
>  work.
>
>  You realised what I have left unspoken thus far, which is this almost
>  obsession-like preference of OSS coders to add new features rather than
>  improving the old, boring codebase. However, there's a reason why it's still
>  called code*base*. It's the base of everything. And adding more and more
>  features to that base is going to make ripping off the band-aid more painful in
>  the long run.
>
>  There has been a huge amount of effort put in over the last few years to improve
>  the codebase. Things that immediately spring to mind (and there's probably a
>  whole load more):
>
>  - Rewrite of the state machine
>  - libssl record layer refactor
>  - Implementation of the PACKET and WPACKET abstractions in libssl
>  - Rewrite of the rand code
>  - Implementation of the new test harness
>  - Significant effort into developing tests
>  - Implementation of the coding style and reformat of the codebase to meet it
>  - Opaque many of the structures (which I know you don't see as an improvement,
>  but I'll answer that point separately)
>  - Implementation of continuous fuzzing
>  - Significant expansion of the documentation coverage
>
>  It is simply not true to claim that we have "an obsession-like preference...to
>  add new features rather than improving the old, boring codebase". None of the
>  above things resulted in or were motivated by user visible features. They were
>  all about improving the codebase.
>
>  Also, infrastructure again. I, as a user, don't care if the kernel gets a new
>  feature that makes some black magic happening. What I care about is that the
>  kernel doesn't throw away my writes (which has happened in May of 2018, see):
>
>  https://www.postgresql.org/message-id/flat/CAMsr%2BYE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG%2BvzHun1EqMxyQg%40mail.gmail.com#CAMsr+YE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG+vzHun1EqMxyQg@...)
>
>
>  Cryptography libs should be equally conservative, considering that cryptography
>  is conservative to begin with. I don't care if TLS 1.3 lets me use new exiting
>  ciphers and handshakes when it unreasonably bogs down my server code.
>
>  BUT, you also have to appreciate that stuff is happening around us
>  that affects our focus. TLS 1.3 happened, and rather than having to
>  answer the question "why don't you have TLS 1.3 yet?" (there's a LOT
>  of interest in that version), we decided to add it.
>
>  Sure, but didn't Matt just say that there are a lot of volunteers working on
>  that library? The disadvantage here is that quality assurance is barely a thing
>  - however, the *advantage* of this is that OpenSSL does not have to follow
>  commercial interests. If we look at this at face value you could just say "No,
>  people, it's high time we streamline some of the internal aspects of the
>  library, TLS 1.3 will have to wait. You can't wait that long? Well, sorry".
>
>  However, your message is clear, we do need to do some cleanup as
>  well. More than that, I agree with you that it's needed (I've
>  screamed out in angst when stumbling upon particularly ugly or
>  misplaced code, so the feeling is shared, more than you might
>  believe).
>
>  But what does "cleanup" entail? That's the hot-button question here. I've
>  already made a suggestion, that is to say, getting rid of opaque structures. If
>  that is deemed too insecure (for whatever reasons), export symbols that allow
>  programmers to query the size of structures, and provide two versions of
>  functions: one function expects the caller to pass an object to which the
>  changes are to be made, and the other one allocates the necessary memory
>  dynamically and then calls the first version. Or just don't allocate my object
>  memory dynamically anymore.
>
>  That being said, cleanup happens, and documentation happens, in a
>  piecemeal fashion, 'cause that's what most people have capacity for.
>
>  So, what you're effectively saying is that I'm the first one who ever asked for
>  SSL object reuse, right? Because if piecemeal work happens on the documentation,
>  and Viktor says that it's possible, then surely no one would have ever answered
>  that question on the mailing list and *not* put it piecemeal-ly in the OpenSSL
>  documentation, right?
>
>  Now, here's something else that you need to consider: API/ABI
>  compatibility needs to be preserved.
>
>  No it doesn't. We *know* it doesn't. When OpenSSL 1.1 was released it broke all
>  *sorts* of applications out there, because all sorts of applications used struct
>  fields rather than accessors. wget, mutt, neon, python, you name it, you broke it.
>
>  API/ABI stability is absolutely required. Every time we make a breaking change
>  it is painful for our users - and more pain is felt the bigger the scale of the
>  break. We simply cannot go around making wholesale breaks on an ongoing basis.
>  If we did so then OpenSSL would be a lot less useful to our users.
>
>  This is not to say that we can *never* make breaking changes. Only that when we
>  do so it must be strongly justified and only done relatively infrequently. We
>  made such a decision when we decided to make the structures opaque. It's not a
>  decision we are likely to repeat anytime soon IMO. We are still feeling the pain
>  of that now (and will continue to do so for at least the next year until 1.0.2
>  goes out of support - and probably beyond that).
>
>  Which brings me onto why structures were made opaque in the first place. A
>  significant driver for this (probably *the* most important one) was to improve
>  the codebase. I have witnessed first hand the harm that non-opaque structures
>  did to OpenSSL. We will be fixing the fallout from them for years to come.
>  Non-opaque structures combined with the requirements for stable API/ABI means
>  you cannot change anything in those structures. Renaming or deleting structure
>  members constitutes an API break. Even *adding* structure members constitutes an
>  ABI break (due to the changed size of the structure). This means the code
>  ossifies over time and cannot easily be refactored. Much of OpenSSL's internal
>  "quirkiness" results from attempting to work around this restriction.
>
>  Things like the state machine refactor and the record layer refactor would not
>  have been possible without opaque structures. In my mind making the structures
>  opaque was one of the best things that ever happened to OpenSSL.
>
>  https://breakpoint.cc/openssl-1.1-rebuild-2016-08-26/
>
>  So since when do we need to consider API/ABI compatibility? Did we grow up
>  recently?
>
>  Or maybe OpenSSL should have switched the language. The point of C is that
>  structures are public. And if I'm going to be honest that approach saved my
>  sorry arse more than a couple times. When zlib choked because it couldn't go
>  past 4 GiBs of data since its fields were uint32_ts, I was able to easily
>  workaround this problem. But what do I know.
>
>  If you really want to fiddle with OpenSSL internal structures - feel free. Just
>  include the OpenSSL internal header files and away you go. Just do so in the
>  knowledge that they could be changed at any time, and your code might break. If
>  this isn't a concern to you then - no problem. If it is a concern to you - then
>  actually you *do* care about API/ABI stability after all.
>
>  Counting symbols is, however, nothing other than a blunt instrument.
>  Quite a lot of those symbols are convenience macros and functions that
>  have accumulated over time.
>
>  You're taking my statement out of context. Counting the symbols wasn't supposed
>  to suggest that there are too *many* of them. I'm in no position to say that,
>  seeing as the original context in which my statement was put is that *I'm not
>  familiar enough with the library*.
>
>  What I said was that reading the code is easy. Learning what the library
>  provides is hard, and that you won't learn much just by looking at the symbols
>  because there's so many of them.
>
>  But nevertheless, I do hear you call for a remake of the SSL API as
>  well as cleaner internals. The latter is easier, and I'm sure it will
>  happen piecemeal as per usual so as to not break something /
>  inadvertently change a behavior (i.e. break ABI). The former is a
>  fairly massive project, and is more of creating a new API and library
>  rather than a mere cleanup job. That will be a massive effort, and
>  you do have to keep in mind how much time all involved can put into
>  it.
>
>  I'm not saying it needs to be done right now. I'm merely suggesting that it
>  might be a good goal post for OpenSSL 2.0.
>
>  Turning structures opaque doesn't prevent people from still messing
>  with their internal fields.
>
>  True. But it makes for a clear delineation where people are forced to
>  be aware that they are playing with internal stuff, and that it may
>  not be a safe thing to do.
>
>  Then why not provide small helper functions for covering the "playing with
>  internal stuff" part? That way it's still controlled, and documented, and
>  unified. You guys must've had some examples to show off in order to justify the
>  process, so surely you know what it is that people do when they use internal
>  stuff. Make functions for those. Don't give them any reason to continue playing
>  with internal stuff.
>
>  I don't like code that tries to protect programmers from themselves. I like code
>  that lets good programmers do smart things. And if bad programmers use that
>  freedom to do bad stuff, then doesn't that mean your API simply didn't support
>  this, and they had to make it work somehow else? Again, helper functions.
>
>  Uhmmmm.... this is factually incorrect. OpenSSL doesn't use its own
>  memory pooling. We have thin wrappers around the usual malloc() /
>  realloc() / free(), which allows any application to do its own memory
>  pooling.
>
>  https://web.archive.org/web/20150207180717/http://article.gmane.org/gmane.os.openbsd.misc/211963
>
>
>  The BUF_FREELISTS code that this post references was ripped out years ago. This
>  no longer represents the current state of OpenSSL in any supported version.
>
>  To conclude, I have a question for you: are you only willing to rant
>  (*), or are you willing to help out in another way?
>
>  This is not the question I feel you should ask because we haven't even
>  established if I *could* make contributions to the project, as my mindset
>  appears to be so much more different. Especially the idea of not wanting to
>  break APIs/ABIs is a huge limitation - just looking at SSL_new() made me give up
>  hope here.
>
>  Yes - not breaking APIs/ABIs is a huge limitation. BoringSSL is not suitable for
>  general purpose use precisely because of this. The only users BoringSSL cares
>  about whether they break or not are Google users. As soon as you have a library
>  that wants to cater for large numbers of users (which we do) then you have to
>  accept that limitation.
>
>  As to whether or not we have established whether you *could* make such
>  contributions - I think you are missing the point. We cannot know whether you
>  are capable or not until you try. It is on the basis of your code that we would
>  make such a judgement. In order for your code to get into OpenSSL it must have
>  been reviewed and approved by two current OpenSSL committers (one of whom must
>  be on the OpenSSL Management Committee). We invite anyone to contribute. In
>  order for this to be a healthy open-source community we *need* those
>  contributions. Only those that make the grade will make it in.
>
>  Note - this review process wasn't always the case. Things used to be much more
>  informal in pre-heartbleed days. This is no longer the case.
>
>  I'm no cryptography expert, I've made that clear from mail one, and my cleanup
>  jobs would be more widespread than what seems to be deemed acceptable right now.
>  I can read and write scalable C code, otherwise I wouldn't even have tried to
>  reuse that SSL object from the beginning.
>
>  So, I ask a question in return: what do you think I *could* be helping with?
>
>  Well, you have vocally complained about the state of the documentation. You have
>  the benefit of being a new OpenSSL user. You know what things were confusing or
>  unclear in the documentation. More experienced OpenSSL coders often don't have
>  the perspective - because some things are just "obvious" to them. So help with
>  pull requests to improve the documentation.
>
>  Matt
>  --
>  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
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

FooCrypt
3 - 6 months

Happy New Year..;)

> On 1 Jan 2019, at 02:43, Richard Levitte <[hidden email]> wrote:
>
> I'll go ahead and ask, how long do you think such a back door would
> stay unnoticed, let alone survive?  I'm considering the fact that we
> have a lot of people looking at our code, just judging from the issues
> and pull requests raised on github.
>
> I can't say that I have an actual answer, but it's a question worth
> asking as well, to see if the T.O.L.A. Act is worth a state of panic
> or not.
>
> Cheers,
> Richard ( who's on vacation and should stop reading these mails )
>
> In message <[hidden email]> on Tue, 1 Jan 2019 01:27:53 +1100, "[hidden email]" <[hidden email]> said:
>
>> Matt et al
>>
>> 'been reviewed and approved by two current OpenSSL committers (one of whom must
>> be on the OpenSSL Management Committee).’
>>
>> Due to the recent legislative changes here in Australia around the T.O.L.A. Act, can a change be
>> made to the OpenSSL policy so that the 2 reviewers, don’t reside in Australia, or are Australian
>> citizens ?
>>
>> ABI/API changes -> breaks -> back door requests….
>>
>> --
>>
>> Regards,
>>
>> Mark A. Lane
>>
>> Cryptopocalypse NOW 01 04 2016
>>
>> Volumes 0.0 -> 10.0 Now available through iTunes - iBooks @
>> https://itunes.apple.com/au/author/mark-a.-lane/id1100062966?mt=11
>>
>> © Mark A. Lane 1980 - 2019, All Rights Reserved.
>> © FooCrypt 1980 - 2019, All Rights Reserved.
>> © FooCrypt, A Tale of Cynical Cyclical Encryption. 1980 - 2019, All Rights Reserved.
>> © Cryptopocalypse 1980 - 2019, All Rights Reserved.
>>
>> On 1 Jan 2019, at 01:11, Matt Caswell <[hidden email]> wrote:
>>
>> On 31/12/2018 11:36, C.Wehrmeyer wrote:
>>
>> On 31.12.18 10:12, Richard Levitte wrote:
>>
>> Yes, it's true, new features are going in. And it's true that it's
>> often more exciting to add new features than to do the janitorial
>> work.
>>
>> You realised what I have left unspoken thus far, which is this almost
>> obsession-like preference of OSS coders to add new features rather than
>> improving the old, boring codebase. However, there's a reason why it's still
>> called code*base*. It's the base of everything. And adding more and more
>> features to that base is going to make ripping off the band-aid more painful in
>> the long run.
>>
>> There has been a huge amount of effort put in over the last few years to improve
>> the codebase. Things that immediately spring to mind (and there's probably a
>> whole load more):
>>
>> - Rewrite of the state machine
>> - libssl record layer refactor
>> - Implementation of the PACKET and WPACKET abstractions in libssl
>> - Rewrite of the rand code
>> - Implementation of the new test harness
>> - Significant effort into developing tests
>> - Implementation of the coding style and reformat of the codebase to meet it
>> - Opaque many of the structures (which I know you don't see as an improvement,
>> but I'll answer that point separately)
>> - Implementation of continuous fuzzing
>> - Significant expansion of the documentation coverage
>>
>> It is simply not true to claim that we have "an obsession-like preference...to
>> add new features rather than improving the old, boring codebase". None of the
>> above things resulted in or were motivated by user visible features. They were
>> all about improving the codebase.
>>
>> Also, infrastructure again. I, as a user, don't care if the kernel gets a new
>> feature that makes some black magic happening. What I care about is that the
>> kernel doesn't throw away my writes (which has happened in May of 2018, see):
>>
>> https://www.postgresql.org/message-id/flat/CAMsr%2BYE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG%2BvzHun1EqMxyQg%40mail.gmail.com#CAMsr+YE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG+vzHun1EqMxyQg@...)
>>
>>
>> Cryptography libs should be equally conservative, considering that cryptography
>> is conservative to begin with. I don't care if TLS 1.3 lets me use new exiting
>> ciphers and handshakes when it unreasonably bogs down my server code.
>>
>> BUT, you also have to appreciate that stuff is happening around us
>> that affects our focus. TLS 1.3 happened, and rather than having to
>> answer the question "why don't you have TLS 1.3 yet?" (there's a LOT
>> of interest in that version), we decided to add it.
>>
>> Sure, but didn't Matt just say that there are a lot of volunteers working on
>> that library? The disadvantage here is that quality assurance is barely a thing
>> - however, the *advantage* of this is that OpenSSL does not have to follow
>> commercial interests. If we look at this at face value you could just say "No,
>> people, it's high time we streamline some of the internal aspects of the
>> library, TLS 1.3 will have to wait. You can't wait that long? Well, sorry".
>>
>> However, your message is clear, we do need to do some cleanup as
>> well. More than that, I agree with you that it's needed (I've
>> screamed out in angst when stumbling upon particularly ugly or
>> misplaced code, so the feeling is shared, more than you might
>> believe).
>>
>> But what does "cleanup" entail? That's the hot-button question here. I've
>> already made a suggestion, that is to say, getting rid of opaque structures. If
>> that is deemed too insecure (for whatever reasons), export symbols that allow
>> programmers to query the size of structures, and provide two versions of
>> functions: one function expects the caller to pass an object to which the
>> changes are to be made, and the other one allocates the necessary memory
>> dynamically and then calls the first version. Or just don't allocate my object
>> memory dynamically anymore.
>>
>> That being said, cleanup happens, and documentation happens, in a
>> piecemeal fashion, 'cause that's what most people have capacity for.
>>
>> So, what you're effectively saying is that I'm the first one who ever asked for
>> SSL object reuse, right? Because if piecemeal work happens on the documentation,
>> and Viktor says that it's possible, then surely no one would have ever answered
>> that question on the mailing list and *not* put it piecemeal-ly in the OpenSSL
>> documentation, right?
>>
>> Now, here's something else that you need to consider: API/ABI
>> compatibility needs to be preserved.
>>
>> No it doesn't. We *know* it doesn't. When OpenSSL 1.1 was released it broke all
>> *sorts* of applications out there, because all sorts of applications used struct
>> fields rather than accessors. wget, mutt, neon, python, you name it, you broke it.
>>
>> API/ABI stability is absolutely required. Every time we make a breaking change
>> it is painful for our users - and more pain is felt the bigger the scale of the
>> break. We simply cannot go around making wholesale breaks on an ongoing basis.
>> If we did so then OpenSSL would be a lot less useful to our users.
>>
>> This is not to say that we can *never* make breaking changes. Only that when we
>> do so it must be strongly justified and only done relatively infrequently. We
>> made such a decision when we decided to make the structures opaque. It's not a
>> decision we are likely to repeat anytime soon IMO. We are still feeling the pain
>> of that now (and will continue to do so for at least the next year until 1.0.2
>> goes out of support - and probably beyond that).
>>
>> Which brings me onto why structures were made opaque in the first place. A
>> significant driver for this (probably *the* most important one) was to improve
>> the codebase. I have witnessed first hand the harm that non-opaque structures
>> did to OpenSSL. We will be fixing the fallout from them for years to come.
>> Non-opaque structures combined with the requirements for stable API/ABI means
>> you cannot change anything in those structures. Renaming or deleting structure
>> members constitutes an API break. Even *adding* structure members constitutes an
>> ABI break (due to the changed size of the structure). This means the code
>> ossifies over time and cannot easily be refactored. Much of OpenSSL's internal
>> "quirkiness" results from attempting to work around this restriction.
>>
>> Things like the state machine refactor and the record layer refactor would not
>> have been possible without opaque structures. In my mind making the structures
>> opaque was one of the best things that ever happened to OpenSSL.
>>
>> https://breakpoint.cc/openssl-1.1-rebuild-2016-08-26/
>>
>> So since when do we need to consider API/ABI compatibility? Did we grow up
>> recently?
>>
>> Or maybe OpenSSL should have switched the language. The point of C is that
>> structures are public. And if I'm going to be honest that approach saved my
>> sorry arse more than a couple times. When zlib choked because it couldn't go
>> past 4 GiBs of data since its fields were uint32_ts, I was able to easily
>> workaround this problem. But what do I know.
>>
>> If you really want to fiddle with OpenSSL internal structures - feel free. Just
>> include the OpenSSL internal header files and away you go. Just do so in the
>> knowledge that they could be changed at any time, and your code might break. If
>> this isn't a concern to you then - no problem. If it is a concern to you - then
>> actually you *do* care about API/ABI stability after all.
>>
>> Counting symbols is, however, nothing other than a blunt instrument.
>> Quite a lot of those symbols are convenience macros and functions that
>> have accumulated over time.
>>
>> You're taking my statement out of context. Counting the symbols wasn't supposed
>> to suggest that there are too *many* of them. I'm in no position to say that,
>> seeing as the original context in which my statement was put is that *I'm not
>> familiar enough with the library*.
>>
>> What I said was that reading the code is easy. Learning what the library
>> provides is hard, and that you won't learn much just by looking at the symbols
>> because there's so many of them.
>>
>> But nevertheless, I do hear you call for a remake of the SSL API as
>> well as cleaner internals. The latter is easier, and I'm sure it will
>> happen piecemeal as per usual so as to not break something /
>> inadvertently change a behavior (i.e. break ABI). The former is a
>> fairly massive project, and is more of creating a new API and library
>> rather than a mere cleanup job. That will be a massive effort, and
>> you do have to keep in mind how much time all involved can put into
>> it.
>>
>> I'm not saying it needs to be done right now. I'm merely suggesting that it
>> might be a good goal post for OpenSSL 2.0.
>>
>> Turning structures opaque doesn't prevent people from still messing
>> with their internal fields.
>>
>> True. But it makes for a clear delineation where people are forced to
>> be aware that they are playing with internal stuff, and that it may
>> not be a safe thing to do.
>>
>> Then why not provide small helper functions for covering the "playing with
>> internal stuff" part? That way it's still controlled, and documented, and
>> unified. You guys must've had some examples to show off in order to justify the
>> process, so surely you know what it is that people do when they use internal
>> stuff. Make functions for those. Don't give them any reason to continue playing
>> with internal stuff.
>>
>> I don't like code that tries to protect programmers from themselves. I like code
>> that lets good programmers do smart things. And if bad programmers use that
>> freedom to do bad stuff, then doesn't that mean your API simply didn't support
>> this, and they had to make it work somehow else? Again, helper functions.
>>
>> Uhmmmm.... this is factually incorrect. OpenSSL doesn't use its own
>> memory pooling. We have thin wrappers around the usual malloc() /
>> realloc() / free(), which allows any application to do its own memory
>> pooling.
>>
>> https://web.archive.org/web/20150207180717/http://article.gmane.org/gmane.os.openbsd.misc/211963
>>
>>
>> The BUF_FREELISTS code that this post references was ripped out years ago. This
>> no longer represents the current state of OpenSSL in any supported version.
>>
>> To conclude, I have a question for you: are you only willing to rant
>> (*), or are you willing to help out in another way?
>>
>> This is not the question I feel you should ask because we haven't even
>> established if I *could* make contributions to the project, as my mindset
>> appears to be so much more different. Especially the idea of not wanting to
>> break APIs/ABIs is a huge limitation - just looking at SSL_new() made me give up
>> hope here.
>>
>> Yes - not breaking APIs/ABIs is a huge limitation. BoringSSL is not suitable for
>> general purpose use precisely because of this. The only users BoringSSL cares
>> about whether they break or not are Google users. As soon as you have a library
>> that wants to cater for large numbers of users (which we do) then you have to
>> accept that limitation.
>>
>> As to whether or not we have established whether you *could* make such
>> contributions - I think you are missing the point. We cannot know whether you
>> are capable or not until you try. It is on the basis of your code that we would
>> make such a judgement. In order for your code to get into OpenSSL it must have
>> been reviewed and approved by two current OpenSSL committers (one of whom must
>> be on the OpenSSL Management Committee). We invite anyone to contribute. In
>> order for this to be a healthy open-source community we *need* those
>> contributions. Only those that make the grade will make it in.
>>
>> Note - this review process wasn't always the case. Things used to be much more
>> informal in pre-heartbleed days. This is no longer the case.
>>
>> I'm no cryptography expert, I've made that clear from mail one, and my cleanup
>> jobs would be more widespread than what seems to be deemed acceptable right now.
>> I can read and write scalable C code, otherwise I wouldn't even have tried to
>> reuse that SSL object from the beginning.
>>
>> So, I ask a question in return: what do you think I *could* be helping with?
>>
>> Well, you have vocally complained about the state of the documentation. You have
>> the benefit of being a new OpenSSL user. You know what things were confusing or
>> unclear in the documentation. More experienced OpenSSL coders often don't have
>> the perspective - because some things are just "obvious" to them. So help with
>> pull requests to improve the documentation.
>>
>> Matt
>> --
>> 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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

Kurt Roeckx
In reply to this post by Matt Caswell-2
On Mon, Dec 31, 2018 at 02:11:56PM +0000, Matt Caswell wrote:
>
> Well, you have vocally complained about the state of the documentation. You have
> the benefit of being a new OpenSSL user. You know what things were confusing or
> unclear in the documentation. More experienced OpenSSL coders often don't have
> the perspective - because some things are just "obvious" to them. So help with
> pull requests to improve the documentation.

Or you could just file a bug pointing out the areas that are
unclear.


Kurt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Authentication over ECDHE

OpenSSL - User mailing list
In reply to this post by Richard Levitte - VMS Whacker-2
On 29/12/2018 22:33, Richard Levitte wrote:

> In message <[hidden email]> on Sat, 29 Dec 2018 17:08:46 +0100 (CET), Richard Levitte <[hidden email]> said:
>
>> In message <[hidden email]> on Sat, 29 Dec 2018 14:19:47 +0100, "C.Wehrmeyer" <[hidden email]> said:
>>
> ...
>>> What's wrong with that, you ask? Let me show you how I'd have done
>>> that:
>>>
>>>> static const unsigned char ssl3_pad_1[] =
>>>> {
>>>>      "66666666"
>>>>      "66666666"
>>>>      "66666666"
>>>>      "66666666"
>>>>      "66666666"
>>>>      "66666666"
>>>> };
>>>>
>>>> static const unsigned char*ssl3_pad_2[] =
>>>> {
>>>>      "\\\\\\\\\\\\\\\\"
>>>>      "\\\\\\\\\\\\\\\\"
>>>>      "\\\\\\\\\\\\\\\\"
>>>>      "\\\\\\\\\\\\\\\\"
>>>>      "\\\\\\\\\\\\\\\\"
>>>>      "\\\\\\\\\\\\\\\\"
>>>> };
>>> So, no. I don't trust anyone. Especially not this mess of a code.
>> 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.
> Never mind this remark...  For some reason, my brain added commas
> after each partial string.  Meh...
>

It still inserts NUL bytes at the end of each array, changing
sizeof(array) as well as cache access patterns (and thus side
channel effects).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
12