{"id":4951,"date":"2018-11-20T18:55:10","date_gmt":"2018-11-20T17:55:10","guid":{"rendered":"https:\/\/monodes.com\/predaelli\/?p=4951"},"modified":"2018-11-20T10:56:30","modified_gmt":"2018-11-20T09:56:30","slug":"errata-security-some-notes-about-http-3","status":"publish","type":"post","link":"https:\/\/monodes.com\/predaelli\/2018\/11\/20\/errata-security-some-notes-about-http-3\/","title":{"rendered":"Errata Security: Some notes about HTTP\/3"},"content":{"rendered":"<h1><em><a href=\"https:\/\/blog.erratasec.com\/2018\/11\/some-notes-about-http3.html\">Errata Security: Some notes about HTTP\/3<\/a><\/em><\/h1>\n<p><!--more--><!--nextpage--><\/p>\n<blockquote>\n<h3 class=\"post-title entry-title\">Some notes about HTTP\/3<\/h3>\n<div id=\"post-body-2929434204158904685\" class=\"post-body entry-content\">HTTP\/3 is going to be standardized. As an old protocol guy, I thought I&#8217;d write up some comments.Google (pbuh) has both the most popular web browser (Chrome) and the two most popular websites (#1 Google.com #2 Youtube.com). Therefore, they are in control of future web protocol development. Their first upgrade they called SPDY (pronounced &#8220;speedy&#8221;), which was eventually standardized as the second version of HTTP, or HTTP\/2. Their second upgrade they called QUIC (pronounced &#8220;quick&#8221;), which is being standardized as HTTP\/3.<br \/>\n<a name=\"more\"><\/a><\/p>\n<p>SPDY (HTTP\/2) is already supported by the major web browser (Chrome, Firefox, Edge, Safari) and major web servers (Apache, Nginx, IIS, CloudFlare). Many of the most popular websites support it (even non-Google ones), though you are unlikely to ever see it on the wire (sniffing with Wireshark or tcpdump), because it&#8217;s always encrypted with SSL. While the standard allows for HTTP\/2 to run raw over TCP, all the implementations only use it over SSL.<\/p>\n<p>There is a good lesson here about <b>standards<\/b>. Outside the Internet, standards are often <i>de jure<\/i>, run by government, driven by getting all major stakeholders in a room and hashing it out, then using rules to force people to adopt it. On the Internet, people implement things first, and then if others like it, they&#8217;ll start using it, too. Standards are often\u00a0<i>de facto<\/i>, with RFCs being written for what is already working well on the Internet, documenting what people are already using. SPDY was adopted by browsers\/servers not because it was standardized, but because the major players simply started adding it. The same is happening with QUIC: the fact that it&#8217;s being standardized as HTTP\/3 is a reflection that it&#8217;s already being used, rather than some milestone that now that it&#8217;s standardized that people can start using it.<\/p>\n<p>QUIC is really more of a new version of TCP (TCP\/2???) than a new version of HTTP (HTTP\/3). It doesn&#8217;t really change what HTTP\/2 does so much as change how the transport works. Therefore, my comments below are focused on transport issues rather than HTTP issues.<\/p>\n<p>The major headline feature is faster connection setup and <b>latency<\/b>. TCP requires a number of packets being sent back-and-forth before the connection is established. SSL again requires a number of packets sent back-and-forth before encryption is established. If there is a lot of network delay, such as when people use satellite Internet with half-second ping times, it can take quite a long time for a connection to be established. By reducing round-trips, connections get setup faster, so that when you click on a link, the linked resource pops up immediately<\/p>\n<p>The next headline feature is <b>bandwidth<\/b>. There is always a bandwidth limitation between source and destination of a network connection, which is almost always due to congestion. Both sides need to discover this speed so that they can send packets at just the right rate. Sending packets too fast, so that they&#8217;ll get dropped, causes even more congestion for others without improving transfer rate. Sending packets too slowly means unoptimal use of the network.<\/p>\n<p>How HTTP traditionally does this is bad. Using a single TCP connection didn&#8217;t work for HTTP because interactions with websites require multiple things to be transferred simultaneously, so browsers opened multiple connections to the web server (<a href=\"https:\/\/twitter.com\/tunetheweb\/status\/1064422216262213633\">typically 6<\/a>). However, this breaks the bandwidth estimation, because each of your TCP connections is trying to do it independently as if the other connections don&#8217;t exist. SPDY addressed this by its <b>multiplexing<\/b>\u00a0feature that combined multiple interactions between browser\/server with a single bandwidth calculation.<\/p>\n<p>QUIC extends this multiplexing, making it even easier to handle multiple interactions between the browser\/server, without any one interaction blocking another, but with a common bandwidth estimation. This will make interactions smoother from a user&#8217;s perspective, while at the same time reduce congestion that routers experience.<\/p>\n<p>Now let&#8217;s talk <b>user-mode stacks<\/b>. The problem with TCP, especially on the server, is that TCP connections are handled by the operating system <i>kernel<\/i>, while the service itself runs in <i>usermode<\/i>. Moving things across the kernel\/usermode boundary causes performance issues. Tracking a large number of TCP connections causes scalability issues. Some people have tried putting the services into the kernel, to avoid the transitions, which is a bad because it destabilizes the operating system. My own solution, with the BlackICE IPS and masscan, was to use a <i>usermode driver<\/i>\u00a0for the hardware, getting packets from the network chip directly to the usermode process, bypassing the kernel (see PoC||GTFO #15), using my own custom TCP stack. This has become popular in recent years with the <i>DPDK<\/i>\u00a0kit.<\/p>\n<p>But moving from TCP to UDP can get you much the same performance without usermode drivers. Instead of calling the well-known <i>recv()<\/i>\u00a0function to receive a single packet at a time, you can call <i>recvmmsg()<\/i>\u00a0to receive a bunch of UDP packets at once. It&#8217;s still a kernel\/usermode transition, but one amortized across a hundred packets received at once, rather a transition per packet.<\/p>\n<p>In my own tests, you are limited to about 500,000 UDP packets\/second using the typical <i>recv()<\/i>\u00a0function, but with <i>recvmmsg()<\/i>\u00a0and some other optimizations (multicore using RSS), you can get to 5,000,000 UDP packets\/second on a low-end quad-core server. Since this scales well per core, moving to the beefy servers with 64 cores should improve things even further.<\/p>\n<p>BTW, &#8220;RSS&#8221; is a feature of network hardware that splits incoming packets into multiple receive queues. The biggest problem with multi-core scalability is whenever two CPU cores need to read\/modify the same thing at the same time, so sharing the same UDP queue of packets becomes the biggest bottleneck. Therefore, first Intel and then other Ethernet vendors added RSS giving each core it&#8217;s own non-shared packet queue. Linux and then other operating systems upgraded UDP to support multiple file descriptors for a single socket (SO_REUSEPORT) to handle the multiple queues. Now QUIC uses those advances allowing each core to manage it&#8217;s own stream of UDP packets without the scalability problems of sharing things with other CPU cores. I mention this because I personally had discussions with Intel hardware engineers about having multiple packet queues back in 2000. It&#8217;s a common problem and an obvious solution, and it&#8217;s been fun watching it progress over the last two decades until it appears on the top end as HTTP\/3. Without RSS in the network hardware, it&#8217;s unlikely QUIC would become a standard.<\/p>\n<p>Another cool solution in QUIC is <b>mobile <\/b>support. As you move around with your notebook computer to different WiFI networks, or move around with your mobile phone, your IP address can change. The operating system and protocols don&#8217;t gracefully close the old connections and open new ones. With QUIC, however, the identifier for a connection is not the traditional concept of a &#8220;socket&#8221; (the source\/destination port\/address protocol combination), but a 64-bit identifier assigned to the connection.<\/p>\n<p>This means that as you move around, you can continue with a constant stream uninterrupted from YouTube even as your IP address changes, or continue with a video phone call without it being dropped. Internet engineers have been struggling with &#8220;mobile IP&#8221; for decades, trying to come up with a workable solution. They&#8217;ve focused on the end-to-end principle of somehow keeping a constant IP address as you moved around, which isn&#8217;t a practical solution. It&#8217;s fun to see QUIC\/HTTP\/3 finally solve this, with a working solution in the real world.<\/p>\n<p>How can use use this new transport? For decades, the standard for network programing has been the <b>transport layer API<\/b>\u00a0known as &#8220;sockets&#8221;. That where you call functions like <i>recv()<\/i>\u00a0to receive packets in your code. With QUIC\/HTTP\/3, we no longer have an operating-system transport-layer API. Instead, it&#8217;s a higher layer feature that you use in something like the <i>go<\/i>\u00a0programming language, or using Lua in the OpenResty nginx web server.<\/p>\n<p>I mention this because one of the things that&#8217;s missing from your education about the OSI Model is that it originally envisioned everyone writing to application layer (7) APIs instead of transport layer (4) APIs. There was supposed to be things like <i>application service elements<\/i>\u00a0that would handling things like file transfer and messaging in a standard way for different applications. I think people are increasingly moving to that model, especially driven by Google with <i>go<\/i>, <i>QUIC<\/i>, <i>protobufs<\/i>, and so on.<\/p>\n<p>I mention this because of the contrast between Google and Microsoft. Microsoft owns a popular operating system, so it&#8217;s innovations are driven by what it can do within that operating system. Google&#8217;s innovations are driven by what it can put on top of the operating system. Then there is Facebook and Amazon themselves which must innovate on top of (or outside of) the stack that Google provides them. The top 5 corporations in the world are, in order, Apple-Google-Microsoft-Amazon-Facebook, so where each one drives innovation is important.<\/p>\n<p><b>Conclusion<\/b><\/p>\n<p>When TCP was created in the 1970s, it was sublime. It handled things, like congestion, vastly better than competing protocols. For all that people claim IPv4 didn&#8217;t anticipate things like having more than 4-billion addresses, it anticipated the modern Internet vastly better than competing designs throughout the 70s and 80s. The upgrade from IPv4 to IPv6 largely maintains what makes IP great. The upgrade from TCP to QUIC is similarly based on what makes TCP great, but extending it to modern needs. It&#8217;s actually surprising TCP has lasted this long, and this well, without an upgrade.<\/p>\n<\/div>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":"<p class=\"excerpt\">Errata Security: Some notes about HTTP\/3<\/p>\n<p class=\"more-link-p\"><a class=\"more-link\" href=\"https:\/\/monodes.com\/predaelli\/2018\/11\/20\/errata-security-some-notes-about-http-3\/\">Read more &rarr;<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"activitypub_content_warning":"","activitypub_content_visibility":"","activitypub_max_image_attachments":4,"activitypub_interaction_policy_quote":"anyone","activitypub_status":"","footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[72],"tags":[],"class_list":["post-4951","post","type-post","status-publish","format-standard","hentry","category-documentations"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p6daft-1hR","jetpack-related-posts":[{"id":7056,"url":"https:\/\/monodes.com\/predaelli\/2020\/04\/03\/openlitespeed-troppo-buono-per-essere-vero\/","url_meta":{"origin":4951,"position":0},"title":"(open)LiteSpeed: troppo buono per essere vero?","author":"Paolo Redaelli","date":"2020-04-03","format":false,"excerpt":"Leggendo la chat di IoRestoACasa.work mi \u00e8 caduto l'occhio su un frammento di conversazione che decantava le qualit\u00e0 del server web LiteSpeed, sostenendo che fosse\u00a0molto pi\u00f9 veloce di Nginx. Tralasciamo che in prima battuta credevo fosse lighttp. Poi ho storto il naso scoprendo che era proprietario ma aveva una versione\u2026","rel":"","context":"In &quot;Proprietary software&quot;","block_context":{"text":"Proprietary software","link":"https:\/\/monodes.com\/predaelli\/category\/software\/proprietary-software\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/monodes.com\/predaelli\/wp-content\/uploads\/sites\/4\/2020\/04\/2631_chart_02.webp?resize=350%2C200","width":350,"height":200},"classes":[]},{"id":3599,"url":"https:\/\/monodes.com\/predaelli\/2017\/12\/27\/basilisk-web-browser\/","url_meta":{"origin":4951,"position":1},"title":"Basilisk web browser","author":"Paolo Redaelli","date":"2017-12-27","format":"link","excerpt":"This Basilisk web browser\u00a0will be a boon for all those people who need to still use Java and Flash based websites: Full support for JavaScript's ECMAscript 6 standard for modern web browsing. Support for all NPAPI plugins (Unity, Silverlight, Flash, Java, authentication plugins, etc.). Support for XUL\/Overlay Mozilla-style extensions. Experimental\u2026","rel":"","context":"In &quot;Software Libero&quot;","block_context":{"text":"Software Libero","link":"https:\/\/monodes.com\/predaelli\/category\/software\/software-libero\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":453,"url":"https:\/\/monodes.com\/predaelli\/2015\/06\/23\/guacamole-html5-clientless-remote-desktop\/","url_meta":{"origin":4951,"position":2},"title":"Guacamole \u2014 HTML5 Clientless Remote Desktop","author":"Paolo Redaelli","date":"2015-06-23","format":false,"excerpt":"Awesome. Quite awesome. Guacamole \u2014 HTML5 Clientless Remote Desktop is really awesome. Guacamole is a clientless remote desktop gateway. It supports standard protocols like VNC and RDP.We call it clientless because no plugins or client software are required.Thanks to HTML5, once Guacamole is installed on a server, all you need\u2026","rel":"","context":"In &quot;Senza categoria&quot;","block_context":{"text":"Senza categoria","link":"https:\/\/monodes.com\/predaelli\/category\/senza-categoria\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":11626,"url":"https:\/\/monodes.com\/predaelli\/2024\/05\/05\/40-tools-for-ethical-hacking\/","url_meta":{"origin":4951,"position":3},"title":"40 tools for ethical hacking","author":"Paolo Redaelli","date":"2024-05-05","format":false,"excerpt":"I know many of them, but not everyone! Shame on me! Here are 40 tools for ethical hacking! Nmap: Network scanner used for network discovery and security auditing. Wireshark: Network protocol analyzer for packet inspection and troubleshooting. Metasploit: Penetration testing framework for exploiting vulnerabilities. John the Ripper: Password cracking tool\u2026","rel":"","context":"In &quot;Tricks&quot;","block_context":{"text":"Tricks","link":"https:\/\/monodes.com\/predaelli\/category\/documentations\/tricks\/"},"img":{"alt_text":"\ud83d\udd0d","src":"https:\/\/static.xx.fbcdn.net\/images\/emoji.php\/v9\/tc1\/1\/16\/1f50d.png","width":350,"height":200},"classes":[]},{"id":2126,"url":"https:\/\/monodes.com\/predaelli\/2017\/01\/31\/google-quietly-makes-optional-web-drm-mandatory-in-chrome-slashdot\/","url_meta":{"origin":4951,"position":4},"title":"Google Quietly Makes &#8216;Optional&#8217; Web DRM Mandatory In Chrome &#8211; Slashdot","author":"Paolo Redaelli","date":"2017-01-31","format":false,"excerpt":"Google Quietly Makes 'Optional' Web DRM Mandatory In Chrome - Slashdot I just don't like what I'm reading. They are briskly walking the path toward the dark side. Everyday it becomes more important to keep supporting Firefox JustAnotherOldGuy quotes a report from Boing Boing: The World Wide Web Consortium's Encrypted\u2026","rel":"","context":"In &quot;DRM&quot;","block_context":{"text":"DRM","link":"https:\/\/monodes.com\/predaelli\/category\/drm\/"},"img":{"alt_text":"chromeears1","src":"https:\/\/i0.wp.com\/monodes.com\/predaelli\/wp-content\/uploads\/sites\/4\/2017\/01\/chromeears1-150x150.jpg?resize=350%2C200","width":350,"height":200},"classes":[]},{"id":3350,"url":"https:\/\/monodes.com\/predaelli\/2017\/09\/11\/wordpress-ssl-settings-and-how-to-resolve-mixed-content-warnings-managewp\/","url_meta":{"origin":4951,"position":5},"title":"WordPress SSL Settings and How to Resolve Mixed Content Warnings &#8211; ManageWP","author":"Paolo Redaelli","date":"2017-09-11","format":"link","excerpt":": WordPress SSL Settings and How to Resolve Mixed Content Warnings - ManageWP WordPress SSL Settings and How to Resolve Mixed Content Warnings September 6, 2012 Tips & Tricks 109 Building a website consists of a varied number of steps, depending on the owner, creator, manager, type of site, and\u2026","rel":"","context":"In &quot;Documentations&quot;","block_context":{"text":"Documentations","link":"https:\/\/monodes.com\/predaelli\/category\/documentations\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/monodes.com\/predaelli\/wp-content\/uploads\/sites\/4\/2017\/09\/WordPress-HTTP-to-HTTPS.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]}],"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/posts\/4951","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/comments?post=4951"}],"version-history":[{"count":0,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/posts\/4951\/revisions"}],"wp:attachment":[{"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/media?parent=4951"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/categories?post=4951"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monodes.com\/predaelli\/wp-json\/wp\/v2\/tags?post=4951"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}