pcb-rnd knowledge pool
HTTPS vs. tarball signatures
https by Tibor 'Igor2' Palinkas on 2021-01-15 | Tags: insight, https, http, security, encrypt, encryption, crypto, digital, signature, sign |
Abstract: HTTPS is not an ultimate solution to network security. It has its part in the overall picture, but it is very often overestimated because of two factors: users do not really understand how it works and there is a campaign going on to mandate HTTPS and classify any HTTP site "unsafe". These have built up a false sense of security. Security is especially important in case of source downloads. This article compares HTTPS to other means of digital signatures on the source tarballs.
1. Full picture
The diagram on figure 1 shows the full path the code takes from the moment the developer types it to the moment the user runs it. The section where HTTPS on the download web server matters is marked with red.
2. Comparison
The following table shows various points an attacker could manipulate the source code along that data flow, from top to bottom, and shows which method can protect against. The HTTPS column means the case the tarball source download page is protected with HTTPS (but does not affect or assume encryption anywhere else).
HTTPS |
tarball
signature |
happens
at | attack |
---|---|---|---|
no | no | developer | Malicious developer or developer's desktop computer cracked |
no | no |
developer
-> VCS | MITM on commit: the attacker modifies the source code while it is being sent from the developer to the VCS server by manipulating network traffic |
no | no | VCS | VCS server cracked, source code is manipulated on the VCS server |
no | no |
VCS
-> release tarball | The attacker manipulates the source code between the version control server and the software that automatically creates the release tarball. |
no | no |
release
tarball | The attacker manipulates the release tarball creation software, or the release tarball once it is created. This assumes the attacker has cracked the server that is building the release tarballs. |
Note: from this point on, the release tarball is signed in the tarball signature scheme, thus any manipulation will cause verification failure, assuming the user did the verification correctly, using the right cert on the blue graph. | |||
no | yes |
release
tarball -> web server | The attacker manipulates the release tarball between the tarball creation server and the web server. |
no | yes |
release
web server | The attacker cracks the web server and manipulates any file offered for download: including the tarballs, checksums and signatures. |
yes 1 | yes |
web
server -> internet -> download system | The attacker sits between the web server and the system used for downloading the tarball, captures and manipulates network traffic real-time. |
no | yes |
download
system | The attacker cracked the system the user is using for the download; the attacker can manipulate the downloaded file, the web browser used for the download, the CAs, etc. |
no | yes |
user's
internal distribution | An attacker on the LAN (including local WiFi, local shared resources such as NAS or other shared remote file system), being able to manipulate the tarball before it is deployed on the target system(s). |
no | no |
compile
and run | The attacker cracked the system where the code is compiled and/or ran. The attacker can manipulate the tarball or the unpacked source code or the compiler. |
-
1
There are a lot of places where this can go wrong. Most users
blindly trust the dozens or hundreds of root CAs installed with their system,
while there are examples of attacks performed using corrupt CAs. In fact
some users will even click their way through adding an exception, accepting
self signed certs or broken certs, still believing HTTPS will protect them.
There is an additional privacy issue where HTTPS performs better: if the attacker does not try to manipulate the download but merely wants to collect data on which computer downloaded the tarball at what time. The tarball signature method does not protect against such sniffing.
Assuming both the HTTPS path and the tarball signature method are used correctly, the tarball signature method provides protection for a significantly longer part of the data flow.
The hardest part is PKI (public key infrastructure): how the user acquires the public key (cert) to verify the signature. This does happen in both the HTTPS and the tarball signature workflows, and it does involve 3rd party servers in both cases. HTTPS seems to be easier to use because of the browser integration, but this is often only false sense of security because of users don't verify the process or the 3rd party cert providers. In case of the tarball signature, the user is forced to manually verify all these which means the user needs to understand how the system works. This reduces false sense of security in favor of promoting real user awareness. This method also reduces the number of 3rd party participants on the PKI, potentially allowing more users to audit the process and certs more easily.
Thus for higher security it is more important to have the tarballs signed than to use HTTPS on the transfer.
3. Tarball signature limitations
While the tarball signature method provides protection for the tarball for a longer section of the workflow, there are still parts of the workflow not covered by it. These can be divided into two groups.
3.1. Pre-tarball attacks
Most of these attacks assume the code can be manipulated in the VCS system without the developers noticing it. This could be performed either by cracking the VCS server or by cracking a developer's workstation or by MITM attacking the network traffic between developers and the VCS.
A reasonable protection against this is that developers follow code modifications happening in the VCS and would notice such attack.
A much higher risk on this side is a malicious developer. At the end, the whole process depends on the user trusting the actual developer who wrote the code. All the advanced digital signature system is in place for two reasons:
- to ensure a 3rd party attacker did not modify the code during network transfer
- to ensure the code is really from the author and not from someone else impersonating the author
However, after ensured both, if it's the developer himself who is the attacker, the user will download and run the malicious code. In theory the user could audit the source code before compiling, but with project size modern software has it is practically impossible.
Since there is really no way for users to ensure the developer is not the attacker, the only reason the user still downloads and uses the software is some sort of initial trust in the developer. It is very important to understand that this initial trust is rarely backed up with actual evidence (e.g. code audit) and most that any digital signature system can do to this is to ensure if the user once trusted a developer(s), further downloads are coming from the same developer(s).
Which means if there is that initial trust towards the developer(s), the same trust can be applied to the developer(s) detecting and undoing 3rd party attackers unwanted modifications to the VCS system.
3.2. Attack on automated tarball creation
A reliable release system needs automation. On repo.hu we have the release tarball build and publish processes automated. This means the only place where the tarball can be signed is the server marked as "release tarball" in the workflow diagram. This server needs to have the private key for the signature. This server is on-line. It is possible that an attacker cracks this server, in which case the attacker acquires the private key and can sign any manipulated tarball version.
The only way to exclude this situation, effectively transforming this risk back to a 3.1. risk is if the developer(s) did the tarball packaging and signing on their developer systems. Or better yet, the signing would happen on an off-line computer, the only one place where the private key would be stored.
However, that would kill automation. At the moment manual steps in the release process seems a higher risk than an attacker acquiring control over the tarball build server.