4 ms·

I don't think certificates are a good solution for most websites. Instead have the browser store the public key first time you visit the site. Then ask the user

by z3t4 7y ago

I don't think certificates are a good solution for most websites. Instead have the browser store the public key first time you visit the site. Then ask the user every time it changes, like with SSH. Also browser should send their public key to the server! So that we don't have to come up with a new password for every damn site.

jaywalk 7y ago
>Instead have the browser store the public key first time you visit the site. Then ask the user every time it changes, like with SSH. The vast majority of users will not understand this. Also let's say you go to a site one day, and you get a prompt that their certificate has changed. Is this legit? How can you know? >browser should send their public key to the server! This already exists (HTTPS Client Certificates) but it's a huge pain in the ass so it's barely ever used. When it is used, it's generally within a controlled corporate environment.
- z3t4 7y ago
  There could still be a trust chain. But most websites don't need it, just like most websites only use the basic level of certification today, all they really want is encryption. (or the green padlock :P) Client certificates has kinda been deprecated by browsers. Which is why it's such a PITA. Also handling signing certificates by itself is a PITA. But most website's wouldn't need signing, just encryption. Automatic SSL certificate signing is not that secure, if an attacker would be able to mess with DNS, or access the HTTP server, they could also create a fake certificate via Letsencrypt. Or if the attacker has access to the client, they could sneak in a root certificate. Most nation states and ISP (those who would like to spy on it's citizen) already have root certificates. All that SSL certificates do is to create extra work for site maintainers. We can have encryption without certificates. If you would for example side-load a list of public keys for the main sites you visit, that would be much more secure then SSL certificates are today.
tingletech 7y ago
> Also browser should send their public key to the server! That would make fingerprinting even easier?
- z3t4 7y ago
  The browser could generate an unique key pair for every website that request a public key. Or there could be a dialog like "news.ycombinator.com want's to know your identify, which profile to use?" (option to generate a new profile), kinda like password managers work today.' The advantage with reusing "profiles" is that you could use the same profile on many web apps like Facebook and Instagram, then you could allow your Facebook friend to access your Instagram photos. Or your "contact list" could be offline (eg. managed by your browser, and not by web apps) and you manage access rights via your contact list, rather then on each and every app.
alwillis 7y ago
Browsers toyed with the idea of using DNSSEC + DANE which would allow a website owner to use self-signed certificates and have them trusted just like commercial certificates. A DNS record (TLSA) would tell the browser how to deal with trusting the certificate, its public key or to validate the chain of certificates, etc: https://www.rfc-editor.org/rfc/rfc7671.html https://www.rfc-editor.org/rfc/rfc7671.html. This would have radically changed the landscape of certificate authorities and browser vendors. Google and Mozilla implemented it back in the day but changed directions. Among other issues, doing additional DNS lookups when you're trying to get the page on the screen as quickly as possible put the kibosh on things. Plus politics. Mind you, using DANE + TLSA is the defacto standard for Mail Transfer Agents to do secure email with each other but SMTP and HTTP have different security requirements. We may eventually get there, but there are political and technical hurdles to overcome when it comes to DNSSEC, which is required for DANE and all the rest. It's really taken off in parts of the European Union, South America, and Asia, but not so much in the US, where only about 25% of internet users are behind a DNSSEC-aware resolver: https://stats.dnssec-tools.org https://stats.dnssec-tools.org. The article DNSSEC, DANE and the failure of X.509 is a pretty good summary: https://blog.hansenpartnership.com/dnssec-dane-and-the-failure-of-x-509/ https://blog.hansenpartnership.com/dnssec-dane-and-the-failu....

by z3t4 7y ago

jaywalk 7y ago

>Instead have the browser store the public key first time you visit the site. Then ask the user every time it changes, like with SSH. The vast majority of users will not understand this. Also let's say you go to a site one day, and you get a prompt that their certificate has changed. Is this legit? How can you know? >browser should send their public key to the server! This already exists (HTTPS Client Certificates) but it's a huge pain in the ass so it's barely ever used. When it is used, it's generally within a controlled corporate environment.

z3t4 7y ago
There could still be a trust chain. But most websites don't need it, just like most websites only use the basic level of certification today, all they really want is encryption. (or the green padlock :P) Client certificates has kinda been deprecated by browsers. Which is why it's such a PITA. Also handling signing certificates by itself is a PITA. But most website's wouldn't need signing, just encryption. Automatic SSL certificate signing is not that secure, if an attacker would be able to mess with DNS, or access the HTTP server, they could also create a fake certificate via Letsencrypt. Or if the attacker has access to the client, they could sneak in a root certificate. Most nation states and ISP (those who would like to spy on it's citizen) already have root certificates. All that SSL certificates do is to create extra work for site maintainers. We can have encryption without certificates. If you would for example side-load a list of public keys for the main sites you visit, that would be much more secure then SSL certificates are today.

tingletech 7y ago

> Also browser should send their public key to the server! That would make fingerprinting even easier?

z3t4 7y ago
The browser could generate an unique key pair for every website that request a public key. Or there could be a dialog like "news.ycombinator.com want's to know your identify, which profile to use?" (option to generate a new profile), kinda like password managers work today.' The advantage with reusing "profiles" is that you could use the same profile on many web apps like Facebook and Instagram, then you could allow your Facebook friend to access your Instagram photos. Or your "contact list" could be offline (eg. managed by your browser, and not by web apps) and you manage access rights via your contact list, rather then on each and every app.

alwillis 7y ago

Browsers toyed with the idea of using DNSSEC + DANE which would allow a website owner to use self-signed certificates and have them trusted just like commercial certificates. A DNS record (TLSA) would tell the browser how to deal with trusting the certificate, its public key or to validate the chain of certificates, etc: https://www.rfc-editor.org/rfc/rfc7671.html https://www.rfc-editor.org/rfc/rfc7671.html. This would have radically changed the landscape of certificate authorities and browser vendors. Google and Mozilla implemented it back in the day but changed directions. Among other issues, doing additional DNS lookups when you're trying to get the page on the screen as quickly as possible put the kibosh on things. Plus politics. Mind you, using DANE + TLSA is the defacto standard for Mail Transfer Agents to do secure email with each other but SMTP and HTTP have different security requirements. We may eventually get there, but there are political and technical hurdles to overcome when it comes to DNSSEC, which is required for DANE and all the rest. It's really taken off in parts of the European Union, South America, and Asia, but not so much in the US, where only about 25% of internet users are behind a DNSSEC-aware resolver: https://stats.dnssec-tools.org https://stats.dnssec-tools.org. The article DNSSEC, DANE and the failure of X.509 is a pretty good summary: https://blog.hansenpartnership.com/dnssec-dane-and-the-failure-of-x-509/ https://blog.hansenpartnership.com/dnssec-dane-and-the-failu....