Switch to HTTPS Now, For Free | Hacker News Reader

Switch to HTTPS Now, For Free

konklone.com

622 pointsrodrigocoelho251 comments

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.

If you just want the security of SSL, don't bother with the EV certificate. It's hugely easier.

I would be willing to bet over 95% of SSL-secured sites don't have business validation certificates. Given virtually nobody visiting your site will know what that means, let alone how to check anything about the certificate you're using, it just doesn't make sense to pay extra for no benefit. A domain-validated certificate costs less while providing the same padlock icon and level of encryption, and takes just minutes to obtain -- pay, paste a CSR, click a link in an e-mail, and you have a cert.

In my case, I don't care about encryption. On my website, I only offer software for download. No private data. Payment is handled by a third party.

The only reason why I want to support https is so that customers can confirm who they are downloading from. Ideally, I'd like an EV certificate, but I can't afford that. So I chose a business validation cert. A domain only certificate wouldn't really confirm anything.

(Also, some of my troubles would have been the same with a domain-only cert. The emails with missing links were those for domain validation, and I had to paste the CSR in the management area that was offline...)

Some if not all payment processing websites, like Stripe, still require that you use SSL to prevent MITM attacks.

If you offer software to download HTTPS is a must. Otherwise any active attacker, from a kid at a coffee shop to the NSA at the ISPs, can make it so when people download your software they're also downloading your software with malware attached. Software downloads are one of the most important things to protect, and it saddens me that some websites still exist that offer software downloads that don't use HTTPS.

Sorry, but you are still wasting your money on a business validation certificate. A domain validation certificate is the only thing that a browser actually validates and ensures the security between you and the website. The rest is just sprinkles on top to make people feel better and to charge website owners extra money.

>> so that customers can confirm who they are downloading from

This would seem that he was in fact looking to provide "some sprinkles [to] make his customers feel better."

Perhaps not a waste of money, then, if it provided what he was looking for?

The sprinkles are for people buying certs, not the customers of the people buying certs. End users don't even know he got a different cert, or what that means.

You're really just wasting your time with a "business validated" certificate. The browser doesn't treat it any differently and consumers like my parents would not know the difference or know what to look for. It's all (brilliant) marketing, nothing else. You're equally secure with a PositiveSSL cert from namecheap.com for $8 (or free with a domain registration)..

> You're really just wasting your time with a "business validated" certificate. The browser doesn't treat it any differently

If your vendor doesn't do a decent job verifying who you are (and this may or may not mean EV), then browsers won't treat the certificate any differently when it's entirely replaced by someone else either.

It doesn't matter how good a job your vendor does, if there is a vendor that does a bad job, then the attacker can get a cert from them. The presence of a single bad cert authority renders all certificates useless.

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.

Business validation is what you should be using for a business site. It's actually a good thing and means that the company is interested in verifying who you are.

I went through the dance with Startcom and agree with the article that the web interface has horrible workflow. However they were clearly doing their best to verify that it actually was a business they were creating an account for. For example, they ignored the phone number I gave them, and instead called on the publicly-listed phone number they found on the internet.

Except not even 99.9995% of your customers will know or care about the level of your SSL Cert.

It really does not add anything to the equation. Just extra costs and work for you.

It's been studied and pointed out that a green-bar does nothing to conversions and sales.

I suggest skipping it always, but often times a higher business type will override the suggestion of whomever has to implement it and maintain it - simply because they really don't get it or don't care about the cost (which isn't really that much, but still, you have to jump through hoops getting the docs in order).

It's been studied and pointed out that a green-bar does nothing to conversions and sales.

I'm not debating this point, but if you have some citations for this assertion, I'd love to read them. I've always heard and read otherwise.

I just completed a multiple-month-long process of converting a dynamic-domain application to support SSL-friendly URIs and implementing SSL on it's web servers based entirely on the concept of adding a green bar for boosting conversions (data isn't quite in yet to verify we did anything). I would really hope that I didn't waste multiple iterations on a pipe dream.

> I've always heard and read otherwise.

Those "Get better conversion rates with EV Certs" internal studies are pure marketing B.S. by the SSL vendors. Do not trust what they say.

