Hacker News Reader

Comment by xamuel | Hacker News Reader

Until there's a free, easy, maintainable, and actually existent solution to SSL certs, enforcing HTTPS-only is just downright extortion.

Referring to solutions that are under construction doesn't cut it. If you're that passionate about it, contribute to the SSL cert solution yourself instead of to the endless calls for HTTPS-only.

The 'Semantic Web' movement promises that if everyone would just publish their websites in XHTML with RDF annotations, we'd magically achieve world peace and end hunger. (I exaggerate slightly.) Should we ban non-semantic websites?

Physical snailmail and the spoken word are unencrypted. Both are frequently used to transfer data more sensitive than cat pics. If I'm surfing a website in a coffee shop, yes, there's a danger someone could intercept the data to spy on me. But they could just as well look over my shoulder, and HTTPS-everywhere isn't gonna do anything about that.

View on HN

I agree wholeheartedly with all of the points you're trying to make but the spoken word / snailmail comparison is broken and detracts from your message.

Saying that spoken word and snail mail are unencrypted and thereby implying that we should be no more worried about unencrypted digital traffic than we are about our real-world conversations is a harmful analogy, because it's evidently superficially true, but it implies that accessing your bank account over HTTP is no more dangerous than saying your credit card number in the street. That analogy would hold if every conversation that we have (or letter we send) could be recorded, filtered and searched at scale by anyone who cared enough to do so. In reality, using encrypted web communication is more analogous to real-world conversation - if somebody is particularly interested in what you, individually, are doing or saying then barring significant efforts on your behalf, they can probably get access to it but encryption, and analogously the security afforded by the difficulty of overhearing people's conversations in real life, prevents widespread, untargeted surveillance that would make, for example, automated harvesting of bank details, or the identification of people interested in a particular political movement trivial.

> Until there's a free, easy, maintainable, and actually existent solution to SSL certs, enforcing HTTPS-only is just downright extortion.

Note that the proposal this comment is in regard to a propasal to ban HTTP for websites of the federal government. It does not mean you have to stop offering HTTP for your own service.

I think the government can afford a couple of SSL certificates, and the privacy and authenticity improvements are well worth it when communicating with goverment institutions.

You can do two things at the same time. Advocate for a better cert solution while advocating for HTTPS everywhere.

The truth is that currently, RIGHT NOW there are dozens of government agencies monitoring HTTP traffic that includes things like Bing searches (!) which millions of people do and do not realize are not private. Browsers need to be designed to aid laymen when things are insecure.

Lastly, I don't know if it is you specifically, xamuel, but there is a history[1] of government agents infiltrating influential organizations and communities in order to slow down movements, change prevailing attitudes, or discredit the members there. I think in cases like this it is important to remember how influential Hacker News is, since it feeds publications that set public perceptions about technology, like Wired and the New York Times.

[1] Operation CHAOS, Project MERRIMAC, Project RESISTANCE, Operation Mockingbird, GATEWAY, CLEAN SWEEP, UNDERPASS, and many others.

What's the difference between infiltration and legitimately voicing an opinion? Should government agents not have a seat at the table in an open forum like HN?

> What's the difference between infiltration and legitimately voicing an opinion?

Visible affiliation.

Excellent point. What does that mean for civilians on that side of the argument- do they have to prove their status? Do the government's actions mean we can't assume good faith anymore?

Anonymous/pseudonymous speech is a long standing tradition of free speech, which many of us are enjoying right now right here. However, there is a difference between private conduct and conduct as a government agent. Government is an agency owned (ultimately) by the people and created by them to achieve certain purposes. To further those purposes, people can institute rules of conducts for the agents of the government. Not using anonymous/pseudonymous speech while performing government duties may very well be one of these rules. Not because government is always evil, but because we think our goals will be achieved better if government would act openly and identifiably and the reasons why we value anonymous/pseudonymous speech largely do not apply to the government actions. The government as such does not have inherent rights that people have (though its agents have them as people, but when working for hire as agents they may be bound by stricter rules than in their private life). That is the difference.

The difference is that they are not voicing individual opinions, they are running operations for the government to quash or change opinion.

Government agents who come to speak and identify themselves as such are obviously always welcomed to have an opinion and voice it in public.

I have replied to several sock puppet accounts on HN that were clearly foreign governments trying to influence the discussion, this is not acceptable.

