Whenever the server requires the client authentication, the server sends the certificate request message to the client after sending its own certificate message and before sending the server hello done message in the SSL handshake protocol. Figure 3.2 in chapter 3 explains the message sequences in the SSL handshake protocol. When the client receives the certificate request from the server, the client is supposed to send its certificate before it sends the client key exchange message. The client also sends the certificate verify message to prove that the certificate sent is indeed belongs to the client. The client verify message is sent after the client key exchange message.
The server cannot possibly trust the certificate provided by the clients. There are almost uncountable clients. Trusting each client’s certificate is practically impossible. Therefore, when a server asks for a certificate a client should provide a list of certificates containing its own certificate along with a set of certificates leading to an acceptable certificate authority. The certificate provided by the client should be inherently trusted by the server to complete the client authentication. That is, this list of certificates should contain at least one certificate that is trusted by the server.
The diagrammatic representation of a basic certificate chain that can be used to validate the client certificate is shown in Figure 7.1. The first certificate (left-most) in this diagram is the client certificate. The issuer of this certificate is ICA(Intermediate CA1.). This certificate is originally issued by the CA. The client can be authenticated successfully if the client sends these three certificates (Client, ICA and CA) to the server and if and only if the server trusts either the CA certificate or the ICA certificate and signature included in client, ICA and CA certificates can be verified by the server.
Figure 7.1: A Basic Certificate Chain
The SSL specification [31, 30, 32, 49] requires that the list of certificates should start with the client’s own certificate followed by the issuer of the client’s certificate and in this way leading to the certificate/certificates that is/are trusted by the server.
7.2.2 Process certificate chain construction
When the server receives a certificate chain from the client, a temporary stack is created to store these certificates. Then the last certificate in the stack is retrieved. This certificate is supposed to be the client’s certificate. The issuer of the certificate is searched using the issuer name on this certificate. Once the issuer certificate is identified, a further check is done to confirm that the certificate found as an issuer of the client certificate is indeed the true issuer. The standard procedure is described in the RFC 4158 [50]. However, the OpenSSL does not employ all the check necessary to find a valid issuer of the certificate to build the certificate chain. For example, an Authority Key Identifier (AKID) should be matched with Subject Key Identifier (SKID) of the issuer in order to confirm that bearer of the SKID is
1
7.2 Certificate Chain Construction 63
surely issuer of the AKID [50]. But OpenSSL checks this constraint only if SKID field is present in the certificate of the subject. The discussion of this issue is out of the scope this thesis.
This procedure of finding the issuer of the certificate is continued till the time it finds the self signed certificate in the chain. The final CA certificate is always self signed. This way the certificate chain is constructed in the OpenSSL.
7.2.3 Certificate Loop
Experiment 8. Send the list of client certificates in such a way that it creates a loop at the server side while constructing the valid certificate chain.
Explanation
The idea behind this experiment is to construct the malicious certificates such that the final CA certificate is never found by the server.
Figure 7.2: The set of malicious certificates that forms a loop during certificate chain con- struction
The client can send the certificates as shown in Figure 7.2. The client sends a set of 5 certificates. One of them belongs to the client2. As observed from Figure 7.2. If an issuer of the certificates is to be retrieved recursively then the order of retrieval will be the client certificate that is always retrieved initially and found at the first place in the list provided by the client, then the issuer of the client certificate is searched. In the example given in this figure, the issuer of the client certificate is certificate with the subject name A , so briefly the certificate searching procedure can be continued as follows: Client(A), A(B), B(C), C(A), A(B), B(C), C(A), ... It should be noted that a loop has formed in the process of retrieving the issuer certificates. Therefore, chain building process will never completed successfully. This can create hazardous effects for the server in terms of the CPU cycles invested for this process.
Analysis
The OpenSSL source code snippet is given in Listing 7.1 where certificate chain is constructed. The terminology used in this listing is summarized in Table 7.1.
1 f o r ( ; ; )
2 {
2The certificate chain can also be formed with only 2 certificates. More certificates are used in this example
3 i f ( d e p t h < num ) 4 { 5 b r e a k; 6 } 7 i f ( c t x−>c h e c k _ i s s u e d ( c t x , x , x ) ) 8 { 9 b r e a k; 10 } 11 i f ( c t x−>u n t r u s t e d != NULL) 12 { 13 xtmp = f i n d _ i s s u e r ( c t x , sktmp , x ) ; 14 i f ( xtmp != NULL) 15 { 16 i f ( ! sk_X509_push ( c t x−>c h a i n , xtmp ) ) 17 { 18 /∗ E r r o r H a n d l i n g ∗/ 19 } 20 [ . . . ] 21 x = xtmp ; 22 num++; 23 c o n t i n u e; 24 } 25 } 26 b r e a k; 27 }
Listing 7.1: Certificate Chain Building in OpenSSL
As shown in Listing 7.1, the depth of the certificate chain generated (so far) is checked against the depth value (More about it later.) at the starting of the unconditional for loop at Line 3. Initially the stack of the certificates denoted by the ctx→chain contains only the client’s own certificate3. The variable num contains the number of certificates in the certificate stack ctx→chain that is updated in the for loop. Therefore, initially (at line 3), num equals 1. This for loop is ended if the self signed certificate is detected. On Line 7static int check _issued (X509 _STORE _CTX *ctx, X509 *x, X509 *issuer)
function is used to check if a certificate is self issued. The ctx→untrusted is the stack containing all the certificates sent by the client. On Line 13, an issuer of the certificatex is searched fromsktmp. Thesktmp is the duplicated stack of ctx→untrusted. Therefore, the stacksktmpalso contains all the certificates sent by the client. If the issuer of the certificatex
is found in the stack of the certificates containing client’s certificate (sktmp) then it is added into another stackctx→chain(line 16). For brevity, unrelated lines from this code snippet are not shown (line 20). Once the certificate is pushed into the another stack (ctx→chain), the variable num is incremented and for loop is continued. As already explained, the first check in the for loopis to check if num> depth. Whenever, this condition is reached, the
for loopis ended.
The variabledepthindicates the number of certificates allowed to be searched or retrieved before finding the trusted certificate. This variable can be set to any integer value. Setting this value very large cannot be very useful. With the increase in the number of the certificates in the constructed chain, the computational overhead on the server also increases. This is because, with the increased number of certificates, the server will also have to verify the signatures in each certificate. As already seen in Chapter 6, the signature verification does require considerable CPU time. The default value for this variable in the SSL configuration file of the Apache web server is set to 10. Therefore, by default, the SSL server running on
3