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

node source

 

 

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.

full data flow diagram from developer to user

Figure 1. Data flow from developer to user

The process starts with the developer typing the code and committing it into a VCS (version control system, e.g. an svn server). Eventually from the VCS a snapshot is packaged as the release tarball and is published on the web server . Users download the tarball to a local system through the internet . In some cases the user then takes the downloaded file and locally distributes it onto multiple workstations where the code is finally run upon.

The left side key distribution graph (blue) shows where the release tarball is signed and where the signature is verified; the right side key distribution graph (dark green) shows where the keys for HTTPS signs the download and where that signature is verified.

It is important to note that attackers can potentially target any part of this flow. Furthermore a reasonable attacker will always attack the section that is easiest to manipulate.

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.
Notes:

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:

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.