
Dispelling common arguments against HTTPS - pantalaimon
https://scotthelme.co.uk/https-anti-vaxxers
======
Spivak
I feel like it's poor taste to try invalidate an opponent's argument by
associating them with some unrelated group that's en-vogue to hate. It doesn't
add anything meaningful to the argument, it exists just to start fights, and
it's a silencing tactic.

"But they're actually similar, their arguments are just like... blah blah." I
don't care. It doesn't really matter. I would think we can do better than
"this argument is bad because it sounds like this other bad thing."

We really need to stop with the glassy-eyed rhetoric about securing the web or
the glorious utopia HTTPS everywhere will be or that people who dislike TLS
hate security or puppies or whatever. If they're wrong or misinformed that's
should be the end of it. The message should be concise and to the point.

TLS is worth it.

* Yes, it's going to be a PITA to implement and probably means retooling plenty of legacy systems. But the tooling to help is getting better.

* Trust will always be an issue. Certificate transparency is helping.

* Yes, it will require automation if you want a site to be accessible indefinitely. Yes, it does create more work for you to develop that automation or manually rotate certs.

* Yes, it is more complex than HTTP by a huge margin. Cryptography is hard. Security is hard.

* Yes, it's going to cause software rewrites.

* Yes, certificate expiration is a pain and will probably bite you in the ass a few times over your career.

* Yes, major players are going to reward your use of TLS and punish its absence. It's something you're just going to have to deal with.

Telling people that their problems aren't problems never solved anything.

------
apostacy
I have to say, I find this article highly insulting. People who are skeptical
of trends being pushed in the technology ecosystem are not the same as anti-
vaxxers. Frankly, people who think that blindly following the edicts of self
interested corporations will keep them safe are the ones who are deluded.

There are many good reasons to be suspicious of calls to deprecate things.
Very often, when Google, Apple, or Microsoft announce that something is being
deprecated, it is of no benefit to the end user, and is just a flimsy way of
covering up a feature regression, or worse, a self serving attack on a
technology that competes with their own.

Was anyone asking for the "save" feature to be removed from HTML5 video? Does
anyone seriously think that the locking down of app stores is about helping
the user be secure, and not about stamping out competition?

There is no rational reason to not continue to support HTTP indefinitely. The
fact that a user could potentially be tricked into going to an insecure site
means absolutely nothing, because a user could be tricked into doing anything.

