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). 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). 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. Cheers, Willy
