Let's Encrypt is Trusted(letsencrypt.org) |
Let's Encrypt is Trusted(letsencrypt.org) |
[EDIT] I have seen this: https://github.com/ebekker/letsencrypt-win
But ideally we would want Microsoft to add a checkbox in the UI of IIS Manager, which when creating a https binding offers to use let's encrypt instead of an installed certificate.
Will definitely use this as soon as they open their doors to me.
Personally, I'm typing this post into a web site using a web browser, so I appreciate that it has a certificate that my browser can validate!
This way, Let's Encrypt in particular would need to be breached for a successful attack, while right now it's enough to breach either Let's Encrypt or any other CA.
Downloading a tool, reading man page, works out of the box only with apache/nginx - ehhh, seems like a lot of work, considering some comments touting 'user friendliness' compared to StartSSL.
The better solution is to integrate this tool into various server tools like Apache and Wordpress and in whatever else you might be running with a one-click installer.
Texas hasn't exactly got a glowing reputation in the software industry due to its mountain of intellectual property lawsuits filed by patent trolls... er, sorry, I mean non-practicing entities
Excuse me while I reserve some skepticism about just how trusted your security certificates should be.
Take for example my setup. It sits on a private NGINX server, and is proxied through a public facing CDN. Trying to simply 'switch on' TLS involves absorbing academic style tutorials from multiple disparate sources, and requires me to have a background in DevOps and that I have at least tried some technical task like this before. In layman's terms: Unnecessary Early Stage Overhead.
Now give Let's Encrypt a few more years and it will be a lot more seamless; possibly the default. It could possibly be 'baked in' to things like Softaculous, and cPanel, which are brilliant drivers for the success of web software. Digital Ocean staff are probably already working on a droplet with LetsEncrypt baked in...
Sure, someone with no devops skills at all will have a harder time, but it's for the better. Soon it will be The Way to install a webserver. Thanks to Let's Encrypt it's so easy to install TLS that nearly every future webserver tutorial will include it.
The project was able to get a CA to sign their keys, this is what happened. Using the word "trust" is simply wrong and might be interpreted as a too simple kind of propaganda after we learned a lot about the untrustable nature of a hierarchical certification infrastructure.
Another, even bigger trust-breaking elephant in the room is the fact that this project is USA based - as long as US government and agencies are insisting on practices we know from authoritarian and anti-democratic states like e.g. China or Saudi-Arabia there is no way any US based project can use the word "trust" for their product description - it might be recognized as a simple lie by informed people.
Questions to the project leaders:
* you must obey US laws and therefore offer MITM access to every Let's-Encrypt "trusted" network stream - why aren't you educating your users about this serious limitation of your product?
* why don't you rebase your project to a country where a government policy exists that is allowing companies to build trustable security based products?
TLS sessions are negotiated between TLS clients and servers. Their confidentiality is guaranteed by that negotiation and the certificate authority, if any, doesn't have the server's private key and can't read the server's TLS sessions.
What CAs have the power to do is misissue certificates. Using a CA's services generally does not increase your exposure to misissuance attacks by that CA. If Let's Encrypt misissues certificates, it could misissue them for sites that are not and never have been Let's Encrypt users, just as any other CA can issue certificates for any public Internet service.
As I've said elsewhere, Let's Encrypt wants to use, and encourage others to use, technologies that limit our power to do the wrong thing, including HPKP and Certificate Transparency. We want more limits on our power and other CAs' power, not fewer, that lead to misissuance events getting caught and attacks on TLS users failing.
However, this is not free.
In return for getting an SSL certificate, your users will need to trust an organization to protect the secrets they share with you and vice versa. This organization has no economic incentive to do good for you or to do harm to you.
What happens when this organization is compelled by the TLA to give up the lucky charms, and there is no team of attorneys to fight back, and no billions at stake, and there is a gag order? And, given the rate at which a "free" SSL certificate will proliferate, these will be some valuable lucky charms.
This is not FUD. This is simply recognizing that "free" SSL certificates don't really address the issues that arise from centralized authority in a decentralized economy.
Although, it makes me even more confused as to why they used python for the official client.
I can't speak exactly to why Python was chosen, but it should be noted this isn't intended to be the be-all-end-all in terms of clients. There are already a number of other independent clients that have been developed for various different purposes.
Not to mention python is on pretty much every platform in existence by default.
If you're expecting this as a global binary like you would in go there's no reason you can't just "pip install letsencrypt"...
...except needing docker and everything running it in a docker container entails over a simple CLI.
Also, it looks like they say "for god's sake don't pip install":
Please do not use python setup.py install or ``sudo pip install`. Those mode of operation might corrupt your operating system and is not supported by the Let’s Encrypt team! https://letsencrypt.readthedocs.org/en/latest/using.html#ins...
> python is on pretty much every platform in existence by default.
....except Windows? Which also doesn't support docker.
> Why python for the client software if you obviously already have Go experience in-house? Using python means you have to run all this virtual-env crap in a bash script, apt-get install a bunch of crap for setup and not support Windows. Seems like using (nearly) dependency-free Go application for the client as well would have been a no brainer. Was it just a case of having more access to python devs, or were there other technical reasons? Anyone know? I bet this has been asked before, but not turning anything up with google.
wow what's going on here? Auto comment robot gone wrong?
Let's Encrypt is the effort of a benefit corp (ISRG) run by people who care about security and privacy enough to bake it into the foundations of the organization [1]. I think this makes them more trustworthy than for-profit CA's, which have a history of misunderstanding the fundamental roles they play in the security chain, e.g. [2].
1. https://en.wikipedia.org/wiki/Internet_Security_Research_Gro...
2. http://www.computerworld.com/article/2501291/internet/trustw...
Lavabit waa ordered to give up their private key, despite the fact that Lavabit wasn't, itself, under investigation. In other words, they were forced to give up their clients privacy and were given a gag orders.
Attorneys don't exempt anyone from anything, but your comment seems to suggest their existence is for entertainment. A team of attorneys might have found a way out of the mess for Lavabit.
The main thing that you trust (every) CA to do is to not issue a certificate for your domain to somebody else.
Which 99% of people already do when the buy a domain name.
There is NO evidence that using SSL restricts your freedom of speech. There is evidence to the contrary though, where SSL allowed people to speak freely without having their communications intercepted or monitored.
Certificate Authorities only reject websites for certificates in rare cases where the domain bears resemblance to a well known company (such as "paaypal.com" or "microsoftproducts.com"). This is not something that every CA does not something that a CA HAS to do.
There is no "false" sense of security HTTPS IS encrypted, and CA signed certificates ARE authenticated. Claims that the whole CA system is MiTM by government are largely unsupported, and if you believe that, then you are screwed over HTTP anyway.
I dont disagree that there are some disadvantages to an HTTPS-only web, but those generalizations are wrong.
How so? Do you expect browsers to stop serving content from sites using boring old HTTP? And the fact is that we've had to go through a central authority to put a website up for a long time, with DNS.
Just look at the stupid way browsers treat self-signed certificates: these are strictly better than plaintext, but plaintext gets no warning and self-signed certificates are warned about and in some cases actually blocked.
Similarly, one mailer (exim, I think?) on seeing an untrusted certificate would actually downgrade to plaintext. There aren't enough palms or enough faces for that.
Let's Encrypt users (in almost every respect) are not more exposed to risks of Let's Encrypt misissuing certificates. (They are more exposed to risks of Let's Encrypt wrongly revoking a certificate, but that creates an availability risk rather than an integrity or confidentiality risk.) In particular, Let's Encrypt never has access to your server's private key or to your TLS session keys. There is no way that Let's Encrypt could take a recorded TLS session and tell somebody how to decrypt it; what we have are signing keys, and all that they ever do is sign things (normally claims about other keys that could be used for other purposes).
Although Let's Encrypt, like any CA, could issue an additional fake certificate which someone who controls your network could use to impersonate you, any site is already exposed to this risk from every CA, whether or not the site uses Let's Encrypt. Let's Encrypt could issue a fake certificate in the name of a site that uses StartSSL or Verisign -- or Verisign or StartSSL could issue a fake certificate in the name of a site that uses Let's Encrypt.
As I've said a number of times in a number of contexts, the people working on the Let's Encrypt project don't think that this model is perfect, and many of us have been involved in expressing concerns about CAs' power in the past. As a result, we're working to limit Let's Encrypt's own power to misissue certificates by participating in the Certificate Transparency system, and hopefully by adopting and encouraging our users to adopt other technologies that will protect them against misbehavior by CAs, including us.
We encourage our users (and non-users) to adopt technologies that would reduce the need to trust us, including HPKP, which lets sites themselves make assertions about what keys they'll use, which browsers will then enforce even if CAs say something different, and Certificate Transparency, which lets people confirm that certificates they encounter in the wild have been publicly disclosed worldwide by the CA that issued them.
If you have other ideas for how CAs can be made less trusted, more transparent, and more accountable, we would love to hear them! And let me express my appreciation for the people who have been working to create the means that we have to do this today.
(If you're not a Let's Encrypt user and want to protect visitors to your site against risk of misissuance of a certificate by Let's Encrypt -- or any other CA! -- you can also adopt CAA and HPKP, to give visitors a browser-side way to enforce your intentions about what certificates they should be accepting.)
I'll also note that ISRG is publishing legal transparency reports, something which is still not very common in the CA industry.
https://letsencrypt.org/documents/ISRG-Legal-Transparency-Re...
However, their release schedule dictates when the service (yes, the client is part of this) is ready for use.
Until then you are waiting for the service to be available.
Oh wow. Really? You haven't done your homework then. So many ways to undermine the certificate authority model, including many famous cases, one involving the Iranian government gaining access to their citizen's "encrypted" traffic. HTTPs is about having traffic be open to powerful entities and closed off to the common criminal. It's a two tier model, not real security.
This reasoning would not apply to CA's.
Technically, yes. UI-wise, no. People have different expectations for https:// URLs, which would be broken if browsers simply accepted any self-signed cert.
No excuse for the mailer behaviour, though.
So the actual problem you have is that you selected an operating system that has zero native support for interpreted languages, and you're mad that they didn't cater their software to you?
(Seriously, though, VBscript, JScript and VBA are natively supported through WSH on Windows)
All this because a couple of theorists in the 1990s decided that security requires authenticity, despite decades of research to the contrary.
There are all kinds of ways to establish authenticity of counterparties. Entire books are written about that. There are much better ways than our current CA model. But we don't need any of them to have passively secure transport, over which we can then negotiate authenticity.
This is arranging deck chairs on the Hindenburg. It's nice that people will (once they finally get around to issuing certs "in mid-2015") be able to have zero-cost certs, but it doesn't change the fundamental broken-ness and wrong-headedness of having CAs in the first place.
The problem is having secured transport against active attacks as well, and without forcing the user to know anything about the site besides its domain.
If you have secrets that are too sensitive for community trust, there are other mechanisms, but they typically have trouble scaling very much beyond continuing a previous face-to-face relationship. For the question of whether, say, news.ycombinator.com is who they say they are, I don't care enough to take Caltrain down to YC's offices and check a fingerprint posted on the wall, if they had one. What I care is that, at scale, the certificate authorities I trust will do a good job of verifying identities and running secure systems.
And I am not an auditor or pen-tester of large companies, and even if I were, I wouldn't want to spend my spare time auditing and pen-testing all CAs just before I can use the internet. (Importantly, I am not an auditor of web browsers or SSL implementations either, and since I outsource my trust to my browser / SSL stack, it's not useful for me to be skeptical of the CAs unless I'm also skeptical of the code.)
Remember that the CA model is bare-minimum security. (Some of the CAs find money in telling you otherwise, but they're stretching the truth.) All it's providing is the security that, in a perfect world, you would have gotten all along from DNS and IP. If you need anything more than bare-minimum security, there are tons of options, ranging from the SSL-based (EV, HPKP) to the completely unrelated (PGP, Pond, etc.). But the world needs a good mechanism for the simplest security that could possibly work, and the CA system seems to have settled into that role.
Some Mesh Networks & protocols like the Tor Browser use an IP derived from a public key.. so you're absolutely sure that who you're talking to is who they say they are.
Why can't we have our cake (long distance electronic communications) and eat it too? (encryption & assuredness of identity)
Celebrating "trustedness" of LetsEncrypt only perpetuates the belief that CA is working fine.
EDIT: See below discussion by other posters
This is what is wrong with the CA, model, not their method of announcing it to a community anxiously awaiting the arrival of their product. What is absurd is that identrust has a shitty non-responsive 90's looking website and wants $299 for an SSL certificate, which is something that should be free. I will say though, they really did sell me on their trust worthiness with the alternating images of a fingerprint and a lock. So now I know they're legit. It is worth the $99 for SSL on a single site annually because there is binary data superimposed on some of the pictures.
In this case, B is LetsEncrypt and is (hopefully) pretty solid, but that isn't always the case. Earlier this year, it became known that CNNIC had issued a CA cert to MCS Holdings (of Egypt), which then did bad things.[1]
The news that everyone is suddenly trusting a new entity B, whether it's some Egyptian IT firm, or LetsEncrypt, comes out of nowhere. Neither cooperation nor even awareness is needed of the major browsers' dev teams.
[1] https://googleonlinesecurity.blogspot.com/2015/03/maintainin...
https://helloworld.letsencrypt.org/
Nice work team!
Really looking forward to spreading HTTPS far and wide.
1: https://www.ssllabs.com/ssltest/analyze.html?d=helloworld.le... 2: https://mozilla.github.io/server-side-tls/ssl-config-generat...
https://mozilla.github.io/server-side-tls/ssl-config-generat...
With a cross signed root, clients with only the IdenTrust root will validate the cert, and clients with only the LetsEncrypt root can validate the cert.
With a cross signed intermediate, the server has to guess which root the client has and serve the correct path, there's a TLS extension to indicate roots the client supports, but nothing actually uses it, so I don't know how the server is going to guess (other than to assume no one has the LetsEncrypt root, since it's new).
[1] but some clients are dumb and won't validate successfully when they reach a root they know :/ Most browsers will though.
I'd like a manual mode, as years of sysadmin work have made me extremely skeptical of tools that try to automatically modify config files.
However, as far as I understood, there is an API that will just hand out the certificate.
I guess they don't want it to be accessed by a web browser because they want us to regenerate and include a newer cert automatically.
So you have a somewhat higher setup cost (setup automatic cert update rather than one-time download of your cert), but then you can't forget to update your cert over the years.
I believe they also want this is be a fast desaster recovery. So if their main intermediate certficate is compromised, they can revoke it and hand out new certificates (using the backup intermediate cert) for all domains within a very short amount of time.
Nevertheless, I would have preferred a good explaination about how to setup this process manually, rather then depending solely on their tool.
(In case this process it too cumbersome without their tool, they should simplify it rather than hiding this in their tool.)
There is a "manual" mode, "Here is the file that you need to post, press Enter when you are ready to continue"
There is a "standalone" option. If you don't have a webserver running, it will bind to port 443 and solve the challenge for you.
There is also a "Webroot" option. Enter in your server's webroot and it will automatically post a file to .well-known and delete the file after validation.
Honestly, it is amazing to me that someone like Google or Amazon did not do this as free service a long time ago. But having an independent entity like this do it is far better.
Does this mean we can now all use Let's Encrypt to generate new certificates without people running into problems?
This does not, however, mean that we can all start using Let's Encrypt. They're doing a slow roll-out before making certs generally available to the public. You can apply for the Beta at https://goo.gl/forms/kf0IGCeAk5, or wait until general availability later this year.
When a server uses a Let's Encrypt certificate, a browser will consider it as issued under an IdenTrust root CA, which the browser trusts. So it will consider the Let's Encrypt certificate trusted.
edit: initially said SSH. I blame the plane wifi
How is this beneficial for IdenTrust?
It establishes IdenTrust as a more influential leader of SSL certificates on the Web. There are other ways CAs can make money, and this extra publicity will probably serve them well.
If someone needs to create a fake CA/public key, they have to hack multiple trusted sites.
It is not current https sys design, but would it be more secure?
What steps are left now? :-)
Though, to be honest they do this for >90% of https sites, in my experience.
But this is kind of a good thing, because after enough attacks on the old model, people will ask for an improvement or replacement of the model.
HTTP Public Key Pinning, or HPKP, is a security policy delivered via a HTTP response header much like HSTS and CSP. It allows a host to provide information to a user agent about which cryptographic identities it should accept from the host in the future. This can protect a host website from a security compromise at a Certificate Authority where rogue certificates may be issued for your hostname.
You can read all about it: https://scotthelme.co.uk/hpkp-http-public-key-pinning/
And here are web-based tools for examining and generating HPKP hashes: https://report-uri.io/home/tools
Unfortunately the best candidate, at least for us, for supplying SCT receipts to end-users, via x509v3 extensions in OCSP responses, is currently not fully supported in Golang.
> So thus beings the transition. EV certs are going to be the only ones that get the "green" chrome in browsers anymore. Sites using standard SSL are going to get the normal no-lock/white treatment. And sites without SSL will get the caution symbol/yellow treatment.
I don't like it, but I suspect this is where we're heading.
[1] https://www.reddit.com/r/linux/comments/3pg37u/lets_encrypt_...
Are there any facts to back up this claim?
Edit: This is what HN looks like in Firefox 38.0.5: http://img4.imagetitan.com/img4/RsbN6Rsn61k2IMN/12/12_l.png
Sure, the background color is white, but there's still a padlock icon.
Final Star Wars VII trailer and LE gets cross-signed. Best. Day. Ever.
(Also: Congratulations and well done, Team Let's Encrypt!)
Second, would you prefer that browsers blessed a new CA completely independently? If not then who should have that power? Governments? Non-profit organizations like ISRG?
The big alternative is to maintain your own list of trusted CA's, going through each and every new CA that you encounter and associate a trust relationship. Not even famous security researchers do this, and I can't really blame them as it is like a lawyer reading every EULA that they encounter and fully investigate the scope of them. The scope and complexity just get beyond what a single person can manage.
I just think it's odd that any CA can turn around and make any other random CA fully blessed. It seems like it completely circumvents the browser manufacturers including root CAs at all.
Totally agreed re: maintaining your own list of CAs. I mostly do go through the system CA list and disabling any from foreign governments I don't ever plan on trusting, but that's mostly feel-good and not actual security.
You're right that this sort of broad power is scary, but I think it's being used reasonably in this context. Do you have specific concerns you are afraid of? The only problem I thought of was a compromised CA cross-signing a malicious CA, but if they are compromised, you could just issue the main CAs certs anyway.
They are also planning on support CT.
I've attempted to maintain a list of all the providers that do (in one way or another), and it's currently 4:
* CloudFlare https://www.cloudflare.com/ssl
* StartSSL https://startssl.com
* WoSign https://buy.wosign.com/free
* Let's Encrypt https://letsencrypt.org
For people reading this comment dozens of months in the future, a maintained list will be kept at https://paragonie.com/white-paper/2015-secure-php-data-encry...
* CloudFlare doesn't give you a certificate. It terminates your TLS connection at their endpoint with a certificate they own the private key to.
* StartSSL free tier is for non-commerical use only.
* Haven't used WoSign so no idea what it is, but clicking on the link took was so laggy it didn't give me much confidence. (I personally wouldn't work with a company in China jurisdiction when it comes to security products.)
Let's Encrypt is a big step forward in having a legitimate, actual, user-friendly, free TLS certificate issuer without restrictions for usage scenarios.
Also note that free single domain certificates have been available from StartSSL for a very long time, but this didn't destroy the certificate industry.
Do you really know the difference between Citi Bank and Citibank? No? Then EV hasn't saved you from being phished.
If you are running a commercial, high-traffic website, then yes, there is.
For example, EV (extended validation) certificates is currently the only way to quickly build and maintain a "reputation" with 3rd party website ranking systems such as Microsoft's SmartScreen and, based on anecdotal evidence, with Symantec SafeWeb and Google SafeBrowsing services. Needless to say that SmartScreen is on by default in IE/Edge and SafeBrowsing is on in Chrome and, in part, Firefox.
First, this is optional software that almost every public server in the world is currently not using. It's like saying just because executable whitelisting exists that downloaded exploit payloads on operating systems is no longer a threat. If nobody uses it, the threat still exists.
In addition to actually implementing it on your server, every single user still has to make a secure initial connection over a trusted network on every device they'll ever use to get to that site.
But not every client even supports HPKP. There's lots of older software which doesn't support it, and IE doesn't support it at all, which by itself would leave 12% of all clients vulnerable.
https://letsencrypt.org/howitworks/technology/
You can only obtain a certificate for a domain if you can validate that you control the domain. Their steps for that (place arbitrary content at an arbitrary URL they request, or create an arbitrary DNS record they request) are such that, if you weren't the legitimate controller of the domain but could do those things, you wouldn't need a fake cert -- you'd already have pwned it thoroughly enough to be able to MITM it in other ways.
This isn't really a failing on Let's Encrypt though, because tons of other CAs issue certs by only verifying this exact same stuff. Certs are only as secure as the least secure CA. Since the security was already this weak, Let's Encrypt has not made it any weaker.
#1 letsencrypt blocks any request for domains which SSLObservatory (https://www.eff.org/observatory) reports as having observed a certificate, and additionally require that you show proof of possession of the private key. Every domain letsencrypt has served will also be treated with this requirement.
#2 letsencrypt will use multiple paths through the Internet. They have not given the exact details yet (I would guess that they will take different path by AS numbers).
#3 There is a block list. I don't remember the exact method used here, but I think it was simply based on Alexa rank.
Technically, you only have to make their systems think you control the domain. If their servers or 'establish proof of ownership' process are hacked, wouldn't this allow an attacker to do the same thing that happened in the DigiNotar hack?
Their technical overview explains how it works: https://letsencrypt.org/howitworks/technology/
Let’s Encrypt has no plans to issue EV certificates at this time.
https://community.letsencrypt.org/t/frequently-asked-questio...
In the yak-herding analogy, Let's Encrypt is a new charity in Ecuador that provides market services for scarf knitters. IdenTrust is a large regional trader in South America. My browser is the local yak-scarf store down the street. It seems totally obvious to me that, in this case, of course I'd hear about IdenScarf making deals with Let's Shave Yaks on the news. But the parent commenter is unhappy about the local yak store not being directly involved, and thinks it's some form of failure of the global yak-scarf supply chain that an individual consumer isn't part of that conversation.
But I will say that, without any numbers, its hard for me to say either way. Clearly, RSA was in independent legal entity, but a $x million dollar check didn't stop them from peddling shoddy crypto… though that's not something surprising to hear in this community.
I didn't mean that literally the threat has been eliminated due to HPKP; it's yet another tool that can be used.
First, this is optional software that almost every public server in the world is currently not using. It's like saying just because executable whitelisting exists that downloaded exploit payloads on operating systems is no longer a threat. If nobody uses it, the threat still exists.
HPKP isn't software--just additional HTTP headers that pretty much every web server can be configured to send.
In addition to actually implementing it on your server, every single user still has to make a secure initial connection over a trusted network on every device they'll ever use to get to that site.
True; it's even described in the RFC: https://tools.ietf.org/html/rfc7469
Key pinning is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to perform Pin Validation; UAs can only apply their normal cryptographic identity validation. (In this document, it is assumed that UAs apply X.509 certificate chain validation in accord with [RFC5280].)
OpenSSH certificates are not X509 certificates though, and out of the box SSH servers will not trust any public authority.
Also, AFAIK CA cross-signing, intermediates and other things that are fairly commonplace in X509 land are either not supported or not widely supported in OpenSSH.
https://github.com/openssh/openssh-portable/blob/master/PROT...
When I first learned about OpenSSH Certskeys, I was really excited; Spent awhile trying to make it useful, but you end up building all the CA infrastructure, and this time instead of distributing certificates to servers once a year, you want to distribute certificates to your _users_ every month or two -- so the pain is higher, there is less automation, and everyone on your team feels it....
Exploring OpenSSH certs is what led me to founding ScaleFT. There had to be a better way.
ScaleFT Access leverages these SSH Certificates, but we expire them every 5 minutes to provide other features that are hard with the limited capabilities of the format:
https://www.scaleft.com/products/access/
There are patches to make OpenSSH use X.509, but they are not widely adopted... and asking people to patch a sshd is a non-starter for many environments.
I run https://certsimple.com. We only do EV certificates, and we do it much faster than any of the existing companies, which normally quote 7-10 days to complete the validation process. I waited around a month for GoDaddy earlier this year, which is how I ended up making CertSimple.
CertSimple do EV certificates in an average of 5 hours.
- We check the customers info against the required government information sources (as well as a number of other places) before customers pay us.
- After we take the order, we provide a specific set of instructions based on a number of characteristics of the customer's actual business to make the validation process as fast as possible.
- We have a real focus on UX: there's no software to install or command line questions, our validation UI updates live, and we manually follow up with every customer to iterate our product.
I'm mike@certsimple.com, or @mikemaccana on Twitter.
They are generally good. There was one case when they started pulling a Comodo thing on us - the lawyer's signature was unintelligible, go and redo the paper - for some secondary document. But each email includes a note to email their support head if something's off, which is what we did and he had the cert issued in an hour after that. So the tops do care about their service levels and there's an easy way to escalate issues.
I ended up paying $10 on namecheap instead.
At least it used to work like that.
gpg --gen-key
a) There is something else that you know about IdenTrust, and that is that your browser vendor trusts them. This is the whole point of this CA thing: in the end you trust whom your browser vendor trusts (with the option of removing CAs for which you disagree). This is far from perfect (especially since the vendors' vetting process can be quite opaque), but it is not nothing - after all, you should trust your browser vendor, otherwise all the encryption of the world can't save you from someone eavesdropping on your websurfing.
b) Your argument can be read (or misconstrued?) to state that it would be perfectly reasonable to trust IdenTrust if they had a 2015-looking, professional website written in Angular and node instead. Which, of course, is not the case as many who entrusted their money to fraudsters with professional looking websites will be able to attest to.
> you trust who your browser trusts
Exactly, and my OS. But I run Mac and I am sure Windows users can relate, there are over 200 CAs and I have no idea what heuristics can be used to determine whether they are trustworthy. It wouldn't be a big deal except a compromise at ANY means they could fake ANY website.
Now, on a serious note. If you were running node and you had a super clean react front end with a picture of Jamie lee Miller from hackers super imposed over the ghostbusters symbol (responsive using html5 flex boxes) for sure I would trust you with the security for every website I visit.
I just meant the comment more as idem trust looks like a random rent collector who hasn't updated their business model since 1995. As a broker of trust, I find it disconcerting I know fuck all about them and even if I did, there are hundreds more like that. If you have the money, I don't because I am broke, for sure it would be worth $100 for a padlock when a user hits your site. With nothing more to go on than their site though, it looks like they have been on autopilot for 10 years and I can't wait for Lets encrypt to go live.
Keys as addresses (I2P, Tor hidden services, CJDNS) fixes a large part of the security problem, then on top of that you can add your choice of address translation. WoT style individualized trust webs? Trusted lists of name assignments DNS style? First-come first-serve á la Namecoin?
If you want to dive in more, you can get this data in other formats too.
One year passed, and I checked my backups. Yup, there it was.
If you take security seriously, you should actually read what's on the page instead of clicking "next, next, next" like some driveby malware-installing Windows-installer. And then this shouldn't be an issue.
I guess this is StartSSL's way of not having to deal with people who don't take security as seriously as they do.
Having a login cert is fine if the "user" is an organisation. It is a broken model for individuals or small businesses.
StartSSL doesn't take security serious. They'll happily accept breaches to their terms of use, as long as you pay up.
This level of proof of control is standard for DV certs, although other providers haven't automated it to the extent Let's Encrypt has, at least not with as high-quality software. One hole in this verification of course, is that 'control' may not actually be 'ownership', it could be someone who's hacked the host or DNS. But that's not unique to Let's Encrypt, it's a side issue, proof of control is standard and accepted for verification for DV certs.
So anyway, that kind of automated proof of control is a lot harder to apply to all of *.example.com, not just an individual host a.example.com. There are likely ways to do it well, but it's harder to do and harder to get right. Is probably why Let's Encrypt, at least for now, is not doing it.
If you control the domain `example.com`, sure. if you just control the single host that `example.com` points to, that doesn't neccesarily mean you control the domain, and in fact DNS contortions are needed to even have example.com point to a host.
Section 9.2.1 (Page 9): https://cabforum.org/wp-content/uploads/EV-V1_5_7.pdf
In addition to using & verifying the legally registered name, it must be verified that there is a physical address for the business, if that address doesn't match the registered location, additional verification is required. There are additional provisions of verification as well. See section 11 of the same document.
So, sure. If you can hack a trusted CA, you can do bad things. That was true before.
Would not MITM just remove that header?
Key pinning is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to perform Pin Validation; UAs can only apply their normal cryptographic identity validation. (In this document, it is assumed that UAs apply X.509 certificate chain validation in accord with [RFC5280].)
The UA will not be able to detect and thwart a MITM attacking the UA's first connection to the host. (However, the requirement that the MITM provide an X.509 certificate chain that can pass the UA's validation requirements, without error, mitigates this risk somewhat.) Worse, such a MITM can inject its own PKP header into the HTTP stream, and pin the UA to its own keys. To avoid post facto detection, the attacker would have to be in a position to intercept all future requests to the host from that UA.
Thus, key pinning as described in this document is not a perfect defense against MITM attackers capable of passing certificate chain validation procedures -- nothing short of pre-shared keys can be. However, it provides significant value by allowing host operators to limit the number of certification authorities that can vouch for the host's identity, and allows UAs to detect in-process MITM attacks after the initial communication.
M2Ys4U 35 days ago
According to their 31C3 talk, they will use multiple
connections from multiple locations (possibly including
Tor?) to mitigate against these attacks.
http://arstechnica.com/security/2015/03/bogus-ssl-certificat...
Trusting a CA means trusting them to write certs, even via an intermediary. If you don't actually trust them, remove those CAs.
The CA model has lots of problems, but I don't see what additional harm this actually causes.
https://groups.google.com/d/topic/mozilla.dev.security.polic...
I can imagine other ways you would restrict certificates (for instance, I'd kinda like to see a spec for a "half-CA", where you need two half-CAs under distinct organizational control to sign you), but I don't think anyone has specified the problem for those precisely, let alone proposed a solution.
Sadly, SPKI more-or-less died on the vine: the atrocious XPKI 'system' won by default. One of my rainy-day projects is to try to revive it: if the last 15 years have taught us anything, it's that centralised global trust is insane.
I don't know if it's worth the money per se, but you can pin a couple of trusted CA root EV certs via HPKP and know it's much more difficult for someone to "accidentally" issue a valid cert for your site.
If you do that, users won't see a lock instead of a green bar, they'll be blocked from accessing the site at all (if it's not their first visit and they're using a modern browser).
The only security feature EV certs have over regular ones right now is the use of certificate transparency, but that should be extended to non-EV certs within 1-2 years.
You could pin your own cert, but that makes it difficult to rotate keys in a heartbleed type situation.
Use this to serve e.g. an S3 site on your own domain using SSL: S3 -> CloudFlare (with CloudFront) uses Amazon's certificates for their hostnames. Cloudflare -> internet uses your website's hostname and certificates.
Total money spent on SSL: $0.
https://blog.cloudflare.com/universal-ssl-encryption-all-the...
Why would they do that? I never used this feature of CloudFlare, but it would be only logical to require you to upload the cert so they can verify against it in the future.
Another benefit of this is ownership can be validated on an ongoing basis (is the TXT record still there? yup, still valid) without requiring any software to be running on any hosts at that domain. And you can validate a domain without even having an A record if you want (say, if you're getting all your ducks in a row before exposing your server to the world).
Though it would not protect from factoring because most EV roots are the same key length/hash.
For anyone else reading, this works because the root programs give authority to issue EV certs separately from other certs. To keep the authority separate (most, perhaps all) CAs use separate roots for EVs.
This is the key. StartSSL is NOT user-friendly at all, even if you want to use it for the non-commercial personal use that it was designed for.
Although i agree that their user interface isn't that much user friendly, it took me just a couple of hours to learn how the process is handled at StartSSL.
You let them create a certificate you then use for your login process. Then you validate your domain by email and then you're pretty much valid to pump out as much certificates as you want.
Only drawback is that the certificates are only valid for one year.
I wouldn't bother with StartSSL with that many catches and hassles.
How do I know? I've got two of them in the past in two occasions.
They only allow one-year certs to be generated, but you can renew them and get as many of them as you want. I've got class one certs from them for two different domains, and I've replaced both those certs twice as they've expired.
Then again, maybe they've changed their policies in the past six months.
> requires a valid U.S. physical non-commercial address for registration
Does it? I'm based in Ireland, and I haven't had to provide the with a valid US physical address, unless this is something new that they've brought in during the last half a year or so.
> and is subject to $79 for revocation fee.
Yup, that's the most annoying thing about dealing with them.
> Oh, it's definitely not automated, someone would have to email you back and force a couple times to complete the provision process.
I can't say I've had that issue myself. They're not as fast as I'd like, but I've never had any major problems with them.
I could say the same for most countries.
[1] https://sandstorm.io [2] https://docs.sandstorm.io/en/latest/using/security-practices...
There are a few existing Nginx configs for that (search for "nginx dynamic ssl cert").
Anyway, Sandstorm developers told me that they wouldn't plan on using Let's Encrypt while it doesn't offer wildcards, so I think we are missing out on supporting this use case.
Given the occasional implementation weakness, and key recoveries, I would much rather bind only one key to a name.
And from the client perspective is makes pinning much easier.
I'm not a fan of one-wildcard-to-rule-them either but keeping active certs to a handful through the judicious use of wildcards is a real boon.
As a service to the community, could you name some places where you can do that?
That server would be used to keep track of your domains and certificate status and which servers are authorized to work with which domains, etc... Also easier to backup.