Infiltrators are paid to participate and push opinions that are unrelated to their own (although they may match by coincidence).

Given that the context of this discussion is using HTTPS on .gov websites, isn't it reasonable to assume that other government departments will provide their private keys to the relevant SIGINT agencies?

I don't see that HTTPS-encrypting .gov websites provides much security advantage.

Arguably there is a solution: just use self-signed certs and/or your own ca. And have browsers implement some form of trust-on-first use and/or some dns/web-of-trust way of avoiding a big scary warning message. This won't fix everything, but it is more secure than http and more honest thsn the idea that you should trust all the CAs browsers bundle.

Ideally browsers should just bundle their own CA certs, and implement some form of semi-formal wot/have a sane UI for the rest. After all we trust our browsers implicitly - but why should we elevate them to do transitive trust for us?

Lets just build on x509, and get some kind of meaningful trust.

Lets say that Apple, Microsoft, Debian, Red Hat (eaxh distribute their own trusted (self-signed) CA cert. And also work with Mozilla, Google to trust (sign) their certs.

Then let trust-on-first-use or some other distributed method take care of the rest. When let's encrypt work: let distributions trust that too.

The resulting system would not be perfect - but I still think it would have a better trust model than our current mess.

Could not agree more with the first paragraph.

As it stands, we punish people who want "half security" much more than people who go for "no security"

What stops the browser from automatically trusting a self-signed cert for PayPal or your bank?

What stops the browser from automatically trusting a forged certificate signed by a bundled CA? That's not a hypothetical question. It's happened before - either through incompetent CAs, or malignant ones (see: Google/Mozilla vs China).

The problem with the current trust model, is that it's unclear who we trust -- or put in another way, who we empower to betray us. No trust without the possibility of betrayal - no betrayal without trust.

With the current model, the path from who the user trusts (eg: Mozilla, Google and the OS vendor) is abused to extend to way too many CAs. So many, that the user can give up (ie: I use the browser and trust the green bar) -- or get a crippled experience, because the model assumes that you trust all bundled CAs. Sure, power users can in theory remove CAs from the store (and add ones, like I do for cacert.org, as I use them for my domains).

The fact that I add cacert.org reminds me of another thing: There should probably not be any CAs that can sign arbitrary subdomain.TLD. Since I add cacert.org, they can empower someone to mitm all my tls connections. But that is a separate issue - this issue already exist.

Trust decisions is all about meaningful choice -- and choosing between not using the web, and trusting Chinese (and every other) intelligence, along with various foreign corporations (they're all foreign to someone) to not enable/be tricked into mitm my email, my web browsing etc.

Certificate pinning, among other things.

> have a sane UI for the rest

If any solution to this mess exists, it is going to require this UI. A fundamental problem with PKI is the trust decisions are not being made by the people that rely on that trust for protection.

What we need is pluggable trust, where it is easy indicate that I trust the shared-by-hand-only cert a friend made for chats between a few friends, a different cert for communications with my bank that I got a copy of by walking into a local branch, and some well-known CA for everything else. This is not "web of trust", though the concepts may overlap; this is about having a easy way to plug in whatever trust model you care to use and allowing different trust models for different endpoints.

> Until there's a free, easy, maintainable, and actually existent solution to SSL certs, enforcing HTTPS-only is just downright extortion.

True - but the second that solution exists, I can't think of anything that should stick with unsecured HTTP, and this article didn't change my mind. I don't think we need a "ban", though. Just flip the way browsers show secured vs unsecured, instead of the green reassuring lock for https, that becomes the expected default and http gets a scary red plaintext indicator.

> Until there's a free, easy, maintainable, and actually existent solution to SSL certs, enforcing HTTPS-only is just downright extortion.

> Referring to solutions that are under construction doesn't cut it. If you're that passionate about it, contribute to the SSL cert solution yourself instead of to the endless calls for HTTPS-only

Right. In similar threads, I've seen a lot of people linking to Let's Encrypt[0]. The idea of that project is great but, at best, all we can do now is discuss how to enforce HTTPS once Let's Encrypt (or something comparable) is available. Anybody who runs a small, personal website that generates no revenue would essentially be screwed if it were enforced before then, as (and someone can correct me if I'm wrong here) there aren't really any affordable options at this point for people who don't have much money to throw towards their site.

[0] https://letsencrypt.org/

StartSSL has been around for a long time, and issues free certs (with a $20 fee iff you need to revoke it before expiration).

I actually used StartSSL. It took, literally, days to figure out how to create the certificate. The next year I renewed it; it took, literally, days to figure out how to renew the certificate.

The next year I just paid someone to do it for me.

I would never recommend StartSSL to anybody.

It's true that the UI is obtuse, but there are step-by-step guides with pictures like [1][2].

[1] https://www.digitalocean.com/community/tutorials/how-to-set-...

[2] http://www.troyhunt.com/2013/09/the-complete-guide-to-loadin...

I renewed three certificates with StartSSL yesterday. It took me literally a couple of minutes to do so.

I have also written up how the entire process works (from generating the key to creating the CSR and getting the thing signed) for a specific (non-webserver) use case and while I don't claim my writeup is perfect, several people have had no difficulty following it in under 15 minutes, even though it was the first TLS certificate they ever installed.

So your point is both that it is so easy it took "literally a couple of minutes" but so difficult "you've written up how the entire process works" that you've had to share with "several people" so they could repeat the same exercise...

Seems like your narrative is contradictory.

Agreed. As an expert in various things, I have learned to try to shut my mouth when the topic is how easy those things are for novices.

A young friend is learning to program, so I set up a virtual server as a place for them to upload things. It was only when I went to give them the account information that I had to stop and think about how complicated the "easy" act of uploading files via SSH is. Shell commands, directory trees, working directories, the fact that the web site is in /var/www and what that means, why index.html is special, what ssh keys and asymmetric encryption are, what a bastion host is, etc, etc.

A part of this problem could be solved with sshfs

That's not contradictory at all. Plenty of system administration tasks fall into the category of "easy to perform but not self-evident to someone with no experience".

No contradiction, something being easy does not imply it being self-evident / obvious. There are many simple things that are non-obvious without retrospect.

You can't get wildcard certs so you'd have to do this for ever subdomain you want to use.

They're still free, whereas no other company (at this time) will give you a free certificate for a single subdomain year after year. If you are using so many subdomains that generating the CSRs and pasting them in StartSSL's CSR field is too much work, then maybe a paid wildcard certificate is the better solution for you. But as long as you can count the subdomains that need a certificate on one hand, I'm not going to pay some other company $50 (maybe more? not sure) for something that takes me less than half an hour per year.

1 company where it's kinda sorta not-so-hard to do SSL is not good enough. If we're going to go HTTPS-only it needs to be as close to as easy to get them as it is to install apache on your old laptop and serve some html you wrote.

What irks me is that the biggest HTTPS-only advocates (mostly Google employees) simply do not care about this problem. They do not address it.

> essentially be screwed if it were enforced before then

Let's Encrypt, if it goes according to plan, is only a few months away. It's not just some fairytale that we're hoping will come true someday. It could be reality very soon! It's got some pretty big names behind it, including one of the Big Three browsers, so I'd say that it has a pretty good chance of success.

And if Let's Encrypt fails, surely someone else will try something similar in the near future. Some registrars are already handing out a free certificate with every domain. I got ~10 certificates in the last year alone, half of them for free (StartSSL) and the other half for $5/yr (PositiveSSL). The momentum is there, it's irreversible. Even if we don't hit $0, we're asymptotically headed toward it.

Moreover, given the pace at which governments and other large organizations move, I have zero worry that HTTPS-only will be "enforced" before free certificates become widely available. Ditto for browser vendors. Chrome will not risk blocking non-HTTPS websites before the time is ripe, because if it did, people will just delete Chrome and move to another browser.

This whole debate is just a bunch of FUD concerning entirely unrealistic scenarios. Why are we spreading this sickening FUD instead of, say, supporting the two well-known organizations (EFF & Mozilla) that are trying to bring free SSL to everyone?

> But they could just as well look over my shoulder

That's not a good argument. "Over my shoulder" surveillance is very hard to achieve covertly and consistently and is much easier to detect than digital surveillance. It also scales pretty poorly compared to digital one, at least until we get cameras that can record in every direction with resolution enough to read computer display from a dozen meters and put them literally on every wall.

> Until there's a free, easy, maintainable, and actually existent solution to SSL certs, enforcing HTTPS-only is just downright extortion.

> Referring to solutions that are under construction doesn't cut it. If you're that passionate about it, contribute to the SSL cert solution yourself instead of to the endless calls for HTTPS-only.

So you want a free, easy, and maintainable solution, but you don't want to talk about solutions that are currently under development? What kind of argument is that? It's as if you specifically added that condition to preempt any discussion about Let's Encrypt. Guess what, a lot of us actually are passionate about this solution, so we're actually contributing to that project by supporting EFF and Mozilla.

The call for HTTPS-only does not ring in a vacuum. Context and timing are critical for any plan that might involve a chicken-and-egg problem. But that's not an insurmountable problem. The proposed enforcement will come into effect some time in the future (if ever). So we still have a few months, maybe a couple of years to prepare for it. That's enough time to build a free CA that can disrupt the shit out of the extortionist market.

Opposing a plan for the future just because a prerequisite does not exist right now is gratuitous negativity, especially if you're deliberately ignoring "actually existent" efforts to build that prerequisite.

Yes, I intentionally wrote that to preempt discussion of Let's Encrypt because Let's Encrypt isn't a working solution yet. If/when Let's Encrypt is a working solution then let's continue the discussion / send "the boys" to break kneecaps wherever someone's using HTTP / etc.

If Let's Encrypt is as close to completion as HTTPS-only advocates claim, then you have very little to lose by simply waiting until it's finished, and then start the evangelism. It isn't like we're standing at a cusp and tomorrow some committee's going to vote whether to permanently ban HTTP or permanently keep it. Right now it's like you're a doctor yanking a patient's access to an important medicine because "there's a better medicine coming along, it's in the last stages of clinical trials, it should be ready any month now".

No, we're like a doctor who is threatening to yank it, with the explicit goal of pressuring others to bring forth a better medicine sooner. Nobody's actually yanking anything yet, and since this is the federal government (of healthcare.gov fame), I don't expect them to yank anything effectively anytime soon.

A doctor using prescriptions to pressure clinical trials into going the way she wants them to. What could possibly, possibly go wrong. (What does that even mean, nobody's actually yanking anything, they're just threatening to do so to coerce people? It sounds creepy and manipulative.)

The analogy breaks if you take it too far. This is politics, not medical science. Good clinical trials will discover facts about the world. Good politics will change the world, making previously discovered facts irrelevant.

Threatening one another into taking action is exactly how progress happens in a market economy. Somebody is always threatening to drive somebody else out of business. Either you disrupt or you are disrupted. And since we probably won't be getting rid of this ruthless system anytime soon, I'd rather want to see the good guys drive the bad extortionists out of business rather than the other way around.

It feels to me that this is very similar stunt to encrypting smart phones. After Snowden published details about various spying programs, people became more cautious when communicating.

This is just to convince general population that now it is safe again and you don't have to worry about someone snooping on you, because the communication is encrypted.

Yes, your communication with let's say Google is encrypted, but that doesn't mean Google won't share your data to the three letter organizations. And this is the simplest way, ignoring NSAs various efforts to place vulnerabilities in encrypting software.

Similarly as with phones encryption, it doesn't really help that much, for example when last time NSA ever needed physical access to your phone?

IMO, this is where benevolent dictators come in.

Banning, discouraging, creating a market for 'solutions to SSL' and evolving the whole thing together is a challenging proposition.

FUD

Snailmail and spoken word are much harder to snoop en masse. Apples, oranges.

Snailmail and spoken word are also much harder to use legitimately en masse. Consider the cost of an email campaign vs. a snailmail campaign.

I can easily intercept all snailmail my neighbour gets and peek through it. I cannot do that for his http-traffic.

You can if you hack that internet box on the corner of your street. Also, your local internet provider can.

it's only extortion if we ignore little things like the definition of the word and the reality of the situation. I guess it would weaken your argument's emotional impact to drop the hyperbole but I feel no particular obligation to accept the way you desire to frame the debate. I find your shallow obvious attempts at emotional manipulation into your point of view to be rather gross.

This issue was raised on a proposal that "would require the use of HTTPS on all publicly accessible Federal websites and web services"; presumably the government would simply become a certificate authority to make the transition smooth.

Physical snail mail and spoken word are far, far more difficult to do bulk captures and data mining against. That's the point.

Reply on news.ycombinator.com