DOCSLIB.ORG

Measuring HTTP/3: Adoption and Performance

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Measuring HTTP/3: Adoption and Performance Measuring HTTP/3: Adoption and Performance Martino Trevisany, Danilo Giordanoy, Idilio Drago z, Ali Safari Khatouni? yPolitecnico di Torino, zUniversity of Turin, ?Shopify [email protected], unito.it, shopify.comg Abstract—The third version of the Hypertext Transfer real state of deployment nor the performance benefits of Protocol (HTTP) is currently in its final standardization phase HTTP/3 have been measured yet. by the IETF. Besides better security and increased flexibility, In this paper, we fill this gap by running a large-scale it promises benefits in terms of performance. HTTP/3 adopts a more efficient header compression schema and replaces TCP measurement study. Firstly, we collect data to understand to with QUIC, a transport protocol carried over UDP, originally what extent the web ecosystem already adopted HTTP/3. proposed by Google and currently under standardization too. Secondly, we run an experimental campaign to measure Although HTTP/3 early implementations already exist and the benefits introduced by HTTP/3 on the users’ Quality some websites announce its support, it has been subject to of Experience (QoE), and how HTTP/3 helps in different few studies. In this work, we provide a first measurement study on network conditions. HTTP/3. We testify how, during 2020, it has been adopted Using the open-source HTTPArchive Dataset, we find by some of the leading Internet companies such as Google, thousands of websites supporting HTTP/3, most of them Facebook and Cloudflare. We run a large-scale measurement owned by a handful of Internet hyper-giants, i.e., Facebook, campaign toward thousands of websites adopting HTTP/3, Google, and Cloudflare. We automatically visit the HTTP/3 aiming at understanding to what extent it achieves better performance than HTTP/2. We find that adopting websites websites under diverse network conditions to measure the often host most web page objects on third-party servers, which performance benefits in terms of QoE-related metrics. We support only HTTP/2 or even HTTP/1.1. Our experiments visit 14 707 websites while emulating artificial latency, show that HTTP/3 provides sizable benefits only in scenarios packet loss, and limiting the bandwidth. In total, we with high latency or very poor bandwidth. Despite the run 735 350 visits over a period of one month. We find adoption of QUIC, we do not find benefits in case of high packet loss, but we observe large diversity across website that HTTP/3 benefits emerge only on particular network providers’ infrastructures. conditions and strongly differ across website providers. Our Index Terms—HTTP/3 ; Performance ; Measurements key findings are the following: • Google, Facebook and Cloudflare are the early I. INTRODUCTION adopters of HTTP/3, representing almost the totality The Hypertext Transfer Protocol (HTTP) is the king of of currently HTTP/3 enabled websites. web protocols and is used to access a plethora of services • For most of them, the majority of web page objects available on the Internet, from websites to social networks are still hosted on non-HTTP/3 third-party servers. and collaborative platforms. HTTP was born in the early • We observe sizable performance benefits only in sce- 90s, and its first version 1.1 was standardized in 1997 [1]. narios with high latency or poor bandwidth. For more than a decade, this version remained unchanged. • The performance speed-up largely depends on the Only in 2014, HTTP/2 [2] was proposed, with substantial infrastructure hosting the website. changes in the framing mechanisms. HTTP/3 is the third • Websites requiring few connections to load are those version of HTTP and is currently in the final standard- benefiting the most. ization phase at the IETF [3]. It promises performance The remainder of the paper is organized as follows: benefits and security improvements compared to version Section II describes HTTP/3 and illustrates related work. arXiv:2102.12358v1 [cs.NI] 24 Feb 2021 2. As a major change, HTTP/3 replaces TCP as transport Section III presents the datasets we use and how we collect layer in favor of QUIC, a UDP-based protocol originally them, and Section IV illustrates our results on HTTP/3 proposed by Google and currently being standardized by adoption and performance. Finally, Section V states the the IETF [4]. Furthermore, it introduces a more effective limitations of our measurements and poses the basis for header compression mechanism and exploits TLS 1.3 [5] future work, while Section VI concludes the paper. or higher to improve the level of security. HTTP/3 is expected to supplant HTTP/2 in the next II. BACKGROUND years, and some of the leading Internet companies already A. HTTP/3 announced its support during 2020 (e.g., the CloudFlare 1 2 The HTTP/3 protocol is the third version of the well- CDN and Facebook ). However, currently neither the known Hypertext Transfer Protocol, born in the 90s to transfer multimedia content and hyper-textual documents 1https://blog.cloudflare.com/http3-the-past-present-and-future/ 2https://engineering.fb.com/2020/10/21/networking-traffic/ over the nascent Internet. With its version 1.1, it has how-facebook-is-bringing-quic-to-billions/ been the king of web protocols for more than 20 years, TABLE I: Description of the employed datasets. HTTP/1.1 HTTP/2 HTTP/3 Dataset Visits Goal TLS TLS QUIC HTTPArchive 53 107 185 (optional) (+TLS 1.3) HTTP/3 Adoption BrowserTime 735 350 HTTP/3 Performance TCP TCP UDP IP Google firstly proposed QUIC in 2012 and, as such, has been the subject of many studies. For example, Wolsing et Fig. 1: Protocol stack for different HTTP versions. al. [12] show that QUIC still outperforms TCP thanks to the fast connection setup. Manzoor et al. [13] show how QUIC performs worse than TCP in Wireless Mesh Networks. superseded only by its second version HTTP/2 in 2014. Wolsing et al. [14] found that QUIC reduces the overall HTTP/2 implemented several novel features, especially page retrieval time compared with standard HTTP. Kakhi et to improve how the data is framed and transported. It al. [15] run a large-scale measurement campaign on QUIC, promised to make the web faster even if its benefits have finding that it outperforms TCP in most cases. However, not universally accepted [6], [7]. these works target older Google’s QUIC versions, while the HTTP/3 is the third version of HTTP. It is currently current standard proposed at the IETF has made significant in the final standardization phase, reaching the 34th draft progress [16]. Moreover, they focus uniquely on QUIC as version [3] and making it stable and usable for real de- the transport layer, neglecting the improvement introduced ployments. The main improvements from version 2 include in HTTP/3 and TLS 1.3, that we aim at measuring in this more efficient header compression, advanced security fea- work. tures based on TLS 1.3, and, especially, the use of QUIC at the transport layer. The resulting protocol stack is thus III. DATA COLLECTION heavily modified, as we show in Figure 1. QUIC, initially We rely on two datasets to study (i) the adoption developed by Google, is a transport protocol based on UDP of HTTP/3 and (ii) its performance on diverse network and is currently in the standardization phase too [4]. QUIC conditions. We summarize them in Table I. revisits TCP, moving congestion control in user space and allowing faster handshakes. Moreover, it solves the long- A. HTTPArchive standing issue of head-of-line blocking, allowing multiple We study the adoption of HTTP/3 using the independent streams within the same connection. Indeed, HTTPArchive, an open dataset available online.3 The QUIC allows independent retransmission for sub-streams dataset contains metadata coming from visits to a list and decouples it from congestion control. This operation of more than 5 M URLs provided by the Chrome User is expected to improve users’ QoE with faster website Experience Report.4. The list of URL is built using the responsiveness, especially in scenarios with poor network navigation data of real Chrome users and contains a conditions. HTTP/3 also mandates the use TLS 1.3 [5], representative view of the most popular website and web directly incorporated at the QUIC layer. Besides the dep- services accessed worldwide.5 Each month, all URLs are recation of older cipher suites, it allows 1-RTT handshakes visited using the Google Chrome browser from a US data and 0-RTT resumption, further reducing session setup time. center, and the resulting navigation data is made public. For each visit, the dataset contains information about the B. Related Work page performance and characteristics as well as details on all the HTTP transactions in the HAR format6, including Given its recent conception, few works already targeted request and response headers. HTTP/3. Saif et al. [8] run experiments controlling both Fundamental for our analyses, the details of HTTP client and server accessing a single web page. They study responses indicate the eventual Alt-Svc header, which the effect of delay, packet loss and throughput but do not is used by servers to announce support to HTTP/3. By measure any major impact on performance. In contrast setting the Alt-Svc header, the server has the possibility to them, we run a large-scale measurement campaign, to inform the client to make subsequent connections using controlling only the client and targeting thousands of HTTP/3 and may specify the support to specific draft HTTP/3 websites residing on their original servers. Marx et versions (e.g., 27 or 29). al. [9] compare 15 HTTP/3 implementations, finding a We download the HTTPArchive dataset starting from large heterogeneity in how congestion control, prioritiza- November 2019, when we observe the first websites offer- tion and packetization work.
Load more

