Remember, unless you're pinning your certificate using DNSSEC+DANE or HPKP, in practice any CA in the world can issue certificates for any domain.
Let's recap: It's 2015. They're using SHA-1 for everything (NOOOO!). They're based in China, which has just said it wants to ban encryption. (So has Cameron in the UK, yes, but at least he hasn't won an election yet. Edit: he pledged to if he wins; we have a coalition government, nobody won last time, least of all us! <g>) It looks like they've messed up OSCP, so even their own cert doesn't pass. Oh, and RC4, TLS 1.0 only, check out their login server: https://www.ssllabs.com/ssltest/analyze.html?d=login.wosign.... - let's put the (slightly) stronger ones at the end, everyone! Ugh.
Let's Encrypt will do it properly. Or Else™. ;)
None of the parties achieved the 326 seats required for an overall majority under the First Past the Post system. The Conservatives won the largest number of votes and seats but under FPTP rules were 20 seats short.
It looks like they cleaned up their forums from when they were last mentioned[1] but I'll still keep my distance.
Anything like this is really a bandaid for the real problem with SSL/CA. As in why can't I be a CA for my own domain? I think Android is a perfect example of this problem - if you import a CA cert using the built in Android credential storage every time you reboot it will show a vague and useless message saying that people may be spying on you. Not which CA cert was added and when - just "hey, you added, on purpose, a CA cert. I'm just making sure you are aware of this".[2] I understand the warning? error?...err simply because now I can sign a cert for ANY domain and Android will accept it as legit. This makes sense for the average users who don't understand or care what a CA is, not advanced users or enterprise users who will most likely use their own CA infrastructure. In this case - it would make more sense for them to be a CA over just company.tld rather than any domain.
Personally - I'm using a modified version of PHP-CA[3] (as in changed the OpenSSL defaults to something sane and fixed some small issues). It's obviously not very advanced (for lack of better words kind of sucks) - but I wanted to hit the ground running with being my own CA for personal use and I have other projects I'm working on.
[1] - https://news.ycombinator.com/item?id=8901822
[2] - https://code.google.com/p/android/issues/detail?id=82036
The certificate authority system is an imperfect solution for the problem of public key infrastructure. It is designed such that a trusted, independent third party can verify messages between two communicating parties. The third party's trusted signature verifies that the user is who they say they are.
Now, if anyone can be a certificate authority, and you can be your own certificate authority, you have effectively removed certificate authorities entirely - you now end up with de facto two parties. This is convenient for you to certify that you are yourself, obviously.
This is inconvenient and dangerous for you when anyone else certifies that they are you using themselves as a certificate authority - if they can sign their public key using their own nominal trustworthiness, the entire problem is back where it started without the certificate authorities in the first place.
By design, certificate authorities need to be 1. trustworthy, 2. highly vetted and 3. very few. If everyone is a certificate authority, then no one is.
Isn't that the situation we are in now? All it takes is one CA with poor security coughDiginotarcough and the whole system is broken. I'm obviously ignoring the fact we have CRLs - but if someone has a signed cert for say chase.com or google.com they can do a lot of damage in a very little amount of time.
Maybe I'm just cynical that there is a profit motive to CAs. I mean, you can't tell me that it's just greed that you can purchase a certificate to turn a user's address bar green because it's "extended validated". The average user won't notice, or even know what that means. Big picture behavior - there is no functional difference between a EV and non-EV signed certificates.
My opinion: if we keep the SSL/CA system the way it is today - we need fewer CAs but create non-profit CAs where the average person can get CA signed/trusted certificate for free or next to free. I'm not talking about grabbing some random dude off the street and start a non-profit - it should be funded and sponsored by companies like Google/Verisign/Microsoft etc.
Do you really trust all of these keys?
https://www.mozilla.org/en-US/about/governance/policies/secu...
Even companies like AOL, VISA, Wells Fargo, and the historically-problematic VeriSign and GoDaddy, and lets not forget the Even the companies with serious legal issues in the past, and several governments (China, Japan, Turkey, etc).
This reliance on a single point of trust is why the PKI systemd is destined to fail in the long run: that single point of trust also a single point of failure. The entire concept of a CA requires handing over key parts of our infrastructure over to a small list of "authorities" (which grants the CA a lot of power), while simultaneously trusting those authorities to never abuse that power or be corrupted from the outside.
> If everyone is a certificate authority, then no one is
This is actually the core problem with PKI. Not only does it presuppose that a "few" trusted authorities is even possible, it also frames the discussion by assuming that only a globally supported solution is required. This attitude also dismisses the capabilities to evaluate trust and merely asserts that most people shouldn't worry about this kind of security problem.
A better idea is to recognize that everybody solves pieces of the trust problem constantly in their daily life. Some of the decisions are made of personal experience or observation, but we also rely on others that we see as an "authority". These are powerful behaviors that should be built upon. Everybody can be a CA, because they already are in.
Someone that sets up an "authority" that is only used between a group of friends is perfectly safe IFF 1) stays at the scale where trust already exists, AND 2) the people involved have some easy way to select the trust basis they wanto to use.
Criteria 2 is the most important. The CA system is de facto boolean trust. (i.e. HTTP-vs-HTTPS). There is no sane way for the typical user to say they want, for any particular transaction or communication, to only trust some specific authority (or authorities). and then switch to a completely different trust basis as needed. Once this ability is in the hands of the average person, I suspect the key distribution problem will solve itself as people self-organize.
Because then anyone who can hijack DNS for your domain can also be a CA for your domain.
There would have to be some sort of authoritative list where it says "this CA cert can sign certificates only for this domain". However, such a system I described would basically be CAs as they currently stand. The question/problem is who would maintain such a list? This is hard question considering we can't even agree on web standards coughMicrosoftcough.
In other words, if you could put a CA into a TXT record at the root of the domain and have browsers/etc trust it, how is it any less secure than what we have now?
Edit: Hmm, looks like the free certs will never pass strict OCSP checks. As broken as the OCSP system is, I would still like to be able to check against it.
However you'll need to build and run your infrastructure upfront so you're already burning some years money just to get those documents. When you finally get them and become ready to apply for inclusion with the vendors (Apple/MSFT/GOOG/Mozilla/Debian etc) it will take another couple of months. Even when you're included there is a big chance that it will take a couple of years to reach a high enough distribution rate to be acceptable for business purposes (think of old android devices or Windows XP).
Getting cross-signed by another CA costs money and they will re-validate your setup as you will sign "below" their root CA.
I wonder what the total initial and running costs of starting up a CA (including WebTrust & yearly re-audit) are today...
Mozilla takes ~1.5 years to include a CA.
> I wonder what the total initial and running costs of starting up a CA (including WebTrust & yearly re-audit) are today...
Without including man-hours, I've estimated it to be $550k for creating and maintaining a CA for three years. The audits make up a large majority of this. Big firms like E&Y charge a lot, which is what my estimate is based off of. You also need HSMs + places to store the HSMs, a CP(S), etc. If you've ever read the WebTrust guidelines, you'll know you need a lot of accountability and security.
You could probably reduce the figure with a small auditing firm. My estimates of course are estimates. Certly got quoted $120k/yr (not including a readiness audit) for a WebTrust audit by E&Y.
Nothing is 100% secure and new CA players will bring a higher encryption usage overall (in this case -> other business model/regional reach). Higher usage will also drive the amount of criminals (including secret agencies) trying to MITM/intercept those encryption. This will push vendors and developers to increase certificate pinning and other models of "bottom-up" models besides the top-down model that the CA-model implements.
IMHO it would be great to have a "working by default" model (which the CA-model is compared to something like pgp) and a protocol-independent way to pin public keys (eg not tied to http/s like HSTS and HKPK).
People and companies in need of "higher" security can pin keys and eg ignore the root trust of their OS/browser. So IMHO the best of "both" worlds.
HSTS http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
HPKP https://developer.mozilla.org/en-US/docs/Web/Security/Public...
I just thought my past employee (used to have StartSSL but got rejected recently) have to buy an wildcard one for a year while "Let's Encrypt" is not yet here, but this is just great. Will tell them to save their money.
Hope they'll update MAC soon. Wonder if they have an option to sign only for an year, so expiry date won't get past 2017. SHA1 should suffice for an year.
And there is a revoke & reissue button in the control panel, though I haven't tried myself.
However, I must ask -- what's their business model?
Even as great as the offer is, this is akin to the free sample... Because once you deploy the https:// address scheme, there is no going back. On the other hand, this would have been perfect if there was opportunistic encryption within HTTP.
I'd be a little suspicious of anything too free like that. I hate to be too xenophobic but I can't say the thought didn't cross my mind.
Unless you send the HSTS header, that's not true. Even so, you could just set the HSTS expiry time to the certificate's expiry (which would have to be done within your code, sadly).
Because otherwise, unless you don't care about incoming links, bookmarks etc, there is indeed absolutely no going back, with or without HSTS. That's the problem, only solvable with opportunistic encryption.
And if you have dozens of domains and subdomains, what would you do in 2 years if this only CA is then kaput? The value of their offering is definitely above 100 USD, it would appear.
This is becoming a freemium product.
That's not really the reason we might not trust a CA. The CA needs to make assurances that it won't improperly sign certificates for an entity purporting to be the principal, e.g., DigiNotar. Maybe this CA has, but that's still a weak argument.
It's a pity no CA besides StartCom and Comodo pick up the S/MIME market. Both options are not very usable for non-IT people.
A lot of CAs sell S/MIME certs, including GlobalSign and CyberTrust. They're not heavily advertised, though.
do i need to attach a mail adress to the csr? do i need to set a challenge password? what is the "free binding domain" on wosign?
But you're right, it's taken from LowEndTalk[1] and it remains unknown to us if the author asked for permission to copy the instructions to his or her blog.
[1]: http://www.lowendtalk.com/discussion/41289/free-chinese-2-ye...
SNI isn't included in Windows XP, yet the SSL won't work in XP anyway.
Which underlies the problems with PKIX: any CA can sign anything, just about. Lowest common denominator. I actually prefer DNSSEC there myself - yes, yes, I know, hear me out for a moment! - because even if it's hierarchical, it's single hierarchical from those who are supposed to control the DNS anyway. (Of course, that still introduces points of attack. It's reasonable for countries to control ccTLDs but I wouldn't mind seeing IANA control the others under international law. And it doesn't really do it very well.)
In practice both have big flaws, but at least one can be used to pin the other so the benefits of both can be realised. Distributed systems may win in the end, but we're only at the start of that journey.
Disclaimer: okTurtles is a competitor to the traditional CA system.
Worst case scenario - if Verisign doesn't want to share the toys in the sandbox, Microsoft/Google/Mozilla et all can just refuse to include their CA certs as trusted certs.
However, Verisign is in a very interesting position as they currently manage/control .com tld.
So what I'm saying is - if the children don't agree to play together then they can take their toys and go home then no one can play.
(I like to use the analogy of children and these big companies because, in my opinion, it appears that's how they operate. They just can't come together, like mature adults, and form some sort of solution to this. Last I heard is that Google wants to show an error page for non-HTTPS enabled sites, on Chrome, which will make everything even worse[1]. Don't even get me started on the whole self-signed cert error message page...).
[1] - http://www.chromium.org/Home/chromium-security/marking-http-...