REMOTE_USER environmental variable not set for TLSv1.3 connections

Bug #1867223 reported by JonH
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
apache2 (Ubuntu)
Fix Released
Undecided
Marc Deslauriers

Bug Description

The recent backport of TLSv1.3 code to Ubuntu 18.04's version of apache2 breaks wsgi scripts that use client certificate authentication because the REMOTE_USER environmental variable is not being set for a TLSv1.3 connection. I tracked down the cause and it is because this upstream patch has not been included: https://svn.apache.org/viewvc?view=revision&revision=1841218

Running Ubuntu 18.04.4 LTS
The bug was introduced in apache2-2.4.29-1ubuntu4.12
The affected source file is : httpd-2.4.29/modules/ssl/ssl_engine_kernel.c

What you expected to happen: When a wsgi script is called, using client certificate authentication, and a TLSv1.3 connection is negotiated, the environmental variable REMOTE_USER should be set to the client certificate's CN. (SSLUserName SSL_CLIENT_S_DN_CN is set in the apache config file)

What happened instead: The REMOTE_USER environmental variable doesn't exist unless I restrict the connection to TLSv1.2.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: apache2 2.4.29-1ubuntu4.12
ProcVersionSignature: Ubuntu 4.15.0-88.88-generic 4.15.18
Uname: Linux 4.15.0-88-generic x86_64
Apache2ConfdDirListing: False
Apache2Modules:
 AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
 httpd (pid 19397) already running
ApportVersion: 2.20.9-0ubuntu7.11
Architecture: amd64
Date: Thu Mar 12 23:09:34 2020
InstallationDate: Installed on 2020-03-04 (8 days ago)
InstallationMedia: Ubuntu-Server 18.04.4 LTS "Bionic Beaver" - Release amd64 (20200203.1)
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: apache2
UpgradeStatus: No upgrade log present (probably fresh install)
error.log:
 [Thu Mar 12 06:25:02.361354 2020] [ssl:warn] [pid 19397] AH01909: 127.0.1.1:443:0 server certificate does NOT include an ID which matches the server name
 [Thu Mar 12 06:25:02.361788 2020] [mpm_prefork:notice] [pid 19397] AH00163: Apache/2.4.29 (Ubuntu) OpenSSL/1.1.1 mod_wsgi/4.7.1 Python/3.6 configured -- resuming normal operations
 [Thu Mar 12 06:25:02.361812 2020] [core:notice] [pid 19397] AH00094: Command line: '/usr/sbin/apache2'
modified.conffile..etc.apache2.sites-available.default-ssl.conf: [modified]
mtime.conffile..etc.apache2.sites-available.default-ssl.conf: 2020-03-12T23:11:20.058759

Revision history for this message
JonH (jh-ml) wrote :
tags: added: regression-update
tags: added: bitesize
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

This isn't exactly the same but related to bug 1865900 and bug 1834671.
Overall triggered by bug 1845263 adding TLSv1.3

@Marc you did the former upload and since it is an update regression and would need push to -security I'd wanted to ask if you'd evaluate the patch above if you agree that it would alleviate some of the issues we see - at least this one here but maybe even a few that formerly thought they have bug 1865900 / bug 1834671.
For now setting to confirmed assigning to you for considering the linked change.

Changed in apache2 (Ubuntu):
status: New → Confirmed
assignee: nobody → Marc Deslauriers (mdeslaur)
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

I'll prepare some updates for testing, thanks.

Robie Basak (racb)
tags: added: bionic-openssl-1.1
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

I have uploaded an apache2 package to the security team PPA for testing here:

https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa

It includes the commit mentioned in this bug, along with a few others related to TLSv1.3.

@JonH: could you please test that package and see if it solves your issue? Thanks!

Revision history for this message
JonH (jh-ml) wrote :

I upgraded to your 2.4.29-1ubuntu4.13 on my test system and then one of my internal production systems and both TLSv1.2 and TLSv1.3 connections are now working correctly with client certificate authentication and wsgi scripts.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apache2 - 2.4.29-1ubuntu4.13

---------------
apache2 (2.4.29-1ubuntu4.13) bionic-security; urgency=medium

  * Add additional missing commits to TLSv1.3 support. (LP: #1867223)
    - debian/patches/tlsv1.3-support-2.patch: fix whitespace and copy/paste
      typos in modules/ssl/ssl_engine_kernel.c.
    - debian/patches/tlsv1.3-support-3.patch: fail with 403 if
      SSL_verify_client_post_handshake fails in
      modules/ssl/ssl_engine_kernel.c.
    - debian/patches/tlsv1.3-support-4.patch: disable AUTO_RETRY mode for
      OpenSSL 1.1.1, which fixes post-handshake authentication in
      modules/ssl/ssl_engine_init.c.
    - debian/patches/tlsv1.3-support-5.patch: retrieve and set
      sslconn->client_cert here for both "modern" and classic access
      control in modules/ssl/ssl_engine_kernel.c.

 -- Marc Deslauriers <email address hidden> Fri, 13 Mar 2020 08:26:16 -0400

Changed in apache2 (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.