Making the public key of the remote available to JS wouldnt help because if you can't trust the identity of the remote server or integrity of the connection then you can't trust the javascript.
Tor hidden services are secure because of the lack of human meaningful names.
Re:DNS over HTTPS
by kernelPan1c on Wednesday January 17, 2018 @12:43PM
(#16169986)
Yes, since you can't trust the JS, doing this would be an attempt at security through obfuscation. I mostly just think it's strange that these keys aren't accessible. If there were ever a mismatch detected, the server could at least know with certainty that there's a bad actor on the connection.
Thanks for Zooko's Traingle wiki. Hadn't seen that one before.
Re:DNS over HTTPS
by Someone1234 on Wednesday January 17, 2018 @12:07PM
(#16169613)
> Why won't browsers allow the certificate's public key to be readable by javascript
Because sites would randomly block reverse proxies, web proxies, enterprise users, people using certain WiFi APs, and it would give advertisers another thing to track users on.
Frankly after looking at what websites did with the User Agent, I'm scared to see what they'd do when a certificate mismatch occurs.
I thought modern browsers ship with pinned certificates for Google and other large companies built in to the browser download.
Re:DNS over HTTPS
by kernelPan1c on Wednesday January 17, 2018 @12:20PM
(#16169732)
Public key pinning helps but it operates on the assumption that the initial key is the correct one. I find it curious that these public keys are not readable by the client.
Similar to how tor hidden services get resolved, distributed hash tables seem like the way to go. Take the ISPs and Cert Authorities out of the equation.