
The HTTPS-Only Standard - konklone
https://https.cio.gov
======
kysol
There's something about their favicon being the default green lock (
[https://https.cio.gov/assets/favicon.ico](https://https.cio.gov/assets/favicon.ico)
) that unsettles me. It feels like a social engineering trick.

~~~
konklone
That's an interesting point. I'll be straight, it's lifted right from
[https://istlsfastyet.com](https://istlsfastyet.com). And cio.gov is in the
HSTS preload list [1] so (once the list makes it into stable channels) the
chances of the domain being downgraded to plaintext are pretty low. But I had
not thought of that angle. Hmm.

[1] [https://18f.gsa.gov/2015/02/09/the-first-gov-domains-
hardcod...](https://18f.gsa.gov/2015/02/09/the-first-gov-domains-hardcoded-
into-your-browser-as-all-https/)

~~~
kysol
..and people complain about transparency :)

I wasn't calling it a social engineering trick, more that it just felt like
one. To the average person they wouldn't second guess the icon. To those who
believe in HTTPSAllTheThings, we question anything out of the ordinary.. and
that little padlock shouldn't appear in the tab.

As I said, it just felt weird, sort of the same feeling you get when you go to
Apple or YouTube and there's a warning on the lock icon. You just want to hit
the back button almost instantly fearing something dodgy is happening.

~~~
Already__Taken
You were absolutely right in calling it a trick. Browsers explicitly[0]
stopped putting the favicon there as sites started to trick users like this.

Seems like an odd choice of UI chrome that browsers decided to keep.

0: [http://www.wired.co.uk/news/archive/2012-04/25/firefox-
fires...](http://www.wired.co.uk/news/archive/2012-04/25/firefox-fires-
favicon)

------
bcg1
Hey gov, how about promoting a transparent decentralized system for
certificate signing that doesn't require paying a vig every year to a
corporation that can easily be leaned on by not-so-well-meaning authorities?

Oh wait, nevermind... I just realized something.

~~~
cesarb
> how about promoting a transparent decentralized system for certificate
> signing

Honest question: with a decentralized system for certificate signing, what
would be the trust root?

The current system has the browser makers as the root of trust; this trust is
delegated to a set of certificate authorities through the list of root
certificates which comes with the browser; these certificate authorities then
delegate to their intermediates, which finally certify a server as trusted for
a fully-qualified domain name.

Without a root of trust, anyone could say "I'm example.gov, this is my
certificate", and present "proof" of that. A trust root is necessary to
prevent this.

So far, the only working proposals I've seen for decentralized trust (which
don't do away with the human readability side of Zooko's triangle) are based
in distributed proof-of-work systems like Bitcoin's, where the trust root is
the distributed "chain". Has anyone ever tried to apply a system like that for
certificate signing for TLS?

~~~
pdkl95
The problem with achieving real adoption of crypto had historically been made
a _lot_ harder than it should be because too many problems are trying to be
solved at the same time.

Separate the problems! It is much easier to find realistic solutions when the
requirements are narrower. The remaining needs can be solved later on. Once
_some_ usable infrastructure has been established, it might be possible to
leverage that infrastructure to add back in some of the missing features.

For HTTPS, a good start would be PHK's suggestion of simply auto-generating
self-signed certs in apache _by default_ , as a replacement for plaintext.
Authenticating those certs can happen later.

After keys are everywhere, a potential solution might be t o allow _both_ PKI
authorities and some sort of web-of-trust (or other methods? blockchain?
something new?), and _exposing the source of trust to the user_ in way they
can manage.

There is no one-size-fits-all solution to the trust problem, so let the user
decide because they know what their requirements are. If I'm browsing to some
bank, a well-known PKI root might be a good trust source. If I'm chatting on
some local forum, a web-of-trust auth might be better (it's a local forum, so
fingerprints can be exchanged manually, friend-to-friend).

~~~
tptacek
Encryption is not separable from authentication.

~~~
CHY872
It _so_ is. A plain old Diffie Hellman key exchange will give you encryption
without authentication.

All you need for encryption is to be able to share a secret - this in no way
requires authentication.

~~~
apendleton
Without authentication your connection is susceptible to undetectable man-in-
the-middle attacks that DHE does nothing to prevent. That they're separable is
superficially true, but not interesting, as encryption alone doesn't stop
people from reading your traffic, which is the whole point.

~~~
pdkl95
This argument comes up so regularly, one might speculate that some people are
_trying_ to keep the internet in plaintext[1].

Yet again, encryption is a replacement for _plantext_ , which is the only
thing it should be compared to. Of course you can MitM attack it, but that's
not something that is easily done in bulk.

Simple encryption _raises the cost_ of an attack from "trivial wiretaps, DPI
optional" to the time, money, and effort required to do a targeted MitM
attack. Additionally, while it is generally impossible to detect wiretaps,
MitM can leak information that betrays the presence of an attack.

Remember, this isn't intended to stop all types of attacks. It is simply a
_very_ easy to implement feature that lets you replace plaintext with
something resistant (not proof) to eavesdropping in general, and proof against
some types of bulk surveillance.

Note: I haven't said _anything_ about presenting this type of non-
authenticated communication to the user as "secure".

[1] see PHK's "Operation Orchestra" talk

~~~
Natsu
It doesn't raise the bar high enough that the people who are _currently
snarfing internet traffic wholesale_ would bat an eye at.

