Change Details

During implementation of mTLS authentication for the VyOS REST API, we discovered that nginx 1.22.1 (shipped with VyOS 1.5) does not correctly populate $ssl_client_verify when TLSv1.3 is used for client certificate authentication. Specifically: - With TLSv1.2: $ssl_client_verify is set to SUCCESS/FAILED as expected - With TLSv1.3: $ssl_client_verify remains empty, preventing the application from identifying authenticated clients This is a known limitation related to TLSv1.3 post-handshake authentication (RFC 8446 section 4.6.2), which nginx handles differently from TLSv1.2. Security implications of remaining on TLSv1.2 for mTLS: - TLSv1.2 is still considered secure when properly configured with strong cipher suites - However, TLSv1.3 provides forward secrecy improvements and removes legacy cipher suites - Restricting mTLS to TLSv1.2 only leaves a gap in the security posture for certificate-based auth Questions: 1. Is there a plan to upgrade nginx in VyOS to a version with proper TLSv1.3 post-handshake auth support? (nginx 1.25+ handles this correctly) 2. Alternatively, would enabling the ssl_early_data or adjusting TLSv1.3 session handling be feasible? 3. Is the current nginx 1.22.1 version pinned for a specific reason (e.g. Debian stable package availability)? Estimated effort for nginx upgrade: medium — primarily packaging and regression testing of existing HTTPS/API functionality. Happy to discuss further or assist with testing.

During implementation of mTLS authentication for the VyOS REST API, I discovered that nginx 1.22.1 (shipped with VyOS 1.5) does not correctly populate $ssl_client_verify when TLSv1.3 is used for client certificate authentication. Specifically: - With TLSv1.2: $ssl_client_verify is set to SUCCESS/FAILED as expected - With TLSv1.3: $ssl_client_verify remains empty, preventing the application from identifying authenticated clients This is a known limitation related to TLSv1.3 post-handshake authentication (RFC 8446 section 4.6.2), which nginx handles differently from TLSv1.2. Security implications of remaining on TLSv1.2 for mTLS: - TLSv1.2 is still considered secure when properly configured with strong cipher suites - However, TLSv1.3 provides forward secrecy improvements and removes legacy cipher suites - Restricting mTLS to TLSv1.2 only leaves a gap in the security posture for certificate-based auth Questions: 1. Is there a plan to upgrade nginx in VyOS to a version with proper TLSv1.3 post-handshake auth support? (nginx 1.25+ handles this correctly) 2. Alternatively, would enabling the ssl_early_data or adjusting TLSv1.3 session handling be feasible? 3. Is the current nginx 1.22.1 version pinned for a specific reason (e.g. Debian stable package availability)? Estimated effort for nginx upgrade: medium — primarily packaging and regression testing of existing HTTPS/API functionality. Happy to discuss further or assist with testing.

During implementation of mTLS authentication for the VyOS REST API, weI discovered that nginx 1.22.1 (shipped with VyOS 1.5) does not correctly populate $ssl_client_verify when TLSv1.3 is used for client certificate authentication. Specifically: - With TLSv1.2: $ssl_client_verify is set to SUCCESS/FAILED as expected - With TLSv1.3: $ssl_client_verify remains empty, preventing the application from identifying authenticated clients This is a known limitation related to TLSv1.3 post-handshake authentication (RFC 8446 section 4.6.2), which nginx handles differently from TLSv1.2. Security implications of remaining on TLSv1.2 for mTLS: - TLSv1.2 is still considered secure when properly configured with strong cipher suites - However, TLSv1.3 provides forward secrecy improvements and removes legacy cipher suites - Restricting mTLS to TLSv1.2 only leaves a gap in the security posture for certificate-based auth Questions: 1. Is there a plan to upgrade nginx in VyOS to a version with proper TLSv1.3 post-handshake auth support? (nginx 1.25+ handles this correctly) 2. Alternatively, would enabling the ssl_early_data or adjusting TLSv1.3 session handling be feasible? 3. Is the current nginx 1.22.1 version pinned for a specific reason (e.g. Debian stable package availability)? Estimated effort for nginx upgrade: medium — primarily packaging and regression testing of existing HTTPS/API functionality. Happy to discuss further or assist with testing.