On Tue, Jan 01, 2013 at 12:04:16PM -0700, Keith Medcalf wrote:

Perhaps the cheapest way to solve this is to apply thumbscrews and have google require the use of co-option freindly keying material by their victims errr customers errr users.

ITYM "product". - Matt

In resp, On 1/2/13, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:

There's a bit more trust (not much, but a bit) to be attached to a cert signed by a reputable CA over and above that you should attach to a self-signed cert you've never seen before. [snip]

Absolutely. A certificate whose fingerprint has personally been validated by a human, and compared to a SHA1 fingerprint learned earlier out of band, is to be trusted with a high level of confidence. It is in a sense may be a more reliable assurance than a CA signature on a certificate, as long as a strong validation process was followed -- it is still stronger if BOTH fingerprint manually validated _and_ signed by a recognized CA. A problem, however, that can come in when designing software - such as browsers -- How do you prove the human actually was properly trained, and followed the correct validation procedure? If the human doesn't actually have to type the expected SHA1 fingerprint, and there is a way the human can just "click OK"; or select an option to "disable checking" -- the average human will likely just spontaneously click that -- not understanding what fingerprint validation is, and simply "Approve" or "Skip" the validation process, and mark as trusted, without manually verifying squat. Therefore: the usefulness of fingerprint validation is often limited, to situations where the operator is specifically trained to follow a reasonable validation procedure, and adherence to the validation procedure is enforced. ---- In resp to, On 1/1/13, Keith Medcalf <kmedcalf@dessus.com> wrote:

Perhaps Googles other "harvesters" and the government agents they sell or

There are plenty of public CAs that will allow you to generate your own private key, and distribute only the CSR to the CA, for their signature attesting to the authenticity of every public attribute of the certificate; a CA signs a certificate based on the public information it claims, based on its signing policy, CAs don't ever actually get to learn the private key of the certificate request. If you are concerned about CA misbehavior on behalf of governments, then it makes sense to have software require manual approval/certificate installation of even CA-validated certs. And the "CA signature" should then simply be a mandatory Pre-Check, before being allowed to install or trust a certificate. [snip] In resp to

On 12/31/12, John R. Levine <johnl@iecc.com> wrote: Really, this isn't hard to understand. Current SSL signers do no more than tie the identity of the cert to the identity of a domain name.

Correct, when an organization name is not listed on the certificate; that is not part of what has been authenticated, only domain control was authenticated. This is what CAs do. They only necessarily attest the details actually published on the certificate; their job is not to attest that the certificate will only be used for legitimate purposes, although they may do that as well, through CSP and revokation practices. If you are the legitimate owner of a domain, then a certificate issued to it with a CN or Altname of a hostname within that domain, is legitimate, if you are actually the person that authorized it, you approved acceptance of the certificate request containing that name, and you, and only people authorized by the principal have access to the private key. CAs, could do their job better, if DNSSEC is implemented securely for a domain, and the CA required a DNSSEC validated TXT record with the Certificate Authority's Issuer /CN=..../OU=.../O=... fields and the CSR Certificate Request's public key SHA256 hash code, together with a DNSSEC validatable record published containing the /CN=..../OU=.../O=... fields of the PKCS#10 CSR, for the Common name (hostname) and a DNSSEC signed CNAME for each alt name on every certificate to be issued. I expect browser CA policies to evolve to require stronger validations.

I supose to the extent that 0.2% is greater than 0.1%, perhaps. But not enough for any sensible person to care.

Where do you draw the conclusion it is only 0.1%? Not that 0.1% is a small number 1 time out of 1000... If you anticipate 86400 attacks in a day, 0.2% could be 8640 more attacks succeeding. I don't thinkyou give the CAs enough credit. There are well-known trojans that generate on the fly self-signed certificates (specifically things like Flashback,Flame,Flashback,Tatanarg,ZeuS). It seems to be a much rarer event, that there is any report and then only a small number of improperly issued CA signed certificates. This is likely reflecting greater difficulty and much lower practicality of improperly issued certificates as an effective attack strategy. There have in the past been cases where a CA was compromised or improperly issued certificates, and the certificates were revoked. Self-signed certificates cannot be revoked, except by manually updating software to blacklist them. You may be missing the fact, that it's still _hard enough_ and inefficient enough to apply for and get false SSL certificates en masse, that the possible attack scope is greatly limited. That is, the CA certificates aren't low-hanging fruit (Self signed ones are). And the increase in difficulty, if self-signed certs are blocked: other attacks against parts of the stack besides the certificate are more likely, OR another target may be picked (Such as brute force attempts to guess valid authentication credentials, or a search for vulnerabilities in the SSL implementation itself, such as buffer overflow, authentication bypass, or MD5 weaknesses allowing substitution of certificate signed content with fraudulent certificate content). -- -JH