
Living with HTTPS - daniel02216
http://www.imperialviolet.org/2012/07/19/hope9talk.html
======
tptacek
This is pretty great. I guess he gave this talk at HOPE, but it's laser scoped
to startups, down to the order in which he gives the advice:

* Enable HSTS

* Don't link to HTTP:// javascript resources from HTTPS pages

* Set the secure flag on cookies

Very few of the sites we test enable HSTS. But it's easy to do; it's just an
extra header you set.

The only quibble I might have is the fatalism he has about mixed-security
Javascript links. I'd go further than he does: when you source Javascript from
a third party, you have leased your users security out to that third party.
Don't like the way that sounds? Doesn't matter: it's a fact. Companies should
radically scale back the number of third parties that they allow to "bug"
their pages.

~~~
NateLawson
All of these are good recommendations.

Another technology to start preparing for is TACK. It allows you, the server
owner, to control browser pinning of your certs while maintaining CA mobility.
This gives you the control over your security that Google has over Gmail via
Chrome cert pinning without having to issue a new browser build every time you
change CAs.

One way to think of it is like a domain transfer lock but with cryptography.
You control how you unlock your pin to allow mobility to a new CA by sticking
a signed file on your SSL server.

<http://tack.io/>

[Disclosure: one of the authors of TACK is a former co-worker.]

~~~
justauser
I see Moxie is one of the authors on the draft. Is this an outgrowth/pivot of
Convergence?

~~~
moxie
The way I see the relationship between Convergence and TACK is that
Convergence is trying to provide trust agility for when we need to trust third
parties, while TACK is trying to reduce the amount that we even need to trust
a third party at all.

I think the first problem gets considerably easier to solve once the latter is
in place, and there's a lot we could do with Convergence-like systems that
would make them more deployable if TACK is adopted.

In the short term, however, TACK stands on its own, and we hope it's a fairly
uncontroversial proposal that will be easy to integrate into the ecosystem.

------
agwa
> There's a second collarary to this: attackers can set your HTTPS cookies
> too.

If your app uses session ID cookies, then another implication of this is that
attackers can set a user's session ID to a value they know, wait for the user
to log in, and then use the session ID to hijack the logged-in session. To
prevent this make sure you regenerate session IDs when logging a user in.
(This isn't the only reason to regenerate session IDs on log in but it's a
very compelling one.)

~~~
tptacek
This is called "Session Fixation". Most modern frameworks prevent it, which is
a reason to use your framework's session functionality rather than re-
inventing it.

Session fixation used to be a common problem. There were lots of J2EE
applications which were not only fix-able, but which would allow an attacker
to fix a session ID with a carefully crafted GET URL. It's much rarer now.

------
jenseng
The author seems to gloss over the importance of browser built-in HSTS lists.
If you're just relying on a response header to tell the browser to use HTTPS,
aren't you still vulnerable? Isn't that the same fundamental problem with
redirecting to HTTPS via Location headers?

In other words, a MITM could downgrade any HTTPS traffic and simply remove
that STS header. The browser would be none the wiser.

~~~
tptacek
No, that's not how STS works. Once the header is set, a MITM can't simply
clear the header; the purpose of STS is to tell the browser to _remember_ that
the site is HTTPS-only.

You are, obviously, vulnerable on first contact to a site, in that an attacker
can prevent you from ever seeing the STS header. The point of STS is that
attackers don't generally get to intercept your first contact with a site.

Adam Langley, by the way, is one of Google's Chrome SSL/TLS/HTTPS people.

~~~
jenseng
I should clarify, I was referring to the first visit to the site. So yes, I
can see how this greatly reduces the vulnerability, though it doesn't
completely remove it.

As an example, a rogue Apple Store employee could insert him self as a MITM
between the access point and the internet connection. Anyone testing out a new
laptop in the store (or logging in to their bank from a just-activated iphone)
would be vulnerable, without the attacker ever having touched any of those
devices.

~~~
tptacek
There are a lot of real security issues HSTS doesn't protect against. But for
its miniscule cost, it does a very good job of protecting against one specific
real threat.

