In the past 20 years we have moved from SSL to TLS (yet we’re still talking about SSL certificates, funny isn’t it). According to Wikipedia’s Transport Layer Security page, this is the release history:
SSL 1.0 -> Never officially released due to security flaws
SSL 2.0 -> 1995, deprecated in 2011
SSL 3.0 -> 1996, deprecated in 2015
TLS 1.0 -> 1999, deprecated in 2020
TLS 1.1 -> 2006
TLS 1.2 -> 2008
TLS 1.3 -> 2018
It’s crazy to think that the modern TLS 1.2 is already 12 years old. Not long ago I dropped everything older than 1.2 and introduced support for 1.3 + I’m using only modern ciphers. But this is easily done on a blog with almost no traffic.
With TLS 1.0 deprecating this year, it’s about time to (re-)adjust the TLS settings of web servers and proxies (if you are still allowing SSL protocols by 2020, shame on you). But the big question is: What will happen when TLS 1.0 is disabled in the configs? Will end-users get an error message? Will some API calls stop working?
These are great questions that are near and dear to my heart. I think almost any company providing some sort of SaaS solution that is accessible through a web browser will need to address it at some point.
Really great read on how to reconfigure NGINX to provide TLS protocol and ciphers used to establish a connection in the access logs and how to handle them further for fetching, parsing and presenting. I’m doing something similar, only instead of Filebeat and Logstash I’m using rsyslog instead.1 End result is the same though – no guessing, logging.
Yeah, definitely going to prepare a blog post on this topic. ↩