Ask HN: Are we killing the web by giving to much power to SSL cert authorities
since https has been made mandatory , are we giving to much power to ssl certificate authorities (the reputed ones)
Given the Web as-is, and its growing importance, it even makes past misconduct of a certain other big tech company in order to try and get control over the Web look like child's play.
And no, SSL cert authorities actually don't have much power at all. Everyone can be a cert authority (just make a properly set up certificate chain with something like OpenSSL and you are good to go) but the companies who have the ultimate authority by either accepting or rejecting cert authorities (or actually by accepting or rejecting their root certificates and/or control over the HSTS whitelist for global deployment) do, which brings me back to the point above.
My two cents.
FWIW the trend has been ongoing for a long time. I remember 10 years ago being frustrated I couldn't scp with the NULL cipher on my own local LAN unless I built from source.
The problem is that browsers might not ever implement anything like that, even providing an unobtrusive danger warning, because so many everyday users would be scared by it or assume their browser is "broken" because their last browser didn't do that on most websites.
Regardless, that really should be the default behavior. There's simply no excuse for not providing an encrypted connection. It comes with virtually every web server out of the box.
What I meant is that you can use a self-signed certificate, which is takes seconds go create. Some server software will even do it for you if I remember correctly. If this is too had for someone to implement, then they really have no business building web apps.
In a world where unencrypted connections are scary and an encrypted but self-signed connection is treated like HTTP connections currently are(not scary), it only makes sense for people to support HTTPS. There's nothing inherently hard about implementing an HTTPS service beyond one extra initial step.
Beyond that, there's LetsEncrypt, and services like AWS will take care of creating signed certificates for you; I imagine they aren't the only infrastructure host that does this.
Its use in every situation (ie, browsing a website dedicated to reviews on salt shakers), might not be necessary and could cause an affect similar to the overuse of antibacterial soap. :p
It will also prevent older computers from accessing the web as ssl standards evolve, which is kind of a shame.
> It will also prevent older computers from accessing the web as ssl standards evolve, which is kind of a shame.
At what point should an older computer no longer work with the current web? Eventually there's going to be a breaking change. A computer old enough that its browser can't be updated is probably vulnerable to all sorts of browser-based attacks.
Browsers are set to scare people away from HTTP pages,
insinuating HTTP is dangerous and not to be used.
This can be handy, if you only need a particular group of browsers to see the page,
and you dont care what every body else does.
The spectre of cert revocation exists when you do HTTPS the "normal" way,
and there are free versions as expostulated by Lorenz-Kraft.
this will take some browser twiddling and brand conversion, as the current framework for HTTPS certification extends to whitelist and blacklists of ^unvetted^ certificates, in a manner homologous to emailserver blacklists.
in other words, you can roll your own but the current infrastructure can blacklist it. its a big job but not yet impossible.
or we could forget all this business about encrypting the protocol [HTTP>HTTPS] and simply encrypt the page moving via the protocol, when there is a concern for privacy.
that being said, the whole point of publishing to the web, is so that everyone can see it.
if you want to publish to an exclusive group, then use a different protocol, that is not clear in public, and not reliant on third party mechanisms.
There are many research projects related to content-oriented networking. Some of them have limited popularity already and are being used to host web content. It seems that may continue to increase in popularity. That would shift from transport layer security to content-oriented security. It's a different set of problems that should involve better distribution and so theoretically a more democratic power structure.
Even http/1 (which is mostly used atm ) flags any page with inputs with a big red !! Insecure !!
That doesn't make it mandatory.
HTTP/1 clients push TLS; HTTP/2 mandates TLS.
I've been trying to be more brief in my comments here, since I tend to ramble on too much. I think perhaps I was too brief this time.
If you're using Google Chrome.
Safari and Firefox don't do this (yet?) unless the page also has a password field. Which seems like the right compromise IMO.
Any other encryption system is not natively supported by the browser so would require some kind of plug in. How would you download that plugin? https?
Using JS to encrypt is a problem because you need to securely download that JS to begin with, requiring https or similar.
I do know that the existence cert authorities greatly undermine the notion of a chain of trust for certs. It was perhaps a necessary compromise, as there are so many certs that it isn't practical for people to verify the authenticity of them as they should, so they have to rely on someone else to do it for them.
Personally, the use of cert authorities reduces my trust in certs signed by them. I don't consider a cert trustworthy just because a CA (that isn't mine) has signed them. I consider them more trustworthy than just accepting certs without any validation at all, but that's not high praise.
I also don't accept the bundles of root certs that are provided by operating systems or web browsers. Those bundles include too many (one is too many) root certs that exist purely to allow undetected spying and MITM attacks.
I think the essential problem is that our entire cert trust mechanism is broken.
With Let's Encrypt, I think the issue is mostly addressed, I think it's harder for internal business networks though, which is where a DNS option would be of value.
Maybe limit DNS public key dist to a .lan TLD, that isn't able to be registered publicly. You have a TXT record for public-key.servername.orgname.lan then that will be used as the public key for servername.orgname.lan and the browser treats it as domain valid cert without CA.
it shouldnt be a browsers corporations business to de-commision a protocol with FUD.
and besides that:
https://nakedsecurity.sophos.com/2013/03/16/has-https-finall...
When stupid people use http and see a warning, they don't think, "huh, I have no login here, provide no personal information, and the information I am receiving is not in any way critical--if it is spoofed by a bad actor, it doesn't matter" and bypass the warning. Instead, their little primitive brains do the fight-or-flight herd behaviour and click "get me out of here".
This puts the CA in the potential position of extorting money from those who must, of necessity, cater to stupid people. It also gives the CA complete control over who gets to publish their information. Forcing the need for a CA is simply totalitarianism.
The only way a CA can exist in a world where https is functionally mandatory is if legislation forces the CA to be free as in beer, fully transparent, and prohibited from arbitrary action by an appeal system that is fast, efficient, and also free as in beer.
Otherwise, we have lost everything that was good about the Web. End of story.