TLS 1.0, 1.1 officially deprecated
datatracker.ietf.org
datatracker.ietf.org
Only the tech industry is so brazenly authoritarian about breaking things that used to work.
Software is written by human beings, human beings make mistakes. The fact these devices can't be updated by the vendor is an implicitly economic problem
Right-to-repair likely wouldn't "solve" these problems for 99% of people, unfortunately. Netflix would never have its customer service people advocating to download custom firmware for smart TV's from "some Russian website" for instance
The real change it would cause is allowing "tech savvy" people to carve out a niche repairing and reselling used, but functional devices. Which even if it's only a 1% decline in sales is an unacceptable proposition for companies.
Selling millions of something every year somehow isn't worth it if even a single PENNY is left on the table, or "spent" in the wrong place instead of lining their pockets
They wouldn't tell that to people directly, but they could tell you to go to a repair man. Who then, would proceed to download that same firmware from the Russian website and apply it, and the TV now works. Netflix gets to keep their reputation, and the customer is happy with the TV.
Smart TVs and many streaming boxes often ship with vendored libcurl/OpenSSL/other libraries that are already years old when the device itself is new. It is frustrating and insecure, but cutting these users out isn’t a clear solution either.
hmm... unless my Amazon credential handshake is in that?
But it's not like the attacks on TLS 1.0 and 1.1 are trivial. To successfully break a single encrypted connection requires massive server farms.
The people actually attempting to maliciously break TLS handshakes are working on much bigger targets.
The attacks aren’t entirely practical, and the threat model for “someone cares enough to MitM my streaming connection” isn’t a common one, but it’s much closer to practical compared to attacks on TLS 1.2 & 1.3.
When was the last time you applied a security update for your networked printer? I'm guessing never, because no printer vendor has a security department, none have security updates, etc...
This is why smart networked printers are where state-sponsored attackers like the NSA like to hide their persistent malware...
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
https://docs.microsoft.com/en-us/windows/win32/secauthn/prot...
.Net says to use the OS schannel protocols. Even the latest Windows doesnt do TLS 1.3 yet.
MSSQL has no support for it either.
Even on the end user side. One i like to point out is disable TLS 1.0 and try and launch discord. Their update cdn only supports TLS 1.0. So the application doesnt function unless the OS client also will use TLS 1.0
I opened a ticket with them about it and was marked solved and responded with.
>Sadly, this is currently working as intended. However, if you would like to see changes to these systems in the future, then you can definitely vote up the suggestions at feedback.discordapp.com.
We are a long way from removing TLS 1.0.
I believe it's enabled by default in insider builds as of this summer.
[1] https://devblogs.microsoft.com/premier-developer/microsoft-t...
Also the link in that document is unsurprisingly 404'd. If only IIS had a method of doing redirects and rewrites :?
https://web.archive.org/web/20200327011332/https://docs.micr...
_TECHNICALLY_ the only thing that exists is TLS. The implementation history is SSL 3.0 < TLS 1.0 ... 1.3
However, SSL is still used colloquially in conversation, e.g. "SSL certificate" and in many legacy config flags, such as Firefox's `about:config`.
For best clarity, check the details of all those settings, even the SSL ones. But TLS is the term for the modern standards.
TLS 1.1 uses version encoded in two bytes that should mean "SSL 3.2", TLS 1.2 uses bytes that should mean "SSL 3.3". TLS 1.3 pretends to be TLS 1.2 to pass through proxies but internally uses two bytes that should mean SSL 3.4 to indicate its version.
Colloquially we still say "SSL" a lot when referring to TLS.
I know it really doesn't matter in the grand scheme of things, but man does it make my eye twitch lol.
I've tried using TLS instead of SSL but due to the friction of general acceptance of SSL I don't see much point in trying to fight.
I wish that TLS 1.4 will be called Transport Security System Layer (TSSL) or something which can be referred to as SSL and we can all go back to normal again. ;)
No, it is a good example by now. A modern M.2 SSD looks much more like a stick of RAM than any kind of spinning disk.
Sure, spinning hard disks are still around, and might stick around for quite a while (data centers, archival...), but when someone at their desk says "save on disk" nowadays, it increasingly will be on such an entirely non-disk-looking disk.
They even have aluminium sliding parts and what looks like some sort of disk inside...
/s
But they don't actually mean SSL vs TLS. They mean a TLS connection (like HTTPS uses) vs StartTLS (where you start out SMTP plaintext then negotiate TLS as an extension.
Are there any resources for retrocomputing in the TLS 1.2+ era? Maybe something like an HTTPS downgrade proxy that requires manual installation of a new cert and is targeted at retro OS isolation?
EDIT you can also use a more recent OpenSSL backport https://github.com/mezentsev/OpenSSL-Backport
Figured that might fix the main problem at the time, but then create new problems for other things. So I gave up.
Will likely do a new box and new install with a different domain name to see if I can get it all working proper with modern tls/ssl stuff (think i saw something about a recent debian update doing some things with ssl and tls) -
But no one got back to me on exporting user data from Synapse - of which I really just need usernames, email addys to a fresh install - so I gave up on that too.
Why are you using an old version of curl to update your debian, instead of pulling a new binary (or source) package?
I was looking into this last year when Wikipedia cut off access for older cipher suites. mitmproxy worked, but is the wrong tool for the job (too slow for everyday use). I needed something leaner that I could chain into other proxies, but got distracted before I could find a solution.
Only thing I can’t seem to get working is PPC support, so you’d have to run the proxy on a secondary Intel Mac.
I think you must have lacked support for TLS-1.2? Very few websites/servers require TLS-1.3
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.
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...
I wouldn't recommend doing that. You might end up blocking users using a proxy (e.g. for privacy reasons), people on corporate networks, people in China [1], and many other non-traditional browsers (e.g. browsers for the blind, 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...
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.
Not only it adds 2^(number of ciphers) ways to misconfigure the server with a gaping security leak, but names are obscure and strings are NEVER the same between nginx and the SSLlabs website which advises what is correct, plus who knows whether SSLLabs is a trustworthy website. Also, 6 months later the ciphers might not be up to date. Why do I have to even choose ciphers? Why isn’t this TLS 1.2.1, then 1.2.2, and so on?
It’s like going to Amazon, choosing n resistors by guessing their value, going to m people asking them if it’s 12 ohms, most of them having no clue what they are talking about, and using it for an airport security device that can put people in jail.
Indeed, more choice means more ways to mess things up, more complexity, more bugs and more vulnerabilities.
That's why TLS 1.3 reduces the cipher suite choice to 5 ciphers, down from 37 from TLS 1.2 (in previous versions there were 319 in total) [1]
1. https://owasp.org/www-chapter-london/assets/slides/OWASPLond...
Now, the technical answer as to why there's something to pick from at all goes like this:
TLS is a negotiated protocol. Some HN regulars are convinced negotiation is a bad idea, and indeed they will point to TLS as an example. But the idea is that with a vast population of servers and clients on the Internet it isn't actually practical to hold a flag day (replacing all software on clients and servers immediately) to upgrade TLS. Different clients and servers may have different priorities, so we'd like them to be able to agree each time on something they're both content with. For example on your general purpose laptop there is hardware AES, so AES ciphers are fast and secure, but some cheap devices don't have that, so for them AES is annoyingly slow/ power hungry. As a result they'd prefer ChaCha20 if possible.
How did the list get so long? There's a point around the turn of the century when countries realise oh, this Internet thing is important, and you get a rash of "cryptographic nationalism" where a government that likes to think of itself as important notices the US government made things like DES and it decides it can do that too, resulting in vanity ciphers which are less analysed, less popular, and basically have no reason to exist. TLS 1.2 doesn't explicitly discourage you from supporting these, and OpenSSL is a stamp collector's library, if a cipher exists and you can implement it, why not? So you get this unwieldy list nobody actually needs, and then apps present it to non-experts like "Pick from this list or be doomed".
You can get advice on how to configure web servers from Mozilla, https://ssl-config.mozilla.org/
For other types of TLS server you should seek advice from experts in the appropriate protocol.
In TLS 1.3 they learned from this mistake and discourage cryptographic nationalism, you have a literal handful of choices, all of them are currently believed to be safe, some are likely poor (slow, power hungry) choices on simple hardware, some would be weak if large quantum computers were actually cheap and readily available, rather than horribly expensive and non-existent. So "I don't care, whatever" is thus safe in TLS 1.3 although presumably OpenSSL still expects you to actually pick anyway.
By supporting older protocols on sites, we're enabling this kind of abuse to run rampant. Maybe it's best to just cut them off.
In the end they just get replaced with something worse.
e.g. I think that Google offering censored search in China is a lesser evil than Baidu, which is not only censored, but likely also tracks and reports all your searches to the government
Although note that I did see a drop of ~2%-3% in traffic after that. I don't directly make any money of these websites (just my personal blog and similar) and most of my viewers are likely to be technical (i.e. not using IE which doesn't support 1.3), so I decided the sacrifice was worth it for another small reduction in needed sysadmin thought+work.
Wrote some thoughts on why here https://blog.nyman.re/2021/02/07/usability-security.html but in short, it's several magnitudes more likely someone will want to check out my blog using a old device vs someone trying to exploit vulnerabilities in the old protocols.
Google.com still allows TLS1.0/1.1 https://www.ssllabs.com/ssltest/analyze.html?d=google.com&s=...
It seems it's a last name of an author and not just the arch nemesis of Sherlock Holmes. ;)
The mailing list archives also say that someone raised a concern at a meeting, which is why the later drafts were named -deprecate. (https://www.mail-archive.com/tls@ietf.org/msg09563.html)
So I'm not actually sure if this RFC is using it in the correct way, or the incorrect way.
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.
Without this RFC, inevitably a bureaucrat in some organisation is going to argue that the shiny 2021 project to implement Protocol X must offer the horribly obsolete TLS 1.0 or a 3DES ciphersuite because it says so in this document written in 2010 and surely if that wasn't important it wouldn't say that.
This RFC means you get to say no, see, that document you're pointing at has been updated by this newer document which says I can use TLS 1.2 and AES-128 instead as I was planning to before this stupid Zoom call I'm in now.
> to withdraw official support for
Regardless i think you're splitting hairs in the definition.
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...
And the article is about recommending against its use.
The mission of the IETF is to produce high quality, relevant
technical and engineering documents that influence the way people
design, use, and manage the Internet in such a way as to make the
Internet work better. These documents include protocol standards,
best current practices, and informational documents of various kinds.This RFC is labeled "Best Current Practice".
What else is "discouraging use of" if not publishing a document that asserts that the best current practice is to not use it?
If you want the TLS 1.0 protocol specification, they still provide it in the same place as before, https://datatracker.ietf.org/doc/rfc2246/
(Just a suggestion, but hey, at least they use DNSSEC)
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).
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...
How does it change the "security" of a site I might visit?
Further, DNSSEC does nothing to protect data along the network path between you and 8.8.8.8 (or NextDNS or whatever). It collapses down to a single "trust me I checked" bit in the DNS header.
If you're worried about someone tampering with 8.8.8.8, a more reasonable approach is to run your own recursive resolver off-net and use DoH to query it.
Not that anyone except me should care, but this beats any recursive resolver in terms of speed, produces less DNS traffic over the network, can eliminate ads/tracking, increases "privacy"^1 and allows for resiliance against other peoples' DNS problems. I have seen people complain they could not reach some website because of some DNS problem; meanwhile I had no problems because I am not making DNS queries over the network every time a re-visit the site.
Why do this? The story is that many years ago I was running a copy of the root zone served over the loopback. Gradually I started adding A records to it for sites I used often. IIRC I think .mil used to have some A RRs in their zone file that were for websites not nameservers. This technique reduces the number of queries needed to resolve those names. Faster lookups. That might be where I got the idea, otherwise I was just experimenting. I got obsessed with faster lookups, fewer queries. Over the years the local DNS setup I use became more complex and I started running multiple authoritative servers over the loopback, but the technique is essentially the same. Gather DNS data in bulk, save it and serve it. It works for me.
1. One property of this is that DNS lookups are not done at the same time as the user accesses the resource, e.g., a website or whatever. Thus, FWIW, a network observer cannot make easy inferences about what reources a user is accessing, e.g., via a shared IP at a CDN, simply by looking at DNS queries.
For recreational web use, like reading HN and sites posted here, I use a text-only browser and a forward proxy that strips unnecessary headers and does not send SNI except when required. Obsessive minimalist. For serious, non-recreational web use I still have to use a bloated graphical browser and ISP DNS just like everyone else.
It is probably inviting DVs and negative, snarky comments to share this in this thread, but there you go.
Scummy DNS providers like commercial ISPs tend to hijack certain DNS queries for their own gain. With DNSSEC they cannot do so.
Furthermore, with the slow but soon irreversible switch over to DNS over HTTPS, with all the DNS centralisation it brings, knowing for sure that nobody tampered with DNS records is a necessity.
Additionally, DNS records are also used in technologies like encrypted eSNI headers. If you are able to supply bad or old eSNI data to another site's cache, that might cause slowdowns or even breakages when eSNI or its successor eventually rolls out. Alternative PKI solutions also store TLS public keys in DNS records, so those are essential to get right as well.
Sure, but at what cost? It's hilariously easy to misconfigure effictively removing the entire domain from anyone who decides to enfirce DNSSEC validation, and DNSSEC gives you no choice in who to trust (Verisign own .com I think, state governments tend to own a lot of the national TLDs etc.)
If your threat is a poisoned DNS cache then... don't use a DNS cache?
> Scummy DNS providers like commercial ISPs tend to hijack certain DNS queries for their own gain. With DNSSEC they cannot do so.
The problem here is that as an end user, I want to resolve gmail.com to the correct endpoint. If my upstream DNS cache is giving me the wrong results, DNSSEC doesn't help me - NXDOMAIN'ing a valid DNS request leaves me in the same position as without DNSSEC. I still can't get my email!
In the face of a malicious upstream handing out the wrong DNS records, a far more sensible solution is to bypass that upstream, optionally encryping the transport so that they can't fiddle with the results in-flight. This actually gets me what I need - the correct DNS record for my request.
> Furthermore, with the slow but soon irreversible switch over to DNS over HTTPS, with all the DNS centralisation it brings, knowing for sure that nobody tampered with DNS records is a necessity.
> Additionally, DNS records are also used in technologies like encrypted eSNI headers. If you are able to supply bad or old eSNI data to another site's cache, that might cause slowdowns or even breakages when eSNI or its successor eventually rolls out. Alternative PKI solutions also store TLS public keys in DNS records, so those are essential to get right as well.
If you care strongly about the integrity of your DNS records, there are better solutions. DNS-over-TLS/HTTPS should in theory let you trust only the owner of the authoritative DNS server, if you can make a direct connection to it to ask questions. DNSSEC forces me to trust a whole load of intermediaries forever. I'm not sure why the latter is better.
Maybe it's better to stop designing things for which the security rests on being able to fully trust DNS? Gmail (and everything else etc.) seems to work quite well right now without depending on DNS being 100% trustworthy, mostly because if I do somehow get an evil-controlled DNS record back, my browser's going to start sounding alarm bells when the TLS cert doesn't work.
People have a lot of funny ideas about what problems DNSSEC solves. This is demonstrably not one of them.
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.
Isn't DNS already implicitly trusted?
Control over RR data belongs to the person publishing it and she is free to distribute it however she likes, e.g., using ICANN DNS to list the IP address of her authoritative DNS server(s). If she chooses ICANN DNS, the ICANN-approved TLD registry and the entity that controls ICANN DNS root servers have no control over the content of the RR data (cf. the domainname), e.g., they cannot declare a RR as "false", "invalid", "revoked", etc. DNSSEC gives them this control.
DNSSEC as used in practice requires that the RR data must be signed ("approved") by a third party, e.g., a TLD registry, whose own RR data must in turn must be signed ("approved") by another third party, e.g., ICANN.
DNSSEC was designed for people who get their DNS data second hand, e.g., from a remote cache run by an ISP or some other third party, including "open resolvers" such as Google. That method carries some additional risk, e.g., RR data in the cache may be manipulated, as compared with retrieving the RR data directly, with no third party ISP/Google middleman, from its source: the authoritative server(s) listed by the person publishing her RR data. There are existing solutions for encrypting individual DNS packets (i.e., not streams, not TLS) travelling from the authoritative server to the user, such as DNSCurve. Alas, few authoritative servers are encrypting DNS packets.
The DNS data travelling between authoritative servers and third party DNS providers running caches is, generally, not secured. I never see any discussion of this online.
In practice everyone finds the designated authoritative servers through the root servers and TLD servers. They're trusted already.
Yes, DNS becomes a CA in schemes such as DANE, but a CA that the domain administrator controls. I don't see any problem with that. We've been spoiled by Let's Encrypt by now, but free, easy TLS certificates and management for even small businesses are a very recent thing.
I much prefer the decentralised nature of DANE over current CAs, even from parties like Let's Encrypt. LE is still an American company and the USA has been proven to be all but transparent and friendly to its allies when it comes to using their power over digital infrastructure for their gains. I am 100% sure that if LE receives a red security letter instructing them to generate a certificate for a certain domain, they will, just like any CA would, before that CA would collapse as soon as anyone finds out. My bank's website security depends on nobody on the other side of the Atlantic getting any funky ideas.
The decentralised nature of DANE makes it a nice system because worst case scenario, some TLDs do not get signatures during the next key rollover. This would be immediately obvious to any observer, so actions like these cannot be done in secret.
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.
IPv6 not so much.
Also, TLS 1.3 is an application protocol, so you only need the server and client to support it. You don't need an OS change for either server or client; although if you rely on TLS libraries shipped with the OS, you would. You also don't need network support, although if your network is particularly hostile, it could cause issues.