
A basic guide to when and how to deploy HTTPS - gits1225
http://erik.io/blog/2013/06/08/a-basic-guide-to-when-and-how-to-deploy-https/
======
bad_user
If you want another reason for enabling HTTPS, even for shitty blogs - on one
of my visits to the US, I stayed at a motel that was snooping on my Wifi
traffic, injecting their own ads in Google's searches and displaying their own
banners in the websites I was visiting.

If you're the owner of a Wifi network, there are already available solutions
for monetizing users' traffic, by injecting ads, like this one:
[http://rgnets.com/](http://rgnets.com/)

So you, as the publisher of a shitty blog or website, do you really want ISPs,
motels or any other third-party to mess with your own content, to inject their
own scripts and frames in your HTML, to degrade the experience for your
readership?

One easy way of fixing that is HTTPS. HTTPS is not just for security or
privacy, it's also for digitally signing the content that's being served.

~~~
Sami_Lehtinen
Https doesn't stop them, mitm solves the problem for them. I'm sure you have
already seen it, if you travel a lot.

It's bad idea to redirect http to https. It's much better to drop http support
completely. Redirection weakens security.

~~~
flyt
This is why we have HSTS.

~~~
Sami_Lehtinen
And secure cookies, yes. But as we have seen, those things simply do not work
out. As the usual layered security approach, it's good idea not to provide
HTTP service at all, so redirection isn't hiding failures to use HTTPS.

------
jvehent
That's a good beginners guide. To take it a step further, check out the
documentation that we maintain at Mozilla:
[https://wiki.mozilla.org/Security/Server_Side_TLS](https://wiki.mozilla.org/Security/Server_Side_TLS)

~~~
herge
Also check out the "Quick Wins for Better Website Security" talk that Dan
Callahan (hey, I wonder where he works) at PyCon Canada.

[https://speakerdeck.com/pyconca/quick-wins-for-better-
websit...](https://speakerdeck.com/pyconca/quick-wins-for-better-website-
security-dan-callahan)

~~~
callahad
Hah! Thanks! I'll also be giving an updated version of that talk at PyCon in
Montreal this April. :)

There's a video of the PyCon Canada talk here:
[http://pyvideo.org/video/2315/quick-wins-for-better-
website-...](http://pyvideo.org/video/2315/quick-wins-for-better-website-
security)

------
njharman
Q: When to deploy https?

A: Always.

~~~
_delirium
For big sites, sure. But at least as things currently stand, that's
infrastructure-inconvenient and somewhat pricey on the low end, especially if
you operate multiple sites and they come and go as hobby projects. Not because
of the compute overhead (negligible for my uses), but because of the need for
a (non-self-signed) SSL certificate, plus a unique IPv4 address, for each
domain. Digital Ocean, for example, won't give you more than 1 IPv4 address
per VPS, which means you need a separate VPS for every side project, if you
want to go HTTPS. I prefer to multiplex all my tiny projects on one VPS,
saving both the extra $60/yr per project and the extra sysadmin overhead. Plus
$50/yr for the certificate, and $15 for the domain, and you have a startup
cost of $125/yr per side project... versus $15/yr that it currently costs me.
Not huge, but more than I want to pay, and raises the mental friction on
something that I currently consider near-free/throw-away.

If IPv6 actually gets deployed to the extent that I can have an IPv6-only site
without needing IPv4 addresses, and someone solves the SSL signing mess, I'd
be happy to use it.

~~~
elithrar
> Plus $50/yr for the certificate

This is certainly no longer true. $7 for a cert from Namecheap (domain
validated).

~~~
evolve2k
Just had a look at namecheap, can anyone explain the main reason to forgo the
PositiveSSL option ($7/annum) and take out their more expensive option;
EssentialSSL ($21/annum).

~~~
elithrar
You get a "site seal" with EssentialSSL. Both are equivalent on a technical
level, so go with PositiveSSL unless your users care about SSL branding (most
don't).

------
bastawhiz
The biggest barrier to HTTPS is the fact that it's a royal pain in the ass for
someone who's not an OPs guy to set up. Unless you're on a shared host or some
sort of PaaS that sets your certificates up for you, it's basically a big "go
fuck yourself" to get everything installed and configured properly.

Even the Mozilla article linked in the top comment asks you to choose a
ciphersuite. Who the heck has time to know and understand what to use, and
then figure out how to make it work on their own server?

Oh, the version of Apache you're running combined with the version of OpenSSL
that comes pre-installed on your Linux distro causes "Re-negotiate handshake
failed" errors? Good luck finding the answer to that on StackExchange.

For most folks that are just trying to ship something, unless security is a
huge issue HTTPS doesn't come first because it's simply too much work. And if
HTTP works out of the box, there's little incentive to turn on HTTPS.

~~~
velis_vel
I was able to get basic SSL working with basically no effort just by Googling
around for 'SSL nginx'; the Mozilla article doesn't tell you to choose a
ciphersuite, it tells you 'use this one unless you know what you're doing'.
And then if you scroll down it gives you some configuration directives you can
just copy-paste into your browser config file.

I'm not even an ops guy and I was able to get it working for my (granted,
fairly simple) site without any pain.

------
lsh
I have dozens of unique domain names to secure and growing. The cost of buying
an individual cert for each one is prohibitive. What can be done instead?

~~~
lsb
No it's not, it's literally $0.
[https://startssl.com/?app=1](https://startssl.com/?app=1)

~~~
duncanawoods
I recently tried the free startssl cert.

Fine on IOS/OSX/W7 Chrome/Safari/Firefox/IE but it was rejected by Android
default browser where startssl must not be a known CA.

I don't think I can do without Android.

~~~
sampk
Either you misconfigured it or you tested using Android <2.1[1] which accounts
for less than 1% Android users.

[https://code.google.com/p/android/issues/detail?id=21632](https://code.google.com/p/android/issues/detail?id=21632)

~~~
duncanawoods
Thanks for the link, it helped me get there. I followed the documentation and
tutorials for nodejs/express which defined the cert and key. As your link
suggested, mobile browsers are less lenient about missing intermediate ca
information so adding this solved it:

    
    
        var express = require('express'),
            path = require('path'),
            http = require('http'),
            https = require('https'),
            fs = require ('fs');
        
        var app = express();
        
        var options = {
          key: fs.readFileSync('cert/rsa.key'),
          cert: fs.readFileSync('cert/rsa.crt'),
          ca: fs.readFileSync('cert/sub.class1.server.ca.pem') // needed this
        };
    
        https.createServer(options, app).listen(443);

------
aeon10
Alot of ecommerce sites (Amazon, Flipkart) seem to use HTTP over HTTPS. Even
when you're logged in. These sessions can easily be hijacked. I assume this is
because of the handshake latency of HTTPS. Is there no way around this latency
to make your website feel faster? I imagine there isnt, because even amazon
uses HTTP.

~~~
joevandyk
amazon uses https for any important/sensitive pages. there's two sessions, one
for http, one for https.

~~~
aeon10
Can you explain more on how two sessions would work? I mean if the hijacker
hijacks the http session he can convert it to https by following the same
steps the user does. Since amazon does not ask the user to reauthenticate on
https pages.

~~~
amarraja
You can set the secure flag when creating a cookie which will only send it
over an HTTPS connection.

It is possible to use both schemes, but it is likely better to stick to all
SSL if possible in case of developer error causing something to get exposed
when it shouldn't.

------
drcode
Anyone know of a good ACTUAL guide for deploying HTTPS? i.e. ins and outs of
different certificate types, configuring on popular backends, etc?

I always have to stumble through this painfully every time it comes up again.

~~~
im_a_lawyer
you are pathetic

~~~
drcode
Because I don't enjoy SSL configuration?

~~~
lsh
"im_a_lawyer" is a little weird/poisonous. Ignore him.

------
aioprisan
Most eCommerce sites do not deploy SSL site-wide, but only on login and
checkout actions. Look at Amazon, Wayfair, etc. Depending on how the site was
coded, you can mitigate session hijacking over HTTP. I'd love to see examples
of Amazon session hijacking because product browse pages are simply over HTTP,
I think you'll find that it's not possible to hijack those sessions.

~~~
aeon10
I've noticed this too. Alot of ecommerce sites use HTTP for browsing. I assume
this is because of speed. However I dont see why the session cannot be
hijacked? If i copy all of the cookies how will the server differentiate the
hijacker from the user. They both have the same cookies.

~~~
rythie
I think you just need one HTTPS only cookie (Amazon seems to have two) and
just check that one (in addition to the others) at purchase time, since that
one can't be stolen.

However, the sign in button is served from a insecure page, so a ISP could
MITM that and get your password anyway.

~~~
aioprisan
it's easier to just hijack DNS anyways

------
herge
What about a CMS for, say, a blog? You want the administration console to be
protected with https, but what about the main pages? Could I make
admin.mydomain.com (and have the admin console on that) https only and my
domain.com http?

I don't want to buy a cert for the site, but I'd be happy to create a self-
signed cert for all the people who can access the admin.

~~~
GeneralMayhem
IANASE, but that should work, so long as you're diligent about keeping
everything that requires a login quarantined to a separate subdomain. Once you
leak a cookie over to the public side, it's over.

~~~
theGimp
It doesn't have to be on a separate subdomain -- setting a secure flag should
provide sufficient protection.

------
wepple
I'm a little surprised such a basic article has made it to frontpage of HN,
and especially considering a number of omissions - such as that Cookies should
be marked with a 'secure' flag when using HTTPS, or that weak ciphers should
be explicitly disabled.

There's no "we're ok, I switched security to ON" in the security world

~~~
callahad
Did we read the same article? The `secure` flag is the fifth of the "Key
Points" at the top of the article, and the entire penultimate section is
devoted to it.

------
jeroends
Does anyone know if it would be completely save to have a site (blog) with the
public part on [http://](http://) on one domain (f.e. aa.com), and the
administration part on [https://](https://) on another domain (f.e. bb.com)?

------
elchief
Don't forget to disable TLS compression and HTTP compression for pages
containing session ids or CSRF tokens.

Basically you need a cookie-less HTTPS subdomain for your static media, and a
www.example.com HTTPS domain for your content.

~~~
yajoe
> Don't forget to disable TLS compression and HTTP compression for pages
> containing session ids or CSRF tokens.

Dumb question: Is this general advice or is it specific to django due to the
"BREACH" [1][2] https attack? It's not clear if it the underlying flaw is in
using a CSRF token or something specific to django's implementation. I had
never heard this before, so thank you.

[1] [http://news.softpedia.com/news/Django-BREACH-Attack-
Against-...](http://news.softpedia.com/news/Django-BREACH-Attack-Against-
HTTPS-Can-Be-Used-to-Compromise-CSRF-Protection-373647.shtml) [2]
[http://stacks.11craft.com/what-is-breach-how-can-we-
protect-...](http://stacks.11craft.com/what-is-breach-how-can-we-protect-
django-projects-against-it.html)

~~~
elchief
General. Don't use TLS compression or HTTP compression for any information you
want to keep secret. BREACH and CRIME attacks exploit this.

You can still use, say, HTML minification.

You can compress your js and css as long as you make sure you aren't sending
your confidential information in those request/response headers. A good way to
do this is to setup a subdomain for media that never uses cookies.

~~~
yajoe
Thanks. We've been segregating authenticated vs non-authenticated traffic to
different domains for a few years now (we had the same realization as moot),
but I was unaware about this specific exploit related to _TLS_ compression.

That said, it seems on nginx TLS compression was not enabled by default, so we
are ok (for this known vulnerability).

------
fdomig
I think there is absolutely no reason to _NOT_ deploy HTTPS.

------
eonil
It would be better to define HTTPS by default, and plain HTTP for exceptional
cases. I would use HTTP only for strictly public and eternally cacheable big
files.

------
yeukhon
Should internal communication also be HTTPS? Even if they are sitting behind
your powerful firewall, should they be HTTPS with some valid certs?

------
shmerl
When? Always.

------
nvr219
when=always

------
notastartup
side question: how do you make your blog entry like the Medium.com style? It's
very easy to read this blog.

------
facorreia
Useful tips here.

