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.

sleske
  • 1,622
  • 12
  • 22
EJ Mak
  • 381
  • 3
  • 6
  • 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. –  May 10 '22 at 21:37
  • 1
    If a site is accessed insecurely, be sure to disable executable content such as Javascript! – Toby Speight May 12 '22 at 12:20

5 Answers5

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?

mti2935
  • 19,868
  • 2
  • 45
  • 64
  • 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 '22 at 23:05
  • 2
    @EJMak, I agree, it might be a tall order. But, taking checksum hash of of the file would likely be much simpler to do than upgrading the site's TLS setup, especially if the site is running on an older system. Also, you mentioned in the question that the user is in contact with the owner of the site, so perhaps it's worth a try. – mti2935 May 10 '22 at 23:40
  • 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 '22 at 08: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 '22 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 '22 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 https://security.stackexchange.com/questions/84162/mitigation-against-mitm-at-starbucks for more info. – mti2935 May 11 '22 at 12:23
  • 2
    Personally, and especially if this is a recurrent need, I'd set up a separate browser profile rather than relying on toggling the option each time and potentially forgetting (in addition to all other mitigations). A shortcut could be configured to launch FF with the right profile and destination `firefox -P NoTLS --private-window www.outdated-site.com` (not really using private mode because it's private mode, but for the easy visual indication that it's not normal mode, and with a profile called NoTLS) – Chris H May 11 '22 at 14:41
  • 1
    @lenin, I agree. The verification checksum would have to be sent through some out-of-band method, such as via phone, SMS, fax, etc - i.e. similar in that regard to [Safety Numbers](https://security.stackexchange.com/questions/139596/signal-protocol-implementations-pub-key-authentication-and-inspectability-all) used in Signal to authenticate other users' public keys. – mti2935 May 11 '22 at 14:42
  • The phrase "checksum hash" should be replaced by "cryptographic hash", since the former is ambiguous but usually means a *non-cryptographic* hash which has no integrity-verifying capability and at best protects you against random line noise. – R.. GitHub STOP HELPING ICE May 11 '22 at 21:21
  • @R..GitHubSTOPHELPINGICE I agree, the terminology around this is confusing. I actually borrowed the term 'checksum hash' from Ubuntu. At https://help.ubuntu.com/community/HowToSHA256SUM, they write, 'Ubuntu distributes the SHA-256 checksum hashes in a file called SHA256SUMS...'. In addition, the fact one of the most widely tools in the linux world for computing sha256 hashes is named **sha256sum** also adds to the the confusion. But, I agree that the term 'checksum' suggests something that is quite different than a cryptographic hash. – mti2935 May 11 '22 at 22:02
  • @ChrisH Setting a different Firefox theme for the alternate profile is another solution; that creates a clear distinction as well. – wizzwizz4 May 12 '22 at 07:58
  • 1
    @wizzwizz4 true, and a visual warning that way could be more obvious. I haven't really played with themes, preferring very much a classic view, and private browsing (which can also be set with `browser.privatebrowsing.autostart` on `about:config`) seems like a close logical match. – Chris H May 12 '22 at 08:13
  • It should be noted: TLS adds trust and encryption. A deprecated TLS certificate renders the connection not (machine-)trusted, but still encrypted. – rexkogitans May 12 '22 at 09:34
  • As Corrodias answer briefly mentions, if the file contains a digital signature, you can verify that instead of generating a checksum. Signatures are used by some package managers to safely transmit programs over HTTP (to allow caching) without compromising integrity – nijave May 13 '22 at 17:51
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.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • 11
    To view this comment, please download and run [**Flash Plugin 14.5.6.7.8.9rev114**](https://shorturl.at/ijmAM). –  May 11 '22 at 00:26
  • 2
    @MechMK1 That link didn't go where I thought it would – nobody May 11 '22 at 07:37
  • 4
    @nobody ... we're no strangers to love, you know the rules, and so do I ... – Matthew May 11 '22 at 12:53
  • 1
    @nobody Awww, the url shortener has broken. It should have gone to [this](https://i.kym-cdn.com/entries/icons/original/000/040/241/anya_heh_thumbnail.jpg) –  May 11 '22 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.

Z.T.
  • 7,768
  • 1
  • 20
  • 35
  • 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 '22 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.

fraxinus
  • 3,425
  • 5
  • 20
  • In this case, the file to be downloaded *is* software, authored by the person who owns the site. – EJ Mak May 11 '22 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 '22 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.

Corrodias
  • 151
  • 2