[openssl-users] Authentication over ECDHE

[C.Wehrmeyer]

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.