Opened 22 months ago

Closed 6 months ago

#1240 closed Bug / Defect (wontfix)

openvpn does not re-read CRLs upon client connect in "capath" mode

Reported by: muszi Owned by:
Priority: major Milestone: release 2.4.9
Component: Certificates Version: OpenVPN 2.4.7 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: CRL
Cc:

Description

I also reported this bug in the Debian Bug Tracking System:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942097

Dear Maintainer,

openvpn does not re-read CRLs upon client connect in "capath" mode (that is,
a directory containing trusted CA certificates and CRLs).

I have a two-level CA setup (one root CA and one intermediate CA that emits
both server and client certificates). Please find attached the test
certificates I have used.

Here is my server config:


# daemon openvpn-server-client
user nobody
group nogroup

proto udp

key /etc/openvpn/server.key
cert /etc/openvpn/server.pem
capath /etc/openvpn/ca-certs
remote-cert-tls client
duplicate-cn
dh /etc/openvpn/dh2048.pem
cipher AES-256-CBC

float
lport 1194

dev tun
server 192.0.2.0 255.255.255.0
comp-lzo
passtos

keepalive 5 20
ping-timer-rem
persist-tun
persist-key


My client config (I guess it does not matter, but anyway):


# daemon openvpn-client-server
user nobody
group nogroup

proto udp

key /etc/openvpn/client.key
cert /etc/openvpn/client.pem
ca /etc/openvpn/ca-certs/ca-test-root.pem
verify-x509-name "example.com" name
remote-cert-tls server
cipher AES-256-CBC

remote localhost
resolv-retry 30
float
rport 1194
nobind

dev tun
client
comp-lzo
passtos

keepalive 5 20
ping-timer-rem
persist-tun
persist-key


I start the openvpn server with strace:

# strace -o /tmp/openvpn.strace openvpn --config config.server-client

... and watch openvpn accessing the capath directory in strace's log on another console:

# tail -f /tmp/openvpn.strace | grep -F "/etc/openvpn/ca-certs"

  • first client connects *

stat("/etc/openvpn/ca-certs/b60149e5.0", {st_mode=S_IFREG|0644, st_size=7339, ...}) = 0
openat(AT_FDCWD, "/etc/openvpn/ca-certs/b60149e5.0", O_RDONLY) = 5
stat("/etc/openvpn/ca-certs/b60149e5.1", 0x7ffd789d74c0) = -1 ENOENT (No such file or directory)
stat("/etc/openvpn/ca-certs/7f67f311.0", {st_mode=S_IFREG|0644, st_size=1870, ...}) = 0
openat(AT_FDCWD, "/etc/openvpn/ca-certs/7f67f311.0", O_RDONLY) = 5
stat("/etc/openvpn/ca-certs/7f67f311.1", 0x7ffd789d74c0) = -1 ENOENT (No such file or directory)
stat("/etc/openvpn/ca-certs/b60149e5.r0", {st_mode=S_IFREG|0644, st_size=1003, ...}) = 0
openat(AT_FDCWD, "/etc/openvpn/ca-certs/b60149e5.r0", O_RDONLY) = 5
stat("/etc/openvpn/ca-certs/b60149e5.r1", 0x7ffd789d7430) = -1 ENOENT (No such file or directory)
stat("/etc/openvpn/ca-certs/7f67f311.r0", {st_mode=S_IFREG|0644, st_size=991, ...}) = 0
openat(AT_FDCWD, "/etc/openvpn/ca-certs/7f67f311.r0", O_RDONLY) = 5
stat("/etc/openvpn/ca-certs/7f67f311.r1", 0x7ffd789d7430) = -1 ENOENT (No such file or directory)
stat("/etc/openvpn/ca-certs/7f67f311.r1", 0x7ffd789d7430) = -1 ENOENT (No such file or directory)

  • next client connects *

stat("/etc/openvpn/ca-certs/b60149e5.r1", 0x7ffd789d7430) = -1 ENOENT (No such file or directory)
stat("/etc/openvpn/ca-certs/7f67f311.r1", 0x7ffd789d7430) = -1 ENOENT (No such file or directory)
stat("/etc/openvpn/ca-certs/7f67f311.r1", 0x7ffd789d7430) = -1 ENOENT (No such file or directory)

  • another client connects *

stat("/etc/openvpn/ca-certs/b60149e5.r1", 0x7ffd789d7430) = -1 ENOENT (No such file or directory)
stat("/etc/openvpn/ca-certs/7f67f311.r1", 0x7ffd789d7430) = -1 ENOENT (No such file or directory)
stat("/etc/openvpn/ca-certs/7f67f311.r1", 0x7ffd789d7430) = -1 ENOENT (No such file or directory)

(7f67f311 is the root CA, b60149e5 is the intermediate CA)


strace log shows that CRLs are read only when the first client connects.
When the next client connects, CRLs are attempted to access only using a wrong
filename ("*.r1" instead of "*.r0"), and open obviously fails.

This is a security problem if I later revoke a certificate, upload the new CRL,
but it does not have effect.

Please feel free to contact me if you need any further information.

--
Regards,
Zsolt

-- openvpn --version
OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 20 2019
library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10
Originally developed by James Yonan
Copyright (C) 2002-2018 OpenVPN Inc <sales@…>
Compile time defines: enable_async_push=no enable_comp_stub=no enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=needless enable_fragment=yes enable_iproute2=yes enable_libtool_lock=yes enable_lz4=yes enable_lzo=yes enable_maintainer_mode=no enable_management=yes enable_multihome=yes enable_pam_dlopen=no enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_silent_rules=no enable_small=no enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_werror=no enable_win32_dll=yes enable_x509_alt_username=yes with_aix_soname=aix with_crypto_library=openssl with_gnu_ld=yes with_mem_check=no with_sysroot=no

-- System Information:
Debian Release: 10.1

APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'stable'), (500, 'oldstable')

Architecture: amd64 (x86_64)

Kernel: Linux 4.9.196 (SMP w/4 CPU cores)
Locale: LANG=en_US.ISO-8859-2, LC_CTYPE=en_US.ISO-8859-2 (charmap=ISO-8859-2), LANGUAGE=en_US.ISO-8859-2 (charmap=ISO-8859-2
Shell: /bin/sh linked to /usr/bin/dash
Init: none (chroot environment)

Versions of packages openvpn depends on:
ii debconf [debconf-2.0] 1.5.71
ii iproute2 4.20.0-2
ii libc6 2.28-10
ii liblz4-1 1.8.3-1
ii liblzo2-2 2.10-0.1
ii libpam0g 1.3.1-5
ii libpkcs11-helper1 1.25.1-1
ii libssl1.1 1.1.1d-0+deb10u1
ii libsystemd0 241-7~deb10u1
ii lsb-base 10.2019051400

Versions of packages openvpn recommends:
pn easy-rsa <none>

Versions of packages openvpn suggests:
ii openssl 1.1.1d-0+deb10u1
pn openvpn-systemd-resolved <none>
pn resolvconf <none>

-- debconf information:

openvpn/create_tun: false

Attachments (8)

ca-test-root.pem (1.8 KB) - added by muszi 22 months ago.
ca-test.pem (7.2 KB) - added by muszi 22 months ago.
crl-test-root.pem (991 bytes) - added by muszi 22 months ago.
crl-test.pem (1003 bytes) - added by muszi 22 months ago.
server.key (3.2 KB) - added by muszi 22 months ago.
server.pem (3.9 KB) - added by muszi 22 months ago.
client.key (3.2 KB) - added by muszi 22 months ago.
client.pem (1.9 KB) - added by muszi 22 months ago.

Download all attachments as: .zip

Change History (17)

Changed 22 months ago by muszi

Attachment: ca-test-root.pem added

Changed 22 months ago by muszi

Attachment: ca-test.pem added

Changed 22 months ago by muszi

Attachment: crl-test-root.pem added

Changed 22 months ago by muszi

Attachment: crl-test.pem added

Changed 22 months ago by muszi

Attachment: server.key added

Changed 22 months ago by muszi

Attachment: server.pem added

Changed 22 months ago by muszi

Attachment: client.key added

Changed 22 months ago by muszi

Attachment: client.pem added

comment:1 Changed 22 months ago by Pippin

Hi, just like to add this as it seems to confirm:
https://redmine.pfsense.org/issues/9915

"While the new structure functions well at startup,
it does appear as though the CRL status is cached at startup.
When the CRL files are updated, it doesn't look like they are re-read,
and revoked clients can still connect."

comment:2 Changed 21 months ago by tct

CC

comment:3 in reply to:  2 Changed 20 months ago by muszi

CC

Pardon?

comment:4 Changed 20 months ago by tct

"CC" is "Carbon Copy", which is the simplest way for me to follow this ticket with email updates. Sorry for any misunderstanding.

comment:6 Changed 13 months ago by Gert Döring

Same bug as #1257?

As a workaround, you can put both CA certs into one file, which works from 2.4.9 up (and always worked for mbedtls builds).

comment:7 in reply to:  6 Changed 13 months ago by WGH

Replying to Gert Döring:

Same bug as #1257?

As a workaround, you can put both CA certs into one file, which works from 2.4.9 up (and always worked for mbedtls builds).

I believe multiple CAs in one file has worked since forever, it's multiple CRLs (--crl-verify) in one file that has been fixed recently.

comment:8 Changed 13 months ago by WGH

I'm pretty sure it's a dup of #623, and the closing comment there sums up the situation pretty accurately (i.e. it's limitations of OpenSSL capath implementation).

Now that --crl-verify support for multiple CRLs is fixed, I believe in most cases it should be just used instead.

In case you want flexibility, you can always write a --tls-verify script. If you want performance as well, you can also write a plugin for it.

comment:9 Changed 6 months ago by Gert Döring

Milestone: release 2.4.7release 2.4.9
Resolution: wontfix
Status: newclosed

Closing this bug. From what I understand, we can't do anything about it, and --crl-verify got fixed in 2.4.9 to handle multiple CRLs.

Note: See TracTickets for help on using tickets.