Recommended publications
  • Is QUIC a Better Choice Than TCP in the 5G Core Network Service Based Architecture?
    DEGREE PROJECT IN INFORMATION AND COMMUNICATION TECHNOLOGY, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2020 Is QUIC a Better Choice than TCP in the 5G Core Network Service Based Architecture? PETHRUS GÄRDBORN KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Is QUIC a Better Choice than TCP in the 5G Core Network Service Based Architecture? PETHRUS GÄRDBORN Master in Communication Systems Date: November 22, 2020 Supervisor at KTH: Marco Chiesa Supervisor at Ericsson: Zaheduzzaman Sarker Examiner: Peter Sjödin School of Electrical Engineering and Computer Science Host company: Ericsson AB Swedish title: Är QUIC ett bättre val än TCP i 5G Core Network Service Based Architecture? iii Abstract The development of the 5G Cellular Network required a new 5G Core Network and has put higher requirements on its protocol stack. For decades, TCP has been the transport protocol of choice on the Internet. In recent years, major Internet players such as Google, Facebook and CloudFlare have opted to use the new QUIC transport protocol. The design assumptions of the Internet (best-effort delivery) differs from those of the Core Network. The aim of this study is to investigate whether QUIC’s benefits on the Internet will translate to the 5G Core Network Service Based Architecture. A testbed was set up to emulate traffic patterns between Network Functions. The results show that QUIC reduces average request latency to half of that of TCP, for a majority of cases, and doubles the throughput even under optimal network conditions with no packet loss and low (20 ms) RTT. Additionally, by measuring request start and end times “on the wire”, without taking into account QUIC’s shorter connection establishment, we believe the results indicate QUIC’s suitability also under the long-lived (standing) connection model.
    [Show full text]
  • Let's Encrypt: 30,229 Jan, 2018 | Let's Encrypt: 18,326 Jan, 2016 | Let's Encrypt: 330 Feb, 2017 | Let's Encrypt: 8,199
    Let’s Encrypt: An Automated Certificate Authority to Encrypt the Entire Web Josh Aas∗ Richard Barnes∗ Benton Case Let’s Encrypt Cisco Stanford University Zakir Durumeric Peter Eckersley∗ Alan Flores-López Stanford University Electronic Frontier Foundation Stanford University J. Alex Halderman∗† Jacob Hoffman-Andrews∗ James Kasten∗ University of Michigan Electronic Frontier Foundation University of Michigan Eric Rescorla∗ Seth Schoen∗ Brad Warren∗ Mozilla Electronic Frontier Foundation Electronic Frontier Foundation ABSTRACT 1 INTRODUCTION Let’s Encrypt is a free, open, and automated HTTPS certificate au- HTTPS [78] is the cryptographic foundation of the Web, providing thority (CA) created to advance HTTPS adoption to the entire Web. an encrypted and authenticated form of HTTP over the TLS trans- Since its launch in late 2015, Let’s Encrypt has grown to become the port [79]. When HTTPS was introduced by Netscape twenty-five world’s largest HTTPS CA, accounting for more currently valid cer- years ago [51], the primary use cases were protecting financial tificates than all other browser-trusted CAs combined. By January transactions and login credentials, but users today face a growing 2019, it had issued over 538 million certificates for 223 million do- range of threats from hostile networks—including mass surveil- main names. We describe how we built Let’s Encrypt, including the lance and censorship by governments [99, 106], consumer profiling architecture of the CA software system (Boulder) and the structure and ad injection by ISPs [30, 95], and insertion of malicious code of the organization that operates it (ISRG), and we discuss lessons by network devices [68]—which make HTTPS important for prac- learned from the experience.
    [Show full text]
  • Analysis of QUIC Session Establishment and Its Implementations Eva Gagliardi, Olivier Levillain
    Analysis of QUIC session establishment and its implementations Eva Gagliardi, Olivier Levillain To cite this version: Eva Gagliardi, Olivier Levillain. Analysis of QUIC session establishment and its implementations. 13th IFIP International Conference on Information Security Theory and Practice (WISTP), Dec 2019, Paris, France. pp.169-184, 10.1007/978-3-030-41702-4_11. hal-02468596 HAL Id: hal-02468596 https://hal.archives-ouvertes.fr/hal-02468596 Submitted on 5 Feb 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Analysis of QUIC Session Establishment and its Implementations Eva Gagliardi1 and Olivier Levillain2 1 French Ministry of the Armies, 2 T´el´ecomSudParis, Institut Polytechnique de Paris Abstract. In the recent years, the major web companies have been working to improve the user experience and to secure the communica- tions between their users and the services they provide. QUIC is such an initiative, and it is currently being designed by the IETF. In a nutshell, QUIC originally intended to merge features from TCP/SCTP, TLS 1.3 and HTTP/2 into one big protocol. The current specification proposes a more modular definition, where each feature (transport, cryptography, application, packet reemission) are defined in separate internet drafts.
    [Show full text]
  • Colorado College Is Hiring!
    Colorado College is hiring! Early Childhood Teacher (multiple positions available) - Children’s Center Under minimal supervision while in the classroom provide nurturing early care and educational experience to benefit the children and families of the CC Community. Design and implement age-appropriate individualized curriculum to foster growth and development socially, emotionally, physically and cognitively for each child. Be flexible, adaptive, reliable, and a confidential resource for families in an assigned classroom (infant, toddler or pre-school). Full position description: https://employment.coloradocollege.edu/postings/4697 OC (on call) Educational Assistant- Children’s Center Hours may vary Monday through Friday between 7:30 and 5:30 up to 1000 hours per fiscal year. Under general supervision, assists with providing on-site early childhood education and supervision for infants, toddlers and preschool children when teachers are sick and/or on vacation, teacher daily breaks, teacher daily planning times, daily kitchen duties, and working in the afterschool care program. Full position description: https://employment.coloradocollege.edu/postings/4607 Counselor (Occasional) Provide professional mental health services to the students of Colorado College. Positions Type: On Call Full position description: https://employment.coloradocollege.edu/postings/4746 Driver/Automotive Technician Performs maintenance and repair of college vehicles and maintenance equipment; drives fleet vehicles, including highway buses. Position Type: Full-time
    [Show full text]
  • How Can We Protect the Internet Against Surveillance?
    How can we protect the Internet against surveillance? Seven TODO items for users, web developers and protocol engineers Peter Eckersley [email protected] Okay, so everyone is spying on the Internet It's not just the NSA... Lots of governments are in this game! Not to mention the commerical malware industry These guys are fearsome, octopus-like adversaries Does this mean we should just give up? No. Reason 1: some people can't afford to give up Reason 2: there is a line we can hold vs. So, how do we get there? TODO #1 Users should maximise their own security Make sure your OS and browser are patched! Use encryption where you can! In your browser, install HTTPS Everywhere https://eff.org/https-everywhere For instant messaging, use OTR (easiest with Pidgin or Adium, but be aware of the exploit risk tradeoff) For confidential browsing, use the Tor Browser Bundle Other tools to consider: TextSecure for SMS PGP for email (UX is terrible!) SpiderOak etc for cloud storage Lots of new things in the pipeline TODO #2 Run an open wireless network! openwireless.org How to do this securely right now? Chain your WPA2 network on a router below your open one. TODO #3 Site operators... Deploy SSL/TLS/HTTPS DEPLOY IT CORRECTLY! This, miserably, is a lot harder than it should be TLS/SSL Authentication Apparently, ~52 countries These are usually specialist, narrowly targetted attacks (but that's several entire other talks... we're working on making HTTPS more secure, easier and saner!) In the mean time, here's what you need A valid certificate HTTPS by default Secure cookies No “mixed content” Perfect Forward Secrecy A well-tuned configuration How do I make HTTPS the default? Firefox and Chrome: redirect, set the HSTS header Safari and IE: sorry, you can't (!!!) What's a secure cookie? Go and check your site right now..
    [Show full text]
  • Product End User License Agreement
    End User License Agreement If you have another valid, signed agreement with Licensor or a Licensor authorized reseller which applies to the specific products or services you are downloading, accessing, or otherwise receiving, that other agreement controls; otherwise, by using, downloading, installing, copying, or accessing Software, Maintenance, or Consulting Services, or by clicking on "I accept" on or adjacent to the screen where these Master Terms may be displayed, you hereby agree to be bound by and accept these Master Terms. These Master Terms also apply to any Maintenance or Consulting Services you later acquire from Licensor relating to the Software. You may place orders under these Master Terms by submitting separate Order Form(s). Capitalized terms used in the Agreement and not otherwise defined herein are defined at https://terms.tibco.com/posts/845635-definitions. 1. Applicability. These Master Terms represent one component of the Agreement for Licensor's products, services, and partner programs and apply to the commercial arrangements between Licensor and Customer (or Partner) listed below. Additional terms referenced below shall apply. a. Products: i. Subscription, Perpetual, or Term license Software ii. Cloud Service (Subject to the Cloud Service Terms found at https://terms.tibco.com/?types%5B%5D=post&feed=recent#cloud-services) iii. Equipment (Subject to the Equipment Terms found at https://terms.tibco.com/?types%5B%5D=post&feed=recent#equipment-terms) b. Services: i. Maintenance (Subject to the Maintenance terms found at https://terms.tibco.com/?types%5B%5D=post&feed=recent#october-maintenance) ii. Consulting Services (Subject to the Consulting terms found at https://terms.tibco.com/?types%5B%5D=post&feed=recent#supplemental-terms) iii.
    [Show full text]
  • Learning HTTP 2.Pdf
    L e a r n i n g H T T P/2 A PRACTICAL GUIDE FOR BEGINNERS Stephen Ludin & Javier Garza Learning HTTP/2 A Practical Guide for Beginners Stephen Ludin and Javier Garza Beijing Boston Farnham Sebastopol Tokyo Learning HTTP/2 by Stephen Ludin and Javier Garza Copyright © 2017 Stephen Ludin, Javier Garza. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com/safari). For more information, contact our corporate/insti‐ tutional sales department: 800-998-9938 or [email protected]. Acquisitions Editor: Brian Anderson Indexer: Wendy Catalano Editors: Virginia Wilson and Dawn Schanafelt Interior Designer: David Futato Production Editor: Shiny Kalapurakkel Cover Designer: Karen Montgomery Copyeditor: Kim Cofer Illustrator: Rebecca Demarest Proofreader: Sonia Saruba June 2017: First Edition Revision History for the First Edition 2017-05-14: First Release 2017-10-27: Second Release See http://oreilly.com/catalog/errata.csp?isbn=9781491962442 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Learning HTTP/2, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. While the publisher and the authors have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the authors disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work.
    [Show full text]
  • Recent Progress on the QUIC Protocol
    Recent Progress on the QUIC Protocol Mehdi Yosofie, Benedikt Jaeger∗ ∗Chair of Network Architectures and Services, Department of Informatics Technical University of Munich, Germany Email: mehdi.yosofi[email protected], [email protected] Abstract—Internet services increase rapidly and much data Task Force (IETF) and is on standardization progress. The is sent back and forth inside it. The most widely used IETF is an Internet committee which deals with Internet network infrastructure is the HTTPS stack which has several technologies and publishes Internet standards. Currently, disadvantages. To reduce handshake latency in network QUIC is being standardized, and it remains to be seen, traffic, Google’s researchers built a new multi-layer transfer how it will influence the Internet traffic afterwards. protocol called Quick UDP Internet Connections (QUIC). It The rest of this paper is structured as follows: Sec- is implemented and tested on Google’s servers and clients tion 2 presents background information about the estab- and proves its suitability in everyday Internet traffic. QUIC’s lished TCP/TLS stack needed for the problem analysis. new paradigm integrates the security and transport layer Section 3 explicitly investigates some QUIC features like of the widely used HTTPS stack into one and violates the stream-multiplexing, security, loss recovery, congestion OSI model. QUIC takes advantages of existing protocols and control, flow control, QUIC’s handshake, its data format, integrates them in a new transport protocol providing less and the Multipath extension. They each rely on current latency, more data flow on wire, and better deployability. IETF standardization work, and are compared to the tra- QUIC removes head-of-line blocking and provides a plug- ditional TCP/TLS stack.
    [Show full text]
  • Caddy Et Traefik : Des Concurrents Sérieux À Nginx Et Haproxy ? Mickaël Masquelin | Quelques Mots Sur Le Laboratoire …
    Caddy et Traefik : des concurrents sérieux à nginx et HAProxy ? Mickaël Masquelin | Quelques mots sur le laboratoire … • Unité Mixte de Recherche • 5 tutelles : • Le CNRS • L’Université de Lille • L’Université de Polytechnique HdF • L’Ecole Centrale • Le groupe YNCREA – ISEN • 6 sites géographiquement distants • Environ 500 personnes (chercheurs, ingénieurs, administratifs, étudiants, …) Mickaël Masquelin – IEMN 10/03/2018 2 Journée thématique “Retours d’expériences” Les objectifs Mickaël Masquelin – IEMN 10/03/2018 3 Journée thématique “Retours d’expériences” RETOUR D’EXPERIENCE SUR CES NOUVELLES APPLIS WEB QUI FACILITENT LA VIE L’idée est de faire un retour d’expérience sur ces nouvelles applications web qui pointent le bout de leur nez et qui viennent révolutionner un peu le paysage informatique … Les objectifs Mickaël Masquelin – IEMN 10/03/2018 4 Journée thématique “Retours d’expériences” RETOUR D’EXPERIENCE SUR CES NOUVELLES APPLIS WEB QUI FACILITENT LA VIE L’idée est de faire un retour d’expérience sur ces nouvelles applications web qui pointent le bout de leur nez et qui viennent révolutionner un peu le paysage informatique … ESSAYER DE VOUS DONNER QUELQUES PISTES J’espère que vous repartirez de la journée thématique avec pleins d’idées, des envies de changer la manière dont vous travaillez, dont vous déployez vos applications ou vos Les objectifs services dans vos contextes respectifs … Mickaël Masquelin – IEMN 10/03/2018 5 Journée thématique “Retours d’expériences” RETOUR D’EXPERIENCE SUR CES NOUVELLES APPLIS WEB QUI FACILITENT
    [Show full text]
  • Introduction
    HTTP Request Smuggling in 2020 – New Variants, New Defenses and New Challenges Amit Klein SafeBreach Labs Introduction HTTP Request Smuggling (AKA HTTP Desyncing) is an attack technique that exploits different interpretations of a stream of non-standard HTTP requests among various HTTP devices between the client (attacker) and the server (including the server itself). Specifically, the attacker manipulates the way various HTTP devices split the stream into individual HTTP requests. By doing this, the attacker can “smuggle” a malicious HTTP request through an HTTP device to the server abusing the discrepancy in the interpretation of the stream of requests and desyncing between the server’s view of the HTTP request (and response) stream and the intermediary HTTP device’s view of these streams. In this way, for example, the malicious HTTP request can be "smuggled" as a part of the previous HTTP request. HTTP Request Smuggling was invented in 2005, and recently, additional research cropped up. This research field is still not fully explored, especially when considering open source defense systems such as mod_security’s community rule-set (CRS). These HTTP Request Smuggling defenses are rudimentary and not always effective. My Contribution My contribution is three-fold. I explore new attacks and defense mechanisms, and I provide some “challenges”. 1. New attacks: I provide some new HTTP Request Smuggling variants and show how they work against various proxy-server (or proxy-proxy) combinations. I also found a bypass for mod_security CRS (assuming HTTP Request Smuggling is possible without it). An attack demonstration script implementing my payloads is available in SafeBreach Labs’ GitHub repository (https://github.com/SafeBreach-Labs/HRS).
    [Show full text]
  • QUIC Record Layer
    A Security Model and Fully Verified Implementation for the IETF QUIC Record Layer Antoine Delignat-Lavaud∗, Cédric Fournet∗, Bryan Parnoy, Jonathan Protzenko∗, Tahina Ramananandro∗, Jay Bosamiyay, Joseph Lallemandz, Itsaka Rakotonirinaz, Yi Zhouy ∗Microsoft Research yCarnegie Mellon University zINRIA Nancy Grand-Est, LORIA Abstract—Drawing on earlier protocol-verification work, we investigate the security of the QUIC record layer, as standardized Application Application by the IETF in draft version 30. This version features major HTTP/2 HTTP/3 differences compared to Google’s original protocol and early IETF drafts. It serves as a useful test case for our verification TLS QUIC methodology and toolchain, while also, hopefully, drawing atten- tion to a little studied yet crucially important emerging standard. TCP UDP We model QUIC packet and header encryption, which uses IP IP a custom construction for privacy. To capture its goals, we propose a security definition for authenticated encryption with Fig. 1: Modularity of current networking stack vs. QUIC semi-implicit nonces. We show that QUIC uses an instance of a generic construction parameterized by a standard AEAD-secure scheme and a PRF-secure cipher. We formalize and verify the it is possible to combine both features in a single message, security of this construction in F?. The proof uncovers interesting saving a full network round-trip. limitations of nonce confidentiality, due to the malleability of short From a security standpoint, a fully-integrated secure trans- headers and the ability to choose the number of least significant port protocol offers the potential for a single, clean security bits included in the packet counter.
    [Show full text]
  • Quick UDP Internet Connections (QUIC)
    Quick UDP Internet Connections (QUIC) Simone Ferlin [email protected] draft-ietf-quic-transport-latest https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html A First Look at QUIC in the Wild, PAM 2018 https://arxiv.org/pdf/1801.05168.pdf Taking a Long Look at QUIC, ACM IMC 2017 https://mislove.org/publications/QUIC-IMC.pdf References for this Multipath QUIC, ACM CoNEXT 2017 presentation https://multipath-quic.org/conext17-deconinck.pdf The QUIC Transport Protocol: Design and Internet-Scale Deployment, ACM SIGCOMM 2017 • https://static.googleusercontent.com/media/research.google.co m/en//pubs/archive/46403.pdf • https://conferences.sigcomm.org/sigcomm/2017/files/program/t s-5-1-QUIC.pdf Why QUIC? • Improve performance and latency of web applications • Most web applications running with HTTP and TCP and TLS (HTTPS). • Keep the idea of flow and congestion control from TCP. • It provides at least a connection-oriented, reliable and in-order byte stream. • It enables stream multiplexing (similar to HTTP/2) to optimize for latency. • Improve security with end-to-end encryption by default and full encryption. • Still with TLS/SSL, but avoiding TLS’s handshake delay inflation. • Overcome slow adoption with code in user-space • No full system updates needed (code inside your browser). • The transport layer with only UDP and TCP is difficult to update. • Overcome slow updates and ubiquitous devices, i.e. middleboxes • TCP is often affected and it became incredibly difficult to propose extensions: Is it Still Possible to Extend TCP?, M. Honda et al., ACM IMC 2011. Where is QUIC? User-space Kernel-space Where is QUIC? User-space Kernel-space Some QUICk remarks • QUIC’s first implementation appeared around 2012 in Chromium • Standardisation group established in 2016 • QUIC-WG: https://datatracker.ietf.org/wg/quic).
    [Show full text]