3 ms·
Peronally I lost faith in browser makers ability to determine trust along time ago. Validate on first use and peer verified checksums of certs is a much better
by teknopaul 9y ago
Peronally I lost faith in browser makers ability to determine trust along time ago. Validate on first use and peer verified checksums of certs is a much better idea imho. Works for ssh.
Where security matters, bank, logins, etc one click to validate an md5 sum against a hash on the webpage itself would be better than Google tring to police who has had their web server hacked.
- diroussel 9y agoIf you visit a few different ssh hosts in a week, and just a few new hosts each month, then trusting the host cert manually is feasible (but who actually verifies). But it's easy in a short browsing session for your User Agent to connect to hundreds of machines over TLS. Manually verifying them all is not feasible. And verify against what? A webpage? How is that validated. TLS and X.509 certs have their flaws, but ssh style trust is not the solution. The problem is: if your browser adds a CA to it's trust root, it can issue (and thus your browser trusts) any site on the internet. I would rather that if I visit https://www.police.uk https://www.police.uk then the certificate is issued by a CA that specifically allowed to issue .uk domain certs. Currently my system trusts "Belguim Root CA2" and "Amazon Root CA 1". Should they be able to sign certs for the .ca or .edu domains? Do I trust Amazon enough to not issue certs for their competitors?