Certificate Authorities [was: Growing Bad Practice with Login Forms]

[Stephen de Vries <stephen () corsaire com>]

Hi Jason,

>   > Anyone can generate a public-private key pair, but not everyone
>   > can have their private key signed by a trusted CA.
>
>  It is the public key that is signed by the CA, not the private key.

Of course, my mistake.
>  And in fact anyone *can* have their public key signed by a trusted CA.
>  Most anyone who really tries can have just about any public key signed
>  and associated with just about any "identity" ... how many times have
>  you obtained certificates yourself and how well do you know the
>  technical and social engineering procedures to fool the CA into
>  believing that you are an authorized representative of a particular
>  organization? It can and has been done.

Yes it is possible, but this is a problem with the procedures at the 
CA's and not an inherent flaw in the system of using trusted third 
parties to verify unknown entities.  The vast majority of phishing 
attacks (i.e. attacks that should have been prevented if the user 
authenticated the server properly) were not caused by attackers 
generating fake certs - they didn't even have to bother.  This points 
more to problems in educating users than it does to flaws in the 
chained certificate approach.  There are flaws in the _implementation_ 
of the certificate system, and you make some interesting points to that 
effect, but I don't see these as insurmountable, nor do they call for a 
complete re-architecture of the whole approach.

>  People associated with CAs like to claim that their business practice
>  ends at the certificate, and that if software exists in the real world
>  that isn't designed very well to make proper use of certificates, 
> well,
>  that isn't their fault nor is it their problem. I hope you see through
>  such arguments -- who do you think caused all those root CAs to be
>  distributed by default with Web browser software if not the CAs 
> themselves?

I don't think CAs could be held solely responsible for this.  There was 
a very real need from users/business to have a technical solution to 
authenticate entities.  And browser vendors recognized that adding root 
certs to their browsers would make the user experience simpler and more 
secure (and I guess that this is the crux of your argument - that this 
has not effectively provided the security promised).

>  The business practices of CAs are designed to ensure annual renewal 
> fees
>  for a service that provides no real security and is put into place
>  *INSTEAD* of the security policy that *DOES* provide real security:

The two need not be mutually exclusive.  And I agree that one of the 
biggest problems with the chained certificate approach (as evidenced by 
the success of phishing attacks) is a lack of user awareness and 
training.  The technical problem of authenticating an unknown entity is 
solved through CAs and certificates - the real problem is that users 
are not aware of it, nor do they know how to protect themselves by 
making use of it.

>  relying on certificates only for an initial, one-time transmission of 
> a
>  public key, where a human must analyze the certificate and consider 
> its
>  chain of trust and its apparent age and origin in addition to whether 
> or
>  not the CA signature can be verified cryptographically. Once you know
>  the public key that you believe is the correct one for the
>  person/server, the value of certificates is over and done with. The 
> only
>  reason for new certificates to be allowed every time an HTTPS request 
> is
>  made is to artificially increase the importance of the CAs for 
> business
>  purposes.

If this process is entirely transparent to the user, how does it 
increase the importance of CAs?

>  This does nothing to help, and in fact hurts, security.
>
>  You're aware of the ASN.1 encoding attacks that target vulnerable
>  buffers in openssl and elsewhere? The fact that we've got code on the
>  client and the server that is just sitting there waiting to attempt to
>  parse overly complex certificates automatically with every request is 
> an
>  unnecessary security risk put into place instead of a simpler more
>  secure "trusted public key management" system solely for a business
>  purpose and not for a security one.

Again the ASN.1 issues point to an implementation problem and not an 
architectural one, the same argument could be used to question the use 
of any piece of software.  It would be unrealistic to argue that 
cryptography should be abandoned because there have been too many 
security vulnerabilities in SSH and SSL.  And I don't believe that 
parsing a certificate is an overly complex programming task, it is 
certainly less complex than implementing public key crypto in the first 
place.

>  Trust determinations for never-before-seen public keys are an 
> exception
>  scenario that must involve a human mind.

...or a trusted third party _if_ the third party's vetting procedures 
are implemented properly.  I think the average user would not want to, 
nor could they, verify every new public key that they come across.  For 
this to be a more secure solution, users would have to perform _more_ 
stringent vetting procedures than CA's currently perform - and I for 
one would not be willing to perform this task for every new public key 
I come across.  Users are barely able to understand the need for 
checking a padlock in their browser - requiring them to inspect a 
certificate _and_ verify the authenticity of the issuer is, I believe, 
asking too much.

