Hacker News new | past | comments | ask | show | jobs | submit login

Yes, as I wrote in one of the three other threads about this co-ordinated release, the Right Thing isn't a list but a minimum version setting, and if you really want it, maybe a maximum.

Programs like web servers that expose a list here are doing that because the libraries they use did that, not because it makes any sense to configure it this way.

Of course the real fix is to change libraries to offer an appropriate API but handling the distance between what a pre-existing library does out off the box and what users want/need is the whole point of application software.

Imagine that TLS 1.3 is found to have a critical flaw and more vulnerable than TLS 1.2. You then set your min/max to 1.2.

Later TLS 1.4 comes out. How can I allow new TLS 1.4 and existing TLS 1.2 clients without allowing TLS 1.3 clients using your method.

The server software would have to be updated to include a blacklist or go back to being an ordered list.

Why not support both configuration strategies?

Because that gives the application even more chances to do the wrong thing, which is what we were trying to avoid.

As other wrote, this might cause problems when TLS 1.3 contains a major vulnerability TLS 1.4 fixes.

In my opinion, the `ssl_protocols` config should accept a string like "TLSv1.2+ -TLSv1.3", basically stating a minimum version, allowing exclusions and including anything newer. In the same spirit, one should be able to do "TLSv1.0-TLSv1.2" for setting a maximum, with specific exclusions if a new TLS version ever becomes a problem.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact