Deprecation of Legacy TLS 1.0 and 1.1 Versions

[Aaronn]

https://webkit.org/blog/8462/deprecation-of-legacy-tls-1-0-and-1-1-versions/

[petecooper]

[Also posted in corresponding discussions for Firefox (https://news.ycombinator.com/item?id=18223672) and Chrome (https://news.ycombinator.com/item?id=18221281) ]

If you want Nginx to use TLS v1.2, this is what you need:

  ssl_protocols TLSv1.2;

…and if you compile a recent Nginx from source and bake in OpenSSL 1.1.1 while you do that, you can have TLS v1.3 with a TLS v1.2 fallback, too:

  ssl_protocols TLSv1.3 TLSv1.2;

See also:

https://caniuse.com/#feat=tls1-2

https://caniuse.com/#feat=tls1-3

[stock_toaster → petecooper]

I don't believe the order in "ssl_protocols" has any relevance. The client and server should negotiate/choose the highest mutually supported protocol version.

[tialaramex → stock_toaster]

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.

[georgyo → tialaramex]

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.

[dddddaviddddd → georgyo]

Why not support both configuration strategies?

[lmm → dddddaviddddd]

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

[jeroenhd → tialaramex]

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.

[Already__Taken → stock_toaster]

If the server hasn't ordered preferences then wouldn't you be trusting that every client is updated enough to understand what "highest" means?

[stock_toaster → Already__Taken]

Perhaps you are thinking of cipher selection, and "prefer server ciphers"? Those are separate tunables.

EDIT: Here is a description of protocol selection: https://en.wikipedia.org/wiki/Transport_Layer_Security#Basic... and shows the basic negotiation phase.

(first two bullet points under the first numbered item)

[cesarb → stock_toaster]

Since TLS 1.3, version selection is more similar to cipher selection. See https://tools.ietf.org/html/rfc8446#section-4.2.1 : "The extension contains a list of supported versions in preference order, with the most preferred version first."

[CydeWeys → petecooper]

Why doesn't nginx default to using TLS v1.2 yet? It came out over a decade ago!

[stock_toaster → CydeWeys]

It does. https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_...

  Default: ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

[CydeWeys → stock_toaster]

So then I don't understand the parent comment. It sounds like if you want TLS v1.2 support, you don't have to do anything special in configuring nginx.

[petecooper → CydeWeys]

Current defaults are `TLSv1 TLSv1.1 TLSv1.2`. The logic in stating `TLSv1.2` or `TLSv1.3 TLSv1.2` is that you're excluding TLSv1 or TLSv1.1 rather than explicitly including TLSv1.2.

[gsnedders]

Does this affect other users of NSURL too?