Your message dated Tue, 18 Apr 2023 20:49:12 +0000
with message-id <e1posgg-00e3xx...@fasolo.debian.org>
and subject line Bug#1034577: fixed in libgwenhywfar 5.10.1-2
has caused the Debian Bug report #1034577,
regarding SSL certificate hostname check too restrictive
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1034577: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034577
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libgwenhywfar79
Version: 5.6.0-2
Severity: serious
Tags: patch upstream fixed-upstream
Forwarded: https://www.aquamaniac.de/rdm/issues/295
A few days ago the communication to the banking server
https://hbci-pintan.gad.de/ doesn't work anymore because the already accepted
server certificate is rejected with the message "Owner of certificate does not
match hostname".
The issue could be easily reproduced with bogus anonymous credentials as below
(the error is triggered before authentication or credentials are needed). The
only relevant parameter for the reproduction is the "--server" parameter, all
other parameters are just there as the command wants them to be present.
```
$ aqhbci-tool4 adduser --username=Anonymous \
--tokentype=pintan \
--user=anonymous \
--bank=0 \
--server=https://hbci-pintan.gad.de/
3:2023/04/18 21-14-36:(null)(50094):banking_update.c: 610: No AqBanking config
folder found at [/home/user/.aqbanking/settings6/users] (-1)
3:2023/04/18 21-14-36:(null)(50094):banking_update.c: 610: No AqBanking config
folder found at [/home/user/.aqbanking/settings/users] (-1)
3:2023/04/18 21-14-36:(null)(50094):banking_update.c: 411: There is no old
settings folder, need initial setup
```
On a system which didn't have any AqBanking setup before, a new user with
unique id 1 will be created (see output of "aqhbci-tool4 listusers").
```
$ aqhbci-tool4 listusers
User 0: Bank: de/0 User Id: anonymous Customer Id: anonymous Unique Id: 1
```
Now, for reproduction of the error, you need to retrieve the server
certificate, which will implicitly validate it.
```
$ aqhbci-tool4 getcert --user=1
5:2023/04/18 21-22-43:aqbanking(50117):siotlsext.c: 233: Status for
certificate 76:42:76:BF:8E:E5:95:22:ED:A7:85:10:8F:52:96:73" has changed to
"Certificate owner does not match hostname" (00000000->00000020), need to
present
4:2023/04/18 21-22-43:gwen(50117):syncio_tls.c: 137: No checkCertFn set, using
GWEN_GUI
===== Certificate Received =====
The following certificate has been received:
Name : fints1.atruvia.de
Organisation : Atruvia AG
Department : unknown
Country : DE
City : Karlsruhe
State : Baden-W?rttemberg
Valid after : 2023/03/21 08:14:05
Valid until : 2024/03/21 08:09:00
Hash (MD5) : 76:42:76:BF:8E:E5:95:22:ED:A7:85:10:8F:52:96:73
Hash (SHA1) : 8E:C0:B3:C1:F7:B6:0A:9B:8F:86:00:D0:F2:72:E9:F6:72:EE:D7:18
Hash (SHA512):
DE:A2:D8:16:29:3B:64:83:34:C4:BD:5C:08:40:DE:45:26:BA:EF:5E:79:E9:21:52:77:DE:3A:A2:F6:B8:98:E4:62:BE:28:31:03:57:D8:67:40:64:35:C7:A1:7C:31:AB:C3:B2:7C:B3:3B:98:31:CE:DE:23:36:50:F9:F2:77:E1
Status : Certificate owner does not match hostname
Do you wish to accept this certificate?
(1) Yes (2) No
Please enter your choice: 2
5:2023/04/18 21-22-52:aqbanking(50117):siotlsext.c: 360: User response to
presentation of cert "76:42:76:BF:8E:E5:95:22:ED:A7:85:10:8F:52:96:73"
(Certificate owner does not match hostname): -108
3:2023/04/18 21-22-52:gwen(50117):syncio_tls.c: 1399: Peer cert not accepted
(-108), aborting
Could not connect to server
3:2023/04/18 21-22-52:aqhbci(50117):provider_online.c: 919: Could not connect
to server (-108)
Could not connect to server
3:2023/04/18 21-22-52:aqhbci-tool(50117):getcert.c: 98: Error -108 [Unknown
error]
3:2023/04/18 21-22-52:aqhbci-tool(50117):aqhbci-tool.c: 275: Error calling
control function (3)
```
Here you can see that Gwenhywfar reports the certificate as invalid with reason
"Certificate owner does not match hostname".
However, the very same configuration was working in the past just fine. Most
likely something on the server end changed.
Inspecting the certificate sent by the server shows that the "Common Name"
field is set to "fints1.atruvia.de", but also that a SubjectAltName extension
is present, which makes the certificate valid also for other hostnames,
including "hbci-pintan.gad.de".
Quoting https://en.wikipedia.org/wiki/Subject_Alternative_Name:
> RFC 2818 (May 2000) specifies Subject Alternative Names as the preferred
> method of adding DNS names to certificates, deprecating the previous method
> of putting DNS names in the commonName field. Google Chrome version 58
> (March 2017) removed support for checking the commonName field at all,
> instead only looking at the SANs.
So, if the certificate is valid, but AqBanking doesn't accept it, I concluded
to have found a bug.
Looking into the code, I think the culprit is some incomplete hostname
verification in Gwenhywfar's source file src/sio/syncio_tls.c at these lines
(line numbers based on current Git master):
```
1041 rv=gnutls_x509_crt_get_dn_by_oid(cert, GNUTLS_OID_X520_COMMON_NAME,
0, 0, buffer1, &size);
1042 if (rv==0) {
1043 GWEN_SslCertDescr_SetCommonName(certDescr, buffer1);
1044 if (xio->hostName && strcasecmp(xio->hostName, buffer1)!=0) {
1045 DBG_INFO(GWEN_LOGDOMAIN, "Owner of certificate does not match
hostname");
1046 errFlags|=GWEN_SSL_CERT_FLAGS_BAD_HOSTNAME;
1047 }
```
Apparently only the Common Name of the certificate is checked, but the "Subject
Alternative Name" extension is not.
Digging a bit more, I realized that the hostname validation seems to be
implemented twice. Within the same the function the following code block is
executed just a few lines before, which seems to be fully sufficient for a
proper hostname validation.
```
975 DBG_INFO(GWEN_LOGDOMAIN, "Checking hostname [%s]", xio->hostName);
976 if (!gnutls_x509_crt_check_hostname(cert, xio->hostName)) {
977 DBG_WARN(GWEN_LOGDOMAIN,
978 "Certificate was not issued for this host");
979 GWEN_Gui_ProgressLog(0, GWEN_LoggerLevel_Warning,
980 I18N("Certificate was not issued for this
host"));
981 errFlags|=GWEN_SSL_CERT_FLAGS_BAD_HOSTNAME;
982 }
```
Trusting the GnuTLS API to do a thorough hostname check already, I consider the
additional manual comparison of only the certificate's CN bogus. So, the fix is
to just drop these lines (patch attached and already committed upstream).
From: Micha Lenk <mi...@lenk.info>
Date: Sun, 16 Apr 2023 15:12:45 +0200
Bug: https://www.aquamaniac.de/rdm/issues/295
Origin: upstream,
https://www.aquamaniac.de/rdm/projects/gwenhywfar/repository/revisions/a901426cfa0d555b7920dc39358af293dedafe85
Last-Update: 2023-04-18
Subject: Remove duplicate hostname check
The hostname in the certificate is checked already a few lines above by calling
gnutls_x509_crt_check_hostname(). No need to check it here again.
This also fixes the bad hostname validation in cases where the used server name
is only available in the SubjectAltName extension of the certificate, and not
in its Distinguished Name (DN).
Fixes #295.
---
src/sio/syncio_tls.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/src/sio/syncio_tls.c b/src/sio/syncio_tls.c
index 6c81d58a..34c35cd7 100644
--- a/src/sio/syncio_tls.c
+++ b/src/sio/syncio_tls.c
@@ -1041,10 +1041,6 @@ int GWEN_SyncIo_Tls_GetPeerCert(GWEN_SYNCIO *sio)
rv=gnutls_x509_crt_get_dn_by_oid(cert, GNUTLS_OID_X520_COMMON_NAME, 0,
0, buffer1, &size);
if (rv==0) {
GWEN_SslCertDescr_SetCommonName(certDescr, buffer1);
- if (xio->hostName && strcasecmp(xio->hostName, buffer1)!=0) {
- DBG_INFO(GWEN_LOGDOMAIN, "Owner of certificate does not match
hostname");
- errFlags|=GWEN_SSL_CERT_FLAGS_BAD_HOSTNAME;
- }
}
size=sizeof(buffer1)-1;
--
2.30.2
--- End Message ---
--- Begin Message ---
Source: libgwenhywfar
Source-Version: 5.10.1-2
Done: Micha Lenk <mi...@debian.org>
We believe that the bug you reported is fixed in the latest version of
libgwenhywfar, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1034...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Micha Lenk <mi...@debian.org> (supplier of updated libgwenhywfar package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Format: 1.8
Date: Tue, 18 Apr 2023 22:12:21 +0200
Source: libgwenhywfar
Architecture: source
Version: 5.10.1-2
Distribution: unstable
Urgency: medium
Maintainer: Micha Lenk <mi...@debian.org>
Changed-By: Micha Lenk <mi...@debian.org>
Closes: 1034577
Changes:
libgwenhywfar (5.10.1-2) unstable; urgency=medium
.
* Add patch 0001-Remove-duplicate-hostname-check.patch to fix too restrictive
SSL hostname check with SAN certifices (Closes: #1034577).
Checksums-Sha1:
671b9f5e655bdb81c0dde5f4fa97d9ffa84912a8 3186 libgwenhywfar_5.10.1-2.dsc
7d580b92edc38802f38d2fb895cf57aff75858ef 33136
libgwenhywfar_5.10.1-2.debian.tar.xz
c5defcf05b1ec2456774c693f9df1f033a235ef1 6936
libgwenhywfar_5.10.1-2_source.buildinfo
Checksums-Sha256:
b1e12f09ffd2a9a02070ee80d7d8454b32a57332f91dc6c532f2e78a81fb4a89 3186
libgwenhywfar_5.10.1-2.dsc
58186efe1345602c2c66636c43f5cb21ed2d6c5785de83dba1a07805ba88078e 33136
libgwenhywfar_5.10.1-2.debian.tar.xz
343fd1b15ebaaec1a6fd0bfc9f6396307002cd27d1d1c460737841c58a48df1f 6936
libgwenhywfar_5.10.1-2_source.buildinfo
Files:
334f7393d96d6ca6766f4d1bb6e739c1 3186 libs optional libgwenhywfar_5.10.1-2.dsc
f8857243f50aca2a4a828903127189a7 33136 libs optional
libgwenhywfar_5.10.1-2.debian.tar.xz
f0495cfca4618cc33915b7696d493a39 6936 libs optional
libgwenhywfar_5.10.1-2_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQJFBAEBCAAvFiEEo+u0H8Wr1nXO5BxF6mymuVG4UTkFAmQ++fURHG1pY2hhQGRl
Ymlhbi5vcmcACgkQ6mymuVG4UTnu+g//Y2NnzSpc34T0qeuIN/DJ+Hxg3PuhzqA0
VBpn5R8ow6bahICenXfYhqfHr/0lnRwmwxUr+ho80F/eljVn1d6dwAOTH0HzW3Ou
dZDRc3tRw1SqvKxlkv/6pbafGYSxxZ36QiDjjgmaMjsFwGqw7AkRGny1B44fgoUY
gmuIoznXW53S0yh7k/UkuRgLCwRL2ydDv61fnthuPs7l5guyY78wyZ7VLlBhI7BK
4zvfFksAYmbkL0Sl0LvW812i4Yt3zyPl6RbPlulSSc/v2EFqXtkthLyw8SjYF4il
pCYofxCtydy3SiWg8RdszeJ3iYejpR7bI5it4E9JsSSZu/4wSyrZXrgl92xQyEdm
8VwSuijw6HpiIx+LeHCLFpiOUj9YXStTOvqPO4HJn0bVpouju+4HV6NYulVrEwzk
g9p+lWU/3p0hvTzDEbb9rWYFfYVaZLSxWCsu8V62AFWcBnk9WE7qZDTJb7ZlgIxJ
og3Nxc4A8TlntG5tEIP7+rmz6CokOdfGQso7N9xH4Gp1k5Ex6+3kqZ5eulVQwK9D
zHhRIMbovx0aGyHrSfAcm5xor1kzypFgXokGgKvT6+3bzlL/qkAjVbiZZ0japSbk
+S1E4mDAazeuW1+iPG7ziFf/Qe/wzmpnLuWUC5rqM4INo0o1aeZE24l80wHkTutl
M6cjq22sdwo=
=uwOD
-----END PGP SIGNATURE-----
--- End Message ---
