Re: Is this right? Question about SSL and PKI...

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 10/26/03 

Date: Sun, 26 Oct 2003 18:05:24 GMT

Ohaya <ohaya@NO_SPAM.cox.net> writes:
> 1) We work with a CA (let's call them "CA-Commercial") that will be
> issuing CLIENT certificates.
>
> 2) We can get that CA-Commercial's root certificate (most of them let
> you just download them), so I can install CA-Commercial's root
> certificate on my server.
>
> 3) I can run, say, MS Certificate server (so, I'm "CA-Inhouse"), on an
> in-house machine, and create a server certificate, and install that in
> my web server (e.g., IIS).
>
> CA-Inhouse doesn't issue client certs, we only use it to issue one
> server certificate, just for our server.
>
> From my testing, since we have CA-Commercial's root certificate on our
> server, our server will include CA-Commercial in the CertificateRequest
> part of the SSL handshake, and then the browser on the client-side will
> send its CA-Commercial-issued client cert to our server (recall, our
> server only has a server cert issued by CA-Inhouse).
>
> What I was surprised about, in the above scenario, was that the client
> authentication succeeded, even though we didn't have a
> CA-Commercial-issued server certificate installed on our server.

nominally certificates are for trust propogation (i.e. you have no
knowledge of who you are contacting ... but you trust somebody else
and they issue certificates that supposedly you can trust).

In the case of "loading" a certificate into a table ... you are
bypassing the "trust propogation" gorp ... and loading the CA's public
key (from the certificate) into a table of trusted public keys. Many
products with SSL support typically ship with some number of trusted
(CA) public keys already preloaded into their trusted public key
table. The majority of the products will accept any certificate that
can be authenticated with some public key in their table of trusted
public keys (whether it was a preloaded trusted public key or a public
key you specifically loaded).

So for the client browser to authenticate the server's certificate ...
it must have the public key of the CA signing the server certificate
(in its trusted public key table) ... or some CA public key from a
trust hierarchy (the CA that signs your server certificate ... instead
of having a self-signed certificate loaded into all the browsers, may
have a CA certificate signed by some other CA ... which in turn has
its public key loaded into the client browswers). So for the client
browswers to authenticate your server .... either 1) the CA
certificate for your MS certificate server (CA-Inhouse) is self-signed
and has been loaded into all the client browser public key tables or
2) the CA certificate for your MS certificate server (CA-Inhouse) is
signed by some other CA which has a public key loaded into the client
browser trusted public key tables.

Similarly for the server to authenticate the client certificates ...
it must have the public key of the CA signing the client certificates
some how (pre)loaded into its table of trusted public keys (or the
public key signing some CA-certificate in the client certificate trust
hierarchy). One purely hypotethical scenario is that the MS
certificate server (CA-Inhouse) has a CA server certificate that is
not self-signed ... but possibly signed by microsoft ... and
microsoft's CA certificate's public key is in the server's table of
trusted public keys. Furthermore it is possible such a microsoft CA
certificate is also not self-signed ... but is signed by some
CA-commercial operation, who's public key is also loaded into the
server's table of trusted public keys. Some such CA-commercial can
also have a common trust root with the entity that is signing the
client certificates.

The implication is that the server will accept as correctly
authenticated any and all client certificates that have been signed by
some validly recognized certifcate authority aka the server doesn't
care what clients are connecting ... just so long as they have
somebody's valid certificate. This may or may not be what you are
really interested in. The client process for a server certificate is
that the person types in a URL and gets back a SSL server certificate
and checks to see if the domain name typed in corresponds with the
domain name in the certificate.

One possibility from your description is that the server isn't
checking to see if the person being authenticated isq actually a
specific trusted person ... but is just checking to see if it is any
random entity with any random valid certificate.

The authentication scenario ... say with RADIUS used by nearly all
ISPs in the world for internet connectivity ... or a web server that
has its client authentication stub to interface to RADIUS is that the
connecting entity claims to be somebody ... which then RADIUS checks
to see if that somebody is in the authentication table. The connecting
entity then authenticates with regard to the claimed somebody with
some authentication material. Then RADIUS typically provides the
authorization information with regard to the authenticated entity.
Most implementations in the world have a password (shared-secret)
registered with RADIUS as authentication information. However, it is
possible to enhance RADIUS to register a public key in place of a
password. The client then performs a digital signature operation for
authentication part of RADIUS ... and the server does a
(certificate-less) digital signature authentication using the public
key registered for the claimed entity.

There is a big different between any client in the world that just
happens to have a valid certificate being allowed access .... and a
client being able to proove that they are a specificly claimed entity
with known access rights.

a little drift with authentication, SSL, PKI, WYTM, MITM, etc
http://www.garlic.com/~lynn/aadsm15.htm#4 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm15.htm#7 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm15.htm#8 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm15.htm#9 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm15.htm#10 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm15.htm#11 Resolving an identifier into a meaning
http://www.garlic.com/~lynn/aadsm15.htm#14 Resolving an identifier into a meaning
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm15.htm#26 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm15.htm#27 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm15.htm#29 SSL, client certs, and MITM (was WYTM?) 

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/ 
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Relevant Pages

  • Re: Explanation of SSH
    ... I am still unclear on how SSH works exactly. ... Client issues SSH command and names server ... "Shopper" says "server sends back its public host and server keys ... Surely there is only one public key it sends ...
    (comp.security.ssh)
  • [NT] Dark Age of Camelot Man-In-The-Middle
    ... use of RSA public key cryptography and an RC4 based symmetric algorithm. ... Seeing the imminent release of code for cracking the game client (which ... At the beginning of each TCP session, the server sends a 1536 bit RSA ... void bytes_out(unsigned char *data, int len) ...
    (Securiteam)
  • Re: Need for encryption in WSE 3.0 if using SS-avoid man-in-middle
    ... SSL only validates you are talking to a SSL certified server; ... They can simply edit the URL the client program ... can be done by using a X.509 certificate on both ends, ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: LDP client authentication fails
    ... I got the LDP working with LDAP server under server client authentication ... I did not installed the certificate in pfx format .. ... Client cert auth won't work without that. ...
    (microsoft.public.windows.server.active_directory)
  • Re: SSL & Man In the Middle Attack
    ... >> it possible for the middle man to intercept all messages from server to me ... > server sends client a signed message along with a digital certificate. ... > client generates a random secret key, ...
    (comp.security.misc)