[HN Gopher] TLS 1.0, 1.1 officially deprecated
___________________________________________________________________
TLS 1.0, 1.1 officially deprecated
Author : cmckn
Score : 220 points
Date : 2021-03-23 20:15 UTC (2 hours ago)
(HTM) web link (datatracker.ietf.org)
(TXT) w3m dump (datatracker.ietf.org)
| diegocg wrote:
| Maybe the IETF could set an example by using TLS 1.3
|
| (Just a suggestion, but hey, at least they use DNSSEC)
| some_furry wrote:
| DNSSEC provides zero benefit to confidentiality. DNS over TLS
| and DNS over HTTPS both do. Additionally, the TLS CA system
| with Certificate Transparency and the HTTPS Everywhere addon is
| better without DANE.
| tptacek wrote:
| They're some of the only people that use DNSSEC; DNSSEC is a
| dead letter.
|
| It's useful to compare the uptake of TLS 1.3 (quite widespread;
| will within a few years be required for conformance; took just
| a couple years) to that of DNSSEC (it's been decades).
| jeroenhd wrote:
| That depends on the TLD. For the American TLDs (.com, .net,
| etc.) you're right, there's barely any uptake. Several other
| TLDs (.cz, .no, .nl, .se, for example) have over half of
| their registered domains using DNSSEC. That's much more than
| TLS before the Let's Encrypt move happened.
|
| The problem is also with cloud providers. Amazon Route 53,
| has only announced support a few months ago [1] even though
| the standard has existed since before Route 53 came into
| existence.
|
| Perhaps it's time for browsers to consider DNSSEC to
| determine the security of the website, similar to how TLS and
| CORS have been added to protect web resources. The uptake
| would improve quickly if people wouldn't be lazy or
| lackluster about their DNS security.
|
| [1]: https://aws.amazon.com/about-aws/whats-
| new/2020/12/announcin...
| growse wrote:
| What threats does DNSSEC defend against?
|
| How does it change the "security" of a site I might visit?
| tptacek wrote:
| Browsers implemented DNSSEC years ago, and then struck
| their support. A lot of the things DNSSEC proponents
| believe it's good at don't actually hold up in the real
| world; for instance, you can't practically deploy DANE
| without creating a scheme where the DNS simply becomes
| another CA that has to be trusted alongside all the others,
| and one you can't revoke when misissuance occurs.
|
| It's funny to watch as the "serious" efforts to get some
| semblance of DANE working all involve some variant of
| stapling to bypass the actual DNS. DNSSEC is a weird,
| clunky, 1990s PKI that has been trying desperately for
| decades to find some reason to exist, even if that reason
| has nothing to do with the DNS.
|
| A thing to pay attention to with European DNSSEC adoption
| is that it tends to happen at the registrar, automatically,
| without customer opt-in. The registrar controls the
| customer zone keys. That's security theater.
| Denvercoder9 wrote:
| > where the DNS simply becomes another CA that has to be
| trusted alongside all the others
|
| Isn't DNS already implicitly trusted?
| tptacek wrote:
| Not in the same way. Again: you can't revoke the DNS.
| kazen44 wrote:
| mind you DNSSEC is also far more complex then TLS. A
| misconfigration of DNSSEC can result in your entire domain
| not being responsive and thus have the risks in regards to
| implementation are far higher.
|
| I don't really think this should be a reason to NOT implement
| DNSSEC, but it is still a reason many companies and
| organisations see it as risky.
| tptacek wrote:
| There are a lot of reasons not to deploy DNSSEC. That it's
| much more dangerous than TLS is just one of them. It would
| be better for the Internet if we scrapped DNSSEC and
| started from scratch with a service model that acknowledges
| what the Internet of 2020 (or, if we can't be that
| ambitious, 2005) actually looks like.
| 1vuio0pswjnm7 wrote:
| Yet it seems like DNSSEC is popular with DNS software
| developers. IME, it's common to find support for it in DNS
| software. Whereas, generally, developers of TCP server
| software do not seem to be as enthusiastic about adding
| TLS1.3 support. Perhaps not until they are required to do so.
|
| Personally, I think the costs of DNSSEC outweigh the
| benefits. I do not use shared DNS caches anyway.
| ipsocannibal wrote:
| According to [1] IPv6 is only at about 33% penetration and this
| is for a backwards compatible 25 year old standard. In contrast
| TLS 1.3 is supported by approx. 14% of websites in 2019 [2]. So
| in comparison to IPv6, TLS 1.3 is being adopted quite rapidly.
|
| 1. https://www.google.com/intl/en/ipv6/statistics.html
|
| 2. https://hostingtribunal.com/blog/ssl-stats/
| deathanatos wrote:
| Because it requires only the ends to adopt, whereas IPv6
| requires cooperation from e.g., my ISP.
| lazyweb wrote:
| On a related note, thinking of setting my personal site to TLS
| 1.3 only. It's still allowing for TLS 1.2 with strong chipers,
| but except for shutting out anyone using older smartphones or
| operating systems, what's the harm? Could I fall out of favour
| with Google & co due to compliance reasons?
|
| Thinking of SSL scan tools like this one [1] which gave me an "F"
| for how I configure my SSH servers, only allowing for very modern
| ciphers and kex without backward compatibility.
|
| [1] https://github.com/rbsec/sslscan
| lenish wrote:
| RFC7457[1] and Wikipedia[2] offer an overview of many of the
| attacks on older versions of TLS. Some of those attacks have
| been mitigated to varying extents in implementations of the
| affected versions. TLSv1.3 is meant to resolve completely as
| many of these issues as possible.
|
| When using older protocol versions, it can be complicated to
| validate that the TLS implementation you are using has the
| necessary mitigations in place. It can be complicated to
| correctly configure TLS to minimize the effects of known
| attacks. Doing that properly requires a fair amount of
| research, threat modelling, and risk assessment both for
| yourself and on behalf of anyone accessing your website or
| service.
|
| IME, TLSv1.2 is still a big chunk of legitimate web traffic. It
| has been steadily dropping since standardization, and TLSv1.3
| is the majority by a wide margin from what I can see. I
| wouldn't be surprised to see some websites and services still
| needing to support it for a couple years more, at least,
| depending on their target audience.
|
| [1] https://tools.ietf.org/html/rfc7457
|
| [2]
| https://en.wikipedia.org/wiki/Transport_Layer_Security#Attac...
| shaicoleman wrote:
| > thinking of setting my personal site to TLS 1.3 only
|
| I wouldn't recommend doing that. You might end up blocking
| using a proxy (e.g. for privacy reasons), people on corporate
| networks, people in China [1], and many other non-traditional
| browsers (e.g. for blind people, game consoles), users on older
| versions of curl/wget/lynx, older mobile phones, etc.
|
| TLS 1.2 when correctly configured is still perfectly fine. And
| users with modern browsers will connect with TLS 1.3. TLS 1.3
| also has protections against downgrade attacks.
|
| Another good scanner for SSL is Qualys SSL Server Test [2].
| Getting an A+ score there doesn't require disabling TLS 1.2
|
| For secure configuration, you can use Mozilla SSL Configuration
| Generator [3]
|
| 1. https://www.zdnet.com/article/china-is-now-blocking-all-
| encr...
|
| 2. https://www.ssllabs.com/ssltest/
|
| 3. https://ssl-config.mozilla.org/
| staticassertion wrote:
| > perfectly secure.
|
| I think you're trying to use 'perfectly secure' here the way
| one might say 'perfectly fine', which changes the reading a
| lot from a first pass.
|
| That said, I agree, there is a subset of TLS 1.2 that is
| suitable.
| shaicoleman wrote:
| Agreed, updated that
| oaiey wrote:
| Is TLS 1.3 is not rolled out to Windows 10? It rolled out to
| insider builds during last autumn but did it arrive already to
| the masses
| AdrianB1 wrote:
| Based on the numbers in the other comments, you risk losing ~
| 10% of the readers. It is up to you to decide if you want to do
| it or not.
| GeneticGenesis wrote:
| I work in the video streaming industry, and we continue to
| support TLS 1.1 extensively for a wide range of "smart" TVs and
| set-top boxes, very frustrating, there was even a long period
| where large CDNs were trying to shut down 1.1 and realised they'd
| lose a lot of business in the streaming space if they did...
| lyeager wrote:
| Maybe now it's finally time for Discord to update their auto-
| updater. Last I checked, you still have to enable TLS 1.1 to get
| updates. https://twitter.com/discord/status/958508910536790016
| ipsocannibal wrote:
| According to [1] 68% of websites still support TLS 1.0 as of
| 2019. Unfortunately, the pace of deprecation is slow.
|
| 1. https://hostingtribunal.com/blog/ssl-stats/
| JshWright wrote:
| There is a difference between "supporting old TLS" and
| "requiring old TLS". Neither are great, but one is terrible.
| VoidWhisperer wrote:
| Some interesting draft names there.. 'draft-moriarty-tls-
| oldversions-diediedie'
| gsmethells wrote:
| Authors: Kathleen Moriarty, Stephen Farrell
|
| It seems it's a last name of an author and not just the arch
| nemesis of Sherlock Holmes. ;)
| kibwen wrote:
| And let's not overlook the uncredited contributions from
| Dieter D. Dietrich.
| LetsNotForget7 wrote:
| Let's not forget Hiedler 0.1, never forget. Yeah TLS 1.2 is
| deprecated, let's 1.3 my all co-doggs! TLS 1.2 is shit my
| dudes. TLS 1.3 or bust.
| ping_pong wrote:
| "Deprecate" means "to discourage use of", and it doesn't mean "to
| end support or to desupport". But it's the most misused word in
| tech that I've seen in the past 25 years.
|
| So I'm not actually sure if this RFC is using it in the correct
| way, or the incorrect way.
| staticassertion wrote:
| It's interesting that you're both literally incorrect from the
| perspective of the English language, but also incorrect with
| regards to the goal of the announcement. Kudos!
| ping_pong wrote:
| I'm literally correct. Look up "to deprecate" in the
| dictionary. In APIs like Java it's clear that you can still
| use the API, but its use is discouraged because it will soon
| become unsupported.
|
| A deprecated API is one that you are no longer recommended to
| use, due to changes in the API. While deprecated classes,
| methods, and fields are still implemented, they may be
| removed in future implementations, so you should not use them
| in new code, and if possible rewrite old code not to use
| them.
|
| https://docs.oracle.com/javase/8/docs/technotes/guides/javad.
| ..
| staticassertion wrote:
| Yeah, I mean, you look it up? lol someone even linked it
| elsewhere.
|
| And the article is about recommending against its use.
| rwbhn wrote:
| The intent seems clear, though: "TLS 1.0 MUST NOT be used" "TLS
| 1.1 MUST NOT be used"
| Bjartr wrote:
| > Deprecation of these versions is intended to assist
| developers as additional justification to no longer support
| older (D)TLS versions and to migrate to a minimum of (D)TLS
| 1.2.
|
| Seems to me like this document is trying to be a tool for
| developers to support telling decision makers that using those
| versions is discouraged.
| zokier wrote:
| https://www.merriam-webster.com/dictionary/deprecate
|
| > to withdraw official support for
| bawolff wrote:
| IETF is a standards body. It doesn't provide support for
| implementations so im not sure how it could withdraw what it
| doesn't provide in the first place.
|
| Regardless i think you're splitting hairs in the definition.
| jakub_g wrote:
| If you're interested in real-world SSL/TLS stats (updated
| monthly):
|
| https://www.ssllabs.com/ssl-pulse/
|
| Feb 2021 data:
|
| - 99.3% sites support TLS 1.2 (or better)
|
| - 42.9% sites support TLS 1.3
|
| - 0.7% sites support only TLS 1.0
| moviuro wrote:
| And for the client-side: 90.29% support according to [0]
|
| [0] https://caniuse.com/tls1-3
| oaiey wrote:
| When you are in a browser. API calls are not evergreen as
| Browsers are.
___________________________________________________________________
(page generated 2021-03-23 23:00 UTC)