
Why HTTPS for Everything? - maxt
https://https.cio.gov/everything/
======
maxt
Here's a Mashable article about adopting HTTPS served via plain old HTTP:

[http://mashable.com/2011/05/31/https-web-
security/](http://mashable.com/2011/05/31/https-web-security/)

It worries me that major websites like this have still not made the switch to
HTTPS/TLS yet. Quite irksome are the reasons (actually, excuses) site owners
sometimes give like overhead, claiming switching over to HTTP/TLS will be
costly and annoying, or even worse - that their threat model doesn't include
HTTPS, and the burden is on the visitor to encrypt their connection to the
site. The onus is on _both_ parties to encrypt, instead of shunting the
encryption to the visitor. As for threat models, the news can be a sensitive
topic for some, and HTTPS can be of great service to visitors who enjoy their
privacy.

I enjoy initiatives like Secure The News[1] which is a small public awareness
campaign urging news outlets to adopt HTTPS/TLS. Initiatives like Google's
HTTPS Transparency Report[2] are great too and give us great insight into the
adoption rate of HTTPS/TLS:

[1] [https://securethe.news/](https://securethe.news/)

[2]
[https://www.google.com/transparencyreport/https/grid/](https://www.google.com/transparencyreport/https/grid/)

~~~
waqas-
im a lead dev for a large publisher. when we switched over to https we faced
the following non-trivial issues:

1\. a lot of third party advertisers/ad servers still run on http, these ads
need to be embedded via DFP usually, which you can understand does not work
out well. We made the switch months ago, to this date i am still making
advertisers switch to https.

2\. google says they give better ranking to https sites, thats simply not true
so far as i have seen. in fact, in the short run your site takes a hit. not
only that, in google webmaster console and google news, you cant shift from
http to https, you have to make new accounts for ur https sites. to this day i
do not know which ones is google crawling. For google news, my new https
account has yet to be approved after months, it looks like google just
magically shifts to https in google news. but if feels icky and hacky:
explicit is always better than implicit.

3\. microservices. remember those microservises that were all the rage? well,
its a bunch of different servers and subdomains, you have to shift all to
https when you shift the mothership to https.

while above points are valid, i still pushed in my org to shift to https. we
now use shiny stuff like http2 and web push, which is awesome. i'd recommend
all publishers to do so. but its understandable that management finds all this
scary, esp cuz its sounds like a major overhaul of your web assets (which is
everything when ure a web publisher) - even though it isnt really actually an
overhaul or anything.

~~~
izacus
> 1\. a lot of third party advertisers/ad servers still run on http, these ads
> need to be embedded via DFP usually, which you can understand does not work
> out well. We made the switch months ago, to this date i am still making
> advertisers switch to https.

So not only the ads collect personal data, slow down web experience and make
every non-adblocked site a pain to watch... you go the extra step to not even
encrypt transfer due to them?

~~~
Fnoord
Adblocking in 2016: using a HTTP firewall, blocking all HTTP requests by
default.

------
timthorn
I feel for later generations - learning tech gets harder and harder. Of course
as the sum of knowledge increases this must be true, but as we go HTTPS-only
the ability to type commands to a web server over telnet as a learning
experience will be a loss.

~~~
userbinator
...as is the ability to inspect the traffic in your network to and from the
devices you own. I think that is an even scarier situation, considering what
others have discovered about "smart" devices precisely because their traffic
was not encrypted. E.g.
[https://news.ycombinator.com/item?id=6759426](https://news.ycombinator.com/item?id=6759426)

Personally, I'm for HTTPS connections to things like government websites
(which is what this article seems to be mostly about), but against "HTTPS
everything" in the way it's going to be implemented.

~~~
test235
> but against "HTTPS everything"

You being against HTTPS everything, is the same as being in support of MITM
attacks somewhere. I am curious when is that the allowable case?

~~~
userbinator
I own my computing devices and I should be able to control the traffic they
create. Encryption must not prevent me from doing that.

~~~
pfg
Encryption does not prevent _you_ from doing that, just everyone else.

Of course, with non-free software and walled gardens, that might involve some
amount of reverse engineering, injecting a CA certificate in a trust store so
you can run a MitM proxy, or do something to bypass key pins, but that's never
really stopped anyone from finding out what an application is sending on the
wire.

You acknowledge that there is a certain amount of traffic that ought to be
encrypted, so you really need a solution for all applications either way.

~~~
ethbro
Effectively, I feel like it does prevent you from doing that due to the
reverse engineering necessity. The time multiplier between engineering vs
reverse engineering is too large.

Who's going to spend the time hacking through {random Chinese smart
lightswitch clone #8392727} that's sold in small volume?

There's going to need to be a legal "right to decrypt traffic" on black boxes,
if we're serious about this.

~~~
ufmace
And that's where we run into problems. How do we make it so that You can
decrypt the traffic from your devices, but random hackers, your ISP, the NSA,
etc can't? It's the same arguments against special decryption keys for the
Government - a backdoor for one entity can be exploited by other entities.

~~~
userbinator
_How do we make it so that You can decrypt the traffic from your devices, but
random hackers, your ISP, the NSA, etc can 't?_

The suggestion made at
[https://news.ycombinator.com/item?id=13303650](https://news.ycombinator.com/item?id=13303650)
of terminating TLS at the border addresses this --- traffic on the public
Internet is encrypted, but is decrypted in the private local network. In some
ways it is similar to a VPN. I run a filtering/adblocking proxy that works in
the same way.

~~~
ethbro
Any pointers on what the encapsulation for that would look like? It seems like
one good option, but I'd say it's only feasible if it doesn't require work on
the part of the manufacturer.

My other thought was just mandating a method of loading CA certs onto all IoT
devices using an open standard connector. If the owner so chooses.

------
ggregoire
Related: last week I deployed my web app for the first time, on AWS. In two
clicks and for free I've been able to create and configure two certificates,
one for the React app on CloudFront and one for the API on BeanStalk. Really
surprised and amazed how simple and smooth was the whole process. Thanks
Amazon for this.

------
dahart
> The IETF has said that pervasive monitoring is an attack, and the Internet
> Architecture Board (the IETF’s parent organization) recommends that new
> protocols use encryption by default.

While HTTPS does prevent just anyone from monitoring, I've long been under the
impression that the government, and possibly influential corporations,
probably have access to any certificates issued by the large CAs.

Is this a tinfoil hat theory? Is anything legally or technically preventing
this from happening, and/or are there ways for me to know when my own browsing
is truly private between myself and only the party at the other end, and not
other curious or intrusive uninvited third parties?

~~~
cesarb
> I've long been under the impression that the government, and possibly
> influential corporations, probably have access to any certificates issued by
> the large CAs.

Everyone has that access. Click on the padlock icon on any HTTPS-using
website, and after a few more clicks you can export a copy of the site's
certificate (at least on Firefox).

But that gains you nothing without the corresponding private key. The private
key is generated on the website's server, and is never sent to the certificate
authority (what is sent is a "certificate request", which has basically the
same information found on the certificate).

> are there ways for me to know when my own browsing is truly private between
> myself and only the party at the other end, and not other curious or
> intrusive uninvited third parties?

Now that's a different question. While having access to the certificates is no
problem at all, being able to create a new certificate for an arbitrary
website allows one to pretend to be that website. The only defense against it
is that, if a CA is caught issuing these certificates, it risks being removed
from the browser's trust lists, which is a death penalty for a CA's business.
Also, there is a new initiative (Certificate Transparency) to make it easier
for these certificates to be caught.

~~~
rhblake
> Now that's a different question. While having access to the certificates is
> no problem at all, being able to create a new certificate for an arbitrary
> website allows one to pretend to be that website. The only defense against
> it is that, if a CA is caught issuing these certificates, it risks being
> removed from the browser's trust lists, which is a death penalty for a CA's
> business. Also, there is a new initiative (Certificate Transparency) to make
> it easier for these certificates to be caught.

There is a defense against rogue CAs: HTTP Public Key Pinning (HPKP) [0].
Chrome, Firefox et al use a HPKP preload list, but unlike with Strict
Transport Security (HSTS) there currently appears to be no way to submit one's
own site for inclusion in the preload lists. See e.g. Mozilla's policy [1].

[0] [https://developer.mozilla.org/en-
US/docs/Web/HTTP/Public_Key...](https://developer.mozilla.org/en-
US/docs/Web/HTTP/Public_Key_Pinning)

[1]
[https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...](https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning)

------
c3833174
So, what's an embedded system supposed to do when it can't reach its NTP
server and needs to validate a cert?

~~~
lvh
As usual: it depends.

Why does it need to validate a cert? How acceptable is it if you get it wrong?
Depending on the answer, perhaps "have a more reliable clock" is the right
answer (plenty of embedded devices certainly have a decent idea of what time
it is, and if it's already big enough to validate TLS). It seems reasonably
probable that the NTP server stops being available for a reasonable amount of
time before you have no idea what time it is anymore and can no longer
validate certificates; so depending on the device, telemetry might be a good
idea too.

It doesn't sound like a reason to give up, though :)

~~~
c3833174
What I meant is:

\- Device is rebooted

\- Can't reach NTP, no RTC or dead RTC battery, happy that time is January
1st, 1970

\- HTTPS breaks

~~~
yjftsjthsd-h
You can reach a web host but not NTP? That seems like an edge case.

------
therealmarv
Main part is "When properly configured". I recently tried out Brave browser on
mobile which supports HTTPS everywhere. It slows the mobile web experience so
much down that it is not funny. I really like to have HTTPS everywhere but
unfortunately not everybody does a good job with that (Handshaking... SPDY,
HTTP/2 etc.)

~~~
nsgi
Interesting, do you get that when browsing HTTPS sites with mobile
Chrome/Safari?

------
wereHamster
Funny that this comes from *.gov. It's in their (the governments) interest to
keep traffic unencrypted so that they can intercept and store everything
(makes life of CIA/FBI/NSA easier). Why bother enforcing HTTPS? /me confused

The people at NSA are probably like "Oh god why? No, stahp it".

~~~
vtlynch
It's almost as if the government is made up of many departments and people who
have different goals and values...

~~~
konklone
And this is a White House policy, with their official blog post and rationale
here: [https://www.whitehouse.gov/blog/2015/06/08/https-
everywhere-...](https://www.whitehouse.gov/blog/2015/06/08/https-everywhere-
government)

"It is critical that federal websites maintain the highest privacy standards
for the users of its online services. With this new action, we are driving
faster internet-wide adoption of HTTPS and promoting better privacy standards
for the entire browsing public."

(Disclaimer: I work on [https://https.cio.gov](https://https.cio.gov), at
GSA.)

------
davidgerard
The thing that convinced my employer this was actually important was the
announcement that Chrome 56 would mark non-SSL login pages as unsafe. Cheers
to Google!

------
newman314
One thing I haven't necessarily seen raised is that including subdomains on
HSTS headers would also affect internal websites on the same domain.

I'd argue that it's a good reason/way to get all internal sites upgraded to
HTTPS but it might not be feasible for a large organization. So something to
consider.

------
dajohnson89
Isn't the CIO a presidential appointment? I wonder who the next one will be.
Or, will there be one at all?

~~~
konklone
Yes, the federal CIO is a presidential appointment.

------
ns8sl
All web traffic that is not encrypted is vulnerable to having its contents
altered enroute.

This is a type of man in the middle vulnerability that allows for javascript,
posts, etc. to be changed into something malicious.

------
ge96
A+ on Qualys yeaaaa

I see people mention Let's Encrypt, maybe I'm a sucker paying the $9.00 for a
year's worth versus free but every 90 days.

~~~
grzm
Let's Encrypt is set up to strongly encourage a completely automated set up,
including renewal. From my experience "but every 90 days" is effectively for
as long as desired.

~~~
ge96
Yeah maybe I'm just using it as an excuse for not learning to do Let's
Encrypt. If it's the same as a standard $9.00 domain validation SSL then I
could be saving that $9.00 by not being an idiot.

------
greggman
Is there any work on a solution for IoT or other end user programs/devices
that would benefit from being able to serve HTTPS instead of HTTP?

------
calvins
https.cio.gov SSL Labs test result:
[https://www.ssllabs.com/ssltest/analyze.html?d=https.cio.gov](https://www.ssllabs.com/ssltest/analyze.html?d=https.cio.gov)

Of note is that they're using a Let's Encrypt cert and running in AWS.

------
ArkyBeagle
"Today, there is no such thing as non-sensitive web traffic..."

I just don't agree. Is it sensitive for me to google a man page or look up
some algorithm or another? Because that's mainly what I use the Web for. The
Web - not intranet ( which is usually quite sensitive ).

Blog reading is sensitive? Hacker News? No, no they are not.

~~~
Veratyr
> Is it sensitive for me to google a man page or look up some algorithm or
> another?

It doesn't make sense to cut out such specific uses. The real question should
be "are my Google searches sensitive?" and the answer to that, for most
people, is "yes".

> Blog reading is sensitive? Hacker News? No, no they are not.

They're not particularly sensitive but they show anyone watching your internet
connection that you're interested in these subjects. Why let that happen when
you can not?

~~~
ArkyBeagle
The claim was that _ALL_ Internet traffic is sensitive. I provided
counterexamples. Position refuted.

I don't care who reads my Google searches. Hope they have plenty of coffee,
because it's pretty boring stuff.

I still get on Usenet. So I know at a very deep level that it's _all_ public.
All to the better.

------
andrewfromx
I use neverssl.com everyday

~~~
yjftsjthsd-h
Why?

~~~
andrewfromx
coffee shop wifi's will not connect unless u goto an http only site.

------
edblarney
A better question is 'why HTTP for anything'?

------
eclipsetheworld
Having a "https." subdomain feels so weird.

~~~
paulddraper
Yeah, should be https.www.cio.gov .

It's too bad the www.www.extra-www.org people are gone; they could have teamed
up for a new proposal.

------
Steeeve
It's worth pointing out that this is an effort to secure government sites: "A
Policy to Require Secure Connections across Federal Websites and Web Services"

Which makes sense to a degree and on the surface.

But it doesn't actually make sense. From an individual standpoint of "my
personal government held information should be secure" it certainly does. From
the standpoint that the government should provide easy and open access to data
it does not. And let's face it - browser warnings about bad certificates are
generally ignored, and the fact that they haven't presented one provides no
real confidence that a connection is in fact secure.

Should I really have to pay someone to find out if a car has been used as a
rental car or in an accident? Is there a real benefit to that data being
transmitted via an https session vs. a http session?

If I'm looking at a congressman's voting history, is there a real benefit to
that data being transmitted via an https session vs. http?

What's the drawback?

There's a layer of complexity in the way that isn't necessary or helpful.
Anybody who has done web based automation has run into plenty of issues with
expired / incorrect / insecure / misconfigured ssl certificates. And we've all
seen trusted certificate authorities compromised. Heck, some of us compromise
secure http ourselves pretty regularly as part of the development and testing
cycle. What happens when we're accessing data from a custom device with
minimal resources? Text processing and network connectivity is one thing.
Adding in encryption support and maintaining SSL is a whole different problem
to deal with.

And what happens when a guy working a low level office wants to expose a web
service for something like viewing an event calendar? There's additional work
to be done to obtain certificates and configure his web server to use them. So
now maybe he doesn't do it because the bureaucracy in place is too painful.

\---

I'm not a fan of making blanket decisions based on flimsy logic. I find it
ironic that their first reason for doing this points to a TAG finding that not
only points out several drawbacks, but lays out that one of the primary
reasons for preferring secure communication would be to minimize pervasive
government monitoring.

~~~
cesarb
Like many, you are forgetting the other half of what TLS provides. It's not
only confidentiality, it's also authenticity. It ensures not only that nobody
can eavesdrop the connection within the browser and the server, but also that
nobody can modify it, for instance to inject a piece of Javascript with a
browser exploit.

~~~
throwaway6845
He's not necessarily "forgetting" it and I wish HTTPS-everywhere advocates
would stop ascribing forgetfulness or bad motives. Some of us have a different
opinion based on our own genuinely-held beliefs.

Requiring HTTPS everywhere is weighing certain factors above others. For many
people, encryption and consequent lack of snooping/MITMing is an absolute
which outweighs all other possible factors. That's fine. You're entitled to
hold that belief. But please don't accuse others, who don't hold that as a
trumps-everything absolute, of "forgetting" or (like the guy upthread who said
"You being against HTTPS everything, is the same as being in support of MITM
attacks somewhere") arguing in bad faith.

~~~
dispose13432
>Some of us have a different opinion based on our own genuinely-held beliefs

Such as?

Browsing a website with an adblocker in a public place may literally give me a
virus.

That's what HTTPS everywhere protects against.

~~~
throwaway6845
Browsing any infected website, HTTPS or otherwise, may give you a virus.

~~~
konklone
Right, but if it's HTTPS, only the website can give you a virus. If it's HTTP,
the website can give you a virus, plus the owner of any network device your
requests traveled through on the way to and from the website. That's often a
lot of owners.

------
be21
Nazi Enigma encryption was cracked, because they encrypted everything, even
repetitive information like weather reports. Https for everything is promoted
by NSA.

~~~
Ao7bei3s
Modern ciphers are designed to resist chosen plaintext attacks.

------
kogepathic
It's great to see a positive attitude toward security also gaining support in
Government.

I just wish all software projects felt the need to be more secure [0]:

> Redis is designed to be accessed by trusted clients inside trusted
> environments.

> While Redis does not try to implement Access Control, it provides a tiny
> layer of authentication that is optionally turned on editing the redis.conf
> file.

> Redis does not support encryption.

This is just broken by design software development. [1] It's irresponsible in
2016/2017 to assume you have impenetrable perimeter security.

Redis' excuse is just bullshit. PostgreSQL supports authentication, SSL, and
even client cert pinning.

[0] [https://redis.io/topics/security](https://redis.io/topics/security)

[1] [http://antirez.com/news/96](http://antirez.com/news/96)

Edit: Loving the downvotes by butthurt developers who have never had a
security audit...

~~~
theGimp
Redis and Postgre are meant to play different roles.

If you don't like what Redis does, you're welcome not to use it.

~~~
kogepathic
> If you don't like what Redis does, you're welcome not to use it.

I like what Redis does, and it's also heavily used in industry. What I am
saying, not incorrectly, is that their approach to security is harmful to
their users. Most of whom won't know, care, or implement additional security
which they should.

It's the same argument with HTTPS. Of course HTTPS is optional in a web
server, but all major web servers support HTTPS, and there has been a
concentrated push to have more people using SSL.

e.g. LetsEncrypt

We should be making it easier for people to deploy secure services. Redis'
approach to security makes it extremely difficult for developers to deploy
secure services.

I'll say it again: It's irresponsible in 2016/2017 to assume you have
impenetrable perimeter security.

~~~
jrudolph
I don't get why it would be that way? It's built to be deployed in a DMZ on a
private network and that's how 99% of users (typically professionals) use it.

~~~
1_2__3
The idea of a hardened perimeter around a soft squishy interior has been
proven repeatedly not to work.

