Opened 7 months ago

Last modified 6 months ago

#1240 new Bug / Defect

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

Reported by: muszi Owned by:
Priority: major Milestone: release 2.4.7
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 7 months ago.
ca-test.pem (7.2 KB) - added by muszi 7 months ago.
crl-test-root.pem (991 bytes) - added by muszi 7 months ago.
crl-test.pem (1003 bytes) - added by muszi 7 months ago.
server.key (3.2 KB) - added by muszi 7 months ago.
server.pem (3.9 KB) - added by muszi 7 months ago.
client.key (3.2 KB) - added by muszi 7 months ago.
client.pem (1.9 KB) - added by muszi 7 months ago.

Download all attachments as: .zip

Change History (13)

Changed 7 months ago by muszi

Attachment: ca-test-root.pem added

Changed 7 months ago by muszi

Attachment: ca-test.pem added

Changed 7 months ago by muszi

Attachment: crl-test-root.pem added

Changed 7 months ago by muszi

Attachment: crl-test.pem added

Changed 7 months ago by muszi

Attachment: server.key added

Changed 7 months ago by muszi

Attachment: server.pem added

Changed 7 months ago by muszi

Attachment: client.key added

Changed 7 months ago by muszi

Attachment: client.pem added

comment:1 Changed 7 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 6 months ago by tincantech

CC

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

CC

Pardon?

comment:4 Changed 6 months ago by tincantech

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

Note: See TracTickets for help on using tickets.