[Impact]
Due to the case comparison differences in the Turkish locale, some routines in
OpenSSL fail to recognize some algorithm names as valid, unexpectedly breaking
crypto.
[Test Plan]
This bug is really easy to trigger:
sudo locale-gen tr_TR.UTF-8
LANG=C curl https://ubuntu.com/ > /dev/null # This work
LANG=tr_TF.UTF-8 curl https://ubuntu.com/ > /dev/null # This fails
The error is curl: (35) error:03000072:digital envelope routines::decode error
[Where problems could occur]
This patch set is relatively massive, and can cause regressions, as illustrated
by the patch #5 which fixes one such regression. Those regressions would likely
show up as either libssl crashes, in case of uninitialized objects, or as
algorithm selection failures if somehow the case comparison is buggy.
[Other Info]
The fix has already been released upstream as part of their 3.0.3 release.
[Original report]
I noticed this when I checked "ua status". It alerted me that I should check my openssl configuration.
"ua status
Failed to access URL: https://contracts.canonical.com/v1/resources?architecture=amd64&kernel=5.15.0-25-generic&series=jammy
Cannot verify certificate of server
Please check your openssl configuration."
I also figured wget&curl doesn't work with https:// URLs at all.
On web I found:
https://github.com/openssl/openssl/issues/18039
So I changed locale to C_UTF-8
#locale
LANG=tr_TR.UTF-8
LANGUAGE=
LC_CTYPE="tr_TR.UTF-8"
LC_NUMERIC=tr_TR.UTF-8
LC_TIME=tr_TR.UTF-8
LC_COLLATE="tr_TR.UTF-8"
LC_MONETARY=tr_TR.UTF-8
LC_MESSAGES="tr_TR.UTF-8"
LC_PAPER=tr_TR.UTF-8
LC_NAME=tr_TR.UTF-8
LC_ADDRESS=tr_TR.UTF-8
LC_TELEPHONE=tr_TR.UTF-8
LC_MEASUREMENT=tr_TR.UTF-8
LC_IDENTIFICATION=tr_TR.UTF-8
LC_ALL=
casaba@ship-macbook:/backups$ sudo locale-gen c
ca_AD ca_ES.UTF-8 ca_IT ckb_IQ cs_CZ cy_GB.UTF-8
ca_AD.UTF-8 ca_ES@valencia ca_IT.UTF-8 cmn_TW cs_CZ.UTF-8
ca_ES ca_FR ce_RU crh_UA cv_RU
ca_ES@euro ca_FR.UTF-8 chr_US csb_PL cy_GB
casaba@ship-macbook:/backups$ sudo locale-gen C.UTF-8
Generating locales (this might take a while)...
C.UTF-8... done
Generation complete.
casaba@ship-macbook:/backups$ update-locale LANG=C.UTF8
casaba@ship-macbook:/backups$ sudo update-locale LANG=C.UTF8
Now the result is (after logout/login)
ua status
SERVICE ENTITLED STATUS DESCRIPTION
cc-eal yes n/a Common Criteria EAL2 Provisioning Packages
cis yes n/a Security compliance and audit tools
esm-infra yes n/a UA Infra: Extended Security Maintenance (ESM)
fips yes n/a NIST-certified core packages
fips-updates yes n/a NIST-certified core packages with priority security updates
livepatch yes n/a Canonical Livepatch service
Enable services with: ua enable <service>
Account: <email address hidden>
Subscription: <email address hidden>
If Ubuntu 22 ships with current configuration, entire TR will suffer considering you can't find http:// downloads anymore.
ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: openssl 3.0.2-0ubuntu1
ProcVersionSignature: Ubuntu 5.15.0-25.25-generic 5.15.30
Uname: Linux 5.15.0-25-generic x86_64
ApportVersion: 2.20.11-0ubuntu82
Architecture: amd64
CasperMD5CheckResult: unknown
Date: Thu Apr 14 10:21:09 2022
InstallationDate: Installed on 2021-12-29 (105 days ago)
InstallationMedia: Lubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819)
SourcePackage: openssl
UpgradeStatus: Upgraded to jammy on 2022-04-09 (4 days ago)
mtime.conffile..etc.ssl.openssl.cnf: 2022-04-10T13:11:20.222505
I've uploaded a fix to the jammy unapproved queue, but it's a rather large patch and I think it should be reviewed by another member of the release team.