The fact that a browser might not give me, the user, the choice to do
something potentially dangerous is ridiculous. HTTPS is not, and probably will
never be as easy to set up as HTTP. Even if you had a script that could
automatically configure my server, and continue to work reliably indefinitely
(and you don't) it would still be inferior to HTTP.

I can access a service over HTTP from over a decade ago, and it will still
work. I want to be able to, if I want to, with little effort, set up a server
that can be accessed by a web browser. I do not want to have to have any third
parties involved. I also do not want to have to set up a certificate authority
or anything like that.

Companies like Google benefit from making the rules of what a web browser
should be. They are happy to take the hit, if it makes it harder for everyone
else. Does anyone think that Amazon.com _wants_ to pay sales taxes? No, but by
pressuring the government to collect taxes on them, it harms their competition
more.

~~~
shakna
> There are many good reasons to be suspicious of calls to deprecate things.

What call to deprecation?

All that's being done is letting a user know if or if not their content could
have arrived from the server without being intercepted.

> The fact that a browser might not give me, the user, the choice to do
> something potentially dangerous is ridiculous.

Currently, all browsers allow you to send generally sensitive information over
HTTP, they just warn you first.

> I can access a service over HTTP from over a decade ago, and it will still
> work. I want to be able to, if I want to, with little effort, set up a
> server that can be accessed by a web browser. I do not want to have to have
> any third parties involved. I also do not want to have to set up a
> certificate authority or anything like that.

You can. That hasn't changed.

------
RIMR
It's really telling that every anti-HTTPS opinion I have ever heard expressed
is either ten years out-of-date (too slow), or completely and totally bonkers
(NSA backdoor).

It seems to me that for-profit bloggers will be contrarian for pageviews, and
aren't afraid to lie if enough stupid people will believe them.

~~~
unqueued
HTTPS is a pain compared to HTTP, and I should not be pressured to use it,
especially if I am on an internal network. Lets Encrypt has made it much
easier, but it is still a significant and unnecessary barrier. And as helpful
as things like the Lets Encrypt bot is, it still cannot be relied upon.

And anyone who doesn't think we are being spied upon is bonkers. It doesn't
matter how secure HTTPS is, because there are so many other ways we can be
monitored.

~~~
shakna
> And anyone who doesn't think we are being spied upon is bonkers. It doesn't
> matter how secure HTTPS is, because there are so many other ways we can be
> monitored.

HTTPS doesn't guarantee that, and certainly isn't state-actor proof, but if
state actors are your concern, you need more than HTTPS, not less.

What it does, is ensure nobody messed with the data before you get it. The
browser indicates that to you.

Basically:

HTTP - Sir, are you aware someone may have changed what is in this enevelope?

HTTPS - Sir, this letter has/not been tampered with.

------
amanzi
I thought this article was in poor taste and I actually have a lot of respect
for Scott and the work he's doing in this space. For a better site with
positive arguments for HTTPS:
[https://doesmysiteneedhttps.com/](https://doesmysiteneedhttps.com/)

Previous discussion here:
[https://news.ycombinator.com/item?id=14753993](https://news.ycombinator.com/item?id=14753993)

------
acomjean
I moved the non-profit's website I maintain over to HTTPs.

My own personal site has both. Though frankly that site is static. Oddly I
find it useful to have that http site when trying to use some hotel wifi where
you need to connect through a splash page. The https don't redirect..

I'm actually surprised this is an issue at this point.

~~~
goblin89
> I find it useful to have that http site when trying to use some hotel wifi
> where you need to connect through a splash page

I’m in that situation frequently as well. While desktop Firefox deals with
captive Wi-Fi portals, on mobile trying to open a personal site of mine over
HTTP and letting the request get redirected seems to be the only way I can
manage to unlock access to Wi-Fi in some airports.

Even though that site gets little to no traffic except for myself or
occasional crawler, the situation bothers me. The reason HTTPS breaks poorly
implemented captive portals is directly related to why we’d want HTTPS in the
first place. Unreliable or absent HTTPS means a user visiting your site is
susceptible to request & response manipulation and injections of undesirable
content, from trackers to malware, by an ISP or another intermediary.

~~~
lostmsu
You can just use pages, that big corps are using for that. E.g. I use
msftconnect.com/redirect

------
sarcasmic
The problem with name-and-shame posts, other than their juvenile premise, is
that you can read up on what the people in question say, and call the author
on their shit. Once you do this, you realize that one these objectors is not
like the others, because once you discount the last few entrants' unjustified
snake oil and utter quackery, you're left with Dave Winer's objections to
Google's strategy on increasing the adoption of HTTPS by more and more
explicit visual indicators of HTTP being 'non-secure' [1] and Mozilla's
differently-worded, but comparable approach to 'deprecating' HTTP.

By cherry-picking his most abrasive soundbites and his most entitled-sounding
Twitter replies, Scott handwaves away Dave's more reasoned frustrations, such
as his 2016 lament [3] that his current webhost doesn't offer a no-cost, push-
button way of enabling HTTPS, and that his long-runing, statically-hosted blog
would now require ongoing maintenance to stay compliant with the ever-changing
list of requirements Chrome and Mozilla set in service of a larger goal. He
wonders that if UI changes don't have the effect Chrome and Mozilla are hoping
for, will more drastic changes follow, like refusing to display HTTP pages
altogether, and reading his words he doesn't appear to buy that static, read-
only sites need strong assurances of identity and resistance from third-party
tampering, especially not at the risk of potentially making access to those
pages impaired in the most popular browsers forever.

Dave clearly questions the true motives of Google's promotion of HTTPS, but
Scott is right that Google never said that they'd deprecate HTTP. But Mozilla
did [2].

I don't agree with all of Dave's points, and I think that for most of the
websites people these days actually visit, strong assurances of identity and
resistance from third-party tampering are important. But it's unfortunate that
Scott tries to present an uncharitable view of Dave's worldview, instead of
letting his points stand on their merits.

[1] [https://security.googleblog.com/2016/09/moving-towards-
more-...](https://security.googleblog.com/2016/09/moving-towards-more-secure-
web.html) [2] [https://blog.mozilla.org/security/2015/04/30/deprecating-
non...](https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-
http/) [3]
[http://scripting.com/liveblog/users/davewiner/2016/01/30/095...](http://scripting.com/liveblog/users/davewiner/2016/01/30/0956.html)

~~~
shakna
> It should be noted that this plan still allows for usage of the “http” URI
> scheme in legacy content.

Mozilla aren't deprecating access to HTTP, but rather new features for pages
accessed over HTTP, features that can allow new attacks to surface for HTTP
pages.

You should also note no date has been set, since that document was written
three years ago.

------
peterwwillis
I like how the author vacillates between "securing the web", "securing all
traffic" and "encrypting the web". Because those things are totally the same
thing.

I actually had a whole rant ready to go about how people pushing HTTPS like
it's Web Contraception is actually harmful to end users and organizations
alike, but it appears there are genuine whackos out there now who have picked
up on all the flaws in HTTPS and are making up things as they go now.
Interesting.

------
testplzignore
Comparing anti-HTTPS people to anti-vaxxers is a terrible comparison and
obvious clickbait. If someone believes that HTTP is good enough, fine with me
- it doesn't hurt anyone. If it's a company, their customers can take their
business elsewhere if they care. On the other hand, anti-vaxxers cause harm to
others due to herd immunity, plus their children usually have no choice in the
matter.

~~~
amputect
I would agree with you if this was just a list of people who think HTTP is
good enough.

If you read the article it's not "HTTP is good enough" it's "HTTPS is too
slow" or "HTTPS is a plot by Google to take over the web" or fundamentally
misunderstanding the value proposition of HTTPS or straight up lying about
what it does.

Anti-vaxxers is absolutely a valid comparison here, the people in this blog
aren't just not using HTTPS, they're actively encouraging people in their
capacity as professionals to avoid using it, for really dumb and dangerous
reasons that don't stand up to even the slightest scrutiny.

