Comment by 3pt14159
11 years ago
It is not a legitimate requirement.
HTTP can be man-in-the-middled passively, and without detection; making dragnets super easy.
In order for HTTPS self signed certs to be effectively man-in-the-middled the attacker needs to be careful to only selectively MITM because if the attacker does it indiscriminately clients can record what public key was used. The content provider can have a process that sits on top of a VPN / Tor that periodically requests a resource from the server and if it detects that the service is being MITM then it can shut down the service and a certificate authority can be brought in.
Edit: Also, all this BS about how HTTPS implies security is besides the grandparent's point: certificates and encryption are currently conflated to the great detriment of security, and they need not be.
> HTTP can be man-in-the-middled passively, and without detection; making dragnets super easy.
Nothing can be man-in-the-middled passively, that makes no sense. That isn't what a MitM is. It requires active involvement by its very nature.
> In order for HTTPS self signed certs to be effectively man-in-the-middled the attacker needs to be careful to only selectively MITM because if the attacker does it indiscriminately clients can record what public key was used.
I genuinely don't understand what you're trying to say.
> The content provider can have a process that sits on top of a VPN / Tor that periodically requests a resource from the server and if it detects that the service is being MITM then it can shut down the service and a certificate authority can be brought in.
If the MitM originates from a specific location (e.g. a single Starbucks, a single hotel, an airport, etc) it would never be detected by that method.
> Also, all this BS about how HTTPS implies security is besides the grandparent's point: certificates and encryption are currently conflated to the great detriment of security, and they need not be.
Only MitM protections AND encryption provide a secure connection when together. Individually they're insecure.
If someone wants to come up with a security scheme which doesn't depend on certificates that would be fine. You just have to solve the encryption issue (easy) and the identity issue (hard).
> Nothing can be man-in-the-middled passively, that makes no sense. That isn't what a MitM is. It requires active involvement by its very nature.
By this I mean record all form submissions done through HTTP.
>> In order for HTTPS self signed certs to be effectively man-in-the-middled the attacker needs to be careful to only selectively MITM because if the attacker does it indiscriminately clients can record what public key was used.
> I genuinely don't understand what you're trying to say.
The default thing we're trying to prevent is someone close to the server MITMing every request, recording each post, and reenacting them so that they are not discovered.
> If the MitM originates from a specific location (e.g. a single Starbucks, a single hotel, an airport, etc) it would never be detected by that method.
That is true for the example I gave which is just a proof-of-concept, but not true for a better method, like decentralization + public key signing.
What I'm fundamentally saying is that Cert + HTTPS is more secure, but it is not fully secure, since you have to trust the cert provider. Just in the same way, HTTPS without cert is not fully secure, but it is (much) more secure than HTTP.
>man-in-the-middled passively
"eavesdropped" is the word you're looking for.
2 replies →
That's all good in theory, but there have been demonstrated attacks against man-in-the-middle-able protocols and we've lacked the ability to respond usefully, precisely because the protocols were designed to be man-in-the-middle-able. Everyone knows it's happening and it's even easier to detect than your example, but there's nothing useful to do with that knowledge other than complain.
https://www.eff.org/deeplinks/2014/11/starttls-downgrade-att...
All the attacker needs to do is target the "CA" of the target.
For example, in an individual user situation, if the "CA" is a mac user, you use a local exploit, and export the private key from the Keychain. Done.