
Switch to HTTPS Now, For Free - rodrigocoelho
https://konklone.com/post/switch-to-https-now-for-free?hn
======
jakobe
I just recently enabled SSL on my business website. It was anything but
simple.

First of all, I had to get a dedicated server, because a bunch of other sites
were running on the same server, and the hosting company doesn't offer
additional IP addresses.

Then I wanted to get an SSL certificate. I picked Comodo, because they seemed
to offer the cheapest full business validation certificate, but then
accidentally bought a domain only certificate because their marketing was so
confusing. Their friendly customer service walked me through a complicated
process for changing my order.

To get the certificate issued, it took me a week to collect the documents they
requested. I had to make sure my business was listed in the yellow pages, so
they could send me an automatic phone call for verifying my number.

After every step in the process, they told me to log into their online
management area, which was offline from time to time.

I had to confirm my email address by clicking a link about a dozen times. Half
of the emails were missing the confirmation link.

Twice I got an email telling me my order will soon be processed, and nothing
happened for two days. I had to open tickets in some online support area or
send them emails to get them to continue processing.

All in all it took me a month to get SSL working. Now I understand why so many
sites do not use HTTPS.

~~~
dpe82
Someone should probably point out: most of your problems were related to doing
full business validation from a crappy provider. Business validation is
optional and doesn't enhance the transport-layer security benefits of using
SSL.

~~~
majelix
> Business validation is optional and doesn't enhance the transport-layer
> security benefits of using SSL.

Except that SSL isn't just about transport-layer security, it's also about
identity. The entire model of SSL breaks down if anyone can buy a certificate
for anything.

~~~
asdasf
Which browser makes it clear to the user that some unknown organization has
"verified" the business hosting the domain they are at? All a user sees is a
little lock, no matter what cert you buy.

~~~
baudehlo
EV Certs show the company identity, which has been verified. Go to paypal for
an example.

~~~
asdasf
Where? Changing the color of the lock? That's the whole point, users have
absolutely no idea that means anything, they can not differentiate between
certs.

------
espeed
Make sure you do not use compression with SSL.

Using compression with SSL could make your site vulnerable to the CRIME and
BREACH attacks. See...