------
DannoHung
Please for the love of god, if you're working at google and read this: Add a
deeply set option to _FORCIBLY_ enable that button in all situations where it
might appear. We sometimes have certificate issues with our proxy server at my
workplace and it makes Chrome practically unusable when they happen.

I know what I'm doing. I'll reset the option when the underlying issue is
resolved, and overall it's a great feature for the browser, but I need to have
the ability to be responsible for myself.

~~~
tptacek
It's very straightforward for a proxy to have its own CA=YES certificate and
mint/sign certs for every HTTPS site the proxy sees on the fly. If you have a
corporate proxy that is intercepting HTTPS traffic, that is what it should be
doing.

Then, the proxy makes its certificate available to users, you download it, and
add it to your CA certs via the UI that browsers provide for that; HTTPS
magically appears to work again.

~~~
dekz
So the proxy server acts as a forced man in the middle? This has to be one of
the most atrocious things I have ever experienced. Forcing a man in the middle
is insane especially in a large company where there may well be a lack in
competency.

HTTPS shouldn't magically appear to 'work' again, considering it is completely
broken when a forced mitm is introduced.

~~~
tptacek
Are you arguing with me, or with reality? I can't tell, because the system I
described is how corporate proxies work pretty much everywhere.

If you want privacy against the administrators of your employer, don't use
your employer's network to do things that need privacy.

~~~
dekz
I don't see how my comment may be interpreted as starting an argument. I was
simply replying on your comment on HTTPS just 'work'ing once you ignore the
man in the middle attack. It's not privacy from an employer that is the
underlying issue. It is the practice itself which should be frowned upon.
People didn't spend their time trying to come up with the ability to have
secure communications from point A to point B just to have someone come in and
break it.

The problem isn't necessarily what the employer sees, it's what the might
employer keep around.

~~~
tptacek
Enterprises are making a policy decision to take advantage of the Internet
security model from the border of their network outward, but to take
responsibility for IP security inside their network. That is a reasonable
policy decision.

But even if reasonable people could disagree about that policy decision: the
reality is that people operating large corporate networks require the ability
to control SSL/TLS sessions; for instance, there are whole industry verticals
where accessing a private email server not controlled by your employer is
grounds for automatic termination, because regulations require them to track
and archive email messages.

Finally, and I'm repeating myself: I am describing the reality of _most_
Fortune-500 enterprise networks. In most corporate networks, you cannot simply
talk from your desktop out to the Internet; you are required to use a proxy.
You're also almost certainly on an 10/8 IP address.

------
sp332
Moxie published a tool called SSLstrip
<http://www.thoughtcrime.org/software/sslstrip/> here's a simple video
demonstration <https://www.youtube.com/watch?v=PmtkJKHFX5Q>

~~~
woobles
Very interesting. Thanks!

------
isaacaggrey
For users, HTTPS Everywhere is a must: <https://www.eff.org/https-everywhere>

Also, by using DuckDuckGo [1] over HTTPS you get the same ruleset in HTTPS
Everywhere [2] even if you don't have the extension installed.

[1] <https://duckduckgo.com/>

[2] [http://www.gabrielweinberg.com/blog/2010/09/duckduckgo-
imple...](http://www.gabrielweinberg.com/blog/2010/09/duckduckgo-implements-
https-everywhere.html)

~~~
harshreality
The chrome extension at least seems to break a lot of sites. They're not
kidding when they say it's alpha.

Pages include resources from https-everywhere'd domains and for whatever
reason (mostly that the ssl versions of those resource urls aren't serving the
same resources, or have broken certs) those resources fail to load. Within an
hour of using it I'd seen it break 3 or 4 sites, so it got disabled.

You can manually disable it for individual sites, _if_ you recognize that it's
the problem, but if some minor resource fails to load it might not be obvious.

~~~
mxxx
The reason the extension 'breaks sites' is because an alarming number of sites
are happy to serve unsecure content all over the place. See the refernece to
New York Times in the original article for an example.

------
timr
Honest question, for those who have done it: what are the _downsides_ of
allowing your whole site to be accessed via SSL?

Obviously, you need to be a bit more diligent about making asset urls
protocol-relative (which can be a PITA across a large, dynamically generated
site), but are there any other gotchas? Server load? Reduced cache-ability?

