[PATCH] QUIC: OpenSSL compatibility layer

Roman Arutyunyan arut at nginx.com
Wed Feb 22 14:20:35 UTC 2023


Hi,

On Wed, Feb 08, 2023 at 07:17:09PM +0400, Sergey Kandaurov wrote:
> On Wed, Feb 08, 2023 at 06:41:38PM +0400, Roman Arutyunyan wrote:
> > # HG changeset patch
> > # User Roman Arutyunyan <arut at nginx.com>
> > # Date 1675867049 -14400
> > #      Wed Feb 08 18:37:29 2023 +0400
> > # Branch quic
> > # Node ID a3142c8833f5bf1186599e7938141f5062fac4a2
> > # Parent  3c33d39a51d334d99fcc7d2b45e8d8190c431492
> > QUIC: OpenSSL compatibility layer.
> > 
> > The change allows to compile QUIC with OpenSSL which lacks BoringSSL QUIC API.
> > 
> > This implementation does not support 0-RTT.
> > 
> 
> Looks good.

A short summary about 0-RTT support in the compatibility mode.

One of the differences between QUIC and TLS protocols is missing
EndOfEarlyData message in QUIC compared to TLS[1].  It does not manifest itself
unless 0-RTT is sent by client.  When 0-RTT is sent, EndOfEarlyData should be
injected into the TLS handshake message stream while converting QUIC to TLS
to satisfy OpenSSL state machine.  The message itself is quite simple, but it
changes the handshake hash, which leads to significant consequences like
mismatching Finished MAC and PSK Binder.  While in theory they can be
recalculated, the solution looks relatively complex.  I suggest that we
postpone this work.

Also, here's a small update to the original patch:

diff --git a/README b/README
--- a/README
+++ b/README
@@ -71,6 +71,7 @@ 2. Building from sources
     Alternatively, nginx can be configured with OpenSSL compatibility
     layer, which emulates BoringSSL QUIC API for OpenSSL.  This mode is
     enabled by default if native QUIC support is not detected.
+    0-RTT is not supported in OpenSSL compatibility mode.
 
     Clone the NGINX QUIC repository
 

[1] https://datatracker.ietf.org/doc/html/rfc9001#section-8.3

--
Roman Arutyunyan


More information about the nginx-devel mailing list