I re-ran the test as follows to actually test the server side with only
the packaged executables.
I used this command for the server side:
/usr/bin/openssl s_server -key key.pem -cert cert.pem -status_file
openssl-1.1.1/test/recipes/ocsp-response.der -Verify 5
with ldd showing it loading its ssl & crypt libraries from
/usr/lib/x86_64-linux-gnu:
ldd /usr/bin/openmssl
linux-vdso.so.1 (0x00007ffe6ee65000)
libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1
(0x00007f44027c4000)
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
(0x00007f44022f9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f44020da000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4401ce9000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4401ae5000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4402d04000)
I built the client from 18.06.16 source with tracing enabled and used it
for both tests and ran it with this command:
LD_LIBRARY_PATH=openssl-1.1.1/build_shared
openssl-1.1.1/build_shared/apps/openssl s_client -status -trace -cert
cert.pem -key key.pem
with ldd showing it loading its own libraries:
LD_LIBRARY_PATH=openssl-1.1.1/build_shared ldd
openssl-1.1.1/build_shared/apps/openssl
linux-vdso.so.1 (0x00007fff51ff9000)
libssl.so.1.1 => openssl-1.1.1/build_shared/libssl.so.1.1
(0x00007fc8c28b4000)
libcrypto.so.1.1 => openssl-1.1.1/build_shared/libcrypto.so.1.1
(0x00007fc8c23e9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fc8c21ca000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc8c1dd9000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc8c1bd5000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc8c2dfe000)
The following logs show the difference between having:
ii openssl 1.1.1-1ubuntu2.1~18.04.15
amd64 Secure Sockets Layer toolkit - cryptographic
utility
and having:
ii openssl 1.1.1-1ubuntu2.1~18.04.16
amd64 Secure Sockets Layer toolkit - cryptographic
utility
ubuntu@bionic-lp-1940141:~$ grep -B1 -A4 CertificateRequest
s_client-18.04.16-from-source-with-trace_server-18.04.15-from-package.log
Inner Content Type = Handshake (22)
CertificateRequest, Length=1570
request_context (len=0):
extensions, length = 1567
extension_type=status_request(5), length=1521
0000 - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2 ....0..........
ubuntu@bionic-lp-1940141:~$ grep -B1 -A4 CertificateRequest
s_client-18.04.16-from-source-with-trace_server-18.04.16-proposed-from-package.log
Inner Content Type = Handshake (22)
CertificateRequest, Length=45
request_context (len=0):
extensions, length = 42
extension_type=signature_algorithms(13), length=38
ecdsa_secp256r1_sha256 (0x0403)
This is indicative of the fix working.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1940141
Title:
OpenSSL servers can send a non-empty status_request in a
CertificateRequest
Status in openssl package in Ubuntu:
Fix Released
Status in openssl source package in Bionic:
Fix Committed
Bug description:
[Impact]
openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a
CertificateRequest message to the client with a non-empty
status_request extension.
This issue was fixed in openssl-1.1.1d and is included in Focal
onward.
Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767
Upstream patch review at https://github.com/openssl/openssl/pull/9780
The issue leads to various client failures with TLS 1.3 as described
in, e.g.
https://github.com/golang/go/issues/35722
https://github.com/golang/go/issues/34040
[Test Plan]
The issue can be reproduced by building with `enable-ssl-trace`
and then running `s_server` like this:
```
openssl s_server -key key.pem -cert cert.pem -status_file
test/recipes/ocsp-response.der -Verify 5
```
And running `s_client` like this:
```
openssl s_client -status -trace -cert cert.pem -key key.pem
```
The output shows a `status_request` extension in the
`CertificateRequest` as follows:
Received Record
Header:
Version = TLS 1.2 (0x303)
Content Type = ApplicationData (23)
Length = 1591
Inner Content Type = Handshake (22)
CertificateRequest, Length=1570
request_context (len=0):
extensions, length = 1567
extension_type=status_request(5), length=1521
0000 - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2
....0..........
000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01
0.....+.....0..
001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86
....0...0......
002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47
0..1.0...U....G
...more lines omitted...
If the `status_request` extension is present in a
`CertificateRequest` then it must be empty according to RFC8446,
Sec. 4.4.2.1.
[Where problems could occur]
The patch disables the `status_request` extension inside a
`CertificateRequest`. Applications expecting the incorrect,
non-empty reply for the `status_request` extension will break
with this patch.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
