{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":290325734,"defaultBranch":"20200720-quic","name":"quic-dev","ownerLogin":"haproxytech","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2020-08-25T21:18:12.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/2300017?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1726496235.0","currentOid":""},"activityList":{"items":[{"before":"fcd6d29acf108c55e1e1c17c04aeae621327adff","after":"8df44eea6dd1203218936fec7b571ab04b16ce91","ref":"refs/heads/qns","pushedAt":"2024-09-18T15:51:08.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"a-denoyelle","name":"Amaury Denoyelle","path":"/a-denoyelle","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/54402659?s=80&v=4"},"commit":{"message":"BUILD: cebtree: silence a bogus gcc warning on impossible code paths\n\ngcc-12 and above report a wrong warning about a negative length being\npassed to memcmp() on an impossible code path when built at -O0. The\npattern is the same at a few places, basically:\n\n  int foo(int op, const void *a, const void *b, size_t size, size_t arg)\n  {\n      if (op == 1) // arg is a strict multiple of size\n          return memcmp(a, b, arg - size);\n      return 0;\n  }\n  ...\n  int bar()\n  {\n     return foo(0, a, b, sizeof(something), 0);\n  }\n\nIt *might* be possible to invent dummy values for the \"len\" argument\nabove in the real code, but that significantly complexifies it and as\nusual can easily result in introducing undesired bugs.\n\nHere we take a different approach consisting in shutting the\n-Wstringop-overread warning on gcc>=12 at -O0 since that's the only\ncondition that triggers it. The issue was reported to and confirmed by\nthe gcc team here:  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114622\n\nNo backport needed, but this should be upstreamed into cebtree after\nchecking that all involved macros are available.","shortMessageHtmlLink":"BUILD: cebtree: silence a bogus gcc warning on impossible code paths"}},{"before":"1e0920f85542d63755cb8824d1000c3a6f22bb9c","after":"fcd6d29acf108c55e1e1c17c04aeae621327adff","ref":"refs/heads/qns","pushedAt":"2024-09-18T14:16:10.000Z","pushType":"push","commitsCount":18,"pusher":{"login":"a-denoyelle","name":"Amaury Denoyelle","path":"/a-denoyelle","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/54402659?s=80&v=4"},"commit":{"message":"BUG/MINOR: mux-quic: report glitches to session\n\nGlitch counter was implemented for QUIC/HTTP3. The counter is stored in\nthe QCC MUX connection instance. However, this is never reported at the\nsession level which is necessary if glitch counter is tracked via a\nstick-table.\n\nTo fix this, use session_add_glitch_ctr() in various QUIC MUX functions\nwhich may increment glitch counter.\n\nThis should be backported up to 3.0.","shortMessageHtmlLink":"BUG/MINOR: mux-quic: report glitches to session"}},{"before":"05a3c726b4b4aa28fdacf22e0e2358e23363607e","after":"1e0920f85542d63755cb8824d1000c3a6f22bb9c","ref":"refs/heads/qns","pushedAt":"2024-09-16T16:11:08.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"a-denoyelle","name":"Amaury Denoyelle","path":"/a-denoyelle","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/54402659?s=80&v=4"},"commit":{"message":"BUG/MINOR: peers: local entries updates may not be advertised after resync\n\nSince commit 864ac3117 (\"OPTIM: stick-tables: check the stksess without\ntaking the read lock\"), when entries for a local table are learned from\nanother peer upon resynchro, and this is the only peer haproxy speaks to,\nlocal updates on such entries are not advertised to the peer anymore,\nuntil they eventually expire and can be recreated upon local updates.\n\nThis is due to the fact that ts->seen is always set to 0 when creating\nnew entry, and also when touch_remote is performed on the entry.\n\nIndeed, while 864ac3117 attempts to avoid useless updates, it didn't\nconsider entries learned from a remote peer. Such entries are exclusively\nlearned in peer_treat_updatemsg(): once the entry is created (or updated)\nwith new data, touch_remote is used to commit the change. However, unlike\ntouch_local, entries committed using touch_remote will not be advertised\nto the peer from which the entry was just learned (otherwise we would\nenter a looping situation). Due to the above patch, once an entry is\nlearned from the (unique) remote peer, 'seen' will be stuck to 0 so it\nwill never be advertised for its whole lifetime.\n\nInstead, when entries are learned from a peer, we should consider that\nthe peer that taught us the entry has seen it.\n\nTo do this, let's set seen=1 in peer_treat_updatemsg() after calling\ntouch_remote(). This way, if we happen to perform updates on this entry,\nit will be properly advertized to relevant peers. This patch should not\naffect the performance gain documented in 864ac3117 given that the test\nscenario didn't involved entries learned by remote peers, but solely\nlocally created entries advertised to remote peers upon updates.\n\nThis should be backported in 3.0 with 864ac3117.","shortMessageHtmlLink":"BUG/MINOR: peers: local entries updates may not be advertised after r…"}},{"before":null,"after":"5b6e8c4d4dc38e16b28c9980344a83ebbbc6bbbb","ref":"refs/heads/ade-qns","pushedAt":"2024-09-16T14:17:15.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"a-denoyelle","name":"Amaury Denoyelle","path":"/a-denoyelle","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/54402659?s=80&v=4"},"commit":{"message":"DOC: quic: document nocc debug congestion algorithm\n\nDocument nocc congestion algorithm as an entry of quic-cc-algo.\nHighlight the fact that it is reserved for debugging and should not be\nused outside of this use case.","shortMessageHtmlLink":"DOC: quic: document nocc debug congestion algorithm"}},{"before":"a7c33b0a358f241fb7d1a20a288afd30a89ce9af","after":"9eaf323bcaf86624fd3116c39d691c9a7d22daca","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-09-09T13:47:20.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"WIP: quic: avoid sending PADDING only Initial packets when probing","shortMessageHtmlLink":"WIP: quic: avoid sending PADDING only Initial packets when probing"}},{"before":"50322dff81f3c05e67bf311ff9ef0c77c833df97","after":"a7c33b0a358f241fb7d1a20a288afd30a89ce9af","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-09-09T13:09:52.000Z","pushType":"push","commitsCount":7,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"MINOR: quic: Add a BUG_ON() to prevent probing without ack-eliciting packets\n\nIt is useless to probe the peer with non ack-eliciting packets.\nAdd a BUG_ON() to detect such situations.","shortMessageHtmlLink":"MINOR: quic: Add a BUG_ON() to prevent probing without ack-eliciting …"}},{"before":"d317fc6b2191de9bc24c41c4b949a8f047c2b975","after":"50322dff81f3c05e67bf311ff9ef0c77c833df97","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-09-06T10:01:39.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"MEDIUM: server: add init-state\n\nAllow the user to set the \"initial state\" of a server.\n\nContext:\n\nServers are always set in an UP status by default. In\nsome cases, further checks are required to determine if the server is\nready to receive client traffic.\n\nThis introduces the \"init-state {up|down}\" configuration parameter to\nthe server.\n\n- when set to 'fully-up', the server is considered immediately available\n  and can turn to the DOWN sate when ALL health checks fail.\n- when set to 'up' (the default), the server is considered immediately\n  available and will initiate a health check that can turn it to the DOWN\n  state immediately if it fails.\n- when set to 'down', the server initially is considered unavailable and\n  will initiate a health check that can turn it to the UP state immediately\n  if it succeeds.\n- when set to 'fully-down', the server is initially considered unavailable\n  and can turn to the UP state when ALL health checks succeed.\n\nThe server's init-state is considered when the HAProxy instance\nis (re)started, a new server is detected (for example via service\ndiscovery / DNS resolution), a server exits maintenance, etc.\n\nLink: https://github.com/haproxy/haproxy/issues/51","shortMessageHtmlLink":"MEDIUM: server: add init-state"}},{"before":"ed9c3a28d8f7108e12d4d69dc93dbf06afc0fb03","after":"d317fc6b2191de9bc24c41c4b949a8f047c2b975","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-09-06T09:24:04.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"BUG/MINOR: quic: Too short datagram during packet building failures (aws-lc only)\n\nThis issue was reported by Ilya (@Chipitsine) when building haproxy against\naws-lc in GH #2663 where handshakeloss and handshakecorruption interop tests could\nlead haproxy to crash after having built too short datagrams:\n\nFATAL: bug condition \"first_pkt->type == QUIC_PACKET_TYPE_INITIAL && (first_pkt->flags & (1UL << 0)) && length < 1200\" matched at src/quic_tx.c:163\ncall trace(13):\n| 0x55f4ee4dcc02 [ba d9 00 00 00 48 8d 35]: main-0x195bf2\n| 0x55f4ee4e3112 [83 3d 2f 16 35 00 00 0f]: qc_send+0x11f3/0x1b5d\n| 0x55f4ee4e9ab4 [85 c0 0f 85 00 f6 ff ff]: quic_conn_io_cb+0xab1/0xf1c\n| 0x55f4ee6efa82 [48 c7 c0 f8 55 ff ff 64]: run_tasks_from_lists+0x173/0x9c2\n| 0x55f4ee6f05d3 [8b 7d a0 29 c7 85 ff 0f]: process_runnable_tasks+0x302/0x6e6\n| 0x55f4ee671bb7 [83 3d 86 72 44 00 01 0f]: run_poll_loop+0x6e/0x57b\n| 0x55f4ee672367 [48 8b 1d 22 d4 1d 00 48]: main-0x48d\n| 0x55f4ee6755e0 [b8 00 00 00 00 e8 08 61]: main+0x2dec/0x335d\n\nThis could happen after Handshake packet building failures which follow a successful\nInitial packet into the same datagram. In this case, the datagram could be emitted\nwith a too short length (<1200 bytes).\n\nTo fix this, store the datagram only if the first packet is not an Initial packet\nor if its length is big enough (>=1200 bytes).\n\nMust be backported as far as 2.6.\n\n(cherry picked from commit eb1a097a6687cd8b93d981eff3d7e257c448ff3e)\n[fl: same patch wich <wrlen> replaced by <dlen> (datagram length)]\nSigned-off-by: Frederic Lecaille <flecaille@haproxy.com>","shortMessageHtmlLink":"BUG/MINOR: quic: Too short datagram during packet building failures (…"}},{"before":"064bf001a50c15ac0caf988f5c6e9d767d41c955","after":"ed9c3a28d8f7108e12d4d69dc93dbf06afc0fb03","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-09-06T09:08:54.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"BUG/MINOR: quic: Too short datagram during packet building failures (aws-lc only)\n\nThis issue was reported by Ilya (@Chipitsine) when building haproxy against\naws-lc in GH #2663 where handshakeloss and handshakecorruption interop tests could\nlead haproxy to crash after having built too short datagrams:\n\nFATAL: bug condition \"first_pkt->type == QUIC_PACKET_TYPE_INITIAL && (first_pkt->flags & (1UL << 0)) && length < 1200\" matched at src/quic_tx.c:163\ncall trace(13):\n| 0x55f4ee4dcc02 [ba d9 00 00 00 48 8d 35]: main-0x195bf2\n| 0x55f4ee4e3112 [83 3d 2f 16 35 00 00 0f]: qc_send+0x11f3/0x1b5d\n| 0x55f4ee4e9ab4 [85 c0 0f 85 00 f6 ff ff]: quic_conn_io_cb+0xab1/0xf1c\n| 0x55f4ee6efa82 [48 c7 c0 f8 55 ff ff 64]: run_tasks_from_lists+0x173/0x9c2\n| 0x55f4ee6f05d3 [8b 7d a0 29 c7 85 ff 0f]: process_runnable_tasks+0x302/0x6e6\n| 0x55f4ee671bb7 [83 3d 86 72 44 00 01 0f]: run_poll_loop+0x6e/0x57b\n| 0x55f4ee672367 [48 8b 1d 22 d4 1d 00 48]: main-0x48d\n| 0x55f4ee6755e0 [b8 00 00 00 00 e8 08 61]: main+0x2dec/0x335d\n\nThis could happen after Handshake packet building failures which follow a successful\nInitial packet into the same datagram. In this case, the datagram could be emitted\nwith a too short length (<1200 bytes).\n\nTo fix this, store the datagram only if the first packet is not an Initial packet\nor if its length is big enough (>=1200 bytes).\n\nMust be backported as far as 2.6.\n\n(cherry picked from commit eb1a097a6687cd8b93d981eff3d7e257c448ff3e)\n[fl: same patch wich <wrlen> replaced by <dlen> (datagram length)]\nSigned-off-by: Frederic Lecaille <flecaille@haproxy.com>","shortMessageHtmlLink":"BUG/MINOR: quic: Too short datagram during packet building failures (…"}},{"before":"73843d5afd4736fe439123748a7f2bde3f47c38c","after":"064bf001a50c15ac0caf988f5c6e9d767d41c955","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-09-06T09:06:53.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"BUG/MINOR: quic: Too short datagram during packet building failures (aws-lc only)\n\nThis issue was reported by Ilya (@Chipitsine) when building haproxy against\naws-lc in GH #2663 where handshakeloss and handshakecorruption interop tests could\nlead haproxy to crash after having built too short datagrams:\n\nFATAL: bug condition \"first_pkt->type == QUIC_PACKET_TYPE_INITIAL && (first_pkt->flags & (1UL << 0)) && length < 1200\" matched at src/quic_tx.c:163\ncall trace(13):\n| 0x55f4ee4dcc02 [ba d9 00 00 00 48 8d 35]: main-0x195bf2\n| 0x55f4ee4e3112 [83 3d 2f 16 35 00 00 0f]: qc_send+0x11f3/0x1b5d\n| 0x55f4ee4e9ab4 [85 c0 0f 85 00 f6 ff ff]: quic_conn_io_cb+0xab1/0xf1c\n| 0x55f4ee6efa82 [48 c7 c0 f8 55 ff ff 64]: run_tasks_from_lists+0x173/0x9c2\n| 0x55f4ee6f05d3 [8b 7d a0 29 c7 85 ff 0f]: process_runnable_tasks+0x302/0x6e6\n| 0x55f4ee671bb7 [83 3d 86 72 44 00 01 0f]: run_poll_loop+0x6e/0x57b\n| 0x55f4ee672367 [48 8b 1d 22 d4 1d 00 48]: main-0x48d\n| 0x55f4ee6755e0 [b8 00 00 00 00 e8 08 61]: main+0x2dec/0x335d\n\nThis could happen after Handshake packet building failures which follow a successful\nInitial packet into the same datagram. In this case, the datagram could be emitted\nwith a too short length (<1200 bytes).\n\nTo fix this, store the datagram only if the first packet is not an Initial packet\nor if its length is big enough (>=1200 bytes).\n\nMust be backported as far as 2.6.\n\n(cherry picked from commit eb1a097a6687cd8b93d981eff3d7e257c448ff3e)\n[fl: same patch wich <wrlen> replaced by <dlen> (datagram length)]\nSigned-off-by: Frederic Lecaille <flecaille@haproxy.com>","shortMessageHtmlLink":"BUG/MINOR: quic: Too short datagram during packet building failures (…"}},{"before":"763a0367a1d7944dce11e18dfa5733ddf1a0c8d7","after":"73843d5afd4736fe439123748a7f2bde3f47c38c","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-09-06T08:41:11.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"DO NOT MERGE: revert 657e745c to reproduce a bug.\n\nsee issue 2663.","shortMessageHtmlLink":"DO NOT MERGE: revert <a class=\"commit-link\" data-hovercard-type=\"commit\" data-hovercard-url=\"https://github.com/haproxytech/quic-dev/commit/657e745c1670ee03b46077d37eabe8520bb43538/hovercard\" href=\"https://github.com/haproxytech/quic-dev/commit/657e745c1670ee03b46077d37eabe8520bb43538\"><tt>657e745</tt></a> to reproduce a bug."}},{"before":"e875aa59a9216d42639b802b5008afc733e4c940","after":"763a0367a1d7944dce11e18dfa5733ddf1a0c8d7","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-09-05T14:57:41.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"BUG/MINOR: quic: Crash from trace dumping SSL eary data status (AWS-LC)\n\nThis bug follows this patch:\n     MINOR: quic: Add trace for QUIC_EV_CONN_IO_CB event.\nwhere a new third variable was added to be dumped from QUIC_EV_CONN_IO_CB trace\nevent. The quic_trace() code did not reveal there was already another variable\npassed as third argument but not dumped. This leaded to crash when dereferencing\na point to an int in place of a point to an SSL object.\n\nThis issue was reproduced only by handshakecorruption aws-lc interop test with\ns2n-quic as client.\n\nNote that this patch must be backported with this one:\n     BUG/MEDIUM: quic: always validate sender address on 0-RTT\nwhich depends on the commit mentionned above.\n\n(cherry picked from commit db13df3d6e64e9993b90f048734538491082cbed)\nSigned-off-by: Frederic Lecaille <flecaille@haproxy.com>","shortMessageHtmlLink":"BUG/MINOR: quic: Crash from trace dumping SSL eary data status (AWS-LC)"}},{"before":"58b6b580199463c8dbd27db738dcde6772020e71","after":"e875aa59a9216d42639b802b5008afc733e4c940","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-09-05T14:46:31.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"BUG/MEDIUM: quic: always validate sender address on 0-RTT\n\nIt has been reported by Wedl Michael, a student at the University of Applied\nSciences St. Poelten, a potential vulnerability into haproxy as described below.\n\nAn attacker could have obtained a TLS session ticket after having established\na connection to an haproxy QUIC listener, using its real IP address. The\nattacker has not even to send a application level request (HTTP3). Then\nthe attacker could open a 0-RTT session with a spoofed IP address\ntrusted by the QUIC listen to bypass IP allow/block list and send HTTP3 requests.\n\nTo mitigate this vulnerability, one decided to use a token which can be provided\nto the client each time it successfully managed to connect to haproxy. These\ntokens may be reused for future connections to validate the address/path of the\nremote peer as this is done with the Retry token which is used for the current\nconnection, not the next one. Such tokens are transported by NEW_TOKEN frames\nwhich was not used at this time by haproxy.\n\nSo, each time a client connect to an haproxy QUIC listener with 0-RTT\nenabled, it is provided with such a token which can be reused for the\nnext 0-RTT session. If no such a token is presented by the client,\nhaproxy checks if the session is a 0-RTT one, so with early-data presented\nby the client. Contrary to the Retry token, the decision to refuse the\nconnection is made only when the TLS stack has been provided with\nenough early-data from the Initial ClientHello TLS message and when\nthese data have been accepted. Hopefully, this event arrives fast enough\nto allow haproxy to kill the connection if some early-data have been accepted\nwithout token presented by the client.\n\nquic_build_post_handshake_frames() has been modified to build a NEW_TOKEN\nframe with this newly implemented token to be transported inside.\n\nquic_tls_derive_retry_token_secret() was renamed to quic_do_tls_derive_token_secre()\nand modified to be reused and derive the secret for the new token implementation.\n\nquic_token_validate() has been implemented to validate both the Retry and\nthe new token implemented by this patch. When this is a non-retry token\nwhich could not be validated, the datagram received is marked as requiring\na Retry packet to be sent, and no connection is created.\n\nWhen the Initial packet does not embed any non-retry token and if 0-RTT is enabled\nthe connection is marked with this new flag: QUIC_FL_CONN_NO_TOKEN_RCVD. As soon\nas the TLS stack detects that some early-data have been provided and accepted by\nthe client, the connection is marked to be killed (QUIC_FL_CONN_TO_KILL) from\nha_quic_add_handshake_data(). This is done calling qc_ssl_eary_data_accepted()\nnew function. The secret TLS handshake is interrupted as soon as possible returnin\n0 from ha_quic_add_handshake_data(). The connection is also marked as\nrequiring a Retry packet to be sent (QUIC_FL_CONN_SEND_RETRY) from\nha_quic_add_handshake_data(). The the handshake I/O handler (quic_conn_io_cb())\nknows how to behave: kill the connection after having sent a Retry packet.\n\nAbout TLS stack compatibility, this patch is supported by aws-lc. It is\ndisabled for wolfssl which does not support 0-RTT at this time thanks\nto HAVE_SSL_0RTT_QUIC.\n\nThis patch depends on these commits:\n\n     MINOR: quic: Add trace for QUIC_EV_CONN_IO_CB event.\n     MINOR: quic: Implement qc_ssl_eary_data_accepted().\n     MINOR: quic: Modify NEW_TOKEN frame structure (qf_new_token struct)\n     BUG/MINOR: quic: Missing incrementation in NEW_TOKEN frame builder\n     MINOR: quic: Token for future connections implementation.\n     MINOR: quic: Implement quic_tls_derive_token_secret().\n     MINOR: tools: Implement ipaddrcpy().\n\nMust be backported as far as 2.6.\n\n(cherry picked from commit f627b9272bd8ffca6f2f898bfafc6bf0b84b7d46)\n[fl: Add ->flags to quic_dgram struct (would arrive with quic_initial feature).\n     Add QUIC_DGRAM_FL_ quic_dgram flags (would arrive with quic_initial feature).\n     Modify quic_rx_pkt_retrieve_conn() to fix a compilation issue and correctly\n     handle the \"if (pkt->token_len) {}\" else block to do so with quic_initial\n     feature]\nSigned-off-by: Frederic Lecaille <flecaille@haproxy.com>","shortMessageHtmlLink":"BUG/MEDIUM: quic: always validate sender address on 0-RTT"}},{"before":"1f6e5f7a61c992e28956e3d75ce4582fa72880bc","after":"58b6b580199463c8dbd27db738dcde6772020e71","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-09-05T13:19:36.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"BUG/MINOR: quic: Crash from trace dumping SSL eary data status (AWS-LC)\n\nThis bug follows this patch:\n     MINOR: quic: Add trace for QUIC_EV_CONN_IO_CB event.\nwhere a new third variable was added to be dumped from QUIC_EV_CONN_IO_CB trace\nevent. The quic_trace() code did not reveal there was already another variable\npassed as third argument but not dumped. This leaded to crash when dereferencing\na point to an int in place of a point to an SSL object.\n\nThis issue was reproduced only by handshakecorruption aws-lc interop test with\ns2n-quic as client.\n\nNote that this patch must be backported with this one:\n     BUG/MEDIUM: quic: always validate sender address on 0-RTT\nwhich depends on the commit mentionned above.\n\n(cherry picked from commit db13df3d6e64e9993b90f048734538491082cbed)\nSigned-off-by: Frederic Lecaille <flecaille@haproxy.com>","shortMessageHtmlLink":"BUG/MINOR: quic: Crash from trace dumping SSL eary data status (AWS-LC)"}},{"before":"39ce6a459f83e6a2a2f7c4c826839aac93e09254","after":"0582778122e13fdb09b3af1b707e8ff1a251673b","ref":"refs/heads/fle-bbr","pushedAt":"2024-09-05T08:34:24.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"WIP: quic: implement BBR.","shortMessageHtmlLink":"WIP: quic: implement BBR."}},{"before":"11352fe0691eb94c7d75727721b1c8630333fcd0","after":"39ce6a459f83e6a2a2f7c4c826839aac93e09254","ref":"refs/heads/fle-bbr","pushedAt":"2024-09-04T16:45:38.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"WIP: QUIC haproxy headers modification (cc excluded).","shortMessageHtmlLink":"WIP: QUIC haproxy headers modification (cc excluded)."}},{"before":"73e44b573f81625df1835240f264625f7042b55c","after":"05a3c726b4b4aa28fdacf22e0e2358e23363607e","ref":"refs/heads/qns","pushedAt":"2024-09-03T17:08:25.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"MEDIUM: mux-quic: allow to only release one buffer\n\nPrevious commit relaxed conditions for QUIC MUX Tx buffer allocation.\nThis was necessary to prevent slow throughput when a standalone stream\ncould only allocate a single buffer. Now, when a buffer is released, it\nis removed from connection buffer window, thus allowing a new\nallocation. However, this virtually allows a QCS to allocate many\nbuffers without any limit.\n\nTo fix this, add a limit on the number of released buffer that a QCS may\nhave. Once this limit is reached, qcc_release_stream_txbuf() operation\nwill return an error, flagging QCS with QC_SF_BLK_MROOM. Each time an\nalready released buffer is freed after ACK reception, new\nqcs_notify_buf() is called by qc_stream_desc layer to wakeup the QCS\nstream if currently blocked.\n\nThe limit is configured via a define QMUX_MAX_QCS_TXBUF_RELEASED. It is\nset to 1 by default. This value is low enough to guarantee minimal\nmemory consumption for a QUIC connection while preserving transfer\nthroughput. Thus, the new buffer allocation limit is now :\n  qc_window_size + (1 * nb_streams)","shortMessageHtmlLink":"MEDIUM: mux-quic: allow to only release one buffer"}},{"before":"34da88ee6e2a5b3e275456556095ccea1b6eb56f","after":"1f6e5f7a61c992e28956e3d75ce4582fa72880bc","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-09-03T17:05:24.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"CLEANUP: assorted typo fixes in the code and comments\n\nThis is 43rd iteration of typo fixes","shortMessageHtmlLink":"CLEANUP: assorted typo fixes in the code and comments"}},{"before":"fe95ae425e3afa9b5a6944867331e300c5921180","after":"73e44b573f81625df1835240f264625f7042b55c","ref":"refs/heads/qns","pushedAt":"2024-09-03T13:33:22.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"MEDIUM: mux-quic: allow to only release one buffer\n\nPrevious commit relaxed conditions for QUIC MUX Tx buffer allocation.\nThis was necessary to prevent slow throughput when a standalone stream\ncould only allocate a single buffer. Now, when a buffer is released, it\nis removed from connection buffer window, thus allowing a new\nallocation. However, this virtually allows a QCS to allocate many\nbuffers without any limit.\n\nTo fix this, add a limit on the number of released buffer that a QCS may\nhave. Once this limit is reached, qcc_release_stream_txbuf() operation\nwill return an error, flagging QCS with QC_SF_BLK_MROOM. Each time an\nalready released buffer is freed after ACK reception, new\nqcs_notify_buf() is called by qc_stream_desc layer to wakeup the QCS\nstream if currently blocked.\n\nThe limit is configured via a define QMUX_MAX_QCS_TXBUF_RELEASED. It is\nset to 1 by default. This value is low enough to guarantee minimal\nmemory consumption for a QUIC connection while preserving transfer\nthroughput. Thus, the new buffer allocation limit is now :\n  qc_window_size + (1 * nb_streams)","shortMessageHtmlLink":"MEDIUM: mux-quic: allow to only release one buffer"}},{"before":"60c9a486bdbfe7275ff610bb53c12eb1d79d2a8d","after":"34da88ee6e2a5b3e275456556095ccea1b6eb56f","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-09-03T08:53:04.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"WIP: quic: to be kept (improve retransmissions)","shortMessageHtmlLink":"WIP: quic: to be kept (improve retransmissions)"}},{"before":"c93c6660e7097551ff0ebc93ed459146a284f610","after":"60c9a486bdbfe7275ff610bb53c12eb1d79d2a8d","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-09-02T16:43:47.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"WIP: quic: add traces","shortMessageHtmlLink":"WIP: quic: add traces"}},{"before":"7c838969f37145453c51b5d8b0844c422100b102","after":"c93c6660e7097551ff0ebc93ed459146a284f610","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-09-02T16:18:56.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"WIP: quic: Add traces","shortMessageHtmlLink":"WIP: quic: Add traces"}},{"before":"8d8bc2c94f722d5407bec0b8f198f712922253d8","after":"7c838969f37145453c51b5d8b0844c422100b102","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-09-02T13:10:52.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"WIP: quic: Add datagram trace about its DCID","shortMessageHtmlLink":"WIP: quic: Add datagram trace about its DCID"}},{"before":"86af5a60ae66cb9b4c54892cd3111a09eed3e047","after":"fe95ae425e3afa9b5a6944867331e300c5921180","ref":"refs/heads/qns","pushedAt":"2024-09-02T08:09:07.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"MEDIUM: mux-quic: allow to only release one buffer\n\nPrevious commit relaxed conditions for QUIC MUX Tx buffer allocation.\nThis was necessary to prevent slow throughput when a standalone stream\ncould only allocate a single buffer. Now, when a buffer is released, it\nis removed from connection buffer window, thus allowing a new\nallocation. However, this virtually allows a QCS to allocate many\nbuffers without any limit.\n\nTo fix this, add a limit on the number of released buffer that a QCS may\nhave. Once this limit is reached, qcc_release_stream_txbuf() operation\nwill return an error, flagging QCS with QC_SF_BLK_MROOM. Each time an\nalready released buffer is freed after ACK reception, new\nqcs_notify_buf() is called by qc_stream_desc layer to wakeup the QCS\nstream if currently blocked.\n\nThe limit is configured via a define QMUX_MAX_QCS_TXBUF_RELEASED. It is\nset to 1 by default. This value is low enough to guarantee minimal\nmemory consumption for a QUIC connection while preserving transfer\nthroughput. Thus, the new buffer allocation limit is now :\n  qc_window_size + (1 * nb_streams)","shortMessageHtmlLink":"MEDIUM: mux-quic: allow to only release one buffer"}},{"before":"8d2db5d964ea2171b1d1c024de0a18c1f3653097","after":"8d8bc2c94f722d5407bec0b8f198f712922253d8","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-09-02T07:43:26.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"WIP: quic: aws-lc crash (s2n-quic - handshakecorruption)","shortMessageHtmlLink":"WIP: quic: aws-lc crash (s2n-quic - handshakecorruption)"}},{"before":"0a4ff73d9ac53a338c332ed9d1ed5f290de2bdfd","after":"86af5a60ae66cb9b4c54892cd3111a09eed3e047","ref":"refs/heads/qns","pushedAt":"2024-09-02T07:04:15.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"MEDIUM: mux-quic: allow to only release one buffer\n\nPrevious commit relaxed conditions for QUIC MUX Tx buffer allocation.\nThis was necessary to prevent slow throughput when a standalone stream\ncould only allocate a single buffer. Now, when a buffer is released, it\nis removed from connection buffer window, thus allowing a new\nallocation. However, this virtually allows a QCS to allocate many\nbuffers without any limit.\n\nTo fix this, add a limit on the number of released buffer that a QCS may\nhave. Once this limit is reached, qcc_release_stream_txbuf() operation\nwill return an error, flagging QCS with QC_SF_BLK_MROOM. Each time an\nalready released buffer is freed after ACK reception, new\nqcs_notify_buf() is called by qc_stream_desc layer to wakeup the QCS\nstream if currently blocked.\n\nThe limit is configured via a define QMUX_MAX_QCS_TXBUF_RELEASED. It is\nset to 1 by default. This value is low enough to guarantee minimal\nmemory consumption for a QUIC connection while preserving transfer\nthroughput. Thus, the new buffer allocation limit is now :\n  qc_window_size + (1 * nb_streams)","shortMessageHtmlLink":"MEDIUM: mux-quic: allow to only release one buffer"}},{"before":"d3616f01cfc2a765a01817324b51d3b73c0188b2","after":"8d2db5d964ea2171b1d1c024de0a18c1f3653097","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-08-30T14:32:37.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"BUG/MEDIUM: quic: 0-RTT securing\n\nIt has been reported by Wedl Michael, a student at the University of Applied\nSciences St. Poelten, a potential vulnerability into haproxy as described below.\n\nAn attacker could have obtained a TLS session ticket after having established\na connection to an haproxy QUIC listener, using its real IP address. The\nattacker has not even to send a application level request (HTTP3). Then\nthe attacker could open a 0-RTT session with a spoofed IP address\ntrusted by the QUIC listen to bypass IP allow/block list and send HTTP3 requests.\n\nTo mitigate this vulnerability, one decided to use a token which can be provided\nto the client each time it successfully managed to connect to haproxy. These\ntokens may be reused for future connections to validate the address/path of the\nremote peer as this is done with the Retry token which is used for the current\nconnection, not the next one. Such tokens are transported by NEW_TOKEN frames\nwhich was not used at this time by haproxy.\n\nSo, each time a client connect to an haproxy QUIC listener with 0-RTT\nenabled, it is provided with such a token which can be reused for the\nnext 0-RTT session. If no such a token is presented by the client,\nhaproxy checks if the session is a 0-RTT one, so with early-data presented\nby the client. Contrary to the Retry token, the decision to refuse the\nconnection is made only when the TLS stack has been provided with\nenough early-data from the Initial ClientHello TLS message and when\nthese data have been accepted. Hopefully, this event arrives fast enough\nto allow haproxy to kill the connection if some early-data have been accepted\nwithout token presented by the client.\n\nquic_build_post_handshake_frames() has been modified to build a NEW_TOKEN\nframe with this newly implemented token to be transported inside.\n\nquic_tls_derive_retry_token_secret() was renamed to quic_do_tls_derive_token_secre()\nand modified to be reused and derive the secret for the new token implementation.\n\nquic_token_validate() has been implemented to validate both the Retry and\nthe new token implemented by this patch. When this is a non-retry token\nwhich could not be validated, the datagram received is marked as requiring\na Retry packet to be sent, and no connection is created.\n\nWhen the Initial packet does not embed any non-retry token and if 0-RTT is enabled\nthe connection is marked with this new flag: QUIC_FL_CONN_NO_TOKEN_RCVD. As soon\nas the TLS stack detects that some early-data have been provided and accepted by\nthe client, the connection is marked to be killed (QUIC_FL_CONN_TO_KILL) from\nha_quic_add_handshake_data(). This is done calling qc_ssl_eary_data_accepted()\nnew function. The secret TLS handshake is interrupted as soon as possible returnin\n0 from ha_quic_add_handshake_data(). The connection is also marked as\nrequiring a Retry packet to be sent (QUIC_FL_CONN_SEND_RETRY) from\nha_quic_add_handshake_data(). The the handshake I/O handler (quic_conn_io_cb())\nknows how to behave: kill the connection after having sent a Retry packet.\n\nAbout TLS stack compatibility, this patch is supported by aws-lc. It is\ndisabled for wolfssl which does not support 0-RTT at this time thanks\nto HAVE_SSL_0RTT_QUIC.\n\nThis patch depends on these commits:\n\n     MINOR: quic: Add trace for QUIC_EV_CONN_IO_CB event.\n     MINOR: quic: Implement qc_ssl_eary_data_accepted().\n     MINOR: quic: Modify NEW_TOKEN frame structure (qf_new_token struct)\n     BUG/MINOR: quic: Missing incrementation in NEW_TOKEN frame builder\n     MINOR: quic: Token for future connections implementation.\n     MINOR: quic: Implement quic_tls_derive_token_secret().\n     MINOR: tools: Implement ipaddrcpy().\n\nMust be backported as far as 2.6.","shortMessageHtmlLink":"BUG/MEDIUM: quic: 0-RTT securing"}},{"before":"2dee9e7e0ca42676f3ca2349b33e34612bc24bd6","after":"d3616f01cfc2a765a01817324b51d3b73c0188b2","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-08-29T16:45:14.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"BUG/MINOR: quic: O-RTT securing\n\nIt has been reported by Wedl Michael, a student at the University of Applied\nSciences St. Poelten, a potential vulnerability into haproxy as described below.\n\nAn attacker could have obtained a TLS session ticket after having established\na connection to an haproxy QUIC listener, using its real IP address. The\nattacker has not even to send a application level request (HTTP3). Then\nthe attacker could open a 0-RTT session with a spoofed IP address\ntrusted by the QUIC listen to bypass IP allow/block list and send HTTP3 requests.\n\nTo mitigate this vulnerability, one decided to use a token which can be provided\nto the client each time it successfully managed to connect to haproxy. These\ntokens may be reused for future connections to validate the address/path of the\nremote peer as this is done with the Retry token which is used for the current\nconnection, not the next one. Such tokens are transported by NEW_TOKEN frames\nwhich was not used at this time by haproxy.\n\nSo, each time a client connect to an haproxy QUIC listener with 0-RTT\nenabled, it is provided with such a token which can be reused for the\nnext 0-RTT session. If no such a token is presented by the client,\nhaproxy checks if the session is a 0-RTT one, so with early-data presented\nby the client. Contrary to the Retry token, the decision to refuse the\nconnection is made only when the TLS stack has been provided with\nenough early-data from the Initial ClientHello TLS message and when\nthese data have been accepted. Hopefully, this event arrives fast enough\nto allow haproxy to kill the connection if some early-data have been accepted\nwithout token presented by the client.\n\nThe token generation (quic_generate_token()) and verification (quic_token_chek())\nhave been implemented into quic_token.c and quic_token.h. The same method\nis used as for Retry tokens to build suche tokens to be reused for future\nconnections. The format is very simple: one byte for the format identifier\nto distinguish these new tokens for the Retry token, followed by a 32bits\ntimestamps. As this part is ciphered with AEAD as cryptographic\nalgorithm, 16 bytes are needed for the AEAD tag. 16 more random bytes\nare added to this token and a salt to derive the AEAD secret used\nto cipher the token. In addition to this salt, this is the client IP address\nwhich is used also as AAD to derive the AEAD secret. So, the length of\nthe token is fixed: 37 bytes.\n\nquic_build_post_handshake_frames() has been modified to build a NEW_TOKEN\nframe with this newly implemented token to be transported inside.\n\nquic_tls_derive_retry_token_secret() was renamed to quic_do_tls_derive_token_secret()\nand modified to be reused and derive the secret for the new token implementation.\n\nquic_token_validate() has been implemented to validate both the Retry and\nthe new token implemented by this patch. When this is a non-retry token\nwhich could not be validated, the datagram received is marked as requiring\na Retry packet to be sent, and no connection is created.\n\nWhen the Initial packet does not embed any non-retry token and if 0-RTT is enabled,\nthe connection is marked with this new flag: QUIC_FL_CONN_NO_TOKEN_RCVD. As soon\nas the TLS stack detects that some early-data have been provided and accepted by\nthe client, the connection is marked to be killed (QUIC_FL_CONN_TO_KILL) from\nha_quic_add_handshake_data(). This is done calling qc_ssl_eary_data_accepted()\nnew function. The secret TLS handshake is interrupted as soon as possible returning\n0 from ha_quic_add_handshake_data(). The connection is also marked as\nrequiring a Retry packet to be sent (QUIC_FL_CONN_SEND_RETRY) from\nha_quic_add_handshake_data(). The the handshake I/O handler (quic_conn_io_cb())\nknows how to behave: kill the connection after having sent a Retry packet.\n\nqf_new_token, the QUIC frame struct for NEW_TOKEN frame has been modified\nto replace the ->data pointer by a 37-bytes static buffer.\n\nAbout TLS stack compatibility, this patch is supported by aws-lc. It is\ndisabled for wolfssl which does not support 0-RTT at this time thanks\nto HAVE_SSL_0RTT_QUIC.\n\nMust be backported as far as 2.6.","shortMessageHtmlLink":"BUG/MINOR: quic: O-RTT securing"}},{"before":"d315862e9c4908b15e07729fe0fc0a0064bac2bc","after":"2dee9e7e0ca42676f3ca2349b33e34612bc24bd6","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-08-29T16:31:17.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"WIP: to be merged into prev commit after reviewing","shortMessageHtmlLink":"WIP: to be merged into prev commit after reviewing"}},{"before":"4d3d3cca4f21cd824dd1d7445c2a691721185274","after":"d315862e9c4908b15e07729fe0fc0a0064bac2bc","ref":"refs/heads/fle-quic-bugs","pushedAt":"2024-08-29T15:14:55.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"haproxyFred","name":null,"path":"/haproxyFred","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45482268?s=80&v=4"},"commit":{"message":"BUG/MINOR: quic: O-RTT securing\n\nIt has been reported by Wedl Michael, a student at the University of Applied\nSciences St. Poelten, a potential vulnerability into haproxy as described below.\n\nAn attacker could have obtained a TLS session ticket after having established\na connection to an haproxy QUIC listener, using its real IP address. The\nattacker has not even to send a application level request (HTTP3). Then\nthe attacker could open a 0-RTT session with a spoofed IP address\ntrusted by the QUIC listen to bypass IP allow/block list and send HTTP3 requests.\n\nTo mitigate this vulnerability, one decided to use a token which can be provided\nto the client each time it successfully managed to connect to haproxy. These\ntokens may be reused for future connections to validate the address/path of the\nremote peer as this is done with the Retry token which is used for the current\nconnection, not the next one. Such tokens are transported by NEW_TOKEN frames\nwhich was not used at this time by haproxy.\n\nSo, each time a client connect to an haproxy QUIC listener with 0-RTT\nenabled, it is provided with such a token which can be reused for the\nnext 0-RTT session. If no such a token is presented by the client,\nhaproxy checks if the session is a 0-RTT one, so with early-data presented\nby the client. Contrary to the Retry token, the decision to refuse the\nconnection is made only when the TLS stack has been provided with\nenough early-data from the Initial ClientHello TLS message and when\nthese data have been accepted. Hopefully, this event arrives fast enough\nto allow haproxy to kill the connection if some early-data have been accepted\nwithout token presented by the client.\n\nThe token generation (quic_generate_token()) and verification (quic_token_chek())\nhave been implemented into quic_token.c and quic_token.h. The same method\nis used as for Retry tokens to build suche tokens to be reused for future\nconnections. The format is very simple: one byte for the format identifier\nto distinguish these new tokens for the Retry token, followed by a 32bits\ntimestamps. As this part is ciphered with AEAD as cryptographic\nalgorithm, 16 bytes are needed for the AEAD tag. 16 more random bytes\nare added to this token and a salt to derive the AEAD secret used\nto cipher the token. In addition to this salt, this is the client IP address\nwhich is used also as AAD to derive the AEAD secret. So, the length of\nthe token is fixed: 37 bytes.\n\nquic_build_post_handshake_frames() has been modified to build a NEW_TOKEN\nframe with this newly implemented token to be transported inside.\n\nquic_tls_derive_retry_token_secret() was renamed to quic_do_tls_derive_token_secret()\nand modified to be reused and derive the secret for the new token implementation.\n\nquic_token_validate() has been implemented to validate both the Retry and\nthe new token implemented by this patch. When this is a non-retry token\nwhich could not be validated, the datagram received is marked as requiring\na Retry packet to be sent, and no connection is created.\n\nWhen the Initial packet does not embed any non-retry token and if 0-RTT is enabled,\nthe connection is marked with this new flag: QUIC_FL_CONN_NO_TOKEN_RCVD. As soon\nas the TLS stack detects that some early-data have been provided and accepted by\nthe client, the connection is marked to be killed (QUIC_FL_CONN_TO_KILL) from\nha_quic_add_handshake_data(). This is done calling qc_ssl_eary_data_accepted()\nnew function. The secret TLS handshake is interrupted as soon as possible returning\n0 from ha_quic_add_handshake_data(). The connection is also marked as\nrequiring a Retry packet to be sent (QUIC_FL_CONN_SEND_RETRY) from\nha_quic_add_handshake_data(). The the handshake I/O handler (quic_conn_io_cb())\nknows how to behave: kill the connection after having sent a Retry packet.\n\nqf_new_token, the QUIC frame struct for NEW_TOKEN frame has been modified\nto replace the ->data pointer by a 37-bytes static buffer.\n\nMust be backported as far as 2.6.","shortMessageHtmlLink":"BUG/MINOR: quic: O-RTT securing"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEueQ6uwA","startCursor":null,"endCursor":null}},"title":"Activity · haproxytech/quic-dev"}