Every single person that has tested this on his site has come to the same exact conclusion - the green-bar has no meaning to the consumer, nor do they even notice it.

http://www.theroiteam.com/blog/is-an-ev-ssl-worth-it-or-even...

http://webmasters.stackexchange.com/questions/7697/ev-ssl-ce...

http://forum.x-cart.com/showthread.php?t=54707

http://www.quora.com/VeriSign/Does-ecommerce-conversion-incr...

The first link mentions EV certificate handshake is slower. Is that really the case? What is the reason?

I'd like to see some facts to back that up: I suspect it is bunk, another problem somewhere that has been mistakenly attributed to the certificate type (perhaps they altered other SSL options on their web server at the same time as changing the cert, or the non-EV cert uses smaller keys so takes less CPU time to process).

The EV certs contain extra information so are likely to be a little larger, but we are talking at most a couple of hundred bytes here so the extra download time getting the cert and CPU time verifying things are not going to be significant.

People do tend to have larger key sizes on EV certs (2048 or 4096 bit rather than 1024 or 2048 (though 1024 bit keys are increasingly rare even for "standard" certificates)) which might impose a measurable latency difference on a mobile (or other low-power) device due to the math involved in verifying the site against the certificate, but nothing like the order of magnitude that link mentions.

Because the browser is going to check if the certificate is revoked as part of the ssl handshake. We have gotten sites being not available because the service that the browsers use to do this validation were not responding fast. The handshake took up to a minute.

Considering Amazon.com doesn't bother with an EV cert, I'd guess they don't affect conversions in any sort of positive manner.

Amazon also says that Settlers of Catan is the number one selling children's musical instrument toy. They don't do everything 100% right.

Once you click your Account, or try to login it will send you on via verified https:// regular pages and the cart does not have SSL. Possibly for speed issues

Yes, it's HTTPS, but it's not EV HTTPS. There's no green bar, just the lock icon that anyone with a $7/year SSL gets.

I agree it shouldn't change conversions, but I would also like to see some data supporting that. I run a lot of ecommerce sites and couldn't imagine the number of transactions not dropping if I just removed my SSL from every site.

We're not discussing whether or not you should have SSL at all. We're discussing whether it's worth getting Extended Validation, displayed as a green bar in browsers. E.g. currently at https://twitter.com you get a lock icon and a green bar that says "Twitter, Inc. (US)" — that's EV. At https://www.facebook.com you only get the lock icon — no EV.

> It's been studied

Got any source? Would really like to show that to some folks here ...

I think you make a fair point on the level-of-cert point. I got the first level of their business cert offerings because I needed a wildcard cert - we still don't have the EV green padlock.

I guess I was more trying to convey that it's reassuring to know that Startcom (at least) go to some effort to investigate their verification, and it's not just a bits-in-bits-out process.

This being said, I'm in a business and if I leave and another ops person comes along, the semantics of 'business' versus 'personal' account makes their job a little easier. I'm certainly not an expert in the area of SSL, but from long experience in other fields, it's a pain in the arse managing 'business accounts' that are really repurposed individual/private accounts.

> It really does not add anything to the equation. Just extra costs and work for you.

Of course it adds something: It makes it more difficult for someone else to go buy a SSL certificate in your name. Security isn't just about driving sales, it's also about protecting yourself and your customers.

> It makes it more difficult for someone else to go buy a SSL certificate in your name

No it doesn't. Just because you wasted money on a joke process, doesn't mean "evil attacker X" has to do it too. They can just go ahead and buy a regular cert for your domain still.

Someone should probably also point out: most of the CAs are more or less equally 'crappy'. We've been through many CAs now and none of them has a process anywhere near 'perfect'.

Btw, Comodo customer support is rather nice. We recently bought a code signing certificate from them and they walked us through the whole process via chat, worked quite well and we were done in about 30 min.

Do you not feel that, due to the security failure in 2011, they are one of the worst? I typically disable their certificate on my machines. The CA system is totally flawed anyway, I don't know why I bother.