>  Do you think that every HTTPS
>  request is made more secure because of business practices that result 
> in
>  automated trust verifications of arbitrary certificate chains? Do you
>  not want your browser to disallow a change of public key once you have
>  determined that you have received, and are using, the one public key
>  that you choose to trust for communications with a particular entity?

I would (and do) trust the CA to perform this operation for me because 
I do not have the time or resources to validate each public key.  Or am 
I misunderstanding your proposition ?

>  See: "Using Trusted Public Keys in SSL Connections"
> http://www.windevnet.com/wdn/articles/2003/0309/
>
>  These are not unjustified criticisms of CAs based solely on my dislike
>  of their business models -- if they were to do the right thing in
>  addition to what it is that they do now, and let the market decide

I am not aware of anything preventing the market from adopting an 
alternative approach...?

>  whether it prefers the model with more security (and more burden on
>  people to make trust decisions) or more automation (and less security)
>  then the finger pointing could go where it is supposed to go in the 
> end,
>  anyway: right back at the person to whom the finger is attached.

The biggest problem of authenticating unknown entities on the web, and 
detecting impostors, is the lack of user education.  Giving the user 
_more_ responsibility is counter productive to security and if there 
are automated solutions (as have been suggested in the parent thread) 
then I think these should be preferred over a more manual approach.

>  I am always surprised how smart people jump to the defense of 
> commerce.
>  It must be because we are all intimately linked to it -- a criticism 
> of
>  commerce is thus a criticism of our own role in it, and nobody likes 
> to
>  be criticised...

I don't think that intelligence is the biggest critic of commerce, as 
you point out many intelligent people vociferously defend it.  I think 
it's a more basic instinct that rebels against the idea that something 
as rich as human life can be reduced to the pursuit of profit.

Regards,
Stephen

>  Sincerely,
>
>  Jason Coombs
>
>
>  Stephen de Vries wrote:
>
>  >
>  > On 28 Jul 2004, at 03:25, Jason Coombs PivX Solutions wrote:
>  >
>  >> Toro, Daniel wrote:
>  >> > Maybe the certificate is hard (near impossible?) to fake
>  >>
>  >> certificate chain validation flaws exist in Internet Explorer,
>  >> Mozilla, and other browsers that enable anyone to forge any server
>  >> certificate.
>  >
>  >
>  > I assume you're referring to the vulnerabilities discovered in IE 
> around
>  > 2001 (Ref: http://www.securityfocus.com/bid/2735).  After patching 
> and
>  > then promptly breaking the patch, Microsoft have apparently 
> resolved the
>  > issue, as described here:
>  > http://www.microsoft.com/technet/security/bulletin/MS02-050.mspx
>  >
>  > As for "Mozilla and other browsers", I assume you're referring to 
> the
>  > X.509 Certificate Chain vulnerability announced in Aug 2002 here:
>  > http://www.securityfocus.com/bid/5410/.  These issues have been
>  > addressed, as described in the solution.  Are you referring to other
>  > certificate vulnerabilities that have not been patched for over a 
> year?
>  >
>  >> I would say that certificate-based server authentication is dead,
>  >> except that it is still produces huge annual revenues for the
>  >> companies that sell this useless snake oil remedy for a problem 
> that
>  >> doesn't exist.
>  >
>  >
>  > Rubbish.  The problem is very real: How do I verify someone's 
> identity,
>  > if I know nothing about them?  Certificate Authorities solve this
>  > problem by verifying this unknown person for me - and subsequently
>  > signing his certificate.  Now, I only need to trust the CA's and 
> their
>  > vetting process, and I automatically trust the people they've 
> vetted.
>  >
>  >> Nobody has trouble communicating their public key to the people who
>  >> need to know what it is.
>  >
>  >
>  > BUT they have a great deal of trouble ensuring that the public key
>  > belongs to that person, and that the person is who they claim to 
> be. 
>  > Anyone can generate a public-private key pair, but not everyone can 
> have
>  > their private key signed by a trusted CA.
>  >
>  >> The tax man must be paid else the padlock will not appear.
>  >> Certificates are a means of extracting money from people who want 
> to
>  >> do something meaningful with the Web.
>  >
>  >
>  > To deduce that the entire certificate architecture is flawed 
> because you
>  > don't agree with the business practices of certificate authorities, 
> is
>  > illogical captain.
>  >
>  > If you have a real critique of the certificate system as implemented
>  > through SSL, then please present your argument in a logical and 
> coherent
>  > form.  No it's not a perfect system, and there are flaws, but these 
> can
>  > be addressed without rewriting the entire concept of using 
> certificates.
>  >
>  > Stephen.
>  >
>  >