Woah! I just read ssl_init_ctx_protocol()...that's... quite something.
So, basically, what our SSLProtocol does is
- select the proper _new() variant for the SSL_CTX_new()
- disable known protocol versions not set in our bitmask
- set the max protocol version based on our bitmask
What does that mean if someone wants to configure TLSv1.3 for their server?
Do I read this correctly that we need to make a new release first before
someone can enable it?
> Am 14.08.2017 um 18:56 schrieb Stefan Eissing <stefan.eiss...@greenbytes.de>:
> Am 14.08.2017 um 17:14 schrieb Eric Covener <cove...@gmail.com>:
>>> I hope this looks attractive to you. All bugs are mine. Let me know what
>>> you think.
>> It looks neat. I think accessible doc will be key.
> yes. I was thinking of generating, but had no bright idea so far.
>> But for the sake of discussion, what will we do / what will
>> distributors do when say TLS1.3 or some esoteric part of it is only
>> available in some SSL toolkit releases?
> Well, the protocol defs do not exclude anything new. So TLS1.3 will just be
> "on" where available.
>> It seems like over time there are a lot of confusion with compile-time
>> vs. runtime openssl, forks, etc that either push towards "modern"
>> being ambiguous for a user or to have lots of different permutations
> That is rather the description of the state SSL configs is in now, is it not?
> Apart from the few who really know everyone copies sth from somewhere.
> And they can continue to do so. We take nothing away. We just offer them,
> hopefully, an easier way to define what they like.
> Plus some predefined policies for people that just want to use sth we offer.
> The rate of change should be very low, I think.
> If a Mom&Pop server goes https: it is just a bit easier to make it work with
> modern browsers.
>> Eric Covener