This is a good initiative. Open source security projects could really make use of this. As a small example, the Gpg4win [1] project does not support HTTPS. Now whether this is due to a lack of funds or motivation is unclear, but a free SSL certificate might sound enticing and may motivate people to install them on their servers.
I am wondering if it really makes a difference. Google for 'cheap ssl certificates' and you will easily find offers from well establish certificate authorities but for 10 % of the usual price, i.e., often below 10 USD. That is not for free but almost …
So no one can do a MITM attack and change the SHA1 checksum, OpenPGP Key ID, file lengths and code signing certificate fingerprints as you download package-integrity.html?
If you don't have any way to trust the signing key "out-of-band", then you shouldn't trust the binaries. I don't really see why they supply separate sha1sums in addition to the pgp signatures.
Now, the fact that people are more inclined to trust the bundled ca keys, rather than a web-of-trust backed pgp key is generally just because people don't understand trust.
Say, if you're in Thailand[1] and require a secure way to communicate, where do you get your os/browser-bundled ca keys? Do you trust a CA that is under influence of the Thai government? Under influence of a sympathetic government?
Do you really trust all the CA keys bundled with your os/browser/phone? Do you know which they are? If not, please don't spread FUD wrt web-of-trust based trust models.
To be clear, both have a bootstrap problem -- but only web-of-trust offers a reasonable way for the individual to ensure proper trust chains. No trust chain is (by definition) without trust, so no model (ca or wot) is immune to being betrayed. But at least wot is designed for the user to be able to influence (and be aware of) trust -- and for easy auditing (most keys are personal, or anchored to personal ids, while it can often be hard to tell who are able to access ca keys and sign possibly rogue certs).
You can do a MITM attack with certificates also. In fact NSA can do it by compromising any CA in the chain.
A distributed system that verifies identity would be much better. For example, namecoin based identities and checksums committed to the blockchain.
In fact, any self-signed public key system with a MAC distributed to many sources would be good enough. It doesn't have to have proof of work. The only requirement is that there are enough root CAs that you can't compromise them all.
This should be taken care of by browsers themselves!
Agreed, CAs are an easily-exploitable smokescreen. Distribution is the way to go here. Seems like you could post your public key in the data section of a namecoin domain entry, no?
I think there is movement on this type of system, but it's slow because people don't realize just how insecure HTTPS is when CAs and the US government are involved.
I heard of a project a while back, but haven't seen it since and I forget the name. My understanding is that it's slow going. I think the best bet is, as mentioned, piggyback onto the blockchain somehow. Namecoin is probably the closest to getting this right.
You're accessing both of those links over unsecured HTTP, which means that those could easily be MITMed as well.
If you were distributing packages over HTTP and distributing the verification signatures over a secure channel, I'd agree (this is similar to what Debian does[0]). But using one insecure channel to verify another doesn't provide you with any more security.
Furthermore, using SSL provides an additional layer of privacy - the path of the URL (everything after the domain) is hidden to eavesdroppers. They can tell which server you're accessing, but they can't tell which resources you're trying to access[1].
[0] Debian signs the packages (GPG, I believe), and the public keys for these signatures are distributed in the ISO that is used to install the base system. So the validity of the signatures is as trustworthy as the ISO used to install the entire OS (which is hopefully very trustworthy, or else there's a much bigger problem!).
[1] It's for this reason alone that I still wish Debian would distribute packages over SSL even though the GPG signatures provide more security in the authenticity of the packages than SSL would provide.
Just remember that the CA certs (that anchor ssl trust) is usually also distributed in a similar way (on the install media). The difference is that you can more easily independently review the trust of any given pgp key (you've personally verified the key, or have personally verified the key(s) of someone that have personally verified the key).
I suppose in theory one could take a snapshot of CA keys, sign them with pgp and use that a s "know set" (note: not known good, as there is no way to be able to fully trust all the certs typically supplied as CA roots -- a subset could probably be verified). But that's not how the CA system is designed.
My company has been a globalsign partner for a little over 2 years. They are a great company and I am really happy to see them supporting the OSI. Nice to have partners that have the same vision when it comes to supporting the FOSS community.
i build software accounting ... and the term open source.Are it freely downloadable or close company but open source to customer ?
Previously i use ssl for testing speed the google spdy.. but performance not much different.
sorry not git hub account for downloadable accounting software but if wanted to real code and product and sell combine,access will be given.
Their $25 fee for revocation during the Heartbleed situation left many of their users who could not pay their fee vulnerable to attack. During these extenuating circumstances you would expect them to offer the revocation for a discounted price or even free, but they did not. I did not have any certificates registered with them and am very glad I didn't.
I imagine that there are a huge amount of StartSSL users who cannot pay the $25 per certificate and have no choice but to leave their server vulnerable. This was pure short-sighted greed on the part of StartSSL.
just to add to this, as well as not waiving the fee for their freely issued certificates, StartCom (Eddy Nigg) also refused to waive it for his long-term paying customers.
I grudgingly paid the revocation fees, and now they've lost my business now forever, as they essentially held the security of my domains to ransom for a quick buck.
The business model of StartSSL seems to be rather simple:
You pay as soon as a human being's work (or other substantial effort) is necessary.
With regard to revocation, I do not understand the complaints since the deal with StartSSL was pretty clear and revocation does not work in practice anyway. That does, however, NOT mean that a server has to remain vulnerable, just get another certificate …
The $25 fee is a bad move but if you don't revoke your old (compromised) certificate, new connections would still be secure if you switched certificate, correct?
I'm using StartSSL just because I hadn't any excuses to answer the question "why not?" and they were the best looking (free, reasonably usable, trusted enough) option on the market.
They offer unlimited free certificates, so, naturally, I've issued one per service (they even encourage that with "web server"/"xmpp server" certificate distinction). I.e., a separate one for mail server, a separate one for HTTP server, a separate one for XMPP server and so on. Naturally, I expected that it's more likely for one service to break (i.e., say, for nginx to have some buffer overflow that'd allow extracting the keys) than all of them, like it was the case with Heartbleed.
That means, revocation would cost me not $25, but $600. Can't afford that.
Luckily, the most sensitive information I protect are my own emails, 99% of which are spam and service notifications.
Using NameCheap above instead would cost you $200/year, instead of $0/year + $600 for a black swan event. "Replace ALL your SSL certificate" events seem to happen less often than once every three years.
Wildcard certs cost $60/year, protect everything on one certificate with free reissues and revocation, and cheap rekeying (which was an option for heartbleed recovery). I would rather pay the "SSL racket" (as StartSSL would put it) to get real service and help than use a free cert from them. StartSSL is permanently removed from all my truststores following heartbleed
this is a reasonable argument, except it's generally considered best practise not to share private keys across servers (most CAs explicitly forbid this in their deeply buried policy files), which also rules out wildcards.
StartCom is appealing as they'll issue as many certificates as you want for a one-off fee.
so I had protected my service against parts of it being compromised, but then I was screwed over completely by heartbleed.
I think drdaeman meant _certificates_ and not _servers_. One certificate can be used on multiple servers, but you can't create multiple certificates “for free“ on Comodo,Gandi or GlobalSSL. You're charged for every cert.
I'm using StartSSL verified, it costed me 99$ (personal verification) plus 99$ (company certification), and I can create any certificate I want, at any time, valid for two years and wildcard included.
Since my company provides custom subdomains for clients, and every client can have multiple subdomains on his own subdomain, we can't afford the price for every client. (I know we should charge them, but this issue is out of my hand).
The 25$ revocation fee sucks, yeah.. but StartSSL has his advantages too.
That is a terrible reason not to recommend StartSSL. They were under no obligation to offer revocation for free. If $25 is that much a problem you probably shouldn't be trying to run a secure server anyways.
The parent comment recommended StartSSL, I was simply stating my opinion of the company and informing people that there is a catch when using their service.
If you obtain a free certificate then $25 per certificate probably is an issue, especially since there is no guarantee that this won't happen again in the near future.
Many people probably have several subdomains which needed certificates, $25 per subdomain can add up quickly if you have several.
No, they were not obligated to offer revocation for free, but a significantly discounted price would have allowed a much larger percentage of people to revoke their certificates. It's not too much different than extortion, since many people who obtain free certificates are not aware of the possibility of the need to revoke a certificate, then they are basically screwed when they are forced to either pay up or have their server left insecure.
Hypothetical Situation: If I start a free SSL cert service and put in my terms that there is a $1,000 revocation fee, would that be acceptable? Many people would signup without thinking they would never need to revoke a certificate, then another Heartbleed-like situation occurs and many of your users have servers that are at risk without revocation, would it be acceptable to say, "Oh well, pay up or else someone could hack your servers".
StartSSL exploited their customers during a time of crisis (yes, servers leaking private information is a crisis) and they deserve the negative PR they are receiving from it.
Many people have even been proposing that StartSSL be removed from the trusted CA lists included with OSs and browsers since so many StartSSL certificates will remain unrevoked, and there is a valid point to that.
The private key could have been stolen any time during that the heartbleed vulnerability has been present on the server (~2 years).
This would allow for a MITM attack which would obtain user credentials and unauthorized access to a server.
Since the attack isn't recorded it's unknown if it was used extensively before it was made public. The time between announcement and patching was likely significant enough for the potential of someone stealing the private key during that period as well.
This is also why re-using the same private key for the new certificate is a bad idea.
Think about the wide variety of sites that would use a free SSL certificate that might not have the funds for revocation. Almost every site I've ever seen has had people try to hack it.
There is a fairly decent chance that a very small site would not have someone steal it's private key, but it's hard to make that assumption, that's why every site about Heartbleed suggests revocation of the old certificates.
Why not just regenerate a key and get a new cert?
Why revoke the old one if all your services will just reject it? I mean, you can do it just to be sure you don't make a mistake. But beyond this why?
Because the BROWSER is what's being attacked in a MiTM. To the server it just looks like a regular client connecting. It never sees the certificate the client saw. There is nothing for the server to reject.
1. Attacker steals the private key via heartbleed or other means
2. Attacker sets up their own server using the stolen private key
3. Attacker tricks a user into accessing their server rather than the real server via any of a number of methods, such as a compromised hotspot.
4. User provides their sensitive information to the attacker, thinking they're on the real site.
No server-side action can mitigate the risk of a stolen private key in the above scenario, since the user never communicates with the legitimate server. That said, most browsers ship with certificate revocation lists disabled by default, so revoking the certificate doesn't help nearly as many people as we'd like. But for people who do enable CRLs, they'll see the scary warning rather than their browser trusting the revoked cert.
And even then, they might grant you a certificate for a domain one day, and the next time you renew or even pay for a revocation (think heartbleed), they may put it on the revocation list and then proceed to delay for a manual review for hours or even days, and then decide your random domain is registered by your client instead of yourself, and you cannot renew even if you can prove domain validation.
They used to be cool, but recently they have become a major hassle to the point where it's faster and easier to just pay per certificate at more conventional CAs like those reselling instantssl. If your time has an hourly price, you'll probably even save money.
Edit: I'm sure it's a noble goal that they do not want to certify domains they cannot prove are owned by the customer, but it doesn't really do much good in practice when the CA next door will happily issue a certificate as long as you can read administrative email for the domain.
Free SSL certificates are completely undermining Internet security. The whole point of certs is that you have a certificate authority that verifies the identity of the person you are issuing the cert to. By giving it away for free and doing zero of the backend work, all you're doing is creating a false sense of security and poisoning the ability to trust https.
As it stands, the majority of CA's do not verify any of this information, besides a very cursory email verification.
Exceptions would obviously include higher priced (OV/EV) certificates, which are no different cryptographically. Even the CA mentioned (GlobalSign) states this fairly clearly on their website.[1]
The SSL protocol uses digital certificates to create a secure, confidential communications "pipe" between two entities. Data transmitted over an SSL connection cannot be tampered with or forged without the two parties becoming immediately aware of the tampering. This Free concept is really bogus. Nothing comes free! http://www.indusface.com/index.php/products/ssl-certificates
[1]. http://www.gpg4win.org/