Quitte the opposite. They themselves came forward about what happened, communicated clearly and took steps to mitigate the problem. From what I saw, they acted responsibly and it has only I erased my trust in them.

That's "increased", yeah?

> The CA system is totally flawed anyway

The flaw basically being that people aren't trustworthy, yes?

Do you have any alternatives? There's ssh's model, where you just hope it's the right certificate the first time; or maybe mob-source it like WoT?

There are flaws with current PKI infrastructure but as you say, it's better than nothing. There are also several initiatives to improve this situation. Google has come with certificate transparency ( http://www.certificate-transparency.org/ ) which essentialy creates public log of all issued certificates so everyone can see and verify that certificates authorities don't issue bogus/fake certificates

There is also an idea to use proof of work to estabilish network-wide consensus about valid certificates (like bitcoin or namecoin blockchain). This would be fully decentralised solution.

I like the idea of a blockchain for it, the only downside would be using all that space.

I didn't know about that incident. Thanks for pointing it out. Here are some references:

https://www.schneier.com/blog/archives/2011/03/comodo_group_...

https://kb.bluecoat.com/index?page=content&id=SA54&actp=RSS

> 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.

Except the identity part is well and truly fucked and in serious need of redoing. It relies on trusted CAs, which has been shown is a bad idea, because some of the trusted CAs mismanaged their private keys or have been paid to or been coerced into giving out valid certificates to third parties, permitting them to impersonate websites.

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.

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

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.

Since you mentioned crappy provider, I would like to add that there is an illusion of choice when it comes to SSL certificates. When I was purchasing an SSL certificate, I researched many and after speaking to the same sales rep on multiple sites, I realized they are all the same company. To quote-

Symantec’s family of dominant SSL brands includes VeriSign, GeoTrust, Thawte, RapidSSL and TC Trust Center.

They own about 70% of the certificates, all priced differently to give you an illusion of choice. So if one provider is crappy, their support is the same; and thus they are all crappy.

I use DigiCert at work, and have been very happy with their support, however they are not cheap.

I had a similar experience when I purchased a software signing certificate from Comodo, exacerbated by the fact that we had accidentally transposed two adjacent digits in the phone number we gave in our listing. It ended up taking about two weeks in all to get Dun & Bradstreet to correct the typo and have Comodo verify the update, and then call us at that number. While the delay was not pleasant, I am glad that they make an effort to ensure that a legitimate organization is purchasing the certificate.

You could have just bought the $7 cert from getssl.me and it would take 2 minutes at most.

They just resell Comodo certificates, so I assume I'd have the same issues with broken emails and offline managment area and emails promising "Your order is being processed right now" (the business validation stuff was only a part of the problem)

Also, it makes me angry how you have all those beautifully designed landing pages everywhere, and as soon as you have ordered, you have to deal with ugly and confusing websites that barely work at all.

You only receive a validation email from Comodo if you use their services.

If you're willing to write off users of Internet Explorer on Windows XP, you don't need a dedicated IP for SSL; you can simply use Server Name Indication (SNI).

Android 2.x also doesn't support SNI.

Android 2.x is rapidly becoming the new "Windows XP".

But then I'd need to support SSL for all domains hosted on the server, and this would mean getting 5 certificates instead of one.

That's not true. Why do you think that?

Actually it is, because you'd still have a domain pointed to an IP address listening on 443, and that IP address wouldn't know how to handle the domain that is not configured to listen on 443, so it would serve the default domain (generally the first SSL-configured domain with Apache, or 'default_server' on Nginx). This means you'll be serving a certificate for your default site 'foo.com' when you requested 'bar.org', providing the user with a domain mismatch security warning.

The second non-solution would be to configure every domain with self-signed certificates, but then you'd still be sending your clients an untrusted certificate. The only way to truly provide SSL on a shared host is to configure it with a UCC certificate that includes every domain you are pointing at it, or generate cheap/free certificates like StartSSL's for every unique domain and subdomain you listen for.

Why does that matter if bar.org doesn't and isn't supposed to support HTTPS, and if there are no links to bar.org via HTTPS? In either scenario if someone manually types in https:// bar.org it's not going to work.

