[WEB SECURITY] Improving Authentication on the Internet

Lyal Collins lyal.collins at key2it.com.au
Thu May 12 08:45:43 EDT 2005

This process of installing site/organisaiton-specific CA cert leads to two
main consequences, imho
- The MITM attacks become simpler to implement, due to poor user training in
the intricacies of trusting certificates
- The trust model is identical to the problem of distributing symmetric
keys, something certs and public key is supposed to eliminate.

Another issue is the digital certs only deliver an intermediated password
authentication outcome.  A password is authenticated by a software process,
and the private key associated with the cert is made avaiable for processing
some data.  Every relying party only acheives the trust of a password being
validated, nothing more.  Is this good enough?

SSL and PKI need serious rework, since the business community can not afford
the growing exposure to unmanaged critical security infrastructure caused by
the overlap of DNS and vast numebrs of hopefully trustable browsers.  Both
problems need to be fixed but PKI alone is not much hep.


-----Original Message-----
From: Mitja Kolsek [mailto:mitja.kolsek at acrossecurity.com] 
Sent: Thursday, 12 May 2005 7:22 PM
To: 'Gervase Markham'
Cc: websecurity at webappsec.org; 'Stanka Šalamun'
Subject: RE: [WEB SECURITY] Improving Authentication on the Internet


A very interesting paper, well done. What it reminded me of is a peculiar
practice some of our local organizations are implementing, including our
government: They don't use the default trusted CAs we all have in our
browsers, but rather use their own for issuing their own servers' certs. So
if you want to visit their sites via HTTPS, you are asked to first install
their root cert in your browser's trusted root cert store. Now, the
peculiarity: you download this root cert via an HTTP connection and you have
no way of verifying its authenticity. Mind you, some root cert download
sites do provide the cert details in cleartext as well, so you can compare
one untrusted piece of data with another untrusted piece of data :-)

I'm interested in knowing if others on this list have similar experiences in
their local environments. The way I see it, if someone "forces" you to
install a new trusted root cert, we need a process for verifying its
authenticity. One way would be to use transitivity and provide download of
newcert.cer via an HTTPS connection authenticating the site owner with an
already trusted root cert like Verisign or Thawte. Another would be for the
officials to provide - written and in person - the newcert.cer's fingerprint
to users at the time of users' enrollment, along with instructions for
newcert's validation upon download. Any other ideas?


> -----Original Message-----
> From: Gervase Markham [mailto:gerv at gerv.net]
> Sent: 11. maj 2005 20:07
> To: websecurity at webappsec.org
> Subject: [WEB SECURITY] Improving Authentication on the Internet
> On the 17th of this month, at the invitation of Comodo, the
> major CAs and browser vendors (including mozilla.org) are 
> having a meeting in New York to discuss some of the issues 
> surrounding the future of SSL and trust on the Internet.
> As a way of working out my thinking on this, I've written a
> paper called "Improving Authentication On The Internet":
> http://www.gerv.net/security/improving-authentication/
> It starts with the basics, mostly as a way to confirm that my
> understanding of the current situation is correct. All 
> comments, both correcting my facts and giving alternative 
> views, are very welcome.
> Gerv
> ---------------------------------------------------------------------
> The Web Security Mailing List 
> http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List

More information about the websecurity mailing list