Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The article title really, really needs an extra word: "Chrome", between "Google" and "Will". At first glance I thought it would be about the search engine, which would be a very disturbing thought indeed; it's already hard enough to find the older, highly informative and friendly sites --- which often are plain HTTP.

Nevertheless, quite convincing security arguments aside, I feel this also has a very authoritarian side to it: they are effectively saying that your site, if it is not given a "stamp of approval" by having a certificate signed by some central group of authorities, is worthless. Since CAs also have the power to revoke certificates, enforced HTTPS makes it easier to censor, control, and manipulate what content on the Web users can access, which I certainly am highly opposed to. I can see the use-case for site like banks' and other institutions which are already centralised, but I don't think such control over the Web in general should be given to these certificate authorities.

With plain HTTP, content can be MITM'd and there won't be much privacy, but it seems to me that getting a CA to revoke a certificate is much easier than trying to block a site (or sites) by other means, and once HTTPS is enforced strongly by browsers, would be a very effective means of censorship. Thus I find it ironic that the article mentions "repressive government" and "censor information" --- HTTPS conceivably gives more power to the former to do the latter, and this is very much not the "open web" but the centralised, closed web that needs approval from authorities for people to publish their content in.

There's a clear freedom/security tradeoff here, and given what CAs and other institutions in a position of trust have done in the past with their power, I'm not so convinced the security is worth giving up that freedom after all...



Repressive governments somehow convincing all CAs worldwide to refuse to issue certificates for your domain is a pretty distant hypothetical. Repressive governments monitoring and altering unencrypted communications in very sophisticated ways is a reality today. It's not a freedom/security tradeoff but a freedom/freedom tradeoff.

Not to mention that, of course, access to most websites is already gated by a central group of authorities - the domain registries - which can and do seize domains. Using raw IPs is one alternative, but if you're in that kind of position, chances are you want to be a Tor hidden service anyway.


Repressive governments monitoring and altering unencrypted communications in very sophisticated ways is a reality today

They could easily alter encrypted communications to effectively censor too, thanks to the all-or-nothing nature of encryption with authentication. Because by design, the certificate is presented in cleartext, it would be pretty easy to blacklist CAs and then cut off the connection if one of those is detected. Alternatively, whitelist CA(s) [1]. Analysing plaintext takes more computational resources, especially if things like steganography are used.

[1] Related article: https://news.ycombinator.com/item?id=10663843


Regarding the censorship:

It's obvious that censorship by western governments is never considered "censorship".

Only the evil enemy censors, we just have to enforce laws.

If one accepts this argument, it makes sense to argue that giving CAs more power is good — because, obviously, they don't censor, they just protect the interests of our economy.


Blockchain technology (which powers the Bitcoin) can easily be used to replace CAs, or provide an alternative which browsers acknowledge, provided enough site owners use it.

And going by the high issuance/maintenance fee the CAs charge for issuing certificates, the industry is a sitting duck for disruption by a Blockchain DNS/CA app.

I, as a site owner, can just sign my 'certificate' myself and put it on the blockchain DNS/CA app. The certificate will have my domain name, public key. And slso an additional field 'ownership sign' which is something like https://<my domain>.com/ownership_sign.pem (which is signed by my private key).

So if I am the true owner, I can self issue as many certificates to myself as I please. Or there could be some forced limitation to prevent any scalability (cough) challenges.

So, the problem you have pointed out is not really with enforcing/encouraging HTTPS, but with the entrenched CA bureaucracy. And I am really surprised, why is it not being disrupted already?


Tor is a tool for circumventing censorship. HTTPS is an important part of using Tor to surf the web: 1) it protects the user from bad exits that could inject malicious javascript into a page and 2) some exits refuse HTTP connections and only allow HTTPS.

Maybe HTTPS makes it easier to censor in theory, but in practice it helps fight censorship by enabling Tor.


There are already points of centralization at the domain registrar and DNS layers.

That was a major (really the major) basis of the fight against SOPA--it would have required ISPs to interfere with DNS resolution as a way of shutting down serial copyright infringers.

And the U.S. federal government can already seize domain names for some reasons.

So, the question is: does the value of pervasive over-the-wire encryption outweigh the risk additional centralization via CAs? Right now I think it does, but that is in part because I believe that the CA infrastructure itself will improve over time.


What we really need is opportunistic unauthenticated encryption with key pinning as a fallback between CA-signed https and plain http. Beating mass passive snooping is worthwhile even if MITM is still a risk.


The Fenrir project does something like this. They first establish a encrypted connection and then you can authenticate, or not. The authentication can also be federated.

Its pretty cool, but its not production ready.

The GNUNet has multible layers and do bottum up encryption on the lower levels.


I agree! There is TCPCrypt, for example: http://www.tcpcrypt.org/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: