X.509 certificate revocation defends against man-in-the-middle attacks involving a compromised certificate. Certificate revocation strategies face scalability, effectiveness, and deployment challenges as HTTPS adoption rates have soared. We propose Certificate Revocation Table (CRT), a new revocation strategy that is competitive with or exceeds alternative state-of-the-art solutions in effectiveness, efficiency, certificate growth scalability, mass revocation event scalability, revocation timeliness, privacy, and deployment requirements. The CRT periodically checks the revocation status of X.509 certificates recently used by an organization, such as clients on a university's private network. By prechecking the revocation status of each certificate the client is likely to use, the client can avoid the security problems of on-demand certificate revocation checking. To validate both the effectiveness and efficiency of using a CRT, we used 60 days of TLS traffic logs from Brigham Young University to measure the effects of actively refreshing certificates for various certificate working set window lengths. Using a certificate working set window size of 45 days, an average of 99.86% of the TLS handshakes from BYU would have revocation information cached in advance using our approach. Revocation status information can be initially downloaded by clients with a 6.7 MB file and then subsequently updated using only 205.1 KB of bandwidth daily. Updates to this CRT that only include revoked certificates require just 215 bytes of bandwidth per day.

<p>This master thesis consists of three parts. The first part contains a summary of what is needed to understand a X.509 parser that I have created, a discussion concerning the technical problems I encountered during the programming of this parser and a discussion concerning the final version of the parser. The second part concerns a comparison I made between the X.509 parser I created and a X.509 parser created"automatically"by a compiler. I tested static memory, allocation of memory during runtime and utilization of the CPU for both my parser (MP) and the parser that had a basic structure constructed by a compiler (OAP). I discuss changes in the parsers involved to make the comparison fair to OAP, the results from the tests and when circumstances such as time and non-standard content in the project make one way of constructing a X.509 parser better than the other way. The last part concerns a WTLS parser (a simpler kind of X.509 parser), which I created.</p>

This master thesis consists of three parts. The first part contains a summary of what is needed to understand a X.509 parser that I have created, a discussion concerning the technical problems I encountered during the programming of this parser and a discussion concerning the final version of the parser. The second part concerns a comparison I made between the X.509 parser I created and a X.509 parser created"automatically"by a compiler. I tested static memory, allocation of memory during runtime and utilization of the CPU for both my parser (MP) and the parser that had a basic structure constructed by a compiler (OAP). I discuss changes in the parsers involved to make the comparison fair to OAP, the results from the tests and when circumstances such as time and non-standard content in the project make one way of constructing a X.509 parser better than the other way. The last part concerns a WTLS parser (a simpler kind of X.509 parser), which I created.