27

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.

2
  • 15
    Disabling TLS because of a warning regarding deprecated protocols is like amputating your leg because you stubbed your toe. It is a solution, but not a good one.
    – user163495
    May 10 at 21:37
  • 1
    If a site is accessed insecurely, be sure to disable executable content such as Javascript! May 12 at 12:20

5 Answers 5

29

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?

14
  • 15
    If the person hosting the site cannot be bothered perform an essential security upgrade, I doubt that they’d be willing or able to provide the correct checksum. But i take your point, and it’s good advice.
    – EJ Mak
    May 10 at 23:05
  • 3
    Would down loading the file from two different devices on 2 different networks and then comparing the checksums of those be a good way to ensure no MitM attack had occurred?
    – Sam Dean
    May 11 at 8:59
  • 4
    @SamDean, no, that only avoids MitM attackers on your network. It's less likely to happen, but other MitM attackers might be on the server's network and intercept all of your downloads anyway.
    – lenin
    May 11 at 10:13
  • 23
    I'd like to add that "the known correct checksum" must be obtained from a trusted and verified source, not from the same site already prone to MitM attack.
    – lenin
    May 11 at 10:15
  • 3
    @SamDean That's a very interesting suggestion (+1). It basically relies on the assumption that an attacker would not be able to MITM two different paths between the client and the server. This is the same assumption that systems like perspectives and convergence rely on. See security.stackexchange.com/questions/84162/… for more info.
    – mti2935
    May 11 at 12:23
10

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.

4
  • 11
    To view this comment, please download and run Flash Plugin 14.5.6.7.8.9rev114.
    – user163495
    May 11 at 0:26
  • 2
    @MechMK1 That link didn't go where I thought it would
    – nobody
    May 11 at 7:37
  • 4
    @nobody ... we're no strangers to love, you know the rules, and so do I ...
    – Matthew
    May 11 at 12:53
  • 1
    @nobody Awww, the url shortener has broken. It should have gone to this
    – user163495
    May 11 at 13:01
9

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.

1
  • 1
    True fact. That oversight still happens in the wild though. PWN'd a embedded device via that way recently. Command injection in downloading the firmware update by messing with the downloaded filename.
    – masterX244
    May 11 at 12:22
8

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.

2
  • In this case, the file to be downloaded is software, authored by the person who owns the site.
    – EJ Mak
    May 11 at 12:13
  • @EJMak good. Even better if the software is signed or you have the checksum. See also the p.s. in my answer.
    – fraxinus
    May 11 at 12:19
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.

  1. 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.