Hacker News Reader

Comment by URSpider94 | Hacker News Reader

Can you provide more background on what you feel that messaging clients are getting right, but browsers are missing?

I can use Signal to communicate to another user without being subject to surveillance. But I cannot use my browser to chat with another browser user with the same degree of immunity to surveillance.

Let's say some xyz website's server was just another Signal client. I can talk to it from my Signal client in a way that is not subject to State surveillance. But I can't do that using HTTPS as my security model.

As to how Signal does it... Read their blog.

If I acquire a SIM card that takes over your friend's phone number, I can install Signal and sign up as your friend. Then when you use Signal to communicate with your friend, you are actually communicating with me. How is that different to HTTPS?

Thank you for mentioning that possibility. I'll raise the issue with Whisper.

Interesting, ok. I am not sure above what you are suggesting is more secure about Signal compared to HTTPS though. In both cases you start out with an address (phone number or domain) which you want to use to communicate with a third party securely. You require a trusted third party to link the address to an identity so that you know you are communicating with the right person. With HTTPS you are trusting the CA, with Signal you are trusting Signal. The CA will have checked for ownership of the domain and Signal will have checked for ownership of the phone number. After you have established secure communication with the end party, you have equivalent guarantees of privacy for future communications with them using either protocol.

This is why you are notified by Signal of key changes. This allows you to verify the change with your contact out of band.

Just like HPKP...

I think you're mistaken. I believe that the communication between your computer and a web server is 100% as secure as a Signal communication, assuming that your browser and the server are using the latest TLS standards and large keys.

What is insecure about a browser is that you can't be sure who is at the other end of the communication. That includes man-in-the-middle attacks, which are basically a variant of the case where you are not talking to the person you think you are.

That problem with Signal is solved by proving the identity of the person you are talking to out-of-band with the application, for example by linking up with your friend while you are standing next to each other, or verifying the link by a phone call.

I hope you can see that there's no directly analogous way to secure a web session for the consumer web, since the process of verifying the identity of the server manually would never scale. The solution to this problem -- ta da -- is to create authorities who you trust who will independently certify the server's identity -- certificate authorities, if you will. And yes, once you add CA's in the middle, the line of trust becomes an n-tree of trust, and you have a much higher risk of things going wrong.

If you want a fully secure Web experience -- delete all CA's except any that you independently audit. Then manually validate the SSL certs of every server you want to talk to and add it manually to your cert store. Now you have a Signal-like experience for the web. Good luck.

Reply on news.ycombinator.com