0

i'm about to secure a webservice with client authentication. (apache2, mod_ssl, openssl).

from what i googled, i found that it's more common to have a ca, which signs the client certs, which will then be checked.

also i found that it should be possible with the help of the sslrequire directive (in the apache configuration) to check something i guess the issuer and subject DN's of the client cert, or would there be a better field for this, in order to check if the client has a certain certificate.

something like (pseudocode): sslrequire issuer_dn='issuer_dn_from_client_cert' AND subject_dn='subject_dn_from_client_cert'

my question is: would that really work ? i mean, if an attacker would guess the issuer&subject DN's - couldn't he craft himself a valid certificate ?

1

Certificates are signed. When a server authenticates clients through certificates, the following three things happen:

  1. The client demonstrates mastery of the private key corresponding to the public key which is contained in its certificate. This part happens within SSL; as part of the protocol, a signature is computed by the client over a challenge from the server. You don't have to care about that because the SSL library you use already does it.

  2. The server validates the certificate. Validation is about making sure that the certificate contents are genuine. To validate a certificate, the server verifies the signature on the certificate, with regards to its issuing CA public key. The CA public key is itself obtained through the CA certificate, which has to be validated as well, and so on. This process ultimately binds to a public key known a priori, called a trust anchor or root CA.

    The Apache SSLCACertificateFile and SSLCACertificatePath directives are used to configure which root CA your server will use.

  3. The server decides whether the authenticated user should be granted access or not. This is what Apache's SSLRequire directive is about: a filter on authenticated identities.

The first step is the method by which the server makes sure that the client is "whoever owns public key Kp" (as found in the sent certificate). Second step is the mechanism which reveals to the server the identity I of the owner of Kp. First and second step together give to the server some guarantee about the identity of the client. Now that the server knows who is calling, the server must still verify that the caller is indeed allowed to do the call. If we want to use strict terminology, the first two steps are authentication per se, while the third step is authorization.


An analogy:

  • The client is Bob.
  • The private key is Bob's face.
  • The certificate is Bob's ID card.
  • The SSLRequire directive is the list of expected guest, within the hands of the security guard.

Bob demonstrates ownership of is face by virtue of that face being firmly attached to his body (the guard checks that the face is not a mask); that's the first step.

The security guards inspects the ID card, concludes that the card is genuine (we assume here that ID cards cannot be falsified), and that the photo on the ID card matches the face of the individual currently standing in front of him. Since Bob's name appears on the ID card, the security guard now knows that he is talking to the genuine "Bob". That's the second step.

Then the security guard checks whether his list of allowed guest contains Bob's name. If it does, he will let Bob in. Otherwise, he will shoo Bob away.

Dave, a party crasher, wants to get pass the security guard. To achieve that, he has to break through one of these steps: either get a fake Bob face (with a mask so perfect that the guard will be fooled), or get a fake ID card (with Dave's face but Bob's name), or alter the guard's list (simply adding his own name to the list). Going back to the Apache server, this means either stealing the client private key (e.g. by cryptographically breaking it -- good luck with that !), obtaining a fake certificate (which entails bribing or hacking one of the CA which Apache has been configured to accept), or altering Apache's configuration (its SSLRequire directive). Since altering Apache's configuration means that Dave already has root access to the machine, this is usually not a relevant attack.

Knowing Bob's name is not sufficient for Dave. THAT is the answer to your question: no, knowing what to put in a fake certificate (the issuer and subject DN required by SSLRequire) does not allow crafting a fake certificate; the attacker still has to corrupt some CA so that he gets his certificate signed (in a way that the server accepts).

3
  • thanks for typing that quite long and elaborate and usefull answer. i got it. now, if the client's certificate would be selfsigned, it would make no sense, right? – frisbee23 Apr 3 '14 at 10:46
  • Self-signed certificates cannot be validated, except in a "direct trust" model: server already has a copy of the self-signed certificate. Indeed, using SSLRequire makes little sense in that case: SSLRequire is most useful for processing certificates which are not known a priori, but obtained dynamically and validated relatively to some root CA. – Tom Leek Apr 3 '14 at 12:37
  • great story which makes all points perfectly clear. Thanks – Andrey Regentov Dec 15 '15 at 3:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.