Why use HTTPS in the DP-3T Protocol?

Question

I'm having a discussion about transparency of the HTTPS protocol over a specific COVID-19 detection app. The opponents maintain that using HTTPS is obfuscating the app, that the app should behave transparently and send all the traffic over HTTP so they can see what they are sending, because the data is "anonymous" anyway.

After some investigation I found out that this part is following strictly DP-3T protocol, which states that "The app opens an encrypted TLS connection to the server and sends the authorization code[...]". I know for sure that they didn't read the whole protocol (neither did I, just some parts of it), but even with this in mind, they keep saying there is no reason not to start using plain HTTP by removing HTTPS. They go further and state that if it appears in the protocol, then it is badly designed.

So what would be the reasons to use HTTPS in an anonymous protocol such as DP-3T?

Answer 1

TLS connections have 3 important, distinct properties:

• privacy, i.e. protection against eavesdropping
• authentication, to make sure the parties communicating are really who they pretend to be
• integrity, meaning the data cannot be modified during transmission

It seems your opponents argue only against the first one, but the other two are critical for most applications. For DP-3T in particular, lack of authentication would mean an attacker could intercept a transmission and drop it while the application would think the code has been transmitted successfully.

And more generally, TLS nowadays is cheap and easy to setup. You would need a very good reason not to use it rather than one to use it. In fact, at least for iOS, it is explicitly required that an app uses transport security, and exceptions must be justified.

Answer 2

Along with cybercriminals willing to do wiretapping over wireless networks, today's complicated networks typically carry a great number of different surveillance middleboxes for different purposes. Those devices not only eavesdrop, but can sometimes modify the transmitted data in arbitrary ways, intentionally or unintentionally.

E.g. a DPI equipment installed by an ISP can be set up to replace the Web site advertisement with the ISP's ads. If configured in a wrong way, this equipment would then also replace unrelated parts of Javascript or XML code in the data streams transmitted by mobile apps or Web sites.

This is just one example.

Therefore, the contemporary threat model for Web sites and mobile apps just assumes encrypted HTTPS as transport. HTTPS is rather easy to set up these days, it comes for free and eliminates such a great number of opaque and complex threats and potential bugs that it's easier and much more reliable — from the operational standpoint — to set it up than to not.

Answer 3

The opponents maintain that using HTTPS is obfuscating the app, that the app should behave transparently and send all the traffic over HTTP so they can see what they are sending, because the data is "anonymous" anyway.

I'm going to assume the boldfaced "they" refers to the end user, and not to the developers (because if it does refer to the developers, then this is a straightforward problem of not using appropriate debugging techniques such as server-side logging).

Realistically, how many of your end users are going to be running Wireshark or a similar piece of software? Of those that are technically proficient enough to run Wireshark, how many are seriously going to find HTTPS traffic suspicious? It's quite possibly the second most popular (layer 7) protocol in the world (after SMTP, I would tend to imagine), and as you say, the DP-3T protocol explicitly requires its use. Anyone who would find it suspicious is unlikely to know enough about networking technology to use Wireshark in the first place. In my opinion, the use of unsecured HTTP is more likely to provoke suspicion than the use of HTTPS.

On the other hand, it's quite possible to hide data in unencrypted network streams using any number of different forms of steganography (in this case, by hiding some data in the purportedly "random" ephemeral IDs that are used by DP-3T, and/or in the secret key when it gets uploaded for an infection report; both of those are opaque blobs of binary data with no meaningful structure for the user to introspect). So the fact that the technical end user is capable of monitoring your app's traffic doesn't actually help all that much with trust anyway.

In any event, we can clearly see that:

• This doesn't convince non-technical users of anything.
• It's unlikely to be effective in convincing technical users that your app is safe, and might convince them that your app is unsafe or at least poorly-designed.
• As described in multiple other answers, TLS does other things besides confidentiality, and that may compromise the security of your implementation in other ways.

Answer 4

In addition to the excellent points made in the other answers, encrypting only data where privacy is of concern tells adversaries that this is data where privacy is of concern, and allows them to focus their efforts on decrypting this data.

In other words, even if privacy is your only concern, you should encrypt everything so that adversaries don’t know where to look. That means using HTTPS, rather than HTTP, where applicable.

Here is a reference I found. Even though it is about different protocols, the basic idea is the same. E-mail Self-Defense:

The more you can encrypt your messages, the better. If you only encrypt emails occasionally, each encrypted message could raise a red flag for surveillance systems. If all or most of your email is encrypted, people doing surveillance won't know where to start.