It doesn't matter how secure the phone line is when you have no idea who
you're actually talking to. Especially when there are people with money, means
and access to make sure that you're always talking to them.

------
JoshTriplett
The most important line in this standard:

> All browsing activity should be considered private and sensitive.

~~~
skrowl
Clearly this government office isn't talking to some of the other ones, right?

~~~
sliverstorm
The Fed employs 2.7M people. I don't really understand the people who imagine
it's one great big well-oiled machine with everybody in agreement, on the same
page of the same playbook.

------
Millennium
The HTTPS-only folks mean well, and I support it as a stopgap solution, but it
is useful only in that it can probably be implemented more quickly than IPSec-
everywhere (or, if IPSec proves to be unsuitable, then some successor standard
with the same goal of encrypting all traffic).

The latter, however, should be preferred as a permanent solution. The Web is
by no means the only part of the Internet that needs to be secured.

~~~
cesarb
IPSEC and HTTPS work at different levels. With IPSEC, your computer can be
sure it's talking to the computer at 198.51.100.1 and not to any other
computer. With HTTPS, your browser can be sure it's talking to www.example.gov
and not to any other web server. Both work equally well against passive
eavesdroppers, but they authenticate different things and so will work
differently against active attackers.

~~~
azernik
In other words, IPSEC is useless without DNSSEC, and that isn't getting
universal adoption anytime soon.

~~~
cesarb
Oh, no, it's useful for what it's designed for: to protect communication
between two computers. If I have IPSEC protecting the connection between my
desktop and my internal DNS server, and between my desktop and my database
server, I know that connection to my database server is protected by IPSEC.

It doesn't protect the mapping between a computer name and a IP address, but
that's not its job.

------
kstrauser
Outstanding! This is wonderful news. I've heard people ask whether a given
site or protocol really _needs_ to be secure but I hold the opposite opinion:
everything should be encrypted unless there's a specific and compelling reason
otherwise. I'm thrilled that major organizations are coming to the same
conclusion.

------
some_furry
[https://istlsfastyet.com/](https://istlsfastyet.com/)

This is a step in the right direction. Worldwide HTTPS adoption makes the
Internet a safer place for everyone.

------
Someone1234
Great. When that is done, then do email with is frankly a far more retractable
problem in general (and a field where there is almost zero innovation or
improvement, thanks to Microsoft (Exchange/Outlook/Outlook.com), Apple (Mail),
and Google (Gmail)).

~~~
bitJericho
What's wrong with email? It's a 40 year old standard that still works great.

~~~
Someone1234
It is insecure in so many ways...

~~~
PaulHoule
One thing that amazes me is that I get a huge volume of spam emails that claim
to be from financial institutions. I use gmail for two reasons: (i)
deliverability to mailing lists I need to be on and (2) other mail programs
don't filter that junk out.

In 2015 it should be impossible to send a fake email from chase.com

~~~
bitJericho
If chase.com uses dkim and spf records and if your mail server is properly
configured then it is indeed impossible.

~~~
me1010
and, of course, DMARC -- so rejection policies can be set.

PGP FTW!

Now if only STEED would be implemented... [http://g10code.com/docs/steed-
usable-e2ee.pdf](http://g10code.com/docs/steed-usable-e2ee.pdf)

But, unfortunately, even mail from a properly configured mail server on
properly protected domain will still end up in gmail users' spam boxes by
default. Domain and server rep systems are a bear to work with.

------
PaulHoule
I guess this means you'll visit a government web site and 2 times out of 10
gets a popup that says the certificate is out of date.

------
jvehent
They also use a pretty strong TLS conf
[https://gist.github.com/jvehent/98fdfef139b6237f7bf5](https://gist.github.com/jvehent/98fdfef139b6237f7bf5)

What strikes me is that their conf is inaccessible to old client (no sslv3, no
sha-1 cert). Honest question: does the government think it's ok to break
website access from ancient clients (XPSP2 IE6)? Or will they be forced to
enable legacy ciphers when the first citizens complain? I'm genuinely
interested, because the topic of TLS modernity is a hard problem to solve. If
that was easy, google.com wouldn't be using RC4-MD5 and a sha-1 cert...

~~~
001spartan
With the number of attacks against SSLv3 and/or RC4, I think it's a good idea.
Especially given that it's a government website. With a target that large,
it's a safe bet that, at any given moment, someone is trying something against
that site. And really, who's going to access cio.gov from an XP box? Heh.

------
zx2c4

        > "the financial cost of procuring a certificate"
    

Doesn't the government have a few of its own CAs installed in every browser?
Can't they procure their own certificates for free?

------
pcunite
I want to select who my browser should trust. Kinda like how I choose which
NTP server to get my time sync from. Make it a popup the first time a browser
starts.

------
tem5050
Nice! They even go in to detail about cipher and protocol choices

------
u23KDd23
An HTTPS only standard is not going to mitigate MITM attacks which is
invariably the biggest issue regardless of perpetrators although this is
clearly a step in the right direction.

~~~
rando3826
Proper HTTPS is secure at MITM attacks. HTTPS can be MITMed if the certs or
local systems have been breached. But the MITM is just a byproduct of a
different failure. Absolutely any secure communication protocol has to be
honored by both parties for it to be secure.

~~~
u23KDd23
I think preventing MITMs when you don't have control of the local systems or
network architecture is important.

~~~
rando3826
But it's impossible. If I'm logging your keystrokes, game over. Unless you add
some firmware to do dsa encryption in your brain, and become very fast at
typing cyphertext.

