An Empirical Analysis of HTTPS Configuration Security

TL;DR

This paper empirically evaluates HTTPS configurations across popular websites, revealing that cloud providers generally offer secure defaults, while individually configured servers are often insecure due to insecure defaults and guides.

Contribution

It provides an empirical analysis of HTTPS configurations, highlighting the influence of cloud defaults and the insecurity of individual server setups.

Findings

Most websites have secure configurations due to cloud provider defaults.

Individually configured servers are more often insecure.

Insecure defaults and guides contribute to insecure configurations.

Abstract

It is notoriously difficult to securely configure HTTPS, and poor server configurations have contributed to several attacks including the FREAK, Logjam, and POODLE attacks. In this work, we empirically evaluate the TLS security posture of popular websites and endeavor to understand the configuration decisions that operators make. We correlate several sources of influence on sites' security postures, including software defaults, cloud providers, and online recommendations. We find a fragmented web ecosystem: while most websites have secure configurations, this is largely due to major cloud providers that offer secure defaults. Individually configured servers are more often insecure than not. This may be in part because common resources available to individual operators -- server software defaults and online configuration guides -- are frequently insecure. Our findings highlight the importance of considering SaaS services separately from individually-configured sites in measurement studies, and the need for server software to ship with secure defaults.