Just to make it clear: this does not mean that it is fine to blindly accept the message on first use.
The "secure way" implies copying the server's public key as well, which people generally don't do, right? Which is equivalent to verifying the fingerprint shown with the TOFU message, correct?
Like I have said the secure way requires the secure copying of both keys before the first connection attempt
The server public key must be copied into "known_hosts" on the client, while the client public key must be copied into "authorized_keys" on the server.
When this is the procedure that is always followed, any message shown by SSH about an unknown host means that the connection must be aborted, because the identity of the server is unknown.
You cannot truly verify the "fingerprint" displayed by SSH, unless you simultaneously have access to another computer, where you have a copy of the fingerprint. What is usually meant by "verifying" is that you remember a few digits of the fingerprint, and those match.
You could have copied the fingerprint from the server, to be able to truly verify it, but that does not make sense, because in that case you should have copied the entire key, not just the fingerprint, and you should have installed it in the client.
When you use only authentication with digital signatures, it does not make sense to use any other procedure, because you must make at least one of the two copies anyway, so when copying the client key to the server you can take the server key, to carry it back to the client.
The TOFU method is meant to be used together with password-based authentication, in less secure applications, where no physical access to the server is required for setting up SSH on the client.
By "less secure" I mean for example applications equivalent to HTTPS, where the client is not really authenticated, e.g. when providing a public password allowing read-only access to an SSH server through Internet.
Sure, I just wanted to make sure that nobody would understand "TOFU is neither necessary nor recommended, just ignore that message and say "yes" when it appears".
Both ends need to be sure of who is on the other end, and there are different ways to achieve that. The way SSH works is that if you haven't copied the server public key locally, it will explicitly ask you to verify it the first time.
I am not sure that "SSH does TOFU". SSH asks you to verify. The human who YOLOs it and approves it without checking is the one doing TOFU, and this is not really secure.
That's a big if, though. Solar and batteries require globalisation, based on fossil fuels.
I feel like nuclear reactors are a better choice.
> in a conflict, not sure having many around is generally a good idea
On the other hand, blowing nuclear reactors could be considered a big escalation. We see with Iran and Ukraine that it's not exactly the first thing one wants to target.
My point was that photovoltaic is "an alternative" to nuclear reactors, but an alternative that relies on globalisation. Nuclear reactors... much less.
1. The US becoming relatively hostile even to countries that considered themselves allies means that being totally dependent on US monopolies (the TooBigTech crew) is a problem. So the first level is "it's important to reduce the dependency to US services". Doesn't matter if it's in the EU, Canada or Mexico.
2. When you start caring about digital sovereignty, or course it's better if you can depend on national services. But that's often not possible. The next best thing is to rely on allies, and diversify the risk.
So it's a gradient. What has taken off is "we need to care about digital sovereignty" and "the US has already used their monopolies against us, we need to do something about it". I think.
Hmm, I am not completely sure what the website is trying to say (there is soooo much text and it's quite unreadable). But it feels like it says "it is hosted on US servers, so it's baaaaad".
The thing is, it seems to be end-to-end encrypted with MLS, which means that the servers cannot decrypt the conversations. Probably some metadata are leaking (which IP is in a call with which other IP), but that's a different threat model. Metadata is always a harder problem.
Now I don't know if Proton knows which users are together in a call, or if it's just leaking IPs. Maybe the article says it, but I didn't have time to decrypt it :-).
I think the argument is that when you load a webpage, you download the code everytime you want to run it, from servers owned by the company building the service. So they can choose to serve you different software (e.g. with a backdoor), just this one time and just for you, and you won't know (not that it would be impossible, but it is generally impossible in practice).
When you download a program on Linux through the distro package manager, you download it once and run this, every time. You know very well when it gets updated. You can compare the hash of your program/package with the one distributed by the distro, and the distro is not the developer of the program (so there is another layer there). You can audit that code (if open source), and at the very least you can compare with others to see if they receive the same code. And again, the program is served by the distro, not by the developer. The backdoor situation would require asking the developer to implement a backdoor, and then asking the distro to server you a different executable, and then hoping that you never, ever check the hash of that program that you own offline. It's a lot harder.
In a way, for ProtonMail (in your browser) to be "end-to-end encrypted", you have to trust Proton. But that kind of defeats the purpose of end-to-end encryption.
Same applies to e.g. WhatsApp Web, which is an interesting example because there exists a browser extension allowing you to "validate" that you run the code Meta expects you to run. Though you still have to trust Meta: the extension only helps making sure that nobody other than Meta is abusing you. The WhatsApp mobile app doesn't have that problem, as it is distributed as an archive by a third party (Play Store).
> In a way, for ProtonMail (in your browser) to be "end-to-end encrypted", you have to trust Proton. But that kind of defeats the purpose of end-to-end encryption.
Yes, and every VPN in the world (that isn't self-hosted) relies on trust that they won't share your info, not even your fingerprint - which defeats the purpose of VPNs. It's very hard to have perfect security. OK, impossible.
Sure, it's always a tradeoff. There is no "perfect" security, but there is "better" and "worse" for the threat model.
My point here is that when you run a webapp from a browser, you have to trust the server. When you run a program that you download on your system, it's easier to check that it doesn't change and to make sure that others get the same one.
Exactly, as with all security you have to ask what the threat model you're defending against is and what you're willing to pay.
If it's "Google knows too much and I want an alternative" Proton is great, cheap, and convienent. If it' "my own government might kill me" then it might be time to think about self hosting.
> "Google knows too much and I want an alternative" Proton is great, cheap, and convienent.
I think that Proton does a good job with the suite (docs, sheets, calendar, password manager), and I believe they have a good VPN (for what we may expect from a VPN).
Interestingly, Proton started with ProtonMail, and I find it's the least convincing of their products:
1. As an individual, writing from your ProtonMail account to (probably) someone on GMail doesn't change anything.
2. As a company, writing from Proton to Proton is a good idea, but there is no need for end-to-end encryption: just choose a mail provider you trust, I guess?
3. The ProtonMail end-to-end encryption in the web browser defeats the purpose of E2EE: you have to trust Proton anyway, because they serve the code every time your employees load the page.
Yeah, well, that's how capitalism was meant to work, but mostly seems to have been implemented with various thumbs on scales (which is also true for most of the -isms).
Feels kinda like the thumbs on the scales resulted in the (d)evolution towards techno-feudalism.
For a specific group of people in the world anything but "USA nr1" is hard to image, I understand. Can the nuanced take be: Europe does it better sometimes? Not the best slogan but you're not in marketing
For mail, the answer is to own your domain. If you move away from (probably) Gmail, you don't want to lock yourself into an @proton.me. Get your domain, and use whatever provider you want (it can be Proton, but there are many others).
Even for own domain, what are the risks of choosing a .com domain and US based registrar if your country can potentially be hit by sanctions or your registrar tends to develop a sudden surge of misplaced morality.
reply