It's hard to justify not having https on any site. Without it you are saying "you might get the intended HTML we sent ... or maybe not if the request has been intercepted".
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 think OP concern is that an HTTP page is vilified with respect to the free pass that HTTPS gets.
Is that in the right ballpark OP ?
Browsers are set to scare people away from HTTP pages,
insinuating HTTP is dangerous and not to be used.
there are ways of being your own CA,
but you have to disseminate a root certificate to all the browsers you want to use the page.
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.
yes i can see a logical next step for state sponsored CA which can be made mandatory by isp after that only way to avoid censorship would be to use VPN but even that would be less effective if the exit node ips are known(which they are), tor will also be limited(because of barrier to entry) and the only reason its still alive is because the US gov is heavy reliant on it .... are we screwed
only as screwed as we allow ourselves to be.
authority is given by tacit consent of those subjected to it.
there are free and/or open CAs and the moment cert revocation becomes a big issue is when the current CAs lose authority and are succeded by grass roots CAs.
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.
Personally I think that it's too centralized and authority-based. I am suspicious that somehow authorities may use their position to compromise security in the name of national surveillance although I don't know if it's actually possible.
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.
No. HTTPS doesn't include NSA in its threat model. The CA system is finding a balance of diversity of CA vendors where any CA being compromised is unacceptable. HTTPS helps in situations such as: public wifi, small state actors, ISPs, domain name takeovers
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.
We really need to get rid of the crazy error message that scares users into thinking that encrypting traffic with a self signed certificate is somehow less secure than not encrypting traffic at all.
Being solved the in the other direction, soon all unencrypted traffic will be marked as dangerous.
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.
Yeah, that's the real problem. The idea that encryption is only safe for users if the site is registered with " authority(ies) " is one of the biggest delusions going right now. Politics of fear.
HTTPS is so easy to set up, whether one uses a certificate or not, that I think that HTTP should be treated as dangerous by the browser and highlighted in red. The default browser behavior should be that of HTTPS Everywhere in that it will show a warning page before letting you override it and continue to the HTTP version.
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.
HTTPS is not easy to set up unless you happen to be using a system that does it automatically via LetsEncrypt, which is fairly rare. And I don't know how you think you can use HTTPS without a certificate.
> HTTPS is not easy to set up unless you happen to be using a system that does it automatically via LetsEncrypt, which is fairly rare. And I don't know how you think you can use HTTPS without a certificate.
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.
> There's simply no excuse for not providing an encrypted connection.
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 might not be "necessary" for a website dedicated to salt shakers, but if I can provide my users privacy when reading my site(unencrypted DNS notwithstanding), why wouldn't I? It should be a common courtesy. While I'm browsing the web, I should expect that nobody but the host can tell what it is that I'm doing.
> 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.
There are situations where http is wanted, the best example are public WiFi networks. Showing another big warning for non-https sites would scare the users more than it currently does with them visiting a https site the first time they're on a public WiFi.
Hold the phone. Public WiFi is where you want your connection to be encrypted at all times. A WiFi login page should be encrypted without scaring the user just because its certificate is self-signed. Beyond that, any connection that is encrypted on public WiFi is better than one with no encryption. I don't care if I'm looking at pictures of dogs and cats; it's not the business of other people on my network to sniff my activity and see exactly what I'm reading, even if they can see my DNS activity. Users aren't in control of whether a site supports HTTPS, thus it's a courtesy, given the ease it takes in implementing HTTPS, that even "innocent" web services do so.
I do agree that encryption is especially required on public WiFi networks. But WiFi login pages error because they mitm your current, encrypted connection. Your proposal would additionally add an error in a case where the user especially chose a http site to not receive a error because they're getting mitm-led. I never had any wifi login page that used a self signed certificate.
Then providers of public wifi need to stop using a MITM to provide wifi access. This is an opportunity for better technology to be developed or implemented or made easier to implement or whatever.
People are, on average, incredibly stupid. Some of those who aren't will inevitably take advantage of this for money and power.
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.
No, we are giving too much power to a certain tech company with a certain browser and OS which now has amassed so much power and influence, including participation in all important W3C working groups, they can basically do whatever they want.
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.
I'm a bit mixed... I wouldn't mind if DNS security were at a point where someone could just self-publish their public key to DNS, and treat it just like domain verification.
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.
i can see great potential for miss use by state actors(both democratic and dictatorships).I can see ssl cert authorities being soft targets for censorship and/or surveillance. is my concern misplaced.
45 comments
[ 3.0 ms ] story [ 109 ms ] threadEven 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.
https://letsencrypt.org/
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.
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.
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.
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.
https://news.ycombinator.com/newsguidelines.html
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.
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...