Closed fgaz closed 10 months ago
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:
Implemented and available in version 12.0.0 (Adorable Asteroid)
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.
Could you reopen the issue?
While I get your point, there are a few things that also need to be considered:
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:
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!
@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:
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!
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.
@fgaz
Implemented generation and fingerprinting of individual certificates.
Feature will be included in the upcoming release:
Awesome, thank you!
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
Additional context