Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yes it does.

It has been trivial to bolt encryption to things for a long time now. Encryption is worthless without trust. Ubiquitous encryption more so because it's no longer a surprise when something is encrypted, it's just expected that you have your snooping client MitM the traffic with dummy certificates.

It doesn't stop 3-letter agencies (though really, people should stop pretending that's where the real threat lies for most people) and it doesn't stop informed hackers or intrusive corporate firewalls.



It doesn't stop 3-letter agencies (though really, people should stop pretending that's where the real threat lies for most people) and it doesn't stop informed hackers or intrusive corporate firewalls.

It doesn't stop any organisation capable of compromising your certification chain.

That might be a TLA going after a root CA. We could debate the ethics of that but I'm not sure it's helpful for this discussion to go over all of that again.

It might be an "intrusive corporate firewall", but if you're doing anything personal and sensitive from work equipment then I'm somewhat lacking in sympathy. No doubt that equipment was provided to help you do your job, and it is quite possible that your employer has statutory and/or regulatory obligations to meet regarding controlling of data and auditing of same, which is probably what any intrusive scanning on the way out is for. As for scanning on the way in, you only have to look at how many idiots open any e-mail attachment even if it's under a neon sign saying "Trojan here!" and how many people try to use things like personal webmail over HTTPS from work computers, and you can see a strong argument for inspection as far as corporate IT is concerned. (I do think it is in the interests of all concerned for employees to be properly informed of the possibility that their "encrypted" communications aren't and any legitimate justifications that apply, though. A throwaway line about monitoring communications on page 17 of the contract is not a good way to build trust, IMHO.)

But how exactly is an "informed hacker" going to compromise something like your on-line banking if it's encrypted this way? Probably the biggest practical benefit of current HTTPS implementations is that they do stop Little Johnny Wireshark spying on everyone else in the cafe or Little Johnny ISP monitoring the private communications of his customers. Even if the chain of trust is compromised and someone has the encryption keys, it's still only that one party who can intercept your communications, and you're still guarding against monitoring across the rest of an untrusted network.


Intrusive corporate firewalls MitM SSL sessions because the client is already compromised (IT installs the firewall's cert as a trusted CA). Any solution can't route around a situation where you don't trust the client machine.


Right but that's my point: it doesn't matter if it's encrypted. It matters if it's encrypted AND you've established trust.

I'd go so far as to say that trust is actually more important - whether someone can read my messages is less important then verifying they're what the sender intended to send.


I agree it's really important, but we need both parts of the puzzle, not just one. Out of interest, what would your proposal for a new trust model for server communication be?


Web-of-trust rather then CA-rooted, with more attention placed on who the signers are.

i.e. if I'm using my bank, then what matters to me is whether the bank is certified by my government, not VeriSign or whoever. If it's a foreign bank, then it matters whether their government trusts them, and it matters to me whether MY government trusts them.

If it's NOT a bank, then maybe my trust requirements are different. But the UI for all this and details are everything - but I think we've definitely stuck way too much import on that little green padlock icon without doing enough to educate users moment to moment about what it means.




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

Search: