Ask both sides to confirm a fingerprint to avoid MITM attacks

[fgaz]

Is your feature request related to a problem? Please describe.

It's good that Dayon! is e2e-encrypted, but as far as I can see it's still susceptible to MITM attacks.

Describe the solution you'd like

When the assisted connects to the assistant, a fingerprint is shown on both sides, and the two parties have to confirm a match via phone/message/other channel. This could happen on every connection or the certificate could be trusted on first use. Short Authentication Strings could be used for easier verification.

Describe alternatives you've considered

• Certificate authorities: I assume the assistant opens the port temporarily and without a domain name, so trusting only CAs is not doable
• Use the rendez-vous server: the assistant sends its public key to the server, and the assisted retrieves it together with ip and port
  • Would make unmediated (ip+port) connections impossible
  • If the server is compromised, MITM is still possible

Additional context

[RetGal]

First of all, thank you for your valuable input!

Since both sides (assistant and assistant) use the same certificate, fingerprint matching can even be automated. So I implemented these checks and added warnings in case of a mismatch:

[RetGal]

Implemented and available in version 12.0.0 (Adorable Asteroid)

[fgaz]

Thanks for the quick fix!

Unfortunately, while this is an improvement, I think MITM is still possible.

Dayon! uses TLSv3 which mandates forward secrecy, so at least the connection is protected against generic MITM attacks from attackers that don't know that Dayon! uses a static TLS key. On the other hand, it isn't protected against targeted attacks or generic attacks by attackers that have scraped the key (and GitHub is heavily scraped for keys).

To have true protections against MITM, I think Dayon! needs to generate new keys on each machine it is installed on, or even on each start if TOFU isn't used, in addition to confirming the certificate like I wrote in OP.

Disclaimer: I'm not a cryptographer, so this might be all wrong.

[fgaz]

Could you reopen the issue?

[RetGal]

While I get your point, there are a few things that also need to be considered:

• Programmatically generating X509 certificates with Java is not possible without the help of external libraries - which are quite bloated.
• X509 certificates used by Java apps are stored in a keystore and therefore cannot be scraped automatically as easily.
• Dayon! shall remain as accessible as possible, especially for people not too savvy with "computers". Accessible in the sense of "easy to use" of course :)

[fgaz]

In my opinion while ease of use (and development) is a noble goal it shouldn't compromise security, especially in this kind of application. There might be a way to achieve both though!

I looked a bit more into TLS, and as far as I can see the cert key is used for two things as far as Dayon! is concerned:

• Secure negotiation of encryption settings, preventing downgrade attacks. This shouldn't be a problem since Dayon! hardcodes TLSv3.
• Authentication, preventing a MITM attack where the connection is encrypted, but not between who you expect it to be. Even if the cert is public, when ephemeral Diffie-Hellman is used (mandatory in TLSv3), I think authentication can still be achieved by verifying via phone that a cryptographic hash of the master secret matches.

So I propose the following: when a connection is established, Dayon! should show a message such as "If the following string is the same on the two computers, the connection is secure: \<hash of master secret here>" (or more accurately, "If the string is different, the connection is NOT secure").

Again, I'm not a cryptographer, but surely this can't be less secure than no authentication at all!

[RetGal]

@fgaz In the meantime I have had several discussions with security experts. The conclusion is that this type of technically complex MITM attack could only be mitigated if each instance of the program uses unique certificates. To do this, they would have to be generated during installation or when the app is started.

As of Java 17 there is no way to compute certificates programmatically there would be two options:

• generate the certificates using the keytool binary, which is part of each JRE
• add third party libraries like Bouncy Castle

Both approaches come with rather weighty disadvantages: calling an external binary increases the attack surface significantly and feels to be a rather hacky solution - while adding Bouncy Castle would double the jar size.

So for now, I would recommend people who fear they may be the target of sophisticated MITM attacks by forces that can intercept and manipulate their internet traffic, to look for another remote assistance solution.

This does not mean, that the use of Dayon! is insecure! The traffic between the assisted and the assistant is always being encrypted. There is just the residual risk, that a force capable of intercept your individual traffic, could, with a lot of effort, decrypt and re-encrypt the transmitted data. But as long as Dayon!'s user base doesn't grow into the millions, this scenario will probably remain theoretical. It also doesn't mean that I consider security secondary. As soon as there is a more practical way to implement individual certificate generation, it will be integrated into Dayon!

[fgaz]

Thanks for researching the issue!

calling an external binary increases the attack surface significantly and feels to be a rather hacky solution

To me it doesn't look less secure nor hacky. If an attacker controls keytool they likely can control Dayon! too. The keytool interface looks stable, and Dayon! could fall back (with a warning/notice) to the bundled keypair if keytool fails.

[RetGal]

@fgaz Implemented generation and fingerprinting of individual certificates. Feature will be included in the upcoming release:

[fgaz]

Awesome, thank you!