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

There's a fundamental flaw with the "CA/DNS/HTTPS/web browser UI" infrastructure that conflated the concepts of "encrypted transmission" and "proof of identity". Despite the scary red screens browsers like to show it's never the case that you're less secure using https to talk to a given server, even if the certificate the server presents is expired, mislabeled, or even entirely forged. Regardless of the encryption there are many ways to fool you into believing the server you're talking to belongs to some other entity, CA's were supposed to address that but they are consistently failing at this both by accident and indifference as well as hacking. These concerns need to be separated. I believe the end game is for servers to generate their own certificates for encrypted communication, and ultimately it will have to be some extension to DNS to handle the proof of identity, but I don't see an obvious evolution from the existing CA system.



> There's a fundamental flaw ... that conflated the concepts of "encrypted transmission" and "proof of identity".

You can not separate those concepts. If you don't have proof of identity, your connection is not secure.

>Despite the scary red screens browsers like to show it's never the case that you're less secure using https to talk to a given server, even if the certificate the server presents is expired, mislabeled, or even entirely forged.

But I completely agree with that, there should be warnings for plain HTTP, with the same severity used for self-signed sites. (And current browsers are too severe with self-signed certs, to the point that they reduce the security of people accessing those sites.)


This.

The ux [especially] places priority of identity ahead of protected, private conversation and then too broadly encapsulates that information. Secondly, verification is too static, too binary (all or nothing), and too optimistic.

1. To what degree is the line leaky and observable? 2. To what degree are we confirming the conversation participants' identity claims? 3. To what degree is the conversion following normal conversation protocol?




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

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

Search: