TLS 1.3 in Practice:How TLS 1.3 Contributes to the Internet (2024)

CCS Concepts: • Security and privacy → Web protocol security;

Transport Layer Security (TLS)[15, 37] has become the de-facto standard protocol for secure communications in web services such as online banking. As of October 2020, more than 90% of Internet traffic is communicated over TLS[20]. TLS has evolved from Secure Socket Layer (SSL) to its newest version, TLS 1.3, enhancing security and performance from its legacy versions[25]. Compared to TLS 1.2[15], for instance, TLS 1.3 guarantees perfect forward secrecy by removing static RSA key exchanges. It also reduces the number of round-trips of the TLS handshake from two to one, aiming to improve the performance of the initial setup.

Due to the significant impact of TLS in the web ecosystem, there have been many studies aiming to understand various aspects of TLS. To name a few, Holzet al. [22] show the statistics of the TLS 1.3 usage and what boosts its deployment. Nayloret al. [33] and Feltet al. [19] investigate the use of HTTPS (HTTP over TLS)[36] in practice. Platonet al. [25] demonstrate how the TLS ecosystem reacts to high-profile security attacks. However, to the best of our knowledge, the new TLS version’s impact on the ecosystem has not been thoroughly studied. Since it has been more than two years since the TLS 1.3’s approval (Aug. 10th, 2018), we believe it is time to analyze how adequately TLS 1.3 is deployed in practice as intended by design.

In this paper, we aim to look closely at the implications of TLS 1.3 deployment in practice, mainly focusing on adoption, security, performance, and implementation. Specifically, we collect TLS handshake messages targeting the Alexa top 1M websites on a daily basis for days from North America (connections in total) to analyze how many websites adopt TLS 1.3 and what security benefits they obtain. Furthermore, we also evaluate the time required to perform a TLS handshake with TLS 1.3 websites (on) from eight different regions to quantify performance gain by upgrading to TLS 1.3, compared with TLS 1.2. Overall, we conclude that TLS 1.3 makes a significant contribution to the Internet in many aspects, based on the following observations:

Adoption.AdoptionAdoption. The TLS 1.3 adoption rate is significantly faster than the previous versions of TLS. It took only 264 days for TLS 1.3 to be deployed by more than 15% of websites after IETF officially approves the protocol. It is remarkably faster than the adoption rate of TLS 1.2, which took around five years to achieve the same adoption rate (i.e., 15%)[4]. We find that third-party platforms (e.g., CDNs) are the main contributors to the high adoption rate at the early stage of TLS 1.3, as they have adopted the TLS 1.3 at once.

Security.SecuritySecurity. TLS 1.3 adoption contributes to enhancing the overall security of the TLS ecosystem. However, we find that 19.1% of the TLS 1.3 adopted websites support TLS 1.3 unstably. The TLS versions of the sessions established with the websites are not always TLS 1.3 after adopting TLS 1.3. It varies depending on when a client accesses the websites or where a client connects to them. This unstable support may weaken a certain website's security since a website can show the lower TLS version at a specific time or from a particular region. Therefore, stakeholders should carefully manage the TLS version both temporally and geographically while upgrading to TLS 1.3.

Performance.PerformancePerformance. Our results indicate that the time taken for a TLS 1.3 full handshake is reduced compared to TLS 1.2 by 57.9% – 77.1% on average, depending on the regions. In particular, websites served on third-party platforms (e.g., Cloudflare) are often geographically located near clients, leading to 27.9% – 69.0% of the performance gains. On the other hand, websites running over cloud platforms (usually farther from the clients geographically) gain performance enhancements of up to 91.1%, which may motivate individual websites to upgrade to TLS 1.3 for more secure and faster web services.

Implementation.ImplementationImplementation. We inspect whether the new features of TLS 1.3 are enabled on server-side and client-side applications or implemented in TLS libraries. 98 (0.03%) of the TLS 1.3 websites do not support downgrade protection (details in section 2 and section 7.1). Furthermore, it takes 516 days after TLS 1.3 was approved when a web browser first check downgrade sentinels sent by servers. Many TLS libraries do not implement the parsing module for certificate extension fields introduced for certificate-related extensions such as signed certificate timestamps[27] and OCSP stapling[34].

The paper is organized as follows. We summarize the TLS handshake with new features in TLS 1.3 and our research topics (section 2). Then, we describe what dataset we used in this paper and how we collected them (section 3). Based on the dataset, we explain our results regarding adoption (section 4), security (section 5), performance (section 6), and implementation (section 7). We review related work (section 8) and finalize this paper with concluding remarks (section 9).

In this section, we describe the datasets that we use to answer the research questions presented in section 2.2. We make three types of datasets—Security Parameters (D1), Handshake Messages (D2), and Platform Information (D3)—using our client-side applications.1

Security Parameters (D1).To understand the adoption rate and the security impact of TLS 1.3, we collect two hello messages in the TLS protocol (ClientHello and ServerHello). Those hello messages are to negotiate the TLS version and other security parameters between endpoints. To collect this data, we implement a client-side application based on $\mathsf {OpenSSL\text{-}1.1.1a}$ that implements the officially approved TLS 1.3 protocol. Our client application sends ClientHello to the intended server and terminates the handshake right after receiving ServerHello, recording the two hello messages and the IP addresses of the target servers.

The collection is performed for each of the Alexa 1M websites on a daily basis from a machine with Intel Xeon E3 CPUs and 8GB RAM. We utilize a single snapshot of the Alexa 1M websites generated in April 2018 during our observation period, which is from to (days in total). Throughout our observation period, around 84% of the websites were consistently collected. There were network outages for 17 days, which are pruned out from the dataset.

Handshake Messages (D2).To analyze the TLS 1.3 features supported in the TLS 1.3 web servers (on) and to compare the initial setup time of TLS 1.3 with that of TLS 1.2, we also collect both TLS 1.2 and TLS 1.3 full handshake messages while measuring the elapsed time to establish the session. The data is collected from AWS machines (2.3GHz CPUs and 8GB memory) in eight different regions—Eastern North America (Ohio), Western North America (California), South America (San Paulo), Western Europe (Paris), South Africa (Cape City), East Asia (Seoul), Southeast Asia (Mumbai), and Oceania (Sydney).

Platform Information (D3).To better understand who upgrades the TLS versions of the Alexa 1M websites and find any different trends due to the platforms, we categorize the TLS websites into two classes based on who is responsible for managing the TLS libraries. They can be defined as 1) first-party responsibility and 2) third-party responsibility. In the former, website owners are responsible for upgrading the TLS libraries since the websites are running over an infrastructure-as-a-service platform such as Amazon Web Services. We consider these websites as first-party responsibility (FPR). On the other hand, if the websites use a CDN network (e.g., Cloudflare) or a website builder (e.g., Squarespace) to deliver contents, the platform providers are responsible for managing the TLS libraries; in other words, the website owners (or administrators) are not responsible for it. We classify these websites as third-party responsibility (TPR).

To identify the two categories (i.e., FPR and TPR), we perform the following platform identification process, as shown in Figure 1.

First, as a preliminary step, we identify each website's IP addresses and the related organizations (of the IPs). We also prepare for a list of known TPR platforms, such as Cloudflare, with their publicly announced IP ranges.

Second, we consider a website as FPR if its domain name and the IP address owner are the same. Google is an example of FPR.

Third, we denote a website as TPR if the website runs over a platform included in the list of known TPR platforms.

Fourth, we check whether a website is running over an anycast infrastructure. Specifically, we identify the anycasting IP address by comparing i) the round-trip times between two vantage points and ii) the sum of the round-trip times from each vantage point to each domain, proposed in prior work[29]. If the latter is significantly smaller than the former (less than 50%), we conclude that the IP address might be used for anycasting, hence classified as TPR.

Finally, we refer to a website as TPR if the round-trip times between clients of eight different regions and the website accessed by more than one IP address are significantly low. Otherwise, we classify the website as FPR.

To this end, we identify websites () as FPR and () as TPR.

Ethical consideration.To minimize the ethical concerns during our data collection, we restrict the number of requests we send to the public servers. Specifically, only one TCP handshake is performed per domain once a day. TLS hello messages were exchanged with our client, which is trivial.

In this section, we first measure the adoption ratio of TLS 1.3 among Alexa top 1M sites. Then, we analyze which factors affect the adoption of TLS 1.3, concluding that it is mainly led by TPR platforms such as CDNs and web hosting companies since they can upgrade TLS libraries simultaneously.

Popular Websites and TLS 1.3.Several studies show higher-ranked websites are likely to adopt new security features quickly. For example, HTTPS and SMTP security extensions are deployed further in popular sites[19, 23]. We investigate whether there is a correlation between the adoption rate of TLS 1.3 and the Alexa ranks of the websites. We consider the four cases—Alexa top 1K, 10K (1K–10K), 100K (10K–100K), and 1M (100K–1M) sites—to understand the correlation.

We find that all the bins show continuous increases with similar patterns. As shown inFigure 2, in general, top-ranked websites have more TLS 1.3 adoption rates. However, in terms of the increment rate, the lower-ranked sites are likely to deploy TLS 1.3 faster. Interestingly, when we see the adoption rate of the sites below 1K, it was the lowest, which means the highest-ranked websites are more conservative in adopting TLS 1.3 than the lower-ranked websites. The sites between 200K and 300K show a higher adoption rate than the sites between 100K and 200K.

We conclude that there is no strong positive correlation between the Alexa ranks and the TLS 1.3 adoption rate from these observations. In other words, the trend of TLS 1.3 adoption shows a different result from that of HTTPS or SMTP security extension supporting domains.

Platform-based Adoption.To better understand the main contributors for the fast deployment of TLS 1.3, we compare the overall tendency of the adoption ratio of the popular platform providers. Specifically, we select the seven most popular platform providers: Cloudflare, Inhosted Lp., SiteGround, Squarespace Inc., Automattic Inc., SingleHop LLC., and Google LLC.

Figure 3 shows the changes of the overall TLS 1.3 deployment and the changes of TLS 1.3 deployment of the platform providers over time. The line demonstrates the overall TLS 1.3 deployment, while the bar graph shows a cumulative TLS 1.3 deployment of the selected platform providers. We observe that the seven companies cover most of the support of TLS 1.3 at the early stage, implying that these major platforms initially drive the rate of deployment.

We also compare the overall trend with the trend of websites served by FPR platforms and TPR platforms. As demonstrated in Figure 4, the result shows that TPR platforms deploy TLS 1.3 at once; thus, we can observe a few step-like increasing trends from the graph. On the other hand, the number of websites that support TLS 1.3 over FPR platforms is gradually increasing, showing a similar shape with the overall trend. We find that after Mar. 20th 2020, websites over FPR platforms account for more than 50% of the TLS 1.3 adoption. From these observations, we conclude that TPR platforms mainly lead the TLS 1.3 adoption at the early stage of TLS 1.3. However, the recent increase is caused by websites served over FPR platforms.

Furthermore, there are two interesting points regarding the platform providers. First, we see a sharp increase between Nov. 11st, 2018 and Nov. 16th, 2018. It is mainly because Inhosted initiated support for TLS 1.3 for 1,696 websites on Nov. 14th, 2018 and Squarespace enabled TLS 1.3 for 4,789 websites on Nov. 15th, 2018 and other 3,001 websites on Nov. 16th, 2018. Second, there is a peak between Feb. 10th, 2018 and Feb. 14th, 2018. It was related to the Google platform. On Feb. 10th, 2018, only 649 websites supported TLS 1.3 over the platform. The number of TLS 1.3 sites over Google increased to 6,760 and 11,962 websites on Feb. 11st and 12nd, respectively, which dropped to 664 websites on Feb. 14th.

One of the main goals of TLS 1.3 is to enhance the security of TLS. By upgrading to TLS 1.3, websites can obtain several security benefits such as enforcing forward-secret and AEAD cipher suites. Moreover, we discuss the critical security issues when web servers unstably support TLS 1.3.

In this section, we quantify how much delay is reduced by TLS 1.3. We measure the elapsed time of both the TLS 1.2 and TLS 1.3 full handshakes and calculate the performance gain defined as

$(1 - \frac{\text{(Elapsed Time for TLS 1.3 Full Handshake)}}{\text{(Elapsed Time for TLS 1.2 Full Handshake)}}) \times 100\;(\%)$

The measurement results are summarized in Table 4. The average performance gain of TLS 1.3 compared to TLS 1.2 is more than 57.9% (in Western Europe). We observe the most significant improvements in South Africa since it is located (on average) geographically farther from the Alexa 1M websites than the other regions. Note that the average round-trip time of South Africa to the Alexa 1M websites is 138.08 ms that is longer than those of other regions. Our manual inspection result shows that the Alexa 1M servers are mostly located in North America (Eastern and Western) and Western Europe. From the observations, we conclude that the longer the delay is taken between the server and the client, the more significant performance improvements one may get.

This trend is clearly shown when we consider the platforms for our analysis. As described inFigure 5, the websites running over TPR platforms experience smaller delay improvements compared to those on FPR platforms. This is because the TPR platforms are usually distributed on a global scale and hence servers tend to be closer to the clients; thus, the networking distances account for the variation in delay performance gains. Note that the correlation between the round-trip time and the FPR gain is 0.87.

Takeaways. From the above observations, we conclude that TLS 1.3 can be more beneficial to websites which cannot use CDN services due to budget or other reasons. We believe this result may motivate individual websites to be upgraded to TLS 1.3 for both security and performance.

In this section, we investigate whether TLS libraries in the wild are correctly and faithfully implement with the new features of TLS 1.3. Specifically, we focus on analyzing two aspects of the implementation: 1) new TLS 1.3 features and 2) common vulnerabilities and exposures (CVEs). We first look at TLS 1.3 libraries to check if they implement the downgrade attack mechanism and the parsing routine for the certificate extension fields. Then, we investigate whether web servers and web browsers properly employ the features. Finally, we review the CVE reports of TLS libraries to measure the security threats caused by the TLS implementations, especially relevant to TLS 1.3. Hence, we focus on the CVEs reported after TLS 1.3 was approved.

As shown in Table 5, of the total seven TLS libraries supporting TLS 1.3, only BorningSSL, Mozilla NSS, and OpenSSL fully support the two new features.

In this section, we discuss related work in two key areas: measuring the Web PKI ecosystem and the TLS deployment.

The Web PKI Ecosystem.The Web PKI ecosystem has been well studied and understood after network scanner tools were introduced (e.g., ZMap[18] and ICSI Notary[6]). These scanners help researchers collect representative datasets in the wild (such as X.509 certificates[10]) within a relatively short time and discover security problems in the Web PKI: including (1) vulnerabilities in the wild[5, 18, 21, 42], (2) revocation[9, 26, 30], (3) aftermath of the Heartbleed bug[16, 43], (4) private key sharing[7], (5) certificate transparency[24, 28, 38, 39, 40], and (6) invalid certificates[8, 26]. These measurement studies help improve the security of the entire Web PKI ecosystem. Moreover, the TLS interceptions have also been studied[14, 17, 41]. The interceptions are mainly conducted by middleboxes such as anti-virus software and security gateways. The studies have reported that the negative effects: specifically, incorrect certificate validation or security downgrade.

TLS Deployment.Unlike the measurements of the Web PKI, the deployment and security of TLS 1.3 are little known. To name a few, Holzet al. [22] showed the statistics of the TLS 1.3 usage and what boosts its deployment; however, it does not present the security implication, performance, and implementation of TLS 1.3. Moreover, Razaghpanahet al. [35] analyzed the cipher suite list and the TLS extensions (specifically, weak cipher suites and vulnerable protocol versions) on Android using passive datasets collected from Lumen Privacy Monitor, a free Android app. In this work, TLS 1.3 was not discussed. Recently, Kotziaset al. [25] first examined how the TLS ecosystem has evolved over approximately six years (February 2012 – April 2018) using passive and active datasets. They observed correlations between the TLS ecosystem's evolution and new TLS attacks; in other words, there have been significant improvements to the TLS ecosystem after new TLS attacks were discovered. However, this study barely measured TLS 1.3 deployment; rather they focused on the draft version 28 of TLS 1.3, since the study was conducted before TLS 1.3 was officially approved by the IETF. In contrast to these three measurement studies, our work focuses on the official TLS 1.3 examining the differences from TLS 1.2 in terms of deployments, security, performance, and implementation of the libraries that support TLS 1.3.

In this paper, we present a comprehensive analysis of TLS 1.3 in terms of its adoption, security, performance, and implementation. To answer the research questions from the four aspects, we conduct a temporal, spatial, and platform-based analysis on our datasets, consisting of TLS handshake messages from the Alexa top 1M websites for 837 days.

Our research leads to the following observations. First, the adoption rate of TLS 1.3 has rapidly increased compared to the previous versions of TLS, led mainly by third-party platforms such as CDNs. Second, we found that websites (19.1%) suffer from unstable support for TLS 1.3 during our observation period. Some websites downgraded to the lower version of TLS even after upgrading to TLS 1.3. Other cases were due to the website migration from the platform that supports TLS 1.3 to the one that does not. There were also cases that this instability happens due to the regional differences. Third, TLS 1.3 achieves reduced delays over TLS 1.2, which is more beneficial for first-party responsibility platforms than third-party responsibility ones. Fourth, we observe that many implementations of TLS libraries do not properly support the new features of TLS 1.3 such as downgrade protections. Finally, our study on CVEs of TLS libraries reveals that many vulnerabilities can be mitigated by simply adopting TLS 1.3.

We thank the anonymous referees for their constructive feedback. The research was supported, in part, by NSF under awards 1916499, 1908021, and 1850392. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the sponsor.

