3 ms·

1. The HTTPS infrastructure is downgradeable and relies on DNS and a multitude of certificates. And not all the ciphers are safe. Yes it can be done securely-is

1. The HTTPS infrastructure is downgradeable and relies on DNS and a multitude of certificates. And not all the ciphers are safe. Yes it can be done securely-ish, but unless you're layering another level of encryption over HTTPS it isn't fully secure. Layering is what the CIA does, according to the Snowden leaks. 2. As for the rest of it: Cool man, that sounds like you want a normal chat app that is more usable and less secure. I use Messenger too for things that don't matter.

lmm 8y ago
> The HTTPS infrastructure is downgradeable and relies on DNS and a multitude of certificates. And not all the ciphers are safe. Yes it can be done securely-ish There's no reliance on DNS. We know what the right way to do HTTPS is, and an app that doesn't have to maintain compatibility with ancient browsers can use a strictly secure profile (no old ciphers, no downgrades etc.). HTTPS is older and more complex than the Signal protocol, but it's also extremely widely deployed and gets a huge amount of attention from security researchers. I think actual attacks on the protocol are less likely with HTTPS than with Signal. > unless you're layering another level of encryption over HTTPS it isn't fully secure. Nonsense. Two layers of valid encryption are no more secure than one, and two layers of flawed encryption will almost certainly still be flawed. > 2. As for the rest of it: Cool man, that sounds like you want a normal chat app that is more usable and less secure. I use Messenger too for things that don't matter. It's not that my chats don't matter. It's that I don't think autodeletion or one-device-only represent a meaningful security improvement.
- 3pt14159 8y ago
  > There's no reliance on DNS. In practice there is for most situations. Are you going to get a static IP and go through the work of finding one of the rare cert authorities to get an HTTPS cert for it authorized? > Nonsense. Two layers of valid encryption are no more secure than one, and two layers of flawed encryption will almost certainly still be flawed. I hate arguing about this because I feel like there is a difference between how mathematicians think and how engineers thinks. I agree that one of the layers should be HTTPS if the context allows for it, because it has a lot of eyes on it, as you mention; but I fail to see how layering encryption is bad from a privacy standpoint. Mathematically, this statement: > Two layers of valid encryption are no more secure than one. Is only true if there are no mistakes and if it would take more operations in the universe to break the first layer of encryption. But why should we, a priori, assume that there are no mistakes? We have hundreds of examples of thought-to-be-secure ciphers / one way hashes ending up in the trash heap. Look at things like Cloudbleed. In reality things break. In reality cert authorities get moled or hacked. If you've been using layered encryption you're safer. Also, HTTPS basically mandates that you use TLS, which for some contexts doesn't work because we'd prefer a one-way (i.e., connectionless) channel to communicate to stop inbound traffic at the physical layer. > It's that I don't think autodeletion or one-device-only represent a meaningful security improvement. It's helped plenty of people that have had their phone seized at the border or their other device seized by the police. Sometimes you don't that information is sensitive until later, and sometimes you choosing to delete it at that point is illegal or impossible.
  - lmm 8y ago
    > In practice there is for most situations. Are you going to get a static IP and go through the work of finding one of the rare cert authorities to get an HTTPS cert for it authorized? You don't need DNS to check whether the server purporting to be messenger.com has a valid certificate for messenger.com. An attacker who controls the network can of course cut you off entirely, but an attacker who controls DNS can't intercept you messages because that doesn't get them any closer to having a certificate. > I agree that one of the layers should be HTTPS if the context allows for it, because it has a lot of eyes on it, as you mention; but I fail to see how layering encryption is bad from a privacy standpoint. Do you feel safer behind two locked doors than one? I guess it can't hurt, but the effort would surely be better spent on virtually any other aspect of the system. E.g. if you double the key length in a single layer of encryption you've made it 2^128 (or whatever your key length was) times harder to crack, whereas if you stack two layers then you've only made it twice as hard. Beyond that my argument would be: many security breaches happen because someone got confused about where the security boundary was. If you use one layer of encryption then everyone knows that the encrypted data is untrusted and the decrypted data is trusted. If you have two layers it's very easy to get lazy and introduce a small hole into one layer assuming the other will cover it, then you do the same for the other layer, and then an attacker figures out how to connect those two holes in a way you hadn't thought of and suddenly you're doomed.