~~~
emmelaich
By protocol relative, are you referring to the // urls?

(<http://paulirish.com/2010/the-protocol-relative-url/>)

Because they wound't be so PITAish would they?

------
rogerbinns
It mentions the free StartSSL certificates, as does their page. But what isn't
clear is if the certificates are free to renew after a year (ie this is just a
teaser).

I currently use a self signed cert and certificate patrol, but apps (in
particular Thunderbird) are becoming increasingly hostile to that.

~~~
spindritf
> what isn't clear is if the certificates are free to renew after a year

Yes, they are. StartSSL will even send you a reminder e-mail.

------
jastr
HTTPSEverywhere is a firefox/chrome browser plugin, that will ensure
connections that can be HTTPS are. It also does a good job preventing ssl
stripping.

<https://www.eff.org/https-everywhere/>

------
rdl
This was by a wide margin my favorite talk at HOPE this year.

(and a great advertisement for using Chrome in secure settings where you need
a web browser)

The irony of Google being one of the main http-only JS resources for a long
time was kind of amusing, though.

~~~
abraham
What do you mean by "Google being one of the main http-only JS resources"?

~~~
rdl
Adsense.

Also I think GA was http only at some point.

~~~
abraham
Adsense can be an issue. At least it isn't a requirement for site
functionality though.

GA has had https support as long as I can remember.

------
clarkevans
I'm wondering if there could be an equivalent DNS entry that might help signal
a site should only be accessed via SSL? Then you could possibly protect
against initial access as well as returning users.

~~~
agl
We can't do a blocking DNS lookup other than for A/AAAA records. About 5% of
Chrome users cannot resolve TXT records because the network is filtering the
DNS requests. (i.e. we know that the network is up and we're asking about a
DNS name that we known exists, but we get a timeout.)

~~~
sadpluto
In [1] you showed us how to authenticate via DNSSEC HTTPS in Chrome. If I
understand correctly this involves a lookup of a TYPE257 record. Given that
only 5% can resolve TXT records, do you know what % of Chrome users can then
resolve TYPE257 records?

Digressing a bit further, wouldn't you say that even if HSTS is enabled _and_
registered in the all the browsers' built-in list, you still have the problem
of unencrypted DNS lookups? (Maybe this kind of attack is orders of magnitude
harder to implement. I honestly don't know.)

[1] <http://www.imperialviolet.org/2011/06/16/dnssecchrome.html>

~~~
tptacek
No. The whole idea of HSTS is that you can never trust the DNS; you assume
that's the most likely way an attacker is going to MITM her victims. HSTS
tells the browser to remember that from that point on, all connections to
SERVER.NAME have to happen under a TLS session with a valid cert.

~~~
sadpluto
Thanks for your answer! I'm more confused by the moment about DNSSEC et al:
isn't the DNSSEC-based validation of HTTPS referred to above supposed to get
rid of CAs in the future? That wouldn't make sense even with DNSSEC
considering that the information is not encrypted? (Right?) I hope you don't
take this as "hijacking", but I'd be most curious about what you and other
security experts think about Paul Vixie's "Whither DNSCurve?" [1], which has
amazingly not been submitted in HN. I just submitted it [2].

(If I could vote for your time investment, please kindly consider commenting
on that article before replying to this comment.)

Thanks again!

[1] <http://www.isc.org/community/blog/201002/whither-dnscurve>

[2] <http://news.ycombinator.com/item?id=4268461>

~~~
tptacek
There is a splinter group of people- who- want- DNSSEC who argue that DNSSEC
will obviate the need for CAs. There reasoning, distilled, is that DNSSEC is
itself a PKI, with the roots signing TLDs and TLDS signing domains and so on.
Since the core architecture purpose of certificates is to "break the tie"
between an attacker's public key and the real site's public key, and since
DNSSEC zones could serve the same purpose, by housing a DNSSEC-signed public
key, blammo, no more Verisign.

There are a bunch of problems with this idea. Most of the ones that spring to
my mind are problems with DNSSEC in general: its brittleness, the reliability
problems I think it's going to cause, the things it does that actually
diminish the security of the DNS... but the big point relevant here is: DNSSEC
replaces a market of CAs with a baked- into- the- Internet fiat authority. If
DNSSEC had replaced SSL CA's in the mid '00s, Ghaddafi's Libya would have been
Bit.ly's CA. This does not seem like a win to me.

I don't think that rent-seeking SSL CAs are as big a problem as many HN users
seem to think they are. I think ultimately there's significant expense
involved in operating a secure CA, and that relative to their purported value,
CA certificates are reasonably priced.

The pressing problem with SSL/TLS is that CAs aren't trustworthy. They are
rent-seeking, as expected, but also shoddily operated. The Internet has
largely lost faith in the people operating CAs.

Moreover, a decade and a half of browser/CA relationships have left all the
major browsers riddled with skeleton-key CA certs run by organization that
nobody can really vouch for. As a result, large companies have purchased
browser-trusted CA operations, and then used them to do incredibly dubious
things. The companies that have been caught doing skanky stuff with their CA
keys haven't even been kicked out of the browser CA stores.

As a result, we're left with a situation in which untrustworthy companies can
potentially sign certificates for (and thus enable transparent MITM attacks
against) critically important sites, like Google Mail. That's an untenable
position.

I personally believe (and, yes, hope) that the future of Internet security
looks much like today, except with things like Trevor Perrin and Moxie
Marlinspike's TACK scheme, to allow security-sensitive sites to overrule bogus
CAs, and to allow us to gradually decrease the architectural dependence we
have on SSL CAs and start experimenting with more flexible alternatives.

I am not a fan of trying to take the same model that just failed us, but
centralizing it and handing it over to the unaccountable groups of people who
control the domain name system.

~~~
sadpluto
Wow. Thank you very much for educating us, Thomas. Your comments require
grabbing some popcorn or equivalent. In particular when you engage in a
constructive debate with someone of your caliber. One of my all-time favorite
threads in HN (or elsewhere...) is
<http://news.ycombinator.com/item?id=893659>. Thanks again.

------
zobzu
What I take out of this, beside things I knew of already (and most others as
well) is:

* Chrome wants to FORCE you to buy an SSL certificate.

* The guy suggest getting one from StartSSL BUT those are crap for 2 reasons: you can only have ONE domain, else you have to pay. The TOS are horrible.

So, dear imperialviolet, if you want me to use certificates that your company
trusts (and by extension, your users), get up with it and make Google provide
free, unlimited SSL certificates.

Til then, no dice.

~~~
jaggederest
If you can't afford the $43/year for a Thawte starter cert, you have no
business running a domain of your own. Seriously, less than $4 a month -
that's going to be dwarfed by any sort of hosting you might be paying for.

And it's only one domain _per cert_ , so your entire argument is silly.

~~~
zokier
Dwarfed by hosting costs? There is tons of shared hosting options in the
$50/year range which are quite usable for lots of purposes.

------
willfarrell
SSL/TLS & Perfect Forward Secrecy - <http://hackerne.ws/item?id=4267767>

------
kmfrk
Obligatory Django link: <https://github.com/carljm/django-secure>.

------
yorhel
Somewhat related question: It's fairly common for sites to have static files
(images/css) served on a different (sub)domain. What are you supposed to do
when the html content is being served on HTTPS? Should the static files be on
HTTPS as well? If so, wouldn't it need a different certificate? Certificates
are only valid for a single domain, after all.

~~~
rmc
You can get SSL certs that are valid for wild card subdomains, e.g.
*.example.com

~~~
agwa
Wildcard certs tend to be very expensive. If you only need two domains it's
probably more cost-effective to just buy two certs.

Edit: a downside of using separate certs is that you'll need to serve the
respective sites from separate IP addresses, or rely on SNI [1] which isn't
supported in older browsers. But if the use case is a separate domain for
serving static files, that's probably hosted on a different server/IP address
anyways, right?

[1] <http://en.wikipedia.org/wiki/Server_Name_Indication>

~~~
Erwin
A certificate can also have a number of alternate names, which providers call
a Unified certificate -- UCC. The nice thing about that is that you can
add/remove names after you've bought the certificate without having to go
through the process.

I haven't tried this in practice though, but this might be useful if you want
to provide a bunch of client.yourdomain.com secure subdomains from the same IP
address. Only downside is that the organization name will be the same.

~~~
peterwwillis
This is also wildly more secure than a wildcard certificate, where if someone
nicks your private key your entire domain is compromised, but with UCC only
select hosts' security could be compromised. I believe it's also supported in
more devices than SNI (since X.509v3)

------
honestq
honest question: why can't banks when customers open a new account, give them
a card with 1. the bank's ip addresses (in each region) and 2. their printed
public key (ssl or ssh format). and why doesn't the bank ask for a public key
from each customer? in-person key exchange.

no one even pays attention to the client side of ssl. how many of you use your
own ssl certificates? you basically can't under the cert authorty scheme. it's
a racket and no one is going to pay for these. and do the banks even care?
they use tactics like cookies and follow-up emails to verify customers
(hardware).

and why does the bank have to be able to switch their ip address without
telling anyone? what if the same was true for phone numbers? people would be
like wtf? load balancing? c'mon. too difficult ot type? thnk about the trade-
offs in security, all for the sake of not looking at a number? ipv4 is no
longer than an area code and phone number. just tell people where your servers
are and let them choose the one that is nearest. which incidentally, contrary
to conventional wisdom, is not _always_ the one that will be the most
responsive in the ever-changing state of the network.

there's nothing more annoying than being subjected to using trial and error
and you are not allowed to do any of the trial when the errors start coming.
out of your control.

what happened to the concept of "important numbers"? are we to believe you
only need to remember "google.com" or "yourbank.com"? that's a security
problem waiting to happen.

second honest question: why does bank website need to embed links to third
party reources and require that customers enable their browsers to access all
these indiscriminantly (user doesn't get to choose) and to enable javascript?

is javascript needed for security of a connect or to accomplish a financial
transaction? because that's all i need from the bank website.

i think we're past the point where customers need to be enticed to use the web
to do things like banking and shopping. they're going to be forced to. so we
can forgo the silly demonstrations and gratuitous use of javascript. save for
"show HN".

what we need is simplicity, reliability and security.

------
jerhewet
Does anyone have any recommendations for search terms I could use to put
together a list of news stories / posts about known man-in-the-middle attacks
that have occurred?

------
newman314
If includeSubDomains is set for HSTS, does that mean that a cert for
<https://foo.com/> is required instead of <https://www.foo.com/> in order to
protect cookies set for foo.com and under?

It's not clear to me from what docs that I have been able to find.

------
jenrzzz
Google Cache mirror if anyone needs it:
[http://webcache.googleusercontent.com/search?q=cache:http%3A...](http://webcache.googleusercontent.com/search?q=cache:http%3A//www.imperialviolet.org/2012/07/19/hope9talk.html)

------
kodisha
Any experience with CORS and https?

Does it work properly?

If i have www.mydomain.com with certificate A, and api.mydomain.com with a
certificate B, can i make CORS call with javascript?

(i know that if you try it with self signed cert, it will just drop the
request)

~~~
samt
Yes this works. Just get all the headers correct.

------
jordanthoms
I have a rails 3.2 site, and I hadn't thought about this much aside from
setting force_ssl to true. Turns out that automatically enables HSTS and
secure cookies - cool!

------
fijal
For what is worth Libya owned a trusted CA (maybe still does), which means
that MITM would happily work, because they can transfer all the certs to their
own authority. I don't personally see how this is more secure than my self-
signed certificate, which generates a warning that's these days very hard to
avoid (even if I _do_ know that the cert is fine)

~~~
tptacek
Stipulate that it's true that Libya owned a browser-trusted CA, and compare
situations:

With signed certificates, Libya can MITM (unpinned) certificate-backed TLS
sessions.

With signed certificates, random people cannot MITM (any) certificate-backed
TLS sessions.

With self-signed certificates, Libya can MITM any TLS session.

With self-signed certificates, random people can MITM any TLS session.

I'm not seeing the argument you're making here.

------
five_star
I learned a lot about internet security here. Thanks a lot!

