Hacker News new | past | comments | ask | show | jobs | submit login

I think you’re confusing transport layer security with end to end encryption.

TLS prevents the people who run Gatwick airport wifi from reading the messages. E2EE would also do that, and would additionally prevent Snapchat themselves from reading the messages.

The lack of E2EE does not imply a lack of TLS.




I am not, no E2EE means that Snapchat can view text messages, hopefully the endpoint does use TLS but even if they do you assume that there is no MITM throughout the chain at all and that the app employs public key pinning to detect such attempts.


That kind of an MITM attack would require both a lack of public key pinning from Snapchat _and_ a compromised certificate authority issuing bogus Snapchat TLS certificates that were trusted by common consumer devices. It's possible for a state level actor, sure, but it's unlikely that kind of countermeasure is being deployed in a blanket over every device connected to the Gatwick airport wifi.

The parent post said (emphasis mine):

> While everything was *TLS* encrypted between all conversation participants and the Snapchat server

To which you replied:

> Snapchat *does not encrypt* text messages only photos and video.

Which isn't true. TLS is encryption, and provides effective protection against an MITM attack from the provider of the Gatwick airport wifi. Sure, E2EE encryption may provide better privacy. It's only providing a meaningful improvement against a certain group of adversaries, though. That's the set of attackers who have the resources to defeat TLS, even without public key pinning, yet who do not have the resources to compromise/keylog one or more of the devices or compel cooperation from Snapchat.

Even if Snapchat did E2EE their messages, you would be very unlikely to have certainty that _your_ messages were secure. All it takes is `shouldE2EE := username != 'dogma1137'`. Or more likely `shouldCCTheNSA := username == 'dogma1137'`. The only defence against that kind of coerced cooperation is a full source code audit, confidence that there's no obfuscated code fooling your auditor, reproducible builds of the app, an ongoing assurance of some kind that the installed build's checksum matches that of the audited code, and finally full and ongoing confidence that none of the other vendors involved in the production of your device from the OS software stack right down to the baseband chip, have been similarly coerced.

tl:dr, TLS is probably all you need. For the cases where TLS legitimately isn't sufficient, you should be assuming that any conversation within 100m of any electronic device has been compromised.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: