Add TLS1.2 and 1.3 subdomains

[Siguza]

There are subdomains for TLS1.0 and 1.1, and despite the separate ports they're using as described in #233, they're linked on the front page.

Any chance we could get the same for TLS1.2 and 1.3?

[lgarron]

Does the latest nginx support TLS 1.3? (Is TLS 1.3 even finalized yet?)

[Siguza]

I had thought TLS 1.3 had been finalised, but looking it up revealed it to still be a working draft.

But nginx does support it since version 1.13 (April 2017).

[plaintextcity]

Test support for TLS1.2 would be helpful to identify client connectivity issues, as some sites are moving to require TLS1.2. Microsoft is doing this for Office 365 on ~~March 1~~ October 31, 2018.

https://support.microsoft.com/en-us/help/4057306/preparing-for-tls-1-2-in-office-365

Test support for TLS1.3 would be helpful as openssl 1.1.1-pre1 now supports TLS1.3. Since a use for badssl is to shakeout middlebox issues, it would be most useful to deploy after the middlebox fixes are all available (I don't know whether they are or not).

[christhompson]

I think that TLS 1.3 support will require OpenSSL 1.1.0 (along with switching to mainline nginx versions, rather than stable). Unfortunately, this removes a bunch of weak/obsolete cipher and protocol support. We can partially recover by using a custom compiled nginx/openssl stack with enable-weak-ssl-ciphers and enable-ssl3, but there are still some ciphersuite options that no longer exist (like MD5).

I'm not sure where the balance is between supporting test cases for obsolete cases and for handling cutting edge. Ideally we'd like to be able to do both but I'm not sure of a good way right now (and I definitely don't want to maintain a fork of OpenSSL just to keep some MD5 patches around). Maybe there'd be a way to build and run two nginx instances, but that adds a ton of complexity to the site.

(We can definitely add an explicit TLS 1.2 subdomain sometime though.)

[Siguza]

I suppose sooner or later you'll need multiple instances anyway to keep old features around. I think the easiest way of doing this would be to update the main instance every now and then, and whenever support for something is dropped, you compile a legacy version of nginx + OpenSSL, move affected features there, bind to a separate port, and then in theory you shouldn't have to ever touch that instance again.

[lgarron]

I'm not sure where the balance is between supporting test cases for obsolete cases and for handling cutting edge. Ideally we'd like to be able to do both but I'm not sure of a good way right now (and I definitely don't want to maintain a fork of OpenSSL just to keep some MD5 patches around). Maybe there'd be a way to build and run two nginx instances, but that adds a ton of complexity to the site.

We thought about this when we needed to support SSLv3 (which doesn't support SNI). The two solutions were:

• Use a separate IP for SSLv3 – pointing either to a different machine, or maybe the same if we can set up clever routing.
• Use separate ports.

We're using the latter:

• https://ssl-v2.badssl.com:1002/ (doesn't work right now; not sure precisely what the problem is)
• https://ssl-v3.badssl.com:1003/ (doesn't work right now; not sure precisely what the problem is)
• https://tls-v1-0.badssl.com:1010/ (works)
• https://tls-v1-1.badssl.com:1011/ (works)

https://tls-v1-2.badssl.com:1012/ would be easy to add (just haven't gotten around to it).

If we want to avoid adding new servers, https://tls-v1-3.badssl.com:1013/ could be handled by a different server on the same machine using the main nginx instance as a reverse proxy, such as a separate instance of nginx (is that possible?) or nginx in a container. Even cooler would be if we could reverse proxy to something that handles the handshake, which then binds back to the canonical nginx instance for serving the domain's contents. Neither sounds simple, though, and badssl.com has stayed maintainable this far by remaining a simple static configuration tree.

[ExE-Boss]

@lgarron The http://tls-v1-2.badssl.com:80 and https://tls-v1-2.badssl.com:443 configurations currently redirect to https://tls-v1-2.badssl.com:1011 and not to https://tls-v1-2.badssl.com:1012 (see https://github.com/chromium/badssl.com/pull/345#pullrequestreview-149545064)

[dasanjos]

Hey, I'm interested in TLS 1.3 as well!

Does the latest nginx support TLS 1.3? Yes, as of nginx 1.15.3 - see http://nginx.org/en/CHANGES

(Is TLS 1.3 even finalized yet?) The latest version of TLS, TLS 1.3 (RFC 8446) was published in August - see https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/

I think that TLS 1.3 support will require OpenSSL 1.1.0 Actually OpenSSL 1.1.1 - see https://wiki.openssl.org/index.php/TLS1.3 The latest stable version is the 1.1.1 series. This is also our Long Term Support (LTS) version, supported until 11th September 2023.

[hellow554]

ping‽

TLS1.3 is available on nginx.

[onefreddy]

hi, any update?