3 ms·

While this may feel true, there are a few reasons why it's not. 1. This assumes https can be trusted, that is, MITM is not a possibility. This is a fair assump

by tasn 9y ago

While this may feel true, there are a few reasons why it's not. 1. This assumes https can be trusted, that is, MITM is not a possibility. This is a fair assumption for many people, but not for people whore are scared of state actors, which is common for journalists in and citizens of some countries. - This can be mitigated to an extent with certificate pinning, but I don't think all software support it (correctly?) and it's another thing to get wrong. 2. This assumes your server is trusted. It is not. If it's hosted in a remote location (e.g. VPS or even metal in a server farm), it can't be trusted. If it's at your home, based on how much of a target you are, it can't be trusted. Even if your server is physically secure, this assumes it won't be hacked, and you should never assume a public facing server won't be. Of course this all depends on your threat models, and this may not apply to you, but https to your own server is definitely not the same, and given that adding end-to-end is almost "free" for most users, it's a good idea to error on the side of safety and just do it.

Tepix 9y ago
Re: 1. You can deploy additional security measures such as certificate pinning or a VPN tunnel to your CalDAV server if you have a high security requirement. Re: 2. If your server is untrusted (because it's a remote virtual server) or hacked, e2e will not protect you.
- tasn 9y ago
  1. That's exactly what I said, though you are just patching a broken system here, why not just use a system that's resilient to all of this in the first place like with end to end? 2. How so? EteSync for example has a git like integrity verification (just with HMAC instead of hash), so it's easy to check consistency across clients, and the server can't forge anything. The worst the server/MITM can do is stop syncing a specific client which would be easy to detect. A rogue server can't even omit specific changes, only stop sync. So I don't agree with your assertion.

by tasn 9y ago

Tepix 9y ago

Re: 1. You can deploy additional security measures such as certificate pinning or a VPN tunnel to your CalDAV server if you have a high security requirement. Re: 2. If your server is untrusted (because it's a remote virtual server) or hacked, e2e will not protect you.

tasn 9y ago
1. That's exactly what I said, though you are just patching a broken system here, why not just use a system that's resilient to all of this in the first place like with end to end? 2. How so? EteSync for example has a git like integrity verification (just with HMAC instead of hash), so it's easy to check consistency across clients, and the server can't forge anything. The worst the server/MITM can do is stop syncing a specific client which would be easy to detect. A rogue server can't even omit specific changes, only stop sync. So I don't agree with your assertion.