-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add TLS1.2 and 1.3 subdomains #332
Comments
Does the latest |
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). |
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 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). |
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 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.) |
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. |
We thought about this when we needed to support SSLv3 (which doesn't support SNI). The two solutions were:
We're using the latter:
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. |
@lgarron The |
Hey, I'm interested in TLS 1.3 as well!
|
ping‽ TLS1.3 is available on nginx. |
hi, any update? |
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?
The text was updated successfully, but these errors were encountered: