Is it safe to ignore/override TLS warnings if user doesn't enter passwords or other data?

Question

A user is trying to access a poorly maintained website using a modern OS (Windows 10) and web browser (Firefox 100.0). They want to download something from there, but they are seeing a security warning indicating that the host is using a deprecated TLS protocol version and/or has an issue with its certificate. The user been in touch with the person who owns the domain and downloadable content, and this person is being slow to get it fixed.

Questions:

1. Can the user (re-)enable old TLS protocol versions for this site in Firefox (security.tls.version.enable-deprecated = FALSE), and safely browse & download content as long as they avoid entering data such as credit card numbers, passwords, etc.?
2. Or does simply browsing a site using old TLS versions itself carry inherent risks?
3. If the latter, is there a way for them to reasonably mitigate these risks? (By reasonable, I mean without configuring network/firewall settings, using a container, etc.)

They are considering firing up an old Windows XP computer running an also-old Internet Explorer, which I'm open to letting them do, as long as they don't share their data on the network and take the device offline as soon as they are done. LMK if you can think of any reasons why this would be a bad idea.

I looked for answers on Firefox forums, this forum, and via a general web search, but I didn't find anything useful.

Answer 1

Of course the site should upgrade its TLS setup. But, until the site owner does that, the user that needs to download the file from the site must look for a workaround.

The user can proceed to download the file - either by using http instead of https if the site allows it, or ignoring the browser's TLS / certificate warnings and proceeding anyway, or by using an older operating system from the same vintage as the site's TLS setup, or by using a command line tool such as curl or wget, or another method. But, as others have mentioned, a man in the middle (MITM) would be in a position to impersonate the site, and serve the user a malicious file instead of the true and correct file.

To mitigate this problem, the user would be well advised to verify the integrity of the file, by taking a checksum hash of the file after downloading it, and ensuring that it matches the known correct checksum for the file.

---

Related:

Are downloads from http connections safe?

ubuntu sources.list urls are not HTTPS -- what risk does this present, if any?

Answer 2

You need TLS, no excuses.

Even if the user isn't sending anything confidential to the site, they are downloading from it. Any attacker in the position to perform a MitM attack will be able to change any resource from the site and the clients cannot detect the attack.

What kinds of resources? For example, the attacker may replace every page with a message "This site needs Flash Plugin 14.5.6.7.8.9rev114 to run, click here to download." and most users will happily download the file.

The attacker can download the entire traffic and get all files downloaded by the users. The attacker can redirect users to another site, can backdoor any file.

Today, TLS certificates are free, easy to install, and even automated. Let's Encrypt for example is one of those.

Answer 3

Yes, you need TLS for read only websites. Because otherwise a rogue WiFi hotspot can serve whatever content it wants on your domain and the user has no way to know it's not authentic. Also, browsers disable features on non-secure websites and display increasingly scary warnings about the website being insecure. So just set up let's encrypt with automatic renewal.

Answer 4

It depends on the stakes involved.

The broken TLS will not, by itself, damage the browser, the downloading computer and the file.

If the file is "look how funny my dog jumps" video and the computer where the user downloads and uses it is not of a national security importance and uses a wired connection to a reputable ISP, then - maybe ok.

What could go wrong, then?

• One could forget to return the browser settings to their secure defaults. This can backfire the next time when a TLS downgrade-type attack is performed on some other site.

• A poorly maintained website is probably poorly maintained in many aspects. It may as well be already controlled by malicious parties, because the owner lagged not only with TLS certificate renewal, but with the security updates as well. The site may be already serving malware.

An updated browser running on an updated OS should be immune to most circulating exploits, but a matter of life is that new security vulnerabilities are discovered all the time.

Then again, the file will be opened with some other software, generally different from your browser. Is this software (e.g. a spreadsheet program or a video player) up to date as well?

---

p.s. If the certificate is ONLY expired ("not valid after" some past date) and not of some deprecated, vulnerable type - chances are that everything else is OK.

Answer 5

There are, to my knowledge, 2 risks of connecting to a site without TLS, both of which have been mentioned in some ways, but I wanted to give my own spin on them:

1. Safety.

The potential for man-in-the-middle attacks mean that any executable code downloaded from the site is suspect. Do not trust any binaries unless and until you can verify their safety independently.

There are two ways that I know of: by hashing the file and comparing it to a hash delivered over TLS or some other, secure channel, and by uploading it to a site like VirusTotal that scans it with a bunch of malware scanners. Neither approach is flawless; malware can still hide in there, but they greatly mitigate the risk. If you're in a high-stakes situation or have any additional reason to suspect the file, confining it to a sandbox (e.g., a virtual machine) is a good idea.

If you're just downloading file that you will treat as plain text, it's not really a risk, but do beware of media files that could exploit vulnerabilities in a player program. As fraxinus helpfully mentioned, the site itself can try to exploit browser vulnerabilities (JavaScript or otherwise). Of course, the file can also simply contain bogus data; if it's a financial report, don't trust the numbers.

All of these things can also occur even with TLS enabled if a site is compromised by a malicious actor, so TLS is not a guarantee of safety, anyway. This is why we put digital signatures on binaries... although build servers and dependency chains can be compromised as well. No security is perfect, but we reduce risks where we can.

2. Privacy.

TLS encrypts the traffic. Without that, as you've correctly identified, any passwords you send aren't secret. In addition to that, Internet Service Providers at the very least can trivially identify what is being transferred to you, including your ISP, the host's, and any others involved in the connection between you and the host. Other actors on your local network and on the host's network may even be able to see the traffic, depending on the network setup. If there is any reason you don't want the whole world knowing what specific page you are visiting and what specific files you are downloading, you must not connect without TLS. Even with encryption, law enforcement agencies can generally get logs from a host, but ISPs, criminals, and private investigators cannot so easily get ahold of them.