@misc{HolzHillerAmannetal., author = {Holz, Ralph and Hiller, Jens and Amann, Johanna and Razaghpanah, Abbas and Jost, Thomas and Vallina-Rodriguez, Narseo and Hohlfeld, Oliver}, title = {Tracking the deployment of TLS 1.3 on the Web: A story of experimentation and centralization}, series = {ACM SIGCOMM Computer Communication Review}, volume = {50}, journal = {ACM SIGCOMM Computer Communication Review}, number = {3}, issn = {0146-4833}, doi = {10.1145/3411740.3411742}, pages = {12}, language = {en} } @misc{HillerAmannHohlfeld, author = {Hiller, Jens and Amann, Johanna and Hohlfeld, Oliver}, title = {The Boon and Bane of Cross-Signing: Shedding Light on a Common Practice in Public Key Infrastructures}, series = {CCS '20: Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security, October 2020}, journal = {CCS '20: Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security, October 2020}, doi = {10.1145/3372297.3423345}, pages = {1289 -- 1306}, abstract = {Public Key Infrastructures (PKIs) with their trusted Certificate Authorities (CAs) provide the trust backbone for the Internet: CAs sign certificates which prove the identity of servers, applications, or users. To be trusted by operating systems and browsers, a CA has to undergo lengthy and costly validation processes. Alternatively, trusted CAs can cross-sign other CAs to extend their trust to them. In this paper, we systematically analyze the present and past state of cross-signing in the Web PKI. Our dataset (derived from passive TLS monitors and public CT logs) encompasses more than 7 years and 225 million certificates with 9.3 billion trust paths. We show benefits and risks of cross-signing. We discuss the difficulty of revoking trusted CA certificates where, worrisome, cross-signing can result in valid trust paths to remain after revocation; a problem for non-browser software that often blindly trusts all CA certificates and ignores revocations. However, cross-signing also enables fast bootstrapping of new CAs, e.g., Let's Encrypt, and achieves a non-disruptive user experience by providing backward compatibility. In this paper, we propose new rules and guidance for cross-signing to preserve its positive potential while mitigating its risks.}, language = {en} } @misc{HillerHenzeZimmermannetal., author = {Hiller, Jens and Henze, Martin and Zimmermann, Torsten and Hohlfeld, Oliver and Wehrle, Klaus}, title = {The Case for Session Sharing: Relieving Clients from TLS Handshake Overheads}, series = {2019 IEEE 44th LCN Symposium on Emerging Topics in Networking (LCN Symposium), 14-17 Oct. 2019, Osnabr{\"u}ck, Germany}, journal = {2019 IEEE 44th LCN Symposium on Emerging Topics in Networking (LCN Symposium), 14-17 Oct. 2019, Osnabr{\"u}ck, Germany}, publisher = {IEEE}, isbn = {978-1-7281-2561-9}, doi = {10.1109/LCNSymposium47956.2019.9000667}, pages = {9}, abstract = {In recent years, the amount of traffic protected with Transport Layer Security (TLS) has significantly increased and new protocols such as HTTP/2 and QUIC further foster this emerging trend. However, protecting traffic with TLS has significant impacts on network entities. While the restrictions for middleboxes have been extensively studied, addressing the impact of TLS on clients and servers has been mostly neglected so far. Especially mobile clients in emerging 5G and IoT deployments suffer from significantly increased latency, traffic, and energy overheads when protecting traffic with TLS. In this paper, we address this emerging topic by thoroughly analyzing the impact of TLS on clients and servers and derive opportunities for significantly decreasing latency of TLS communication and downsizing TLS management traffic, thereby also reducing TLSinduced server load. We propose a protocol compatible redesign of TLS session management to use these opportunities and showcase their potential based on mobile device traffic and mobile web-browsing traces. These show promising potentials for latency improvements by up to 25.8\% and energy savings of up to 26.3\%.}, language = {en} }