lmm 8y ago

> The HTTPS infrastructure is downgradeable and relies on DNS and a multitude of certificates. And not all the ciphers are safe. Yes it can be done securely-ish There's no reliance on DNS. We know what the right way to do HTTPS is, and an app that doesn't have to maintain compatibility with ancient browsers can use a strictly secure profile (no old ciphers, no downgrades etc.). HTTPS is older and more complex than the Signal protocol, but it's also extremely widely deployed and gets a huge amount of attention from security researchers. I think actual attacks on the protocol are less likely with HTTPS than with Signal. > unless you're layering another level of encryption over HTTPS it isn't fully secure. Nonsense. Two layers of valid encryption are no more secure than one, and two layers of flawed encryption will almost certainly still be flawed. > 2. As for the rest of it: Cool man, that sounds like you want a normal chat app that is more usable and less secure. I use Messenger too for things that don't matter. It's not that my chats don't matter. It's that I don't think autodeletion or one-device-only represent a meaningful security improvement.

3pt14159 8y ago
> There's no reliance on DNS. In practice there is for most situations. Are you going to get a static IP and go through the work of finding one of the rare cert authorities to get an HTTPS cert for it authorized? > Nonsense. Two layers of valid encryption are no more secure than one, and two layers of flawed encryption will almost certainly still be flawed. I hate arguing about this because I feel like there is a difference between how mathematicians think and how engineers thinks. I agree that one of the layers should be HTTPS if the context allows for it, because it has a lot of eyes on it, as you mention; but I fail to see how layering encryption is bad from a privacy standpoint. Mathematically, this statement: > Two layers of valid encryption are no more secure than one. Is only true if there are no mistakes and if it would take more operations in the universe to break the first layer of encryption. But why should we, a priori, assume that there are no mistakes? We have hundreds of examples of thought-to-be-secure ciphers / one way hashes ending up in the trash heap. Look at things like Cloudbleed. In reality things break. In reality cert authorities get moled or hacked. If you've been using layered encryption you're safer. Also, HTTPS basically mandates that you use TLS, which for some contexts doesn't work because we'd prefer a one-way (i.e., connectionless) channel to communicate to stop inbound traffic at the physical layer. > It's that I don't think autodeletion or one-device-only represent a meaningful security improvement. It's helped plenty of people that have had their phone seized at the border or their other device seized by the police. Sometimes you don't that information is sensitive until later, and sometimes you choosing to delete it at that point is illegal or impossible.
- lmm 8y ago
  > In practice there is for most situations. Are you going to get a static IP and go through the work of finding one of the rare cert authorities to get an HTTPS cert for it authorized? You don't need DNS to check whether the server purporting to be messenger.com has a valid certificate for messenger.com. An attacker who controls the network can of course cut you off entirely, but an attacker who controls DNS can't intercept you messages because that doesn't get them any closer to having a certificate. > I agree that one of the layers should be HTTPS if the context allows for it, because it has a lot of eyes on it, as you mention; but I fail to see how layering encryption is bad from a privacy standpoint. Do you feel safer behind two locked doors than one? I guess it can't hurt, but the effort would surely be better spent on virtually any other aspect of the system. E.g. if you double the key length in a single layer of encryption you've made it 2^128 (or whatever your key length was) times harder to crack, whereas if you stack two layers then you've only made it twice as hard. Beyond that my argument would be: many security breaches happen because someone got confused about where the security boundary was. If you use one layer of encryption then everyone knows that the encrypted data is untrusted and the decrypted data is trusted. If you have two layers it's very easy to get lazy and introduce a small hole into one layer assuming the other will cover it, then you do the same for the other layer, and then an attacker figures out how to connect those two holes in a way you hadn't thought of and suddenly you're doomed.