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
