You could pivot to in-depth reviews of the various providers.
I'm sure some providers will be a pain in the backside, some will be great, others somewhere in the middle, and all will have various differing support options, up-sell discounts to "premium" certs and so on and so forth.
I've long had the idea of hosting a site for product reviews of enterprise software. There's so much shitty software produced by big vendors and IT managers keep buying them. I'd love to right this wrong, but the threat of libel scares me. The biggest vendors spend all their money on sales and lawyers.
Goodness, what on earth were you thinking of writing about these providers that'd be so libellous?
;-)
More seriously: by the time you'd become a worthwhile legal target, you'd have to be earning a decent living from your reviews that'd more than cover predatory legal costs.
Given the ridiculous number of review sites out site, and how few of them apparently end up in court, I think you can work out the likelihood of such issues for yourself.
You could try being a Yelp for CAs. The exemption for letting other people write their opinions on the internet is pretty ironclad [as long as you honor DMCA notices].
At least to me, it seems the simplest solution is to only sell advertising via a 3rd party bidding system where you aren't involved in the sales process and don't initiate contact. [i.e. Moderation of ads is handled by the 3rd party, not you ]
> Increased risk of losing everything to the American legal system: non-zero
Nah. The worst that will happen is you'll get a letter from a lawyer demanding you take it down. It will be a completely fake letter, with zero basis in law, but if you are worried you can take it down at that point at no monetary cost to you.
Make yourself easily contractible to encourage early contact.
You can also make a way for them to submit a rebuttal that you'll post, that works too.
A lot of states have anti-SLAPP laws that make it much harder for big companies to throw their weight around to legally intimidate legitimate critics, so it might not be as bad as you think:
There's a shift happening in the browser space as well to "downgrade" the UI for DV certs, much less green locks and bars and more gray and no red security warnings.
We're entering a world where every site has a DV cert (most likely for free with registering a domain) but that all of the things for which we now consider "needing SSL" will require an EV cert.
EV certs will only make sense (for the vast majority of sites) when consumers start actually recognizing the difference between EV and DV, personally I don't see that happening real-soon as many non-technical consumers don't even notice if there's no SSL cert at all...
Ask yourself do you remember what sites use EV certs and would you notice if one had a DV instead... if you wouldn't ask yourself why a company would pay more money for that EV cert, when they can get a perfectly good DV one for free
And yet Heroku still charges $20 per month on top of their usual fees just to host your certificate. This is why I've moved so many simple static sites to Digital Ocean droplets.
About time! It's insane that CAs have gotten away with charging extortionate amounts of money for a couple paragraphs of text that cost ~nothing to generate for so long.
If this is true, it's far better news than Let's Encrypt ever was. I tried the Let's Encrypt beta and was extremely disappointed that getting a certificate isn't possible with DNS records—you have to do the challenge response by serving a page from the live server. This is a non-starter for many use cases. If every CA is going to be offering certs free soon, at least one of them is bound to have a real API that's not encumbered by terrible tooling.
Throughput drop and latency increase aren't solved by free certificates.
In throughput Netflix did a lot of work [1] to optimize HTTPS for their use case, and still went from 40 Gbps (network limited) to 10 Gbps (cpu limited). So they would need a 4x deployment to satisfy https everywhere to serve already encrypted files. This is probably not a big deal unless you're doing a pretty high volume of traffic, or have a really low powered server.
TLS setup adds at least one extra round trip to connection setup. This is a major latency penalty if you don't have servers close to your users. This is more likely to affect smaller sites/services, as geographic distribution comes at a signifigant cost (lots of servers + geodns/smart clients, or proxy through a cdn and lose end to end confidentiality)
Given that they own the whole stack, there would be value in statically encrypting content and serving that through an unencrypted channel, after having served the correct parameters through an authenticated-encrypted channel of course.
Basically, something like serving a torrent file through HTTPS and then using standard, unencrypted, full-speed bittorrent for sending the raw data.
Since the files are public, static encryption wouldn't do any good - the attacker could still build a database of hashes of all encrypted files, and then identify what you downloaded. What they really need is to sign the files, to avoid tampering.
TLS actually supports this, using a NULL cipher - you can make a regular HTTPS connection where the domain is verified and the data is protected from tampering, but everything is in clear-text. Alas, browsers don't support this configuration, since it's usually used by mistake or as an attack.
For 1. as I said the easy way is to distribute the torrent file through an authenticated, verified connection and then use that torrent file to get the raw data. Anything that doesn't hash to a piece in this torrent file is considered garbage.
For 2. that's an issue I didn't have in mind, and as long as the attacker can sign-in they can match an exchange with a database of hashes, so it's not protected in this regard.
I think you're correct. The cost for an SSL certificate is trivial for any legitimate company, and the processing overhead to encrypt every request hasn't been a concern for years.
Ad supported sites can't really use it since the vast majority of ads are still not SSL compatible, meaning you get mixed content warnings (and no ads / revenue).
Most ad networks aren't very technically savvy and some try to steal or capture more user data through normal http.
Any modern ad platform will support HTTPS and there are plenty of options. Many top publishers are already using HTTPS for the entire site so this isn't really a big issue.
- It's somewhat complicated for a site to implement correctly
- It mainly protects users who have already connected to a site once
from a secure location and whose browsers support HSTS and other "fixes"
- Circumvented easily via phishing
- Does not prevent nation states from MITMing connection
- Can only host one site per IP, without a wild-card or UCC cert
(which not all clients support)
- Makes caching difficult to impossible
- Adds performance overhead
- Potential for new attacks on the TLS layer
(SSL Strip, STARTTLS Command Injection, BEAST, POODLE, RC4, CRIME,
TIME, BREACH, Truncation, FREAK, Logjam, Heartbleed, BERserk,
Root cert forgery, ChangeCipherSpec injection, Protocol downgrade,
Certificate errors, Renegotiation, Triple Handshake,
Virtual Host confusion, DoS)
- General confusion by users as to what makes a connection secure
Someone asked why somebody might not use HTTPS and i'm just saying what their excuses are. This isn't even a list of reasons why people cannot support HTTPS, which includes public agency policies, legacy support requirements, funding limitations and lack of resources.
> - It's somewhat complicated for a site to implement correctly
This is true, but the same thing was said about running a site at all not long ago.
> - It mainly protects users who have already connected to a site once from a secure location and whose browsers support HSTS and other "fixes"
The point of using a valid CA is to allow the first connection be secure. It's certainly true that you can secure subsequent connections more than the initial one though.
> - Circumvented easily via phishing
Phishing is attacking something completely different and is not something SSL/TLS can or should protect you against. It's like expecting a seat belt to protect you from being run over.
> - Does not prevent nation states from MITMing connection
Actually it does if HPKP is used, though not on the initial connection.
> - Can only host one site per IP, without a wild-card or UCC cert (which not all clients support)
This is supported via the server name indication extension, and additionally by using multiple subject alternative names. The former is better though since it allows each site to have its own key.
> - Makes caching difficult to impossible
True, but that's a feature. Caching on the client is still of course entirely based on what the client chooses to do.
> - Potential for new attacks on the TLS layer (SSL Strip, STARTTLS Command Injection, BEAST, POODLE, RC4, CRIME, TIME, BREACH, Truncation, FREAK, Logjam, Heartbleed, BERserk, Root cert forgery, ChangeCipherSpec injection, Protocol downgrade, Certificate errors, Renegotiation, Triple Handshake, Virtual Host confusion, DoS)
Note that there are protections again those, and saying "because it might have a problem" is basically just burying your head in the sand of the problem you already have.
> - General confusion by users as to what makes a connection secure
True, but not a good reason since you as a site owner can do most of the work for them (in combination with their browser).
There sometimes may be an excuse in the extra roundtrips required to set up a TLS connection. For a public blog that doesn't accept submitting any information (like comments), for example, plain HTTP may be fine.
I wish that were true, but honestly, plaintext isn't fine for anything at all in 2015, whether authenticated, important, public or otherwise, whether the network is the internet or a LAN.
HTTP sites have had attack scripts injected into them by nation-states, used to DDoS others on a massive scale - and that capability, and the desire to use it, is unfortunately proliferating rapidly.
Unless you want to be part of that problem, you're going to have to go HTTPS on everything - cat videos included - no matter how important or unimportant you think it is. I really wouldn't be surprised if tcp/80 goes the way of tcp/23.
On a brighter note - the speed difference is negligible with modern cryptography, and as others have mentioned, TLS 1.3 is developing handshakes with less TCP round trips. It's possible that a future protocol (taking into account what's been learned by Google's QUIC experiment) may deliver faster handshakes over UDP if possible to avoid the TCP handshake overhead - there's energetic research in that area at the moment.
Fair enough. TLS 1.3 might introduce a zero-RTT handshake (with some security trade-offs), but that's obviously going to take quite some time to get rolled out.
> For a public blog that doesn't accept submitting any information
TLS is not about accepting information, it's about ensuring that the connection's encrypted and authenticated.
It is still important to prevent unauthorized third parties from watching which articles you're reading. And it's still important that you know that you're reading a blog you expect to read, not a modified version served by someone else (although CA system isn't completely sufficient for this, at least it thwarts less-powerful adversaries from spoofing).
I'm having some difficulty thinking of a scenario where, given the choice, I'd trade off authentication for speed. The information would have to be of so little value that it doesn't matter if the remote party gets what I send or if I get what the remote party sends.
You're assuming that the probability of interception is 100% In reality, the probability of interception is miniscule, but the probability of speed is 100%.
The probability of interception is massively higher than miniscule, see the recent wide scale hijacking of Chinese traffic to DDOS Github or ISPs inserting ads and tracking into responses.
These types of attacks have been hypothetical for a long time, but we're starting to see real world impacts of not using https, and they aren't trivial.
The Greek government inserting ads into that site is very low on my list of concerns, but the additional 200-400ms on the first page load is much higher up.
Am I correct in understanding your point as "there can be no conceivable case where two fewer TCP roundtrips would be worth the speed gain over the decreased security"?
Unless someone care about a single extra round-trip timing, e.g. extra 10-300ms with 300 being quite a stretch? I'm sure it doesn't matter if a blog page opens in 40ms or 55ms - a reader won't tell the difference.
Hey - so I tweeted that...and to be very clear, nothing in that tweet should have been implied as a yes. But since it was potentially construed as a yes, it was deleted to avoid confusion.
In the blog post, you point out that you perform additional validation for your OV certificates while the free CAs do not. But since they are equally trusted by the browsers, how does that increase security for me?
On the other key differences:
- Shorter lifetimes is actually an advantage, since it reduces the risk when your keys are compromised. Revocation is a mess, the only way you can be sure that a certificate can no longer be used is when it's expired.
- No wildcards is an advantage too, since you can give each service its own certificate and if one is compromised, the others are fine. If you're using an organization-wide wildcard cert, a compromise is much worse.
- Limited flexibility - "you must have root access to your servers " is factually incorrect, the automated Let's Encrypt client is optional and you can request a certificate manually.
- Limited support - why would I need a SLA for a certificate, anyway? The OCSP servers?
- Management difficulties - while this is true now, the automation enabled by Let's Encrypt is likely to facilitate management, not the contrary. I'm currently working on a Puppet module which will automatically provision certificates for web servers, something which used to be much harder.
- Build Trust with Purchased SSL - how do I increase trust by using a OV certificate? It's not like an average website user would look up the certificate details, and there's no functional difference between a OV and a DV certificate.
> The levels of encryption, validation, and trust that business and commerce websites require are available only with purchased SSL.
Unless you're talking about EV certificates, I don't see how. There's no "level of encryption" which isn't available with a free CA, and the additional validation and trust do not matter unless it's a EV certificate. Even an EV certificate does not protect against MitM. The real answer is key pinning.
As a Namecheap customer, I'm disappointed by this blog post. It reads like an attempt to spread FUD about free DV certificates. I initially became a customer because I read good things about your business ethics, but this makes me question my choice.
As a Namecheap customer I was very very disappointed with this post when I read it yesterday. Also, it looks like they deleted a comment on their post from someone else who was disappointed and called them out on their FUD.
Much better, but they're still arguing that somehow, non-EV certificates with identity validation are more valuable than DV certificates because users are going to look up the certificate details.
> We think that validation of a certificate’s owner is an important point that needs to be highlighted and discussed. Recent developments in SSL automation are fantastic from a technical point of view, however, consumers need to be educated on this new security paradigm and the appropriate signals to look for when making a security determination. Looking for ‘https’ and a lock in the browser bar, the traditional indicators that have been messaged as reliable, may not be so reliable anymore when it comes to the consumer definition of security.
This is laughable. It's been hard enough to get users to check for the presence of a security indicator at all. Most don't even know the difference between DV and EV, and EV certificates do have a strong visual indicator. OV certificates don't have any, except
Hell, I might not realize in time that my online banking session only has a DV certificate today instead of EV and I'm a professional.
Sure, I sometimes check which CA a particular site is using, out of curiosity. But no normal user is ever going to do that on a regular basis.
> Additionally, any time we receive a report of abusive activity and/or fraud involving a certificate, Namecheap works with CA’s to investigate the reported sites, and CA’s often take quick action to revoke site certificates as a result. This third-party revocation capability is important; it provides an additional layer of post-issuance protection.
Soo... How does that protect me as a Namecheap customer? Buying from Namecheap doesn't mean that an attacker couldn't request a Let's Encrypt certificate anyway, unless you use cert pinning and you can do that with free certificates. There are some enterprise use cases where you'd just pin the CA instead of single certs, but those only matter at scale.
Namecheap is right about OV certificates being more trustworthy than DV ones, but the thing is - it doesn't really matter.
> Additionally, given recent developments, we strongly believe that additional education is required on the correct signals for consumers to use when making a security determination; browsers must necessarily shoulder some of this responsibility,
Like.... EV certificates? C'mon, browser vendors aren't going to add another security indicator just to protect your revenue.
Yeah, their points are all pretty shaky. I've been a fan of Namecheap for awhile because of their past support for a better internet, but it's extremely disappointing to see this post from them.
I guess I didn't expect them to put their profits over what's best for the web.
Thanks for posting here to clear things up. (Sometimes deleting tweets can cause more confusion than it removes.)
Does the blog post I linked to reflect the opinion of most of Namecheap, though, really? I like Namecheap and I would be disappointed if the majority of the company believed that all free CAs will be operated like Let's Encrypt.
I don't think we're making a blanket statement about "all free CAs" here. Encryption is one important aspect that free SSL providers offer, validation and trust is another that isn't offered by most.
I respect that. I hope free certs will be a boon for the EV cert industry, since businesses will need to stand out more as trusted.
Perhaps, though, you could pass it along to whomever it concerns, that the blog post reflects poorly on Namecheap. It's obviously targeting Let's Encrypt, but it uses vague phrases like "SSL certs from free providers" that _do_ come across as blanket statements.
I wonder whether spammers and phishers will make use of that? We often tell people to look for the lock symbol or "https" - those will no longer be (weak) signifiers of trust.
DV SSL certificates are not effective counter-measures for phishing or scammers. That's one of major advantages of EV certificates.
EV SSL (instead of the green lock) appear as the company name in a green bar (see GitHub, Stripe etc). Almost all financial institutions use EV for any account handling (in fact I think it's technically against regulation for a CA to offer DV to those).
The downside to EV is that it isn't free - the validation is much stronger and actually requires (human) resources and time to validate that the domain (and buyer of the cert) represents a government-recognized company/organization.
Let 'em. With something like Let's Encrypt that uses an API to sign domains on the fly, I'm having a hard time thinking of a use case that would be appropriate for wildcards but not appropriate for this.
The vertical axis isn't labeled and I can't tell what the bars are supposed to represent from the context? Is the vertical axis pain? Cost? Customer base?
Thanks for the feedback Mike! It's speed. I've reverted the text back to the previous copy which was more specific.
Further info: ask anyone you know who's got an EV cert from a traditional provider: it's a slow, painful process. CAs typically quote 7-10 days. I waited a month for GoDaddy earlier this year, and many others have too.
CertSimple starts checking your details while you fill in the form, and flags a wide variety of issues before you pay us. Our average validation time is 5 hours.
During validation, we provide very, very specific instructions based on a number of aspects of your order and your company. People with .io domains and Swedes really like us. As do in many other situations where the EV process typically shows down.
We update in realtime during the validation, and the certs downloads automatically.
We're about to replace the graph with the wall of Twitter customers from our front page, so let me know what you think of that!
Maybe someone listened but it recently took 2 days to get an EV cert from Comodo via Namecheap. Some of that was probably due to having a registered company with a DNB Number - YMMV.
Is there really much demand for that? If you want an EV cert you're going to be a big business with a lot of employees just to handle that kind of stuff. 2 days really isn't that long - getting internal signoff on the idea of using an EV cert probably takes longer than 2 days.
That seems kind of self-fulfilling. If the process is slow and bureaucratic then naturally only slow, bureaucratic organizations will get them. But maybe demand for EV certs would be greater if the process was more streamlined.
I've recently spent two months trying to get a code signing cert from Comodo (same validation process as EV) for a completely legit real business and ultimately failed. The whole experience sucked beyond belief.
Great, it's totally clear now. I guess somebody changed the text and didn't realize the implications for the graph? Seems like an easy mistake to make.
But to what agencies will they disclose the private keys?
We need a SSL system where there's both a CA-signed key and a self-generated and self-signed key. That would prevent both forged sites and CA-assisted snooping. CA-signed alone is vulnerable to Government wiretapping. Self-signed alone is vulnerable to site spoofing. Both together would provide some real security.
That's how the CA system currently works: you generate a key and a certificate signing request, and only disclose the public key via the CSR to the CA. The CA then uses their own key to sign yours. The CA key literally cannot be exported, and this is audited.
Wiretapping is immediately evident based on the key used in any malicious certificates; HPKP helps this.
This is all good and well, but if we take a step back it pretty much means that anybody can get a DV certificate without any verification, which means CAs are useless, which means that DV certificate offer no more guarantees about anything than self-signed certificates.
Which is an excellent thing: maybe we'll finally be able to just use self-signed certificates ? And ask CAs for something where they actually can provide value, ie EV certificates, for as long as we're okay to stay with this model ?
This should be a call to browser vendors: when this is more widespread, accept self-signed certificates as if they were DV certificates !
DV certificates does provide a service that self-signed certificates don't, though: they verify that the server controls x.com according to the public DNS system, not just according to the user's ISP/DNS server.
Strictly speaking, they verify that server controls x.com according to the CA's ISP/DNS server/any other parties in the middle instead of the user's ISP/DNS server/any other parties in the middle.
That's just not true. It changes exactly nothing in the amount of guarantees provided by a DV cert. They guarantee that you are communicating with the domain you think you are communicating with and that there is no man in the middle. Self-signed certs can't provide that guarantee.
Of course there's still the question of how trustworthy are the CAs. But I don't believe them charging money for DV certs has any impact on that either.
I tried using CloudFlare for my site, but they (or their CA partner) wouldn't issue a certificate for my domain (piranhas.co) because it contains the substring “iran”. Seriously[0].
Unfortunately, the CAs have their policies and we must adhere to those. We're working, however, on ways to better (and automatically) communicate with them when we encounter false positives. In this particular case, yes, some have very basic string matching for keywords like "iran" -- but in these scenarios we can (and do) request them to recheck by hand.
Your particular request should have been handled in less than 24 hours (or shorter, if non-free plan). The process for some of them is more manual than we'd like, but a support request can be filed to expedite if this happens again.
I had the a similar problem, they refused to issue a certificate because the domain had a trademarked word in it. Seems strange they would be the ones to enforce trademarks, but I guess it could be considered as an anti-phishing measure or something.
This is a relic of the CA/B Forum (https://cabforum.org/) delegating review of brand/trademark checks to the CAs. We (CloudFlare) send hostnames to the CA for issuance and they check against internal lists, holding up anything for manual review that may violate another's trademark or be used for phishing (e.g., "pavpal" with a 'v' rather than a 'y'), etc.
Each CA has their procedures but most look at data sources like the Alexa Top 1000, and specific requests from high value targets like Microsoft, Google, etc. In some cases, e.g., Microsoft, the CAs must actually reach out to specific contacts at those firms before they can issue. In other cases, they manually review and release to us.
While we often make announcements there, Twitter isn't an official support channel. Requests should be filed at https://support.cloudflare.com where they can be tracked and responded to directly.
Two caveats with Cloudflare, not really criticisms, more just that this is the deal:
First, it's a shared certificate (several hundred other domains will share the cert with you). This has occasionally led to some awkwardness and misunderstanding in the non-tech world [1] and a few times has led to a site being blocked as "porn/inappropriate" by content filters as it gets identified with other sites.
Second, in many cases it's not full browser to server encryption.
Browser --(SSL)--> Cloudflare --(Not SSL)--> Server
"Several hundred other domains" is factually inaccurate. At most, there are ~40 other zones on the certificate (typically, far fewer).
The challenge here is IPv4 address space; we don't require SNI for paid plans -- cert will be returned even if server_name is omitted from the TLS ClientHello -- so we must assign these customers dedicated IP pools. We're actually in the progress of migrating all paid customers to their own certificates, so this issue will go away soon.
The article already mentions existing free providers like StartSSL and Let's Encrypt - if you really like I can add CF in there too John ;^) - but that's not news.
Perfect illustration of 'free as in speech or free as in beer?'. Wonder who I should contact at CloudFlare for my 'free' DV cert that I can use on my server...
From their page on SSL [0], it's only for CloudFlare customers.
Also, it's not end-to-end encryption, but from client to CloudFlare - so "your" certificate may have 20+ other CloudFlare clients' domains included.
If you are using CloudFlare it makes it easy to set up, and +1 to them for making it available on all their plans. However, they're not a CA (they use Comodo?) nor a place to get free DV SSL certs (on its own).
On a personal note, I'm not surprised at all by this news. I received and installed a LetsEncrypt DV over the weekend on my Ubuntu/nginx/node DigitalOcean Droplet. So easy - no way a CA can justify selling DVs anymore.
Highly recommend webroot mode with something similar to this[1].
Put that into a cronjob together with service nginx reload and automated zero-downtime renewal is up and running.
There may be some regulation (or suggested guidelines) about high-trust sites (like banks) that are vulnerable to phishing requiring EVs. Otherwise using the Google Safe Browsing API (as they plan on doing[1]) will probably work and is automated.
I can't wait to test it out when the Public beta will start. I am currently in the process of deploying a new webserver at work so I will certainly give this a go.
I just used this feature with them the other day. The way it works is that if you enable SSL on a site passing through them, they'll auto-generate the front-end cert. I believe you can add your own cert for a premium. The back-end cert can be set to validated/unvalidated/unencrypted.
Let's Encrypt is a bit of a joke though. You have to renew every 3 months. Anyone who has used these certs knows what a huge pain in the arse it is to do even once a year.
"Oh but we'll work out some way to semi-automate it". Ok, where is it for those of us on cheap cpanel providers who barely know what we're doing? I though this service was for us?
no. It will be automated completely. You set stuff up once and the certificate will be kept up to date.
>Ok, where is it for those of us on cheap cpanel providers who barely know what we're doing
let's encrypt support will be added into cpanel or even into the web servers powering cpanel. All you'll have to do is check a checkbox or set a configuration file entry in the style of `enable_letsencrypt=yes` and you're done.
You won't have to care when the certificate expires. At that point 3 months starts to become interesting because expiration provides a nice hard cutoff date for revocation which works independently of OCSP and CRL availablility.
automation will eventually be the way just that Letsencrypt client and 3rd party clients need time to evolve and develop to the stage that is acceptable for most folks
there's a list of clients being developed on their forums some already have auto renewal automation done
No, I mean, this is great news, but I thought I could create value by listing the CAs that provide free SSL on this page: https://paragonie.com/white-paper/2015-secure-php-data-encry...
And soon I won't be. Dammit. And the worst part is, I can't even be angry about that, because it's subverted by a significant security gain.