Spotting the Sin During Code Review

First, identify all of the input points to your application that come from the network. For each of these points, determine whether or not the code is using SSL. While APIs vary widely from library to library and language to language, its easiest to just search for SSL and TLS in a case-insensitive manner. And if youre using older Windows libraries, search for PCT (Private Communication Technology), a deprecated Microsoft predecessor to SSLv3). If a particular input point isnt protected with SSL, there may be a significant problem right there!

Beyond this point, the issues we discuss in this sin are most often appropriate to client code, because server code often uses passwords or some other mechanism for authenticating the client. When client certificates are used, however, the same code review methodology applies.

For each input point using SSL, check to see if the certificate is compared against a list of known good certificates (an allow list). People who do this kind of thing are generally not hooked into a commercial PKI, and are essentially managing their own in an ad hoc way.

If it is on the allow list, then there may still be revocation risks, and there may be risks with the allow list being generated in an insecure manner. Also, you should make these checks before using the connection to send data.

If the code doesnt use an allow list, then check to see that all of the following validation steps are taken:

• The certificate is signed by a known CA, or else there is a chain of signatures leading back to a known CA.

• The certificate is within its validity period.

• The hostname is compared against the proper subfield in at least one of the DN field or the X.509 v3 subjectAltName extension.

• The program treats a failure of any one of these checks as a failure to authenticate, and it refuses to establish a connection.

In many programming languages, this will often require you to look deep into documentation, or even the implementation. For example, you might run across the following Python code using the standard socket module that comes in Python 2.4:

 import socket  s = socket.socket() s.connect(('www.example.org', 123)) ssl = socket.ssl(s) 

Its unclear on the surface what the SSL library checks by default. In Pythons case, the answer is that, according to the documentation, the SSL libraries check absolutely nothing. Some languages might check the date and the chain of trust, but then you should be sure that theres a good list of CAs attached, and to take the proper actions if not.

When looking to make sure that revocation is done properly, you should look to see if either CRLs or OCSP is used at all. Again, APIs vary widely, so its best to research the SSL API that is actually in use by a program; but searching for CRL and OCSP in a case-insensitive way will do in a pinch .

When one or both of these mechanisms are being used, the biggest things to look out for are as follows :

• Whether this is being done before data is sent.

• What happens when the check fails.

• In the case of CRLs, how often are they downloaded.

• In the case of CRLs, are the CRLs themselves validated ( especially if theyre downloaded over plain HTTP or LDAP).

Look out for code that simply looks inside the certificate for certain details such as the DN and does not perform the appropriate cryptographic operations. The following code is sinful because it checks only to see if the certificate has the text "CN=www.example.com" and anyone could issue themselves a certificate with this name .

 X509Certificate cert = new X509Certificate(); if (cert.Subject == "CN=www.example.com") {  // Cool, we're talking to example.com! }