There are several different methods for checking whether certificates on the web have been revoked, timely discovery of revoked certificates are important to ensure security when authentication within the HTTPS protocol is used. These methods have both advantages and disadvantages as they can contribute to security but at the same time worsen performance on the web browsers. This thesis examines these methods in more detail to identify the pros and cons and whether it is possible to find a good tradeoff between security and performance. This is important as a user is exposed to major security flaws if the integrity of a domain cannot be verified. Our analysis includes to which extent OCSP and CRL are used, how much OCSP affects the browser Firefox's performance, and how many web servers implement methods to verify revoked certificates, such as OCSP staple and must-staple. We also compare web browsers own lists of revoked certificates and look for patterns and differences between them. The analysis shows that OCSP and CRL have largely been replaced by other methods of verifying revoked certificates such as OneCRL and CRLSet. It turned out that OneCRL and CRLSet only cover a small fraction of the total number of certificates available. Often, it takes several weeks for certificates to appear in these lists after being revoked. We also found that OCSP's impact on the web pages performance is minimal. We concluded that the existing methods for verifying revocation statuses are inadequately used by CAs, web browsers and web servers, which poses a major security risks for users. Many certificates are not checked at all. However, we believe that it is possible to increase the security without reducing performance if CAs, web browsers and web servers can collaborate in the development of improving and combining current methods for checking revoked certificates.

Transport Layer Security (TLS) is a vital component to the security ecosystem and the most popular security protocol used on the Internet today. Despite the strengths of the protocol, numerous vulnerabilities result from its improper use in practice. Some of these vulnerabilities arise from weaknesses in authentication, from the rigidity of the trusted authority system to the complexities of client certificates. Others result from the misuse of TLS by developers, who misuse complicated TLS libraries, improperly validate server certificates, employ outdated cipher suites, or deploy other features insecurely. To make matters worse, system administrators and users are powerless to fix these issues, and lack the ability to properly control how their own machines communicate securely online. In this dissertation we argue that the problems described are the result of an improper placement of security responsibilities. We show that by placing TLS services in the operating system, both new and existing applications can be automatically secured, developers can easily use TLS without intimate knowledge of security, and security settings can be controlled by administrators. This is demonstrated through three explorations that provide TLS features through the operating system. First, we describe and assess TrustBase, a service that repairs and strengthens certificate-based authentication for TLS connections. TrustBase uses traffic interception and a policy engine to provide administrators fine-tuned control over the trust decisions made by all applications on their systems. Second, we introduce and evaluate the Secure Socket API (SSA), which provides TLS as an operating system service through the native POSIX socket API. The SSA enables developers to use modern TLS securely, with as little as one line of code, and also allows custom tailoring of security settings by administrators. Finally, we further explore a modern approach to TLS client authentication, leveraging the operating system to provide a generic platform for strong authentication that supports easy deployment of client authentication features and protects user privacy. We conclude with a discussion of the reasons for the success of our efforts, and note avenues for future work that leverage the principles exhibited in this work, both in and beyond TLS.