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.
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.
While it's true that you should disable compression, most browsers disable it client-side now so this isn't a huge issue. As for BREACH, HTTP compression has a huge performance benefit, so it's not really feasible to disable it. Unfortunately, it's pretty difficult to protect the attack using other methods.
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.
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.
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.
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]
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.
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!
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.
.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.
StartSSL will also refuse to give you a certificate based on some sort of blacklist of words, which they won't disclose. I remember they didn't even want to tell me why they refused my domain, I had to send many emails asking for more information, until the guy answering finally decided to tell me.
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:
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.
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.
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?
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.
It doesn't particularly matter if people trust StartSSL, it matters if browsers trust them (which they do).
There are about 100 root CAs, and something like 1000 CAs if you include intermediates (controlled by ~650 different organizations - https://www.eff.org/observatory), and browsers trust ALL of them. All it takes is one to issue a malicious cert, or to get hacked, to do a MITM attack on ANY domain without showing a browser warning.
The trustworthyness of a single CA doesn't make a difference, because if any CA isn't trustworthy then an attacker can use them instead the other ones. This is the problem with CAs, and the problem with centralized trust systems in general. There are hundreds of weak points.
But also, StartSSL does fairly thorough identity verification. I've had to send them photos of my passport and talk to them on the phone to do identity verification. It's also worth noting that it's the CA that both https://www.eff.org/ and https://pressfreedomfoundation.org/ use.
As long as there's a broken CA system, the choice of CA does not matter in the slightest as long as it's trusted by browsers. Users only care if it breaks a website with a scary warning, but if it doesn't, it doesn't matter. There's no need to spend money.
StartSSL does charge if you have more than very basic needs, like if you want multiple alt names, or if you want a wildcard. But it's still cheaper than the competition.
making certs doesn't take money. verifying you own the domain (lowest level cert) doesnt take money. all this is fully automated, everywhere. Being an SSL provider is a juicy business once you get things rolling.
Now then again, it dosn't matter if you trust them or not, because your browser trust them for you. using another provider will not make you have a better trust in the sites you browse.
Any of the providers can compromise everyone elses trust, as long as they're trusted by the browser.
And thats why the current SSL trust scheme sucks, by the way.
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.)
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 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 [email protected] 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.
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…
> 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?
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 ) 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…)
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.
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.
Well, if you go by % of internet traffic Google is 40-50% of all internet traffic. You could probably get above 99% of all internet traffic with a shockingly small number of sites. While Google, for example, uses SSL it's not like your data is really secure from monitoring there.
I think that somebody is the EFF. HTTPS-Everywhere (look to the bottom of the page to DL the latest .xmi) has a LOT (certainly hundreds) in their list ... with qualifiers noted.
I understand that some time ago there were reasons behind not using https (price, setup, performance), but now you can get a certificate for few bucks[1].
[+] [-] jakobe|12 years ago|reply
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|12 years ago|reply
[+] [-] espeed|12 years ago|reply
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
BREACH Attack (HTTP Compression): http://breachattack.com, http://security.stackexchange.com/questions/39925/breach-a-n...
CRIME Attack (SSL/TLS/SPDY Compression): http://en.wikipedia.org/wiki/CRIME_(security_exploit), http://security.stackexchange.com/questions/19911/crime-how-...
[+] [-] konklone|12 years ago|reply
I developed my nginx config based on their recommendations: https://gist.github.com/konklone/6532544
[+] [-] bitwizzle|12 years ago|reply
[+] [-] barrydahlberg|12 years ago|reply
[+] [-] elchief|12 years ago|reply
[+] [-] huhtenberg|12 years ago|reply
> 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|12 years ago|reply
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.
[+] [-] greyfade|12 years ago|reply
I agree, though, it is kind of silly, knowing that Google has been complying with large numbers of FISA requests.
[+] [-] alextingle|12 years ago|reply
[+] [-] mrb|12 years ago|reply
[+] [-] cpncrunch|12 years ago|reply
[+] [-] jlongster|12 years ago|reply
http://safebrowsing.clients.google.com/safebrowsing/diagnost...
[+] [-] handsomeransoms|12 years ago|reply
[1] http://www.informationweek.com/security/attacks/how-startcom...
[+] [-] ivanr|12 years ago|reply
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|12 years ago|reply
I mean, we're not talking a huge amount of money. Webfaction is $5/month [1]. Still!
[1]: https://www.webfaction.com/features
[+] [-] dimension7|12 years ago|reply
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|12 years ago|reply
[+] [-] jafaku|12 years ago|reply
[+] [-] vangale|12 years ago|reply
[+] [-] ewolf|12 years ago|reply
If not, than this is exactly what we need to establish HTTPS as the new standard.
[+] [-] kijin|12 years ago|reply
Use a different port number.
https://example-domain.com:12345/ is a completely different website from 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|12 years ago|reply
[+] [-] yeukhon|12 years ago|reply
[+] [-] zmmmmm|12 years ago|reply
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|12 years ago|reply
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.
[+] [-] micahflee|12 years ago|reply
There are about 100 root CAs, and something like 1000 CAs if you include intermediates (controlled by ~650 different organizations - https://www.eff.org/observatory), and browsers trust ALL of them. All it takes is one to issue a malicious cert, or to get hacked, to do a MITM attack on ANY domain without showing a browser warning.
The trustworthyness of a single CA doesn't make a difference, because if any CA isn't trustworthy then an attacker can use them instead the other ones. This is the problem with CAs, and the problem with centralized trust systems in general. There are hundreds of weak points.
But also, StartSSL does fairly thorough identity verification. I've had to send them photos of my passport and talk to them on the phone to do identity verification. It's also worth noting that it's the CA that both https://www.eff.org/ and https://pressfreedomfoundation.org/ use.
As long as there's a broken CA system, the choice of CA does not matter in the slightest as long as it's trusted by browsers. Users only care if it breaks a website with a scary warning, but if it doesn't, it doesn't matter. There's no need to spend money.
StartSSL does charge if you have more than very basic needs, like if you want multiple alt names, or if you want a wildcard. But it's still cheaper than the competition.
[+] [-] zobzu|12 years ago|reply
Now then again, it dosn't matter if you trust them or not, because your browser trust them for you. using another provider will not make you have a better trust in the sites you browse. Any of the providers can compromise everyone elses trust, as long as they're trusted by the browser.
And thats why the current SSL trust scheme sucks, by the way.
[+] [-] olefoo|12 years ago|reply
And to further your paranoia, the NSA and Israeli intelligence orgs have form on doing each others dirty work.
But what that really points out is the brokenness at the heart of the PKI system as it's currently implemented.
When was the last time you audited your browsers trust store?
[+] [-] gsnedders|12 years ago|reply
[+] [-] lem72|12 years ago|reply
[+] [-] derstang|12 years ago|reply
[+] [-] grinnick|12 years ago|reply
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|12 years ago|reply
[+] [-] jlgaddis|12 years ago|reply
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|12 years ago|reply
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 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 [email protected] 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|12 years ago|reply
[+] [-] AhtiK|12 years ago|reply
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|12 years ago|reply
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…)
[+] [-] slig|12 years ago|reply
I had this same question on a yesterday's thread: https://news.ycombinator.com/item?id=6438992
[+] [-] chc|12 years ago|reply
[+] [-] tlrobinson|12 years ago|reply
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.
[+] [-] andrewvc|12 years ago|reply
[+] [-] Zoepfli|12 years ago|reply
Somebody should go through the top 10k websites and make a list, then repeat every few months.
[+] [-] consultant23522|12 years ago|reply
[+] [-] cpeterso|12 years ago|reply
[+] [-] teeja|12 years ago|reply
https://www.eff.org/https-everywhere
[+] [-] glazskunrukitis|12 years ago|reply
[1] http://getssl/en/ssl-certificates
[+] [-] ivanr|12 years ago|reply