Hi Willy, > Le 29 mars 2017 à 18:29, Willy Tarreau <[email protected]> a écrit : > > Hi Manu, > > On Wed, Mar 29, 2017 at 06:10:13PM +0200, Emmanuel Hocdet wrote: >> Hi Willy, >> >>> Le 27 mars 2017 à 17:54, Willy Tarreau <[email protected]> a écrit : >>> >>> Hi Manu, >>> >>> On Mon, Mar 27, 2017 at 05:46:46PM +0200, Emmanuel Hocdet wrote: >>>>> I'm not much comfortable with the "sslv3" and so on as they easily read >>>>> as "use sslv3 only" (for me at least) but we can get rid of them once we >>>>> have everything needed with min-tls/max-tls, and if some users want to >>>>> keep them anyway then we can complete the doc to mention explicitly what >>>>> they do (ie: stop disabling support for sslv3). So that's no big deal. >>>>> >>>> >>>> If I understand the needs, parameters is to reset settings from default >>>> server. >>> >>> Absolutely. The typical use case would be a defaults section setting the >>> default >>> server with "no-sslv3 no-tlsv10 no-tlsv11" but one local server requires to >>> run >>> with one such versions, and just for this we don't want to cancel the >>> convenient >>> default-server settings, so having a statement to say "go back to defaults >>> for >>> this one" is better. >>> >>>> For ssl we could have 'ssl-all' and avoid any 'no, 'no-no' tls version ? >>> >>> Maybe something like this. But I *tend* to think that once we have your >>> min-tls/max-tls it could be a no-brainer. Emeric told me he thinkgs that >>> it's probably bad to make an exception for certain keywords (and I tend >>> to share his opinion on this one), so maybe over the long term we'll still >>> have them with proper doc and possibly warnings suggesting a different >>> syntax. After all, saying "I don't want to disable SSLv3 for this server" >>> tends to imply you explicitly know you want it, so the value of having >>> these confusing keywords might possibly be only to ensure users naturally >>> find the keyword they're looking for without having to think too long. >>> >> >> >> with: >> force-tlv == min-tlv + max-tlv > > This one I totally agree. > >> no-tlv => obsolete (and no need (no-no) tlv) > > We can't easily obsolete it since it's present in almost 100% of existing > configs (at least for no-sslv3), so dropping it will postpone adoption > which is bad for getting useful feedback. That's why I proposed that > we only reject situations where no-tlsvX leaves a hole. > >> default min-tlv and max-tlv can be overwrite on local definition. > > Yes that was my previous point, they could be used to simply override > the default-server setting even if this one used to have "no-sslv3" > for example. > >> So min-tlv, max-tlv (and force-tlv) could be the only useful parameters: tlv >> and no-tlv >> can be removed from default server parameters. > > Hmmm from default-server, that could make sense indeed since they were > not used in the past. > >> A no-tlv définition on server (compat) can work or generate warning if 'hole' >> is detected. > > I think we can go as far as an error if there's a hole since the situation > seems to be mostly undefined today (from what I understand).
I went on a warning to start to not break configuration. openssl work with hole, but keep the lower or upper range (it depend). no-tlsv12 work, but will generate warning with tlsv1.3 in openssl. > So I think that we agree on all these in the end (note however, that it's tls, > not tlv but that's a detail). > We agree. (note: It’s the short name of tlsv, or I was tired :-D ) > Last point is that sslv3 has to have its name in the value. While there's > a 2.1 offset between ssl and tls versions (tls 1.0 is ssl 3.1), I'd rather > not put confusing SSL versions there nor invent fake TLS versions to name > SSL (eg: tlsv0.9). Strictly speaking we should use only the SSL version > since it's what is exchanged over the wire. Or we can say that version 0 > is SSLv3. So I'm open to suggestions here. > No changes, keep the name in the version. It’s just shorter to speak with tlsxx :). ++ Manu
