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
>> defined.
> 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
>> cove...@gmail.com

Reply via email to