• 2016. Enable TLS 1.3 by default. https://bugzilla.mozilla.org/show_bug.cgi?id=1310516. Accessed: 2019-04-27.
• 2016. TLS Fallbacks are Dead. https://textslashplain.com/2016/05/04/tls-fallbacks-are-dead/. Accessed: 2019-05-02.
• 2019. C++14 implementation of the TLS-1.3 standard. https://github.com/facebookincubator/fizz. Accessed: 2019-04-29.
• April. SSL Pulse. https://www.ssllabs.com/ssl-pulse/. Accessed: 2019-04-27.
• David Adrian, Karthikeyan Bhargavan, Zakir Durumeric, Pierrick Gaudry, Matthew Green, JAlex Halderman, Nadia Heninger, Drew Springall, Emmanuel Thomé, Luke Valenta, et al. 2015. Imperfect forward secrecy: How Diffie-Hellman fails in practice. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security. 5–17.
• Bernhard Amann, Matthias Vallentin, Seth Hall, and Robin Sommer. 2012. Extracting certificates from live traffic: A near real-time SSL notary service. Technical Report. Citeseer.
• Frank Cangialosi, Taejoong Chung, David Choffnes, Dave Levin, BruceM Maggs, Alan Mislove, and Christo Wilson. 2016. Measurement and analysis of private key sharing in the https ecosystem. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. 628–640.
• Taejoong Chung, Yabing Liu, David Choffnes, Dave Levin, BruceMacDowell Maggs, Alan Mislove, and Christo Wilson. 2016. Measuring and applying invalid SSL certificates: The silent majority. In Proceedings of the 2016 Internet Measurement Conference. 527–541.
• Taejoong Chung, Jay Lok, Balakrishnan Chandrasekaran, David Choffnes, Dave Levin, BruceM Maggs, Alan Mislove, John Rula, Nick Sullivan, and Christo Wilson. 2018. Is the Web Ready for OCSP Must-Staple?. In Proceedings of the Internet Measurement Conference 2018. 105–118.
• D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk. 2008. Internet X. 509 Public Key Infrastructure Certificate and CRL Profile.
• CVE. 2014. CVE - CVE-2014-3566. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566. (Accessed on 03/26/2019).
• CVE. 2019. CVE - CVE-2019-15651. https://nvd.nist.gov/vuln/detail/CVE-2019-15651. (Accessed on 10/19/2020).
• CVE. 2020. CVE - CVE-2019-15651. https://nvd.nist.gov/vuln/detail/CVE-2020-12457. (Accessed on 10/19/2020).
• Xavier deCarnéde Carnavalet and Mohammad Mannan. 2016. Killed by proxy: Analyzing client-end TLS interception software. In Network and Distributed System Security Symposium.
• Tim Dierks and Eric Rescorla. 2008. The transport layer security (TLS) protocol version 1.2.
• Zakir Durumeric, Frank Li, James Kasten, Johanna Amann, Jethro Beekman, Mathias Payer, Nicolas Weaver, David Adrian, Vern Paxson, Michael Bailey, et al. 2014. The matter of heartbleed. In Proceedings of the 2014 conference on internet measurement conference. 475–488.
• Zakir Durumeric, Zane Ma, Drew Springall, Richard Barnes, Nick Sullivan, Elie Bursztein, Michael Bailey, J.Alex Halderman, and Vern Paxson. 2017. The security impact of HTTPS interception. In Network and Distributed Systems Symposium.
• Zakir Durumeric, Eric Wustrow, and JAlex Halderman. 2013. ZMap: Fast Internet-wide scanning and its security applications. In 22nd {USENIX} Security Symposium ({USENIX} Security 13). 605–620.
• AdriennePorter Felt, Richard Barnes, April King, Chris Palmer, Chris Bentzel, and Parisa Tabriz. 2017. Measuring HTTPS Adoption on the Web. In Proceedings of the 26th USENIX Conference on Security Symposium (Vancouver, BC, Canada) (SEC’17). USENIX Association, Berkeley, CA, USA, 1323–1338. http://dl.acm.org/citation.cfm?id=3241189.3241292
• Google. 2019. HTTPS encryption on the web – Google Transparency Report. https://transparencyreport.google.com/https/overview?hl=en. (Accessed on 03/08/2019).
• Nadia Heninger, Zakir Durumeric, Eric Wustrow, and JAlex Halderman. 2012. Mining your Ps and Qs: Detection of widespread weak keys in network devices. In Presented as part of the 21st {USENIX} Security Symposium ({USENIX} Security 12). 205–220.
• Ralph Holz, Jens Hiller, Johanna Amann, Abbas Razaghpanah, Thomas Jost, Narseo Vallina-Rodriguez, and Oliver Hohlfeld. 2020. Tracking the deployment of TLS 1.3 on the Web: A story of experimentation and centralization. ACM SIGCOMM Computer Communication Review 50, 3 (2020), 3–15.
• Hang Hu and Gang Wang. 2018. End-to-end measurements of email spoofing attacks. In 27th {USENIX} Security Symposium ({USENIX} Security 18). 1095–1112.
• Daniel Kales, Olamide Omolola, and Sebastian Ramacher. 2019. Revisiting User Privacy for Certificate Transparency. In 2019 IEEE European Symposium on Security and Privacy (EuroS&P). IEEE, 432–447.
• Platon Kotzias, Abbas Razaghpanah, Johanna Amann, KennethG. Paterson, Narseo Vallina-Rodriguez, and Juan Caballero. 2018. Coming of Age: A Longitudinal Study of TLS Deployment. In Proceedings of the Internet Measurement Conference 2018 (Boston, MA, USA) (IMC ’18). ACM, New York, NY, USA, 415–428. https://doi.org/10.1145/3278532.3278568
• Deepak Kumar, Zhengping Wang, Matthew Hyder, Joseph Dickinson, Gabrielle Beck, David Adrian, Joshua Mason, Zakir Durumeric, JAlex Halderman, and Michael Bailey. 2018. Tracking certificate misissuance in the wild. In 2018 IEEE Symposium on Security and Privacy (SP). IEEE, 785–798.
• Ben Laurie, Adam Langley, and Emilia Kasper. 2013. Certificate transparency.
• Bingyu Li, Jingqiang Lin, Fengjun Li, Qiongxiao Wang, Qi Li, Jiwu Jing, and Congli Wang. 2019. Certificate transparency in the wild: Exploring the reliability of monitors. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security. 2505–2520.
• Zhihao Li, Dave Levin, Neil Spring, and Bobby Bhattacharjee. 2018. Internet anycast: performance, problems, & potential. In Proceedings of the 2018 Conference of the ACM Special Interest Group on Data Communication. ACM, 59–73.
• Yabing Liu, Will Tome, Liang Zhang, David Choffnes, Dave Levin, Bruce Maggs, Alan Mislove, Aaron Schulman, and Christo Wilson. 2015. An end-to-end measurement of certificate revocation in the web's PKI. In Proceedings of the 2015 Internet Measurement Conference. 183–196.
• Robert Merget, Marcus Brinkmann, Nimrod Aviram, Juraj Somorovsky, Johannes Mittmann, and Jörg Schwenk. 2021. Raccoon Attack: Finding and Exploiting Most-Significant-Bit-Oracles in TLS-DH(E). In Proceedings of the 30th USENIX Conference on Security Symposium (Vancouver, BC, Canada) (SEC’21). USENIX Association.
• Bodo Möller and Adam Langley. 2015. TLS fallback Signaling Cipher Suite Value (SCSV) for preventing protocol downgrade attacks.
• David Naylor, Alessandro Finamore, Ilias Leontiadis, Yan Grunenberger, Marco Mellia, Maurizio Munafò, Konstantina Papagiannaki, and Peter Steenkiste. 2014. The Cost of the S in HTTPS. In Proceedings of the 10th ACM International on Conference on emerging Networking Experiments and Technologies. ACM, 133–140.
• Yngve Pettersen. 2013. The transport layer security (TLS) multiple certificate status request extension.
• Abbas Razaghpanah, ArianAkhavan Niaki, Narseo Vallina-Rodriguez, Srikanth Sundaresan, Johanna Amann, and Phillipa Gill. 2017. Studying TLS Usage in Android Apps. In Proceedings of the 13th International Conference on Emerging Networking EXperiments and Technologies (Incheon, Republic of Korea) (CoNEXT ’17). ACM, New York, NY, USA, 350–362. https://doi.org/10.1145/3143361.3143400
• E. Rescorla. 2000. HTTP over TLS. https://tools.ietf.org/html/rfc2818
• Eric Rescorla. 2018. The transport layer security (TLS) protocol version 1.3.
• Richard Roberts and Dave Levin. 2019. When Certificate Transparency Is Too Transparent: Analyzing Information Leakage in HTTPS Domain Names. In Proceedings of the 18th ACM Workshop on Privacy in the Electronic Society. 87–92.
• Quirin Scheitle, Oliver Gasser, Theodor Nolte, Johanna Amann, Lexi Brent, Georg Carle, Ralph Holz, ThomasC Schmidt, and Matthias Wählisch. 2018. The rise of certificate transparency and its implications on the Internet ecosystem. In Proceedings of the Internet Measurement Conference 2018. 343–349.
• Emily Stark, Ryan Sleevi, Rijad Muminovic, Devon O'Brien, Eran Messeri, AdriennePorter Felt, Brendan McMillion, and Parisa Tabriz. 2019. Does certificate transparency break the web? Measuring adoption and error rate. In 2019 IEEE Symposium on Security and Privacy (SP). IEEE, 211–226.
• Louis Waked, Mohammad Mannan, and Amr Youssef. 2018. To Intercept or Not to Intercept: Analyzing TLS Interception in Network Appliances. In Proceedings of the 2018 on Asia Conference on Computer and Communications Security. ACM, 399–412.
• Scott Yilek, Eric Rescorla, Hovav Shacham, Brandon Enright, and Stefan Savage. 2009. When private keys are public: Results from the 2008 Debian OpenSSL vulnerability. In Proceedings of the 9th ACM SIGCOMM Conference on Internet Measurement. 15–27.
• Liang Zhang, David Choffnes, Dave Levin, Tudor Dumitraş, Alan Mislove, Aaron Schulman, and Christo Wilson. 2014. Analysis of SSL certificate reissues and revocations in the wake of Heartbleed. In Proceedings of the 2014 Conference on Internet Measurement Conference. 489–502.