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!
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.
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!
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.
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.
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?
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.
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.
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.
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.)
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).
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.
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].
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 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 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.
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...)
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.
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.
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.
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.
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
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.
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.
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.
> 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.
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 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.
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.
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).
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.
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.
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.
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 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…
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.
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 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.
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.
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.
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.
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.
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...
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.
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.
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.
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?
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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.
(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.
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
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).
> 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.
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.
> 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…)
263 comments
[ 2.0 ms ] story [ 136 ms ] threadOn 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 mean, we're not talking a huge amount of money. Webfaction is $5/month [1]. Still!
[1]: https://www.webfaction.com/features
Edit: Actually, I just looked... WinXP still doesn't support it with IE, so, actually it could be a big issue still.
SNI is still a no-go on XP though.
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...
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.
Read https://en.wikipedia.org/wiki/Server_Name_Indication for more info.
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?
And dedicated IPs for websites are extremely expensive.
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).
(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…)
(Source: http://developer.android.com/about/dashboards/index.html)
One caveat is that the free certificate lasts only a year.
If not, than this is exactly what we need to establish HTTPS as the new standard.
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
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.
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")
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.)
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.)
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).
Those aren't horrible trade offs tho, but yes, those are limitations.
http://safebrowsing.clients.google.com/safebrowsing/diagnost...
Somebody should go through the top 10k websites and make a list, then repeat every few months.
[1] http://getssl/en/ssl-certificates
E.g. http://en.wikipedia.org/wiki/Hacker_News redirects to https://en.wikipedia.org/wiki/Hacker_News .
https://www.eff.org/https-everywhere
[1] Ex: https://ianthedeveloper.com
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.
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...)
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?
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.
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.
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).
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.
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 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.
Got any source? Would really like to show that to some folks here ...
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.
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.
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.
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.
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 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.
https://www.schneier.com/blog/archives/2011/03/comodo_group_...
https://kb.bluecoat.com/index?page=content&id=SA54&actp=RSS
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.
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.
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.
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.
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.
[1] http://www.informationweek.com/security/attacks/how-startcom...
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.
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.
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.
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.
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.
So how do you know if the content you're reading has not been tampered with? You don't, unless the connection is encrypted.
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.
> 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.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.
And Google is what... ?
I agree, though, it is kind of silly, knowing that Google has been complying with large numbers of FISA requests.
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.
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.
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-...
I developed my nginx config based on their recommendations: https://gist.github.com/konklone/6532544
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:
Doesn't this leave you vulnerable to session theft?
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.
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.
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.
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)
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.)
But I'm not quite sure what I need to do to make it better?
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
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-...
LOL! Kids...
Full Paper: "BREACH: Reviving the CRIME Attack" (http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%2...)
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.
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.
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.
Plus he was going for validation, which isn't free and is a pretty obnoxious process regardless of who you go with.
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.
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.
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.
(b) Why? I understood they were among the better providers.
My Safari can't verify the identity of that website. This is Safari 5.1.7.
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
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).
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.
It also highlights a critical SSL issue; there's really little strength in the concept of a certificate proving the identity of anyone.
http://lolroot.ca/
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.)
"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
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?
I had this same question on a yesterday's thread: https://news.ycombinator.com/item?id=6438992
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…)