SSL Gone in 30 Seconds - A BREACH Beyond CRIME [video]:
[http://www.youtube.com/watch?v=pIKIXQNFplY&hd=1](http://www.youtube.com/watch?v=pIKIXQNFplY&hd=1)

BREACH Attack (HTTP Compression):
[http://breachattack.com](http://breachattack.com),
[http://security.stackexchange.com/questions/39925/breach-
a-n...](http://security.stackexchange.com/questions/39925/breach-a-new-attack-
against-http-what-can-be-done)

CRIME Attack (SSL/TLS/SPDY Compression):
[http://en.wikipedia.org/wiki/CRIME_(security_exploit)](http://en.wikipedia.org/wiki/CRIME_\(security_exploit\)),
[http://security.stackexchange.com/questions/19911/crime-
how-...](http://security.stackexchange.com/questions/19911/crime-how-to-beat-
the-beast-successor)

~~~
konklone
SSL Labs does a great job of SSL testing domains and making recommendations:
[https://www.ssllabs.com/ssltest/analyze.html?d=konklone.com](https://www.ssllabs.com/ssltest/analyze.html?d=konklone.com)

I developed my nginx config based on their recommendations:
[https://gist.github.com/konklone/6532544](https://gist.github.com/konklone/6532544)

~~~
espeed
Instead of using nginx or a Web server for SSL, you might consider using
something like stunnel for SSL termination as recommended by 'cperciva:
"...for security reasons, I prefer to keep SSL termination separate from HTTP
serving"
([http://colin.percival.usesthis.com](http://colin.percival.usesthis.com),
[http://www.daemonology.net/blog/2009-09-28-securing-
https.ht...](http://www.daemonology.net/blog/2009-09-28-securing-https.html)).

In his 2010 talk "Everything you need to know about cryptography in 1 hour"
([http://blip.tv/fosslc/everything-you-need-to-know-about-
cryp...](http://blip.tv/fosslc/everything-you-need-to-know-about-cryptography-
in-1-hour-3646795)), Colin also recommends limiting SSL use to a confined
area.

Amazon does this.

For example, Amazon.com only uses only SSL when you log in, check out, or
access "Your Account". Everywhere else Amazon.com uses HMAC request signatures
over HTTP, similar to how AWS API requests are signed.

See "Signing AWS API Requests"
([http://docs.aws.amazon.com/general/latest/gr/signing_aws_api...](http://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html))

To Colin and the other security professionals on HN:

    
    
      * Is limiting SSL still recommended in spite of the trend toward Always-On-SSL?
    
      * What are the current best practices and tradeoff considerations of this approach?

~~~
chc
> _In his 2010 talk "Everything you need to know about cryptography in 1 hour"
> ([http://blip.tv/fosslc/everything-you-need-to-know-about-
> cryp...](http://blip.tv/fosslc/everything-you-need-to-know-about-cryp...)),
> Colin also recommends limiting SSL use to a confined area._

Doesn't this leave you vulnerable to session theft?

~~~
espeed
The session ID is encoded into each URL or Form, and the request is signed
using an HMAC-SHA-256 signature.

~~~
espeed
UPDATE: Looking again at Amazon.com's current HTML, it does not appear that
Amazon.com is securing all requests so it may be vulnerable.

------
huhtenberg
Oh, the sweet irony -

> _SSL’s not perfect, but we need to make surveillance as expensive as
> possible_

immediately followed by -

> _And hey, bonus: more complete referrer information in Google Analytics_

Make up your mind already. Are you against the surveillance or for it? You
can't really sit with one ass on two chairs.

    
    
      --
    

(edit) Point being is that if you are pulling the anti-surveillance card, then
you shouldn't really be siphoning off your visitors data to Google.

~~~
doppel
I wouldn't exactly categorize "everyone can see your data" and "we can now
track your movement on our own site" together.

The idea of surveillance, in this case, is that no 3rd parties can snoop on
your data. If you are actively using a site, it should be under the assumption
that they can and will track anything you do on their site.

~~~
huhtenberg
> _no 3rd parties can snoop on your data_

And Google is what... ?

~~~
ars_technician
Someone you are willfully sending information about requests to? What's so
hard to understand. Just because you let your doctor put his finger in your
ass doesn't mean you want to let everyone...

~~~
huhtenberg
Except with external analytics you are letting your doctor to finger other
people's asses. See the difference?

------
mrb
Summary: obtain a certificate from StartSSL. They provide free certificates as
long as it is for an individual, not a company's website. Their process to get
a cert is a little more difficult that the competition, but konklone.com
provides a nice step-by-step guide.

~~~
cpncrunch
Nope, you can use it for a company as well.

~~~
elchief
If you read their terms, and I have, you definitely can't use the free certs
for shopping or banking sites. It's kind of vague as to whether you can use it
for a commercial site that doesn't involve shopping or banking though.

~~~
cpncrunch
I did read their terms, which is why I posted that. Nowhere does it say that
you can't use the free certificate for a company. In fact if you read their
FAQ ("The certificate is for my company, what shall I do?") it says "even in
case he/she decides to obtain certification as an employee or representative
of an organization". So it is specifically saying that you can use it for a
company website.

Also it doesn't say in policy.pdf that you can't use it for banking. It just
says you can't have a subdomain with the word "bank" or similar in it. So you
could use the free certificate for an online bank, although it's probably not
the best idea :)

Please don't downvote me just because you didn't read the terms properly. My
comment above was correct.

~~~
xenophonf
@cpncrunch, you need to re-read section 3.1.2.1 of StartSSL's policy:

    
    
      Class 1 certificates are limited to client and server
      certificates, whereas the later is restricted in its usage for
      non-commercial purpose only. Subscribers MUST upgrade to Class
      2 or higher level for any domain and site of commercial nature,
      when using high-profile brands and names or if involved in
      obtaining or relaying sensitive information such as health
      records, financial details, personal information etc.
    

That said, if you're a business, you pay $60 to get verified for a year, and
then you can create as many certificates as you want.

~~~
cpncrunch
Ah, yes, you're correct. I guess their FAQ just needs clarified a bit.

------
jlongster
One gotcha that these kinds of tutorials don't mention is that if your site
might be blacklisted if google doesn't say it's been 100% clear of trojans for
the past 90 days. I hit this on my domain when I accidentally had an .exe file
in my static files. I've had to wait 3 months until I can get the certificate.

[http://safebrowsing.clients.google.com/safebrowsing/diagnost...](http://safebrowsing.clients.google.com/safebrowsing/diagnostic?hl=en-
US&site=jlongster.com)

------
handsomeransoms
Fun fact about Startcom (providers of StartSSL): they were the only
certificate authority that the "Comodohacker" responsible for breaching
Comodo, Diginotar, and others, was unable to hack. [1]

[1] [http://www.informationweek.com/security/attacks/how-
startcom...](http://www.informationweek.com/security/attacks/how-startcom-
foiled-comodohacker-4-lesso/231601037)

~~~
ivanr
You probably meant to say that they are the only CA Comodohacker admitted
attacking and failing to obtain any fraudulent certificates. Given that there
are over 100 CAs, it's likely that the same person/organisation attempted
attacking others and failed.

One interesting thing about that incident is that Startcom never released a
report to state exactly what had happened, which is in contrast with some
other hacking incidents they suffered. If what Comodhacker said was true (that
he had been able to communicate with the NSM), then they definitely were
hacked -- just not critically.

------
kemayo
It is sort of worth noting that it's only free if you have a dedicated IP
address. If you just have a cheap hosting plan somewhere, you'll need to pay
them for said dedicated IP before you can set up SSL, generally.

I mean, we're not talking a huge amount of money. Webfaction is $5/month [1].
Still!

[1]:
[https://www.webfaction.com/features](https://www.webfaction.com/features)

~~~
handsomeransoms
Webfaction enabled SNI on all of their servers in December 2011 [1], which
means you no longer _need_ to buy a dedicated IP address to use SSL. In fact,
when they made this switch, they switched my server over to SNI automatically
and stopped charging me the extra $5/month automatically. Awesome!

A small fraction of Internet users on extremely out-of-date system cannot use
SNI. If you need to support those users, you will still have to buy a
dedicated IP address. I personally don't bother (if you're running IE 6 on
Windows XP, you have bigger problems).

This is a great guide! I did the exact same thing several months ago and am
very happy with the result. Enough with the excuses not to deploy SSL!

[1] [https://blog.webfaction.com/2011/12/server-name-
indication-e...](https://blog.webfaction.com/2011/12/server-name-indication-
enabled-on-all-servers/)

~~~
dangrossman
Almost 1 in 5 people on the web are still running Windows XP. No version of
Internet Explorer on XP supports SNI. Neither does Safari on XP, the browser
in Android 2.x, the BlackBerry browser or Opera Mobile before 10.1. It may be
a minority of users, but it's not just "people who are still running IE6".

Pretty much everyone would love to use SNI; site owners wouldn't have to pay
for extra IPs, hosting companies wouldn't have to worry about securing and
allocating them just for SSL use, tons of IPv4 space could be put back into
circulation, and CAs would be able to sell many more certs. Unfortunately the
group that can't use it is too large to ignore, so none of that's happening.

~~~
handsomeransoms
I appreciate your detailed response! I should not have been so dismissive of
those users. Still, I maintain that the "extra cost for a dedicated IP" is a
poor excuse for not implementing SSL.

~~~
agwa
Unfortunately. it's not always just the cost - too many providers (e.g.
DigitalOcean) obnoxiously don't support multiple IP addresses on a server/VM.

~~~
cmircea
DigitalOcean is small... Windows Azure does not support multiple IPs except
for hosted websites. Cloud Services or Virtual Machines get only one IP.

And dedicated IPs for websites are extremely expensive.

~~~
agwa
Further proving my point... Joyent is another example of a cloud provider
which only gives you one IP address.

It doesn't need to be this way - Linode gives extra addresses for $1/month
each (provided valid technical justification, such as the need to run HTTPS).

------
dimension7
Excellent guide but unfortunately StartSSL does not support all top-level
domains. I went through the trouble of registering with StartSSL, they even
issued a client certificate for my email account at .tk domain, but they
refuse to issue SSL server certificates for any .tk domain.

Even though this is a perfectly legitimate top-level domain (yes I paid for a
real .tk domain, and I fully control the DNS settings just as any other domain
— it is not a free web-based redirect domain, which the Tokelau NIC also
offers), StartSSL does not let you choose it when requesting a certificate.
They have a drop-down of supported TLDs, but .tk is nowhere to be found (and
you cannot edit the HTML to submit this domain anyways, it will be rejected by
the server). Initially this appeared to be a simple omission, but
investigating further revealed it was an intentional decision to not allow
issuance of SSL certs to .tk due to "abuse".

Quite annoying to have purchased an apparently legitimate domain, only to
discover it is considered "second-class" by certain online services. Now I am
faced with a decision to buy another new domain at a more reputable TLD,
switch all my servers and services over, or find another SSL issuer which
supports .tk. CACert appears promising, also issuing certs for free, but sadly
they are not widely accepted by browser vendors. A paid SSL authority would
likely issue a cert for .tk, but at this point I'm inclined to not use SSL at
all, or stick with my own self-signed certs (I mainly use my server for
personal services, so wide accessibility is not a major concern, but having a
"real" trusted cert would be nice).

Does anyone else have any experience with acquiring SSL certs for less popular
TLDs? I picked .tk because a short and easily recognizable domain was
available, got in before many of the better names were snatched up as in .com,
etc, but perhaps giving in and buying a longer domain name at a popular TLD is
worth it if it means StartSSL and other services will consider it more
trustworthy.

~~~
jakebellacera
.tk domains are probably restricted because they're free to register, thus are
heavily associated with abuse. Abusive websites with certs that haven't been
caught could be misleading to users. That's my guess, anyway.

------
ewolf
Are there any downsides to these free certs? Do they work in all browsers; is
there anything that could be better security-wise?

If not, than this is exactly what we need to establish HTTPS as the new
standard.

~~~
tjohns
There are some minor caveats, but nothing really worth worrying about. Most
browsers accept StartCom certs these days, so that's not a concern unless
you're supporting ancient systems. The big difference is in how much
validation is done.

The cheap certs only offer domain verification; in other words, they verify
that the person holding the certificate owns the domain in question. Typically
via an automated email to one of the contact addresses associated with the
domain. The catch here is that you're only allowed to fill out the CN=
(domain) field in your cert; the others are blanked out. For what most people
use SSL for, that's sufficient.

The more expensive certs will go a step further and verify the identity of the
entity or person holding the certificate. This entails things like checking
your articles of incorporation if your'e a business; things that tend to
require a human operator at the CA reviewing your submission. In return, you
get to fill out more fields in your certificate. However, nobody ever looks at
the details for certs, so this is pretty much wasted money, IMHO.

The only point at which the more expensive certs get you something of value
is:

1\. You pay to get a wildcard cert, which lets you use your cert on as many
subdomains as you want. If you actually need it for technical reasons (e.g.
you let users create their own subdomains), this might be worthwhile. Most
folks won't need this.

2\. You pay to get an "Extended Validation" or "EV" cert, which gets you a
little green box in the address bar with your company name. There's strict
requirements on identity validation to get these, and it's supposed to
engender more trust on the part of users. They're also very expensive.
Personally, I suspect nobody really cares about these and it's just a racket
for the CAs. But opinions vary.

~~~
rurounijones
The fact that EV certificates exist in the first place is an indication in my
mind just how badly CAs messed up the certs originally. ("We need to sell
more! Get rid of the checks")

It also drives me nuts that browsers still class self-signed certs below
normal (non-ev) certs when they basically offer the same level of guarantees
(in terms of "this person is who they claim to be")

~~~
ivanr
You are wrong. Attacks against sites with self-signed certificates are trivial
to execute (you just need to download the tools and learn how to run them) and
can be fully automated. Obtaining fraudulent certificates is occasionally
possible (getting more difficult every day), but it generally needs to be done
one site at a time, and requires a _lot_ of resources.

That said, there are many ways in which browsers could improve the handling of
self-signed certificates. For example, having a Convergence-like system to
fall back to seems useful. Another possibility would be to use opportunistic
encryption, where all access is encrypted even without a certificate. (This
would defend only against passive attackers, but it's better than no
encryption.)

------
kijin
If you don't have a dedicated IP for each domain, and if you need to support
clients who can't use SNI (IE on Windows XP, Android 2.x, etc.), here's a
simple solution:

Use a different port number.

[https://example-domain.com:12345/](https://example-domain.com:12345/) is a
completely different website from [https://another-domain-on-same-
ip:32412/](https://another-domain-on-same-ip:32412/).

No need for a dedicated IP address. No need for wildcard certs, SNI, or any of
that fancy stuff. Sure, it's ugly. But it works with every browser (even IE6),
and it's not like anybody is actually going to type that into an address bar.
You'll be redirecting your HTTP website to your HTTPS website anyway, aren't
you?

You can only have two of the following three: (1) shared IP, (2) pretty URLs,
and (3) legacy client support. Choose which two you want to have.

~~~
mike-cardwell
A lot of corporate networks only allow machines to connect outwards on a
certain whitelisted range of ports, ie 80 and 443. A certificate warning for
ancient clients because you're using SNI is a _much_ better failure mode than
a connection error.

------
yeukhon
StartSSL has some complains in the past. See this (paid user, but why would
they provide a free SSL ...?)
[http://danconnor.com/post/50f65364a0fd5fd1f7000001/avoid_sta...](http://danconnor.com/post/50f65364a0fd5fd1f7000001/avoid_startcom_startssl_like_the_plague_)

------
zmmmmm
Do people trust StartCom? Just curious ... I always wondered why you have all
these very expensive cert providers who charge a _lot_ for SSL certs, and then
this mysterious company with ties to Israel is handing them out for free?

I know it's pure paranoia, but this would seem to be an excellent way to
compromise a lot of SSL traffic if you were into that, and the Israelis are
pretty famous for all kinds of spying activity that makes PRISM look tame.
Just curious what others think about this?

~~~
lwf
With StartCom, you just send them a CSR and they sign it. They don't get
access to your key.

StartCom passed an outside audit and is included in most modern browsers by
default, indicating that they at least trust StartCom.

They charge for the work they have to do. So, EV and identity validation cost
money. Most "domain validated" certs are basically no work, as you can see
from the incredibly cheap prices other SSL vendors offer them at.

~~~
makomk
Actually, the default is for StartCom to generate your private key for you.
They do let you generate your own private key and just upload the CSR though.

------
derstang
For another point of view...free is what you get
[http://danconnor.com/post/50f65364a0fd5fd1f7000001/avoid_sta...](http://danconnor.com/post/50f65364a0fd5fd1f7000001/avoid_startcom_startssl_like_the_plague_)

~~~
brubaker
I tend to take people that have a running douchey commentary with a grain of
salt.

Plus he was going for validation, which isn't free and is a pretty obnoxious
process regardless of who you go with.

------
grinnick
I used this guide to help switch a site to HTTPS just last week. Very useful
and super simple.

On issue I did run into (not relevant to the article but anyway) was that
Heroku charges $20/month to use SSL on a custom domain.

~~~
ceejayoz
I believe that's because Heroku's on AWS and using ELB, so they have to have
an ELB just for you ($15/month).

------
jlgaddis
Note that in addition to using it for your web site, you can also use this
same certificate for e-mail, assuming you run your own mail server.

Long story short: I recently moved my e-mail from Google Apps to a machine
under my control. As part of that project, I "redeemed" an unused SSL
certificate I had purchased a while back for Postfix and Dovecot.

(While I paid for mine, you can use a self-signed one and most MTAs won't
complain or refuse to deliver mail, if memory serves.)

------
IgorPartola
This is where domain registrars should give you a basic wildcard SSL cert for
free when you register the domain. There is no reason why you should get that
separately. The first registrar to realize that it is basically free to them
to provide you the SSL cert and bundle the two things together wins.

I also wonder if advances in DNSSEC will help eliminate various SSL cert
dealers: if you have a secure way to prove that example.com translates to a
given IP, and DNSSEC could distribute the public cert for HTTPS in some
standard manner, then CA's have no reason to exist anymore. See
[http://blog.huque.com/2012/10/dnssec-and-
certificates.html](http://blog.huque.com/2012/10/dnssec-and-certificates.html)
for a decent discussion of this.

Edit: even better, if I could provide a secure way for you to communicate with
my site over HTTPS without relying on a CA, I could also provide you my public
GPG key securely. That way you know that me@example.com really has the
certificate with ID DEADBEEF. Of course you don't know that I am Igor Partola
is who claims to own igorpartola.com, but at least you can securely associate
the email address with the GPG key, which is good enough if you, let's say,
only know me as my online identity and only care to communicate with me about
things related to that identity.

For example, if you found a project of mine on GitHub, and found a huge
security flaw in it, you might want to securely email me an exploit and a
patch without advertising the vulnerability to the world. It's good enough to
have the email/GPG key association without needing to authenticate my real-
life identity.

------
wtn
I was under the impression the private key for authentication to the StartSSL
site was generated in the browser with the keygen tag, not on the server…

~~~
Tortoise
It is. The website is wrong. Assuming your browser implements it securely,
it's no less safe than generating it client-side with openssl.

~~~
konklone
Oh, whoops. Can you recommend how I should change the text? Anything you can
link to to show me what you mean?

~~~
wtn
My understanding is that StartSSL will, by default, generate a TLS/SSL private
key and public certificate pair for you server side. One can manually override
by creating a private key locally and uploading a CSR.

The site authentication private key and the S/MIME private key, however, are
always generated in the user's browser.

From my experience (on OS X), if you want maximum flexibility for selecting
your S/MIME key size, the browser you should use is the last pre-Chromium
release of Opera. It allowed me to select 4096-bit RSA private key and SHA-256
hash algorithm, whereas Firefox, Safari, and Chrome have no option greater
than 2048 bits.

------
AhtiK
> And hey, bonus: more complete referrer information in Google Analytics

It's interesting, I did switch to HTTPS for all my sites but Google Search
still did not reveal search keywords to Google Analytics from users logged in
at Google. If that's what was referred as "referrer information".

Did anyone get lucky with getting 100% of google search keywords after
switching to SSL?

~~~
bigiain
What he meant was that Google Analytics will correctly identify visitors
coming from a link on a SSL secured site (for example
[https://news.ycombinator.com](https://news.ycombinator.com) ) if your set is
SSL secured as well - all browsers strip the referrer header if they're going
from an https page to an http one.

Google search queries/keywords are a different issue - Google is intentionally
making it impossible to see most of those (presumably, they've got a plan
about how to sell that information to marketers using Adwords…)

~~~
AhtiK
Many thanks for clearing that up! I had no idea browsers strip referrer
headers with https->http navigation.

------
chc
Just going to throw out that if you use a Cloudflare business plan, you can
just tick a couple of boxes and get SSL for free.

~~~
tlrobinson
While I like Cloudflare, it's worth noting you give up true "end to end"
encryption SSL normally provides. It's entirely possible for Cloudflare to
allow others to eavesdrop on your traffic, and in fact I think the connections
between Cloudflare and your servers are normally unencrypted.

Basically, using Cloudflare SSL is good for protecting your customers from
eavesdroppers on WiFi, not so good for protecting against NSA surveillance.
But it's probably better than nothing.

~~~
chc
Whether the connection between you and Cloudflare is encrypted is up to you.
It's right in the same box as the option to turn on encryption in the first
place.

------
Zoepfli
In the switch to https everywhere, we have barely started. For every HN and
wikipedia with https there are 20 websites without (and whether the ones that
do https do really secure https is yet another question).

Somebody should go through the top 10k websites and make a list, then repeat
every few months.

~~~
cpeterso
Note that Wikipedia supports HTTPS, but it is not the default (yet).

~~~
Zoepfli
Funny, it is for me: any wikipedia page redirects to its https counterpart.

E.g.
[http://en.wikipedia.org/wiki/Hacker_News](http://en.wikipedia.org/wiki/Hacker_News)
redirects to
[https://en.wikipedia.org/wiki/Hacker_News](https://en.wikipedia.org/wiki/Hacker_News)
.

~~~
makomk
Do you have a user account at Wikipedia by any chance? They've been
redirecting logged-in users to the SSL version for a while, and under some
circumstances it also seems to redirect users who have been logged in but
aren't right now.

~~~
Zoepfli
I do indeed have a WP account. It redirects as well when I'm logged out.

------
valtron
As I understand it, (correct me if I'm wrong), https has two parts:

1\. Encryption: protects from eavesdropping (e.g. your internet provider can't
see what you're communicating)

2\. Authentication: protects from MITM (e.g. someone changing the data en-
route)

For full security you need both; but #2 is much more complicated than #1
because it needs a trusted third party, certificates, etc. It's effectively a
barrier to having everyone use encryption.

Why isn't it possible to opt for only #1? It should be as simple as adding
"Encrypt +All" to your apache settings.

~~~
dragonwriter
You can't have protection from eavesdropping without protection from MITM,
because MITM can be used for eavesdropping (as well as actually inserting
malicious traffic into the communication.)

Which is why encryption without authentication is pointless (or, worse,
illusory security) in most cases. On the internet, your communication is
_inherently_ being handed off through a number of intermediaries to an
endpoint. If you don't know who the endpoint is, it doesn't do you any good to
know that your connection is secure from you to the endpoint.

~~~
tedunangst
I agree and disagree. Not all adversaries have active intercept capabilities.
Some are just passive. Defending against them isn't entirely pointless.

I really, really dislike the CA cabal. Self signed "encrypt only" certs
combined with auto cert pinning in browsers would probably solve 99% of the
problem.

~~~
tptacek
What's a "just passive" adversary, other than a "potentially active adversary
that chooses not to use the information they're collecting to leverage an
active attack"?

Nobody likes the CA problem, but you can't handwave the problem away.

TACK (which provides auto-pinning) is hopefully going to be a solution to the
lack of trustworthiness in CAs, but TACK's deployment model also presumes a CA
infrastructure.

~~~
tedunangst
Well, more or less exactly what you said. An active attack is detectable, a
passive one is not. There is no risk to me if I walk around with a wifi
adapter in promiscuous mode just recording traffic. Actually doing a mitm
exceeds my admittedly low risk tolerance.

------
Abundnce10
_And hey, bonus: more complete referrer information in Google Analytics for
people visiting from sites already using HTTPS (like Hacker News)_

If I enable SSL on my website do you think I will be able to get the referring
keyword from Google? Now that Google is making all searches secure about 80%
of the searches show up as 'Keyword Unavailable'.
[http://searchengineland.com/post-prism-google-secure-
searche...](http://searchengineland.com/post-prism-google-secure-
searches-172487)

------
dendory
This is kind of glossing over the point. We all know SSL is good and should be
used everywhere. But the simple fact is that to have a fully capable SSL
server you need two things: A certificate and a unique IP. There are firms now
offering free certificates, but not everyone has the choice to select them.
And IP certainly aren't free on most hosts. Sure there are always solutions,
like moving to a self hosted model and so on, but it is a significant
inconvenience for most.

~~~
jackalope
SSL/TLS is entirely a server/client exchange that has absolutely _nothing_ to
do with IP addresses. If you get the wrong certificate, you have either a
crappy client, a crappy server, a misconfigured client, or a misconfigured
server. For each case, there is a workaround, and that is where the
inconvenience lies.

~~~
al2o3cr
Mostly true now, but not historically true - until SNI [1] was rolled out
widely, implementing SSL _absolutely_ required a dedicated IP. Short story
shorter, the TLS handshake happens _before_ the Host: header exchange in HTTP;
before SNI there wasn't any way for a host that responded to multiple names to
identify which cert to use for the handshake.

[1] SNI -
[http://en.wikipedia.org/wiki/Server_Name_Indication](http://en.wikipedia.org/wiki/Server_Name_Indication)

~~~
andrewaylett
That's still not quite true -- subject alternative names allow you to put
multiple domains on a single certificate. That does raise trust issues if
you're doing shared hosting, but it should be fine if you run all of the sites
and don't mind them being obviously linked.

------
tootie
Using HTTPS everywhere doesn't really help much. It doesn't help at all if the
surveillers either have your cert or access to decrypted traffic inside the
firewall. Any PII being sent over the wire should most definitely be
encrypted, but encrypting my access to a news site isn't really hiding
anything. The requested URL still need to be unencrypted, you'd just be
encrypting content that is already availble unencrypted.

~~~
dangrossman
> The requested URL still need to be unencrypted

The SSL connection is set up before the HTTP request is sent; that's why the
dedicated IP per domain is required, since the domain (Host header) is part of
the request as well. The URL you're accessing is not sent in the clear.

~~~
cbr
Partly. On a modern system with SNI the hostname is sent in the clear. This
removes the requirement for a dedicated IP per domain with SSL for those
users, but until SNI everywhere you still need one.

------
ck2
Don't forget to enable ssl stapling which is now available in both nginx and
apache and supported in firefox 25 and newest Chrome.

------
cpeterso
You can also get free SSL certificates from LOLroot CA!

[http://lolroot.ca/](http://lolroot.ca/)

~~~
mmagin
That's dumb.

If you're going to install a new root certificate on all your client machines,
you could just as well generate your own CA inside your organization and do
the same thing without trusting some third party.

(Edit: I think I've been trolled.)

~~~
GoodIntentions
Ya Think?

"Self-signed certs as a service! IN THE CLOUD! Need Support for your self-
signed cert? 5k/year - 1 (800) 555 - 5549"

I wonder if they have an affiliate program

~~~
makomk
They've got something better - anyone can download a copy of the signing key
and set up their own unofficial LOLroot affiliate.

------
imaginator
StartSSL offer a great service.

If you'd rather use the Java Keytool to manage your certs, I wrote up this
guide on making it work with StartSSL.
[https://buddycloud.org/wiki/buddycloud_SSL_setup](https://buddycloud.org/wiki/buddycloud_SSL_setup)

Should just be a copy paste, wait, paste, export job.

------
chris_mahan
When it's harder to get SSL working than to install debian stable on a
machine, I'd say SSL is too hard.

~~~
astrodust
This is mostly the fault of the SSL certificate providers, which vary in
complexity between the obnoxious GoDaddy and even more obtuse and impossible
to deal with.

Compounding this, the configuration file formats for each web server platform
vary wildly, selecting the correct format and installing it properly can be
tricky.

Making matters worse, it's very easy to set up something that looks like it's
working, but is actually broken on some subset of the browsers out there.

These problems can be solved with better standards, better documentation,
testing tools, and most of all, providers that actually care about the user
experience they're selling.

~~~
chris_mahan
Can't the providers be disposed of, and replaced with an open-source automated
system?

~~~
astrodust
It's not that they need to be open-source or not, it's that their user
interface is absolutely awful.

You can set up your own CA but you can't sign for domains unless you're in the
proper chain. The ones holding the keys for these are the big providers.

------
conductor
> As you can see, StartSSL will believe you own the domain if you control
> webmaster@, postmaster@, or hostmaster@ with the domain name

I see a potential vuln here for free e-mail services. If one manages to
register one of those addresses he can create a trusted certificate and use it
for MITM.

~~~
joosters
Several paid-for certificates from a few CAs do just the same. If you're
paying $0 for a certificate, don't expect more than ~$0 worth of identity
checks!

It also highlights a critical SSL issue; there's really little strength in the
concept of a certificate _proving_ the identity of anyone.

------
nasalgoat
On a side note, which cert provider you go with can dramatically effect your
latency times.

In testing, we found that DigiCert was 50-100ms faster on queries than our
existing GoDaddy certificate, based on the location of their CA hosts.

The improved response time resulted in a 15% increase in traffic on our API.

------
nilved
This isn't strictly related to this post, but I've always thought that the
idea of paying a fee for SSL certificates was a bad one. Time spent buying and
setting up an SSL certificate would be better spent making your site available
as a Tor hidden service.

~~~
icebraining
I'd rather disconnect my web server, it'd take less effort and receive the
same number of visitants.

------
autoreverse
Globe SSL [https://globessl.com/](https://globessl.com/) has domain validated
certs at $24 per 3 years.

I've been using these since 2011 (starting with one year certs before
switching to 3 years later) with no problems.

------
Sami_Lehtinen
Because certs are so easy to get, it's better to use fingerprint
identification for sites, to make sure it's right one. That's what I've been
doing for ages, with https, and smtps. I'll be blogging about it soon.

------
megaframe
Been wanting this for a long time but didn't know of a free vendor and didn't
seem worth paying for (just for my personal use)... now I got it working on
everything but OSX, it just does not seem to want to accept the cert.

------
waaatwaaat
Why r u decrypting your private encrypted key? To use for csr request? Can't u
do car request with private encrypted key? And why point nginx/apache/watevr
at the decrypted private key? Sounds unsecure?

------
iancarroll
If you host with SingleHop, they allow generation of unlimited SSL
certificates. [1]

[1] Ex: [https://ianthedeveloper.com](https://ianthedeveloper.com)

------
hcarvalhoalves
If browsers got fixed to not freak out on self-signed certificates, this
wouldn't even be an issue, HTTPS could be a default.

~~~
AnthonyMouse
Sort of. You actually do need to know when a certificate is self-signed
because it means the connection isn't _authenticated_ even if it's
_encrypted_.

But what they ought to do is to accept the self-signed certificate, show
something other than the usual lock icon but do the encryption anyway, and
then freak out if the certificate changes before it expires.

~~~
hcarvalhoalves
The point is, sometimes you just don't care about authority, you just care
about the encryption.

HTTPS with self-signed certificates is better than moving plaintext over the
wire, in the same way PGP is better than moving plaintext over the wire. It
doesn't matter that you don't have a "trusted" peer to tell you this PGP
signer is who it says it is. As long as you can trust you acquired his key in
a secure way (e.g., out-of-band), it's better than the alternative.

Plus, MITM concerns over self-signed certs are moot. This vulnerability exists
at the DNS level anyway.

------
mcv
Is it irony that Safari considers his $0 certificate unsafe, or did he simply
get what he paid for?

~~~
aroch
Safari (wel, the OSX Keychain) doesn't include StartCOM in it's Truststore --
which I'm pretty OK with. I revoke it from all my trsutstores

~~~
gmac
(a) That's not my experience. This site of mine is secured with a StartCom
cert, and Safari has always been perfectly happy with it:
[https://mappiness.me](https://mappiness.me)

(b) Why? I understood they were among the better providers.

~~~
mcv
> This site of mine is secured with a StartCom cert, and Safari has always
> been perfectly happy with it: [https://mappiness.me](https://mappiness.me)

My Safari can't verify the identity of that website. This is Safari 5.1.7.

~~~
gmac
Interesting, and a bit concerning. I just checked it on a friend's MacBook
too, and that worked (Safari 6.0.5). Perhaps there's been a change at some
point?

------
jbarrec
Thank you so much for sharing this!!

