Problem to solve – We are deploying a Public Key Infrastructure (PKI) at our company, but we have no means to tell if everyone is utilizing it properly. How can we find Invalid Certificates?

Contributing Author – Robert Wright, Network Engineer with 15+ years experience

Certificates?

“Remember, kids, only members of Annie’s secret circle can decode Annie’s secret message. Set your pins to B-2”

In the 1983 cult classic, A Christmas Story, little Ralphie is able to decode Little Orphan Annie’s Caesar cipher because they both have a pre-shared key (B-2). Today’s encryption requirements demand much more than a simple mail order decoder ring. These requirements, some of which are driven by federal regulations, guide a corporation IT organization to deploy Public Key Infrastructure (PKI).  http://en.wikipedia.org/wiki/Public_key_infrastructure 

Deploying a PKI is quite a serious and lengthy endeavor. Who will lead this effort? Who will own the various components of the PKI once it’s installed? What vendor will we go with? What process will we follow to distribute certificates? What do we do should our certificate become compromised? All very good questions, but we are missing at least one critical question every project requires. Do you know which one? Say it to yourself right now. …How do we measure success?

Self Signed Certificates … BAD !!

Once you deploy a PKI, ALL certificates should be issued per your certificate issuing policies. That’s simple right? Well what about all that new gear the <Insert Team Name Here> just deployed? Does it even use certificates? Well if they did, they would follow all processes and policies right? Fudge… Any more the answer is yes.  It is using a certificate and it just so happens to be self-signed, not your multi-thousand dollar infrastructure you just spilled your heart and soul into.

Many enterprises have implemented or are in process of implementing distributed performance management platforms with capabilities of multiday packet storage. These systems give you the extremely unique ability to locate invalid certificates through packet analysis. Impossible you say? Too time consuming you say? Not so with basic skills and a platform supporting scripting capabilities!

Transport Layer Security … Good !!

Like your certificate issuing process, network communication protocols follow a strict structure laid out by working groups. This lends itself well when we start writing scripts to key off particular offsets and patterns. Certificates from our PKI will be found during the SSL/TLS handshake. This is a requirement for any communication protected by the most prolific authentication protocol in existence today, Transport Layer Security (TLS). http://en.wikipedia.org/wiki/Transport_Layer_Security

By embracing filtering, in our process, we can increase performance, and reduce risk of incorrect identification. Through industry standards, we know that the certificate is exchanged as part of the Server Hello message. So our first filter should be to filter for the appropriate source port. In the case of websites utilizing standard protocols and being protected by TLS, this would be a source port of TCP 443. Why? During TCP communication the client typically selects a dynamic port, while the server maintains a static port. Since we are interested in seeing the server handshake, from THE server we will filter on its communication.

Locate the Invalid Certificates

Our next step of our filtering is to isolate those packets containing the certificate. In the case of TLSv1 this can be accomplished by the use of a pattern filter of 0x16030100000B and a mask of 0xffffff0000ff. At this point our packet capture will be limited to only those packets sourced by the server and containing the certificate we wish to review.

At this point in the process, standards make our job extremely easy. By utilizing offsets we can tell our script to go 172 bytes into the packet (TLSv1) and extract the next X number of bytes. This will be our issuer, or rather the machine which claims to vouch for the server’s identity. By comparing this issuer with the subject (the server’s claimed identity) located at 318 bytes into the packet, we can tell if the remote server is vouching for itself (self-signed) or utilizing our PKI. This comparison can be accomplished through the use of GNU utility AWK.

This same task can be utilized to compare the validity fields of “notbefore” and “notafter” to determine if the certificate supplied is valid at the time of the client’s request.

In closing, by leveraging your corporation’s existing investment in packet capture technology you will be able to determine not only the success of your project, but also violators of your PKI investment.

Questions

• Any of you ever had a PKI where you could not locate the invalid certificates?
• How did you go about identifying and locating these certificates?
• Any words of wisdom or caveats from your experience?