Recent Features
| |||||||||||||
Fraudulent certificates in the wild — againFraudulent certificates in the wild — againPosted Jan 6, 2013 19:53 UTC (Sun) by giraffedata (subscriber, #1954)In reply to: Fraudulent certificates in the wild — again by Lennie Parent article: Fraudulent certificates in the wild — again
That still doesn't address the issue that when you blacklist a certificate authority, you're hurting not only the CA, but all the people who got legitimate certificates from them in the past and their partners. Maybe we should handle the fact that CAs simply aren't trustworthy by having everyone have certificates from at least 3 separate chains of trust and have to present at least two of them to be considered authenticated. I wonder if the protocol allows for that. Then not only would these fraudulent Google certificates not work, but revocation of the CA's valid certificates wouldn't hurt much either (other than the issuer, who would have to give refunds).
(Log in to post comments)
Fraudulent certificates in the wild — again Posted Jan 6, 2013 20:18 UTC (Sun) by corbet (editor, #1) [Link] That sounds like a way to punish all the people getting certificates from all the other CAs too. I get irritable enough having to pay for our certificate from one provider...
Fraudulent certificates in the wild — again Posted Jan 7, 2013 0:14 UTC (Mon) by Lennie (subscriber, #49641) [Link]
In that case I think DNSSEC is probably a better route. It isn't multiple chains, I know. It is just one chain.
But we already depend on DNS, at least with DNSSEC/DANE your domain only depends on the CA(s) of your choice (yes, multiple is possible too if you want).
An other question: Why do you pay your CA ? If all you need is a simple certificate and cheap is all what you want, there is one in Israel which can deliver it from free already: StartSSL
Fraudulent certificates in the wild — again Posted Jan 17, 2013 12:18 UTC (Thu) by robbe (guest, #16131) [Link]
> there is one in Israel which can deliver it from free already: StartSSL
Please show me a process where a business (like LWN) can obtain a cert for free from StartCOM -- without pretending that they are an individual.
Until then I will consider the cited as widely spread misinformation.
Fraudulent certificates in the wild — again Posted Jan 17, 2013 13:18 UTC (Thu) by cortana (subscriber, #24596) [Link]
StartSSL indeed do only issue free domain-validated certificates to individuals. If you get your identity validated ($60) and then your connection to an organization validated (another $60) then you can issue as many certificates under that organization's domains as you want without paying anything extra. So it isn't free, but it is within the reach of all but the smallest organizations, and you are not punished for issuing multiple certificates for different services (as you are with a CA that charges you per certificate).
Fraudulent certificates in the wild — again Posted Jan 17, 2013 18:02 UTC (Thu) by giraffedata (subscriber, #1954) [Link] As I understand it, it isn't an issue of to whom a certificate is issued, but for whom. So even the hypothesized fraud of "pretending they are an individual" would not work. The certificate the business would get by doing that would be a certificate proving the identity of some person (where a person's identity apparently consists of his email address). So no browser would accept that as proof that the web server on the other end of some socket is lwn.net. Or that it is operated by the organization commonly known as LWN.
Another free certificate busted Posted Jan 17, 2013 18:21 UTC (Thu) by man_ls (subscriber, #15091) [Link] For $120 you can get many SSL certificates from other "vendors" (i.e. prime number sellers). In fact for that kind of money you get a wildcard certificate from most sellers, so you don't have to spend anything on subdomains.
Fraudulent certificates in the wild — again Posted Jan 20, 2013 19:49 UTC (Sun) by Jonno (subscriber, #49613) [Link]
Actually, you are allowed to get free and/or individual validation (at $60) certificates from startssl.com for use by an organization, but if you don't pay the extra $60 for organizational validation the certificate will only list the individual admin's name (who they considered their customer), not the organization's name, in the certificate metadata. That metadata is not particular important, however. For example, the lwn.net certificate belongs to "GeoTrust Inc." (the issuing vendor) according to its metadata...
Also worth noting is that for those $60 (or $120 if you are particular about the metadata) you get to issue an unlimited number of certificates, including wildcard- and SAN-certificates, for an unlimited number of domains, during a 350 day period, and each certificate is valid for 2 years.
I have yet to find any other place that offer even a single 2-year wildcard- or SAN-certificate at that price. Single-host certificates can be had cheaper at other places, but those are free at StartSSL (even for organizations, if you are not particular about the metadata).
(Note that I'm in no way affiliated with StartSSL or StartCom Ltd, Iäm just a satisfied customer.)
Fraudulent certificates in the wild — again Posted Jan 20, 2013 21:59 UTC (Sun) by giraffedata (subscriber, #1954) [Link] Actually, you are allowed to get free and/or individual validation (at $60) certificates from startssl.com for use by an organization, but if you don't pay the extra $60 for organizational validation the certificate will only list the individual admin's name (who they considered their customer), not the organization's name, in the certificate metadata. That metadata is not particular important, however. For example, the lwn.net certificate belongs to "GeoTrust Inc." (the issuing vendor) according to its metadata... I don't know what you're calling metadata, but what tells to whom a certificate belongs is its "subject" attribute. The subject attribute has various components, the two most important being "common name" ("CN") and "organization" ("O"). The lwn.net certificate belongs to common name "lwn.net" and unspecified organization. In contrast, the certificate offered by www.bankofamerica.com belongs to common name "www.bankofamerica.com" and organization "Bank of America Corporation." In the lwn.net certificate, GeoTrust is the "issuer" attribute. I couldn't tell from the startssl.com certificate just what its $60 product is, but as the description includes the phrase "organization validation," I presume that product has both the CN and O field filled in, whereas the free product has only CN (like lwn.net). I know it can't be that the $60 product's Issuer attribute indicates the Startssl customer. The Issuer attribute has to identify Startssl. You seem to say that the free certificate includes the individual admin's name. I can't see how that can be, since Startssl has no credible way to know the admin's name. Email address, maybe.
Fraudulent certificates in the wild — again Posted Jan 20, 2013 22:46 UTC (Sun) by cortana (subscriber, #24596) [Link]
> I couldn't tell from the startssl.com certificate just what its $60 product is, but as the description includes the phrase "organization validation," I presume that product has both the CN and O field filled in, whereas the free product has only CN (like lwn.net)
That is correct. They (in my case) also filled in E, L, ST and C.
Fraudulent certificates in the wild — again Posted Jan 21, 2013 16:10 UTC (Mon) by Jonno (subscriber, #49613) [Link]
> I couldn't tell from the startssl.com certificate just what its $60 product is, but as the description includes the phrase "organization validation," I presume that product has both the CN and O field filled in, whereas the free product has only CN (like lwn.net)
Actually, both individual validation ($60) and organizational validation ($60+$60) will include O, L, ST, C and emailAddress, but for individual validation, O will contain the name of the individual validated, not the organization for which the individual works. I.e. for lwn.net the difference is whether it would contain "O=Jonathan Corbet" or "O=Eklektix, Inc.".
A free certificate from StartSSL will only contain CN, C and emailAddress.
Fraudulent certificates in the wild — again Posted Jan 20, 2013 23:08 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
you are mixing up fields filled in, and information validated
Just because a field was filled in, or nor filled in, it doesn't tell you how much effort went into validating the information that's in those fields.
this is the same thing as mistaking precision (lots of numbers after the decimal) for precision (how accurate those numbers are)
The fact that you can't tell this information from a cert, is one of the major problems with the current CA concept.
Fraudulent certificates in the wild — again Posted Jan 21, 2013 1:48 UTC (Mon) by giraffedata (subscriber, #1954) [Link] you are mixing up fields filled in, and information validated No, I'm not. I suspect you read something into what I wrote that I didn't intend, for you to think that. (A weird brain slip may have contributed - I wrote "I couldn't tell from Startssl's certificate" where I meant to say, "from Startssl's web site"). I meant to explore what is the difference between Startssl's free and $60 product. The customer isn't going pay more to have himself scrutinized harder and get the same certificate in the end. The difference therefore must consist, ultimately, in what fields are filled in. Whether the information in those fields is true, or the certificate authority expended effort to be sure it's true, is a whole different conversation.
Fraudulent certificates in the wild — again Posted Jan 21, 2013 2:13 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
what fields are filled in do not really matter.
All that matters in there is one other bit set (in what field I don't know), in the BofA cert that says "this is an extended validation cert", which means that the cabal of CA vendors promise that they actually validate who the cert belongs to, and they set the rules that prohibit anyone other than that handful of (I think 5) vendors from issuing any certs that set that "extended validation" bit
The people who buy the extended validation certs do pay a LOT more to have themselves scrutinized more, in exchange the browser puts the green bar when browsing to the site. This gives everyone involved the warm and fuzzies and makes them think that they are more secure.
Fraudulent certificates in the wild — again Posted Jan 21, 2013 9:08 UTC (Mon) by giraffedata (subscriber, #1954) [Link] what fields are filled in do not really matter. Nonetheless, all the evidence is that having fields filled is in fact what people are buying with Startssl's $60 product. That product is not an EV certificate.
The people who buy the extended validation certs do pay a LOT more to have themselves scrutinized more, in exchange the browser puts the green bar when browsing to the site. I would say they're paying to have the browser put the green bar up (more specifically, they're paying for an EV certificate). If they failed to be scrutinized more in the process, they wouldn't exactly demand a refund. I think there probably is value, by the way, in having the Organization field filled in in a non-EV certificate. To the extent that a browser user pays any attention to the certified identity at all, many probably realize that even a non-EV certificate has some verification of the information and give the web site correspondingly higher respect if the name of the organization is vouched for than if only the domain name is.
Fraudulent certificates in the wild — again Posted Jan 21, 2013 9:19 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
> many probably realize that even a non-EV certificate has some verification of the information and give the web site correspondingly higher respect if the name of the organization is vouched for than if only the domain name is.
umm, the CA organizations don't fill out any of these fields, they are filled out by the org that submits the signing request.
The fact that LWN.net's cert doesn't list an organization doesn't tell you anything other than the fact that the LWN cert request didn't have that information in it when it was submitted to the CA
Fraudulent certificates in the wild — again Posted Jan 21, 2013 16:10 UTC (Mon) by Jonno (subscriber, #49613) [Link]
Not quite, while openssl will by default copy those fields from the certificate request to the certificate, there is no such requirement by the specification.
For example, StartSSL will ignore the metadata in the certificate request, (only using its public key) and instead use the CN (common name) and subjectAlternateName from the web form used to make the request, and O, L, ST, C, emailAddress (organization, location, state, country, email) from the validation they did of you.
For EV certificates, all certificate vendors promise (to the browser vendor) to do this, and additionally to do a slightly more thorough validation than what StartSSL does for normal certificates, but the principle is the same.
Fraudulent certificates in the wild — again Posted Jan 21, 2013 9:51 UTC (Mon) by anselm (subscriber, #2796) [Link] All that matters in there is one other bit set (in what field I don't know), in the BofA cert that says "this is an extended validation cert", which means that the cabal of CA vendors promise that they actually validate who the cert belongs to, and they set the rules that prohibit anyone other than that handful of (I think 5) vendors from issuing any certs that set that "extended validation" bit Actually, there is no »extended validation cert« bit. The way a browser recognises an EV certificate is that it has a list of all the vendors (there's about 25 of them now, not 5) that issue EV certificates, together with a special OID – different for each vendor – that that particular vendor will reference in an EV certificate's Certificate Policies extension field. When a certificate from one of the EV certificate vendors comes in, the browser checks that certificate's CP extension field against the list entry for that vendor, and if there is a match, then the certificate is considered an EV certificate. This tricky method makes it nearly impossible for vendors outside the cabal – or indeed entities who operate their own internal CAs – to offer certificates that look like EV certificates and are treated by browsers as such. If you want to join the cabal, you essentially need to convince the browser makers (by filing large amounts of expensive paperwork) that you're crossing every t and dotting every i, and they will include your magic OID in their list of EV certificate issuers.
Fraudulent certificates in the wild — again Posted Jan 7, 2013 15:07 UTC (Mon) by pjones (guest, #31722) [Link]
Sounds like a good time for some other CA to provide cheap/free certificates as a loss leader for other services.
Fraudulent certificates in the wild — again Posted Jan 7, 2013 15:28 UTC (Mon) by Lennie (subscriber, #49641) [Link]
What CA wants a fast race to the bottom ?
It is already a very slow race to the bottom.
Do you really believe service will improve if it is a fast race to the bottom ? There is a reason Verisign sold it's SSL-branch to Symantec.
If you want free certs, you can also go to Gandi (sub-CA from Comodo), you'll get a free cert with your domain. At least for the first year. Go Gaddy might also have a similair service (there own CA ?).
Fraudulent certificates in the wild — again Posted Jan 7, 2013 18:06 UTC (Mon) by giraffedata (subscriber, #1954) [Link] There is a reason Verisign sold it's SSL-branch to Symantec. And there's a reason Symantec bought it. Looks to me like evidence that it's a profitable business with a future. (Actually, a sale of a business tells you nothing about whether it's a good business; it tells you the seller and buyer believe that the buyer can operate the business better than the seller can).
Fraudulent certificates in the wild — again Posted Jan 8, 2013 17:34 UTC (Tue) by Lennie (subscriber, #49641) [Link]
Yes, it was just my interpretation about why they didn't want to be in that business anymore. Obviously I could be wrong.
Fraudulent certificates in the wild — again Posted Jan 9, 2013 11:46 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
The "profitable business" only has to last until it's paid for its purchase, and not even that long if you believe you can sell it to a bigger sucker. SSL CAs are in the picture for at least one more generation of browser technology (say, 10 years), but longer term they're dead by their own hands. Since nobody in the stock market has apparently heard of periods of time longer than a quarter that doesn't matter for Symantec.
But anyway, CAs are not solely in the SSL market. For SSL there was a competitive market, and technological pressure to innovate the CAs out of existence. The walled gardens are a much better opportunity. Typically the walled garden owner agrees a monopoly deal with you, the CA, where either they bundle your certificates with an SDK or their ISVs come to you separately to buy one, say once per year. The owner takes a slice of the money, you spend a slice more on overheads and the rest is clear profit with zero risk of being undercut by desperate competitors. Even if something goes wrong, the walled garden owner is in more trouble than the CA and will spend money on both PR and digging its way out, they're unlikely to offer the CA as scapegoat if they think they can still fix it, and as we've seen with SSL, you can just insist that whatever happened is "in the past" (when else would it be?) and won't happen again.
So expect Verisign SSL to still be there in ten years, but with SSL certificates as a very small part of the business, hardly mentioned in any financials and largely forgotten by the general public.
Fraudulent certificates in the wild — again Posted Jan 9, 2013 14:25 UTC (Wed) by Lennie (subscriber, #49641) [Link]
I don't know what technology will be choosen in the future, but AFAIK DNSSEC/DANE is the currently only generally available protocol/standard.
The only parties that need to implement it are the browser vendors. They do however depend on an Internet where proper checking of DNSSEC material is possible.
This can be handled by something part of the browser, handled by the operating systems or something installed on the network or local machine ( http://www.nlnetlabs.nl/projects/dnssec-trigger/ ).
This hasn't happend, partly, because there are other issues in the network that prevent this. From DSL-routers which block large responses to just plain browser resolvers. A failover to HTTP or similair to collect this information is possible, but no-one has come forward to setup a large distributed network of servers for this.
From the browser vendors I only see an interrest in this field from the Google Chrome/Chromium developers and Firefox developers.
Google Chrome/Chromium uses the same NSS-library and, I believe, the same CA-store as Mozilla/Firefox.
The NSS-library is getting a lot of development, for example to refactor to easily support SPDY, but I haven't seen a lot of DNSSEC-/DANE-related development.
The Chrome/Chromium developers are developing their own DNS-library to improve performance. I've not seen any initiatives to add DNSSEC-validation support to it.
Chrome/Chromium does support this as a test:
No other browser supports this and you can't have both the normal CA-chain and the DNSSEC-chain in the same SSL-certificate configuration. It is something that might be possible in theory, but different browsers handle this case differently and you end up with at least one browser giving errors depending on the choices you make.
Even if all this is said and done DNSSEC does not solve what the CAs call "extended validation" certificates (also known as the green bar).
In the meantime there are addons for Firefox and Chrome which you can use to add DNSSEC-/DANE-support to those browsers. I think even an IE-extension when combined with DNSSEC-trigger you have a full solution which should always work.
Fraudulent certificates in the wild — again Posted Jan 9, 2013 17:27 UTC (Wed) by giraffedata (subscriber, #1954) [Link] The "profitable business" only has to last until it's paid for its purchaseThis is equally true of Verisign and Symantec (with the Verisign version being "until it's paid for what it could have sold for.") And that was my point: the fact that the SSL CA business transferred from one company to another doesn't tell us whether the business has a future. (If you look closely, you see I haven't argued that SSL CAs are here to stay; I argued that the transfer to Symantec is not evidence of that). ... not even that long if you believe you can sell it to a bigger sucker ... Since nobody in the stock market has apparently heard of periods of time longer than a quarter ... Give me a reason to believe that Verisign likes long-lived businesses more than Symantec, that Verisign is less interested in the stock market, or is a smaller sucker than Symantec, and then we have evidence, together with the sale of the SSL CA business, that SSL CAs are doomed. That wasn't present in the original post.
Fraudulent certificates in the wild — again Posted Jan 14, 2013 11:16 UTC (Mon) by ortalo (subscriber, #4654) [Link]
Pretty realistic analysis.
But then, what should (open source) browsers developers do? It is time to start an alternate "certificates-like" technology? It it time to push for crazy things? [1] I am not especially worried about paying for LWN.net: for that we could certainly find a way. However it seems the Web will be here apparently within 10 years and more and more people are using it for (slowly) increasing financial transactions. Sounds like things could turn annoying in general...
[1] My try: support GnuPG certificates with individuals as roots of trust in browsers, integrate gnucash with git for secure publication of accounting status. Crazy enough?)
Fraudulent certificates in the wild — again Posted Jan 14, 2013 10:57 UTC (Mon) by ortalo (subscriber, #4654) [Link]
IMO, that's probably a key point. The fact that LWN.net needs to pay for that is a bug. (Is it in Fozilla's bugzilla at least?)
Maybe what's reasonable to do is to convince browsers's developers that nowadays certificates issued by some CAs are less reliable than even some self-signed ones. If they really care about HTTP security (and I am pretty sure they do), they must support self-signed as much as CAs. With all their support for modules updates, why not go wild and implement efficient (final) certificates packages distribution in the brower?
If other organizational-level constraints impose you to use a commercial certificate (I suspect it may be that), then let's build on these problem to that these constraints are not legitimate.
As a side note, I am gonna give a short course in security this afternoon (university level). I've done that regularly on a short period for the last decade. The audience is pretty technical (most of them will be embedded systems developpers or network administrators in the short term).
Fraudulent certificates in the wild — again Posted Jan 7, 2013 5:19 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
The protocol gives you no way to have a cert signed by multiple CAs
Fraudulent certificates in the wild — again Posted Jan 7, 2013 6:38 UTC (Mon) by giraffedata (subscriber, #1954) [Link] I was talking about having multiple certificates for the same identity. I might demand that you supply two of them, or give you the opportunity to offer an alternate certificate if I don't trust the first one.
Fraudulent certificates in the wild — again Posted Jan 7, 2013 6:47 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
no standards exit for doing that. If you're going to require deploying a new standard to the entire Internet you may as well try to make it be DNSSEC based.
Fraudulent certificates in the wild — again Posted Jan 7, 2013 15:45 UTC (Mon) by jpnp (subscriber, #63341) [Link]
SSL certs are based on the principle of being signed by a trustworthy 3rd party. It's pretty reasonable that if a CA turns out not to be a trustworthy party (whether due to corruption or incompetence) that they be blacklisted.
This should act as incentive to purchasers of certificates to make some sort of effort to assess whether there supplier is in fact trustworthy. Something that is sorely needed; the nature of SSL in browsers (excepting separate classes of certificate such as EV certs) is such that you as a site owner have almost no incentive to use a trustworthy CA since any attacker can use a dodgy CA and it will work just as well in the users browser.
|
|||||||||||||