People wouldn't be connecting to the website using HTTPS if it didn't have a certificate in the first place, so why does it matter if 'bar.org' doesn't have a certificate?

I don't think it's at all obvious or universally true that it's better to get an 'Unable to connect' error message than a certificate warning (btw, the default site could tell the user they arrived there by accident should they continue past the warning). Depends on the context.

I'd still say it's definitely not true that you "have to" get an SSL cert for all virtual-hosted domains on one IP address if that IP address is responding to SSL requests on 443.

You'd need at most two IP addresses to resolve this problem: one for HTTP/HTTPS sites, and one for HTTP-only sites.

Nope, just find a CA that will give you a certificate with SAN extensions at a cost that you can afford. Usually you can get up to 5 SANs at a reasonable cost, and up to 100-150 SANs for more dollars.

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

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-...

SSL Labs does a great job of SSL testing domains and making recommendations: 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

Thanks. We also have a step-by-step configuration guide called SSL/TLS Deployment Best Practices. I've just submitted it here:

    https://news.ycombinator.com/item?id=6447518

In the nutshell, it's a continuously updated "everything you need to know" about SSL/TLS.

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://www.daemonology.net/blog/2009-09-28-securing-https.ht...).

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...), 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...)

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?

> 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...), Colin also recommends limiting SSL use to a confined area.

Doesn't this leave you vulnerable to session theft?

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

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.

Yes and no. Depends on what you let open sessions do. For example, you can steal my Amazon cookies and dick with my wish list, or put a bunch of crap in my cart, or fill my recommendation list with weird stuff. But you can't buy anything because Amazon asks again for my password. (There does seem to be an option now to skip that, but I've never enabled it. Lets pretend I'm talking about the old Amazon.)

> 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.

My main concern about a scheme like this is the vulnerability to SSL stripping.

I'm not sure what you can do mitigate it apart from have SSL on all the time, HSTS telling the browser that it should be using SSL and hoping that the first time a user comes to your site is via a https link.

Deploying SSL partially is very dangerous, because then you have to be _very_ careful that the session ID is not compromised. I'd go as far as to say that it's virtually impossible to do that securely (for the average web site, built by more than one person who are not security experts, maintained under pressure over a period of years, and so on).

Someone else here mentioned SSL stripping, which is another problem, which you can't avoid [with partial SSL] no matter how much you try.

If you're deploying SSL today and you're not using HTTP Strict Transport Security, you're doing it incorrectly.

That's very convincing. What then is the advantage of only selectively using SSL, and why are some people recommending it?

