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? -Stefan > 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 >
