Gmail and SSL

Jimmy Hess mysidia at gmail.com
Thu Jan 3 02:06:15 UTC 2013


In resp, On 1/2/13, Valdis.Kletnieks at vt.edu <Valdis.Kletnieks at 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 at 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 at 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




More information about the NANOG mailing list