Performance issues (I'd say most are imagined, but there is definitely an increase in latency) and higher cost of deployment with SSL (essentially more expensive CDNs). Some sites that rely on 3rd party services might struggle to deploy full SSL if not all services support it.

In my experience, most people are recommending partial SSL because they're not aware of the security issues. For example, many developers "know" that you're supposed to use SSL only to protect login credentials.

Using encrypted tokens help mitigate stolen session IDs (https://owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF...).

And while HSTS helps protect against sslstrip, you're still vulnerable to MITM attacks due to issues with the CA system.

See moxie's 2011 talk "SSL and the Future of Authenticity" ( http://www.youtube.com/watch?v=Z7Wl2FW2TcA)

Encrypted tokens might help against CSRF, but if I have your session ID, it's game over. The best you can do is restrict the user agent used with the session, but that's an obstacle that can be overcome. You might try to restrict the IP address used with the session, too, but those change often even without attack that it's not practical, either.

The robustness of the public CA system is a legitimate problem, but it's not a concern for most of us. People like to complain that the public CA security model is not perfect, but we have to remember that the CA ecosystem was not designed for perfection; it was designed to enable ecommerce. We now have different goals (well, some of us) and have to change our approach accordingly.

MITM attacks using fraudulent certificates are very costly and make sense only against very high-value properties. If you're legitimately worried about them, you should consider using public key pinning, which effectively deals with the problem. (But, alas, only works in Chrome today.)

We just scored F: https://www.ssllabs.com/ssltest/analyze.html?d=scirra.com

But I'm not quite sure what I need to do to make it better?

What web server are you using.

the big one is you need to remove the following cyphers: SSL_CK_DES_192_EDE3_CBC_WITH_MD5 (0x700c0) SSL_CK_RC4_128_WITH_MD5 (0x10080)

and disable sslv2

What tacticus said: disable SSL 2. But there's nothing wrong with the web server. (Also, given that you're using IIS, it's unusual that TLS 1.1 and 1.2 are not enabled.)

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.

Can you please clarify exactly what you mean by compression? Is this referring to typical gzip compression in HTTP results or something else?

>Is this referring to typical gzip compression in HTTP

Yes. It's a major vulnerability discovered in the past few months that significantly weakens the crypto.

Website Describing the attack: http://breachattack.com/

Django Blog Post: https://www.djangoproject.com/weblog/2013/aug/06/breach-and-...

That's not cool. The last thing we need is more things for people to use as reasons for not using HTTPS at all.

Yes, BREACH exploits HTTP body compression so this means typical gzip compression in HTTP results (see http://breachattack.com, http://en.wikipedia.org/wiki/HTTP_compression#Security_impli...).

Full Paper: "BREACH: Reviving the CRIME Attack" (http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%2...)

Don't use HTTP compression on private responses when using TLS. It's okay to HTTP compress publicly available images/scripts/stylesheets

Well, be careful that it is just the body that gets compressed.

The vulnerability occurs when the cookie is part of the compression payload. Although that does depend on the attacker being able to control what gets sent.

Probably best to serve your public/static content on a cookie-less domain, so your session cookie is not sent on those requests.

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.

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.

> no 3rd parties can snoop on your data

And Google is what... ?

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...

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

I think the idea is to make MitM snooping more difficult, not necessarily data collection by a third-party.

I agree, though, it is kind of silly, knowing that Google has been complying with large numbers of FISA requests.

Google Analytics data is anonymized and aggregated - it's very different than request patterns and sessions tied to a specific IP.

The data Google give back to you in Analytics may be "anonymized and aggregated", but the data you're allowing them to collect from your users on your behalf is certainly individually-identifying and specific (and shareable with the NSA either wholesale via some PRISM-like means, or at the very least via court order or NSL)

I've been told Piwik (http://piwik.org) is very good. I'll give them a shot. If they're good enough, maybe I'll replace Google Analytics with them - then at least I own all the data myself.

/etc/hosts...

   # Screw Google...
   127.0.0.1	www.google-analytics.com
   127.0.0.1	ssl.google-analytics.com

Are you sure they only use one domain? Perhaps for analytics, but there is also adsense, doubleclick and who knows what else.

I don't mind adsense, and if I did, there's always AdBlock. No, analytics was annoying me because of page load time. The number of times my browser stopped loading because "waiting for google-analytics.com" got me wound up enough one day to just block them for good.

Yeah, I use this myself a lot, especially when I'm in places with bad wifi.

I mentioned this in a separate comment, but I can use this as inspiration to try out Piwik (http://piwik.org), and see if it can replace Google Analytics.

I use Chartbeat for real-time-y stuff and alerts, which it's exceptional at. I think Piwik may have a harder time replacing that one, but I'll certainly try it.

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.

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

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.

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.

@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.

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

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...

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...

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!

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

You can use StartSSL certificates with SNI (Server Name Indication) which allows you to have multiple sites/domains on the same IP. And really, just get a VPS from Digital Ocean -- be the master of your IP, configuration and fate.

Only issue with SNI is that it has to be supported by the browser. Generally not an issue these days, but something to be aware of.

Edit: Actually, I just looked... WinXP still doesn't support it with IE, so, actually it could be a big issue still.

It's worse than you suggest. XP doesn't have the StartCom root cert unless the user has installed a manual root cert update.

I think the root cert was added through Windows Update a to XP few years ago, so there's a decent chance boxes in the wild have.

SNI is still a no-go on XP though.

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...

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.

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.

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.

Why's this a problem related to SSL?

Without SNI, SSL works on an IP address level rather than a hostname level, just like HTTP/1.0 worked at the IP address level and HTTP/1.1 works at the hostname level with the Host header.

Read https://en.wikipedia.org/wiki/Server_Name_Indication for more info.

Sorry, I wasn't clear. I understand SNI and SSL without SNI.

What I'm not seeing is why it's a problem when a host such as DO doesn't allow multiple IP addresses on a single machine.

Is it because you may want to host multiple sites on that machine and use one IP address for SSL?

Oh, nevermind. It's because you may want to support multiple SSL sites on the same box without requiring your clients support SNI. That makes sense.

We really need to just EOL everyone who has a browser without SNI. People like to say that there's still a lot of XP users out there but surely even a reasonable chunk of them are using Chrome or Firefox with SNI support, right?

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.

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).

In digital oceans defense, the right answer if you need an additional ip for an Ssl secured website is to pay $5/month for it and get a free 512m/20G droplet for it. If the price difference between Linode's $1/month extra ip address and DO's $5/month extra vps is a sticking point - you're not indicating that you care very much about privacy/security.

(There may well be other reasons spinning up additional vpses for each SSL secured site doesn't suit you, but a few dollars a month price difference is surely only being used as an excuse for inaction rather that a show-stopping financial burden - at least for anyone in the top 99% of HN's demographic…)

Yes, XP does not support SNI. Users will be presented with a certificate error however the correct site will be served. It will just have the wrong cert. If this is not a deal breaker for the small percentage of XP traffic expected you should use SNI anyway. Maybe a javascript check to point out to the user why the wrong cert was displayed would nudge them to upgrade.

But they're all in China, so if that isn't your market, then don't worry about it.

If you're in the Mobile space, cutting out Android 2.x is unacceptable: 33.1%!

(Source: http://developer.android.com/about/dashboards/index.html)

Any IExplorer on Windows XP, Safari on Windows XP, Android 2.x, Blackberry, Symbian, Java before 1.7, Windows Mobile up to 6.5 ... the list is quite significant. Depending on your target, you can easily talk about 25% of the traffic.

Yep. Sadly true. We as an e-commerce provider would loooove to enable it as well, but we have to be able to cater to all users for the most part.

Safari on Windows isn't even supported anymore. Who uses it?

A surprisingly large chunk of that ~6% market share.

I used StartSSL certs on a few of my Webfaction-hosted websites with SNI. It was fairly simple, and considering the cost, an excellent service that I highly recommend.

One caveat is that the free certificate lasts only a year.

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.

I had StartSSL certs for a .ST site and it worked fine.

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.

They work in all modern browsers, they do not work in certain (very) old versions of curl, wget, android etc.[1]

They should be alright for most stuff, especially for personal use.

And they're free because it costs them nothing to issue them.

[1] - https://forum.startcom.org/viewtopic.php?f=15&t=1802

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.

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")

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.)

I think the main catch here is that they're only willing to issue level 1 certs to individuals. For commercial endeavors, they make you pay money, and then they also have you send in proof of identity and stuff, and manually review your documents. I don't think there's a practical difference in security level, but I'm not an expert in this (which is why I don't address this aspect in my guide).

Unless I've misunderstood their policy, they also forbid individuals using Class 1 certificates commercially. For example, if you run a blog with "Support my blog! Buy my T-shirt swag from swag-selling-site.com[link]!" then your blog is commercial (per legal definition of commercial; IANAL); thus StartCom's policy forbids you to use their free certificate for that site.

The first sentence and a half of this paragraph[1] from https://startssl.com/policy.pdf expressly forbid it. Its final "when" clause might be trying to limit what is forbidden, but, grammatically, it has no power to restrict the first sentence, and doesn't properly restrict the second sentence either.

[1] "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."

(Naturally, I hope I've misunderstood their policy.)

I am pretty sure that you can't use them for commercial projects

They do not work on Windows XP (unless the user is using Firefox or Chrome), as the StartCom certificate is not part of the XP trusted root certs. There is an update available from Microsoft to add some new root certs but as far as I can tell it is a manual only update, which means it's very unlikely to be installed by XP users.

We tried to switch our site to https only recently, and had to backtrack because of this (and because we are too cheap/stubborn to buy an SSL cert from someone who is in the XP trusted root certs).

StartSSL is wide spread enough that anyone who doesn't have their root installed is probably used to clicking their way through SSL warnings anyway.

They don't provide an EC or DSA CA (only RSA) you are limited to 1 domain + 1 alt name (the main domain) per cert

Those aren't horrible trade offs tho, but yes, those are limitations.

They won't authorize brand new domain names for about 72 hours. And you have to renew every year. Otherwise, I've used em and they're good.

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/ 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.

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.

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...

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?

This is my thoughts exactly.... Cue Conspiracy Theory

And how do they guarantee identity for zero cost to them? To actually meet all the CA requirements to be a default trusted root isn't easy.

Like all inexpensive ssl certs, the only guarantee of identity is "domain validation" -if you can read mail going to webmaster@, hostmaster@, Postmaster@, or the email address in a Whois lookup for the domain in question, they'll provide you with a signed key for that domain.

There are higher levels of validation - "business validation" usually involves faxing someone copies of various government supplied paperwork and receiving phone calls on publicly available phone numbers (which is just "outsourcing the identity guarantee" to yellow pages or Dun and Bradstreet.) "EV" validation ( for "green address bar as well as padlock icon" security requires all that plus spending lots of money.

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.

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.

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: in chrome this is not 100% true, some certs are pinned by having their trust hardcoded. its a very small list, require browser update, and of course, you're still trusting a large CA anyway)

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.

>it matters if browsers trust them (which they do).

We had endless problems with StartSSL on mobile browsers. They have only recently been added to the latest Windows Mobile 8 repo and you can forget about any phone OS (except iOS) that was released before 2012.

The thing with SSL providers is most people think if it works on Chrome and IE they're set, but for certain businesses they need something that will work on the Wii Browser, an IBM Power System, or an older dumbphone. SmartTV's in particular are pretty annoying to get any CA list because whoever implemented the browser portion on the devices probably just imported some random Java lib from circa 2002.

If you are doing something small and personal, StartCom is just fine. If you're running a business, at some point it may become inevitable that you switch to oldest provider you can reasonably sign up for, in particular one of the Original Three (Thawte, GlobalSign, or Verisign). If you're running a non-profit advocating for privacy and cryptography where a large number of your users may be based in the middle east running on legacy hardware, you may want to take a cursory look to see if your users are getting any cert problems and get a cert from Thawte (the cheapest of the three - though you will need to chain to an intermediary cert if you got with their 123 option).

Just because you're paranoid...

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?

For another point of view...free is what you get http://danconnor.com/post/50f65364a0fd5fd1f7000001/avoid_sta...

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.

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.

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

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 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.

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…

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

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

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.

> 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?

They don't provide that anymore, even if you're on HTTPS.

I had this same question on a yesterday's thread: https://news.ycombinator.com/item?id=6438992

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…)

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

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.

What, I thought you had to pay? Yup, it says you have to pay

You have to pay for the business plan. If you're already paying for that, the SSL is free. Unless they've changed how it works and I've just gotten grandfathered in or something.

Nope, they issue it for you. I believe that's pro and up.

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.

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.

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 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].

[1] http://getssl/en/ssl-certificates

FYI, in my research, about 10% of Alexa top 1 million sites support SSL. For the configuration of those 10%, see SSL Pulse https://www.trustworthyinternet.org/ssl-pulse/

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

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

E.g. http://en.wikipedia.org/wiki/Hacker_News redirects to https://en.wikipedia.org/wiki/Hacker_News .

Are you using the HTTPS Everywhere extension, perhaps?

No I'm not. I'd love to, but there is none for Safari as far as I'm aware of.

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.

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

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.

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

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.

I believe the problem is that it's impossible to distinguish between "the remote server doesn't care about authentication" and "the remote server cares about authentication, but your traffic to it is being intercepted and modified by an eavesdropper who is retransmitting the data without the authentication flag".

You can opt for only #1, but virtually every browser will put up gigantic warnings about it because it's indistinguishable from a MITM attack.

Unencrypted communication is also indistinguishable from a MITM attack.

Right, but it's distinguishable from encrypted communication.

We have client-side signals for those things. http means unencrypted, https means encrypted. To do encrypted-but-not-authenticated, I guess you'd need a third URL scheme for it, to know when you're supposed to get that, since you can't shoehorn it into https safely.

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.

Still, having #1 is still better than neither. Instead of the NSA (sorry for beating a dead horse) simply siphoning your plaintext off the wire, isn't it more secure if you force them to have to actively fudge every single key exchange in order to read your traffic?

(The "locks on doors" argument.)

The problem with this argument is that you don't need to be the NSA to compromise an unauthenticated encrypted channel; that's a task well within the capabilities of online criminals.

I'm didn't mean NSA specifically; that was just an example. I know it doesn't require massive hardware or anything like that because it doesn't involve breaking the encryption.

My original point is twofold:

First, having encrypted/unauthenticated communication is still better because it takes more effort to intercept, while doing so for unencrypted/unauthenticated is trivial (e.g. Google's WiFi sniffing debacle).

Second, encrypted/unauthenticated can be implemented to be almost completely transparent (for example, server and browser do a key exchange on every request; kind of how gzip compression is automatic), whereas encrypted/authenticated requires certificates (which you have to pay for, renew, copy on your server, etc.).

Right now X% of sites use HTTPS and (100 - X)% don't. It would be best if 100% of sites used HTTPS. But using _some_ form of encryption for the (100 - X)% is better than nothing, and more achievable than saying "encryption-only is useless, everyone should use authentication as well".

(I can't find any stats for HTTPS usage, hence the variables.)

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.

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.

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.

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...

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.

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.

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

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.

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.

> 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.

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.

The particular publicly-available information that people are interested in is privacy-sensitive. It's easiest to see this by thinking about articles on sexual, medical, and religious topics at Wikipedia (or WebMD!). Although the information is public, users don't want others on the network to know that they read it.

And on some networks, the content of news articles that we might think of as totally innocuous is considered very sensitive, and the network operator might try to block it. The most familiar example might be news about annual commemorations of 6/4. Using HTTPS provides resistance against content-based censorship because the network operator doesn't know when users are reading the specific things that they wanted to prevent them from reading.

It can get worse than people snooping on what you're reading ... they can also modify the content. In many places, like at cheap motels or providing free Wifi, they inject ads into content pages or other crap.

So how do you know if the content you're reading has not been tampered with? You don't, unless the connection is encrypted.

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

You can also get free SSL certificates from LOLroot CA!

http://lolroot.ca/

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.)

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

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

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

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

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

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.

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

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.

> 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.

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.

That's why no free mail servers allow you to do that.

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.

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.

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

Globe SSL 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.

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.

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.

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?

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

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

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

But how do you distinguish a self-signed certificate from a MITM NSA-signed one?

NSA does not use self-signed certificates for MITM, they have access to certificate authorities to get there own certificates that show up as valid in your browser.

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.

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.

MITM would be unnoticeable then.

Unless you visited the site before. (like ssh). Or if the trust was provided through another channel (DNS).

If somebody can tamper with your HTTP connections on the fly, they can surely rewrite the DNS too.

maybe, maybe not they use separate paths in general so its quite a bit hard as you need to be closer to the client, or compromise more hosts. not saying it's the bulletproof solution tho. it's definitely not. its just that some services (like ssh) actually provide that feature.

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

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

(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

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

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

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

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?

a) Well, if you setup your startcom SSL cert with the browser, that means you've been forced to add StartCOM to your truststores.

b) I simply don't trust them, particularly since they use a keybased auth system -- any compromised computer that was used to setup a startcom cert can download the private keys

a) True, but I set it up from Firefox.

b) I think it's moot whether this is better or worse than a password, but I'd probably pick the key-based system (which requires you to physically have my computer) over a password-based one (which might be hacked remotely).

It checks out okay for me (Safari) and with a testing tool: http://www.digicert.com/help/

Thank you so much for sharing this!!

Reply on news.ycombinator.com