Domain-validated SSL will soon be free from the large CAs
certsimple.com
certsimple.com
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.
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'm pretty sure you're saying that with tongue firmly in cheek.
Just in case, though, even in the UK you're covered by fair comment:
(I'm in America, where going to court and hoping not to end up destitute afterwards means you already lost.)
;-)
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.
Increased revenue for writing my opinion on the Internet: Definitely $0
Increased risk of losing everything to the American legal system: non-zero
Hence, I hesitate.
Just be careful and look through the lawsuits Yelp got hit with so you don't get accused of extortion.
http://www.huffingtonpost.com/2011/04/02/yelp-extortion-case...
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 ]
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.
https://en.wikipedia.org/wiki/Strategic_lawsuit_against_publ...
My attorney thought I might win the case but a single day of court would cost $6,000 at the time. I settled.
- walking
- asking a friend to drive me somewhereWe'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.
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
- Safari uses a grey lock for DV certs
- Edge uses a hollow grey lock for DV certs
- Mozilla launched Let's Encrypt, and then changed DV certs from grey to green in Firefox.
- Chrome still uses green for DV and hasn't changed
[1]: https://community.letsencrypt.org/t/shouldnt-verification-vi...
Highly recommend this blog post [1] for more.
[1]: https://timtaubert.de/blog/2015/11/more-privacy-less-latency...
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).
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.
Injecting ads, changing content. All possible when the content isn't encrypted end-to-end.
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.
- 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 secureNot really. SNI is about to be called "ancient". Well, it's not supported by IE on Windows XP, but good riddance.
https://en.wikipedia.org/wiki/Server_Name_Indication
The rest of the excuses are basically 'it's not 100% perfect some of the time so why bother any of the time.'
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.
> - Adds performance overhead
Not much, see https://istlsfastyet.com/
> - 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).
- It's somewhat complicated to install it on your door
- Government can kick your door down
- It takes time to turn the key to open the door
- Friendly neighbors can't just hop in whenever they like
- Confusion if door is locked or unlocked by looking at it
Hmm, let's keep our doors without locks then?
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.
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)
Basically, something like serving a torrent file through HTTPS and then using standard, unencrypted, full-speed bittorrent for sending the raw data.
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.
1. Attacker tampering with the data
2. Attacker learning what the user is watching
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.
That could mean a few things, but either way, things are looking good for site owners.
Original question: https://twitter.com/matbacon89/status/667348413470650370
Person's response: https://twitter.com/matbacon89/status/667348648741744640
In between, they _did_ say something like "You'll have to wait and see! :)"
I wonder if they deleted it in light of this blog post, which I find disingenuous: https://blog.namecheap.com/ssl-from-namecheap-whats-the-diff...
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.
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.
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.
> 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.
I guess I didn't expect them to put their profits over what's best for the web.
They would refuse to renew certificates every now and then if they deemed your use commercial though.
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.
Prepare for wildcards to cost a fortune to compensate.
WC certs are already a ripoff anyways.
Serving multiple sub-domains from the one IP whilst still supporting clients without SNI.
https://certsimple.com/images/blog/compare.svg
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?
We do `fast`
It probably doesn't actually mean anything.
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!
Our average validation time is five hours.
Nobody else has our tech or does anything close. When they catch up to what we're doing now we'll be another year ahead.
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.
CAs never see your private key, they are incapable of giving it to the NSA.
Wiretapping is immediately evident based on the key used in any malicious certificates; HPKP helps this.
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 !
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.
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.
And indeed, no surprise. Competition causes companies to compete! Shocking. But good to see just the same.
How was your experience with LetsEncrypt?
1. not implemented the auto client yet for nginx (which meant stopping the service)
2. the opaque-ness of when my domains would be whitelisted
Both of which will be fixed for public beta/release (I believe).
[1]: https://community.letsencrypt.org/t/using-the-webroot-domain...
Regarding #2, do I understand correctly that domain whitelisting is just about which domains can be used with the current closed beta?
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.
[0]https://letsencrypt.org/2015/10/29/phishing-and-malware.html
Just to clarify here, "your" certificate will definitely have around 90 or so other domains listed in it as SANs.
This will make it free without using cloudflare (which isn't desirable/suitable or all circumstances).
It is free via StartSSL too, though some people have issues with that option.
[0]: https://twitter.com/matiaskorhonen/status/561063104596172800
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.
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.
- CloudFlare's PM for TLS
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
1 - http://arstechnica.com/information-technology/2015/03/ted-cr...
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.
"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.
there's a list of clients being developed on their forums some already have auto renewal automation done
see
https://community.letsencrypt.org/t/list-of-client-implement...
for plesk https://community.letsencrypt.org/t/plesk-and-letsencrypt/42...
for Centmin Mod LEMP stack http://centminmod.com/letsencrypt-freessl.html
cpanel feature request at https://features.cpanel.net/topic/provide-support-for-lets-e... where cpanel folks are interested too