Package: libneon27-gnutls
Version: 0.30.2-3
Severity: normal
Tags: patch
Hello maintainers!
Since a little while ago, I could no longer synchronize my laptop with
my Radicale server:
What happens:
--8<---------------cut here---------------start------------->8---
$ syncevolution radicale
[WARNING] radicale: ignoring username , it is not needed
[WARNING] radicale: ignoring username , it is not needed
[INFO @radicale] target side of local sync ready
[INFO @radicale] @radicale/cal-personal: using configured
database=https://butters.digitalbrains.com:5232/peter/calendars/personal.ics/
[ERROR @radicale] transport problem: REPORT 'check for items': Neon error code
1, no HTTP status: Certificate verification error: unrecognized errors (524288)
[...]
--8<---------------cut here---------------end--------------->8---
What should happen:
--8<---------------cut here---------------start------------->8---
[WARNING] radicale: ignoring username , it is not needed
[WARNING] radicale: ignoring username , it is not needed
[INFO @radicale] target side of local sync ready
[INFO @radicale] @radicale/cal-personal: using configured
database=https://butters.digitalbrains.com:5232/peter/calendars/personal.ics/
[INFO @radicale] @radicale/cal-vakanties: using configured
database=https://butters.digitalbrains.com:5232/peter/calendars/vakanties.ics/
[INFO @radicale] @radicale/con-personal: using configured
database=https://butters.digitalbrains.com:5232/peter/contacts/personal.vcf/
[INFO @radicale] @radicale/tasks-personal: using configured
database=https://butters.digitalbrains.com:5232/peter/tasks/personal.ics/
[INFO @radicale] @radicale/cal-personal: starting normal sync, two-way (peer is
server)
[INFO @radicale] @radicale/cal-vakanties: starting normal sync, two-way (peer
is server)
[INFO @radicale] @radicale/con-personal: starting normal sync, two-way (peer is
server)
[INFO @radicale] @radicale/tasks-personal: starting normal sync, two-way (peer
is server)
[...]
--8<---------------cut here---------------end--------------->8---
cadaver fares no better:
--8<---------------cut here---------------start------------->8---
$ cadaver https://butters.digitalbrains.com:5232/peter/
Could not open collection:
Certificate verification error: unrecognized errors (524288)
dav:/peter/?
--8<---------------cut here---------------end--------------->8---
The Radicale server is the latest from debian-oldstable/stretch:
radicale 1.1.1+20160115-4.
It turns out that GnuTLS requests OCSP stapling from the Radicale
server, but the Radicale server does not include a stapled response.
When libneon invokes GnuTLS's gnutls_certificate_verify_peers2(), it
returns a bit set in gnutls_certificate_status_t:
/**
* gnutls_certificate_status_t:
* @GNUTLS_CERT_MISSING_OCSP_STATUS: The certificate requires the server to
send the certifiate status, but no status was received.
*/
typedef enum {
GNUTLS_CERT_MISSING_OCSP_STATUS = 1 << 19,
} gnutls_certificate_status_t;
This is the 524288 (1 << 19) seen in the error messages above.
The conservative patch is simple, and has been attached. It is for
Debian stable, because I currently don't have a properly configured VM
for doing it based on unstable, and it is so trivial that I don't think
this will present any problems to you. Please let me know if I am
mistaken in this or you'd like me to do further tests.
For discussion I here include the patch:
- if (status && status != GNUTLS_CERT_INVALID) {
+ if (status && status != GNUTLS_CERT_INVALID
+ && status != GNUTLS_CERT_MISSING_OCSP_STATUS) {
char *errstr = verify_error_string(status);
ne_set_error(sess, _("Certificate verification error: %s"), errstr);
ne_free(errstr);
return NE_ERROR;
}
I don't really understand why GNUTLS_CERT_INVALID does /not/ cause
certificate verification to fail. But it could be that this bit is never
set alone, always together with a more precise failure bit, and as such
it never triggers on modern GnuTLS's (since it tests that only that bit
is set). This test was introduced in neon upstream in this git commit:
https://github.com/notroj/neon/commit/b514d5b286eeee4155431c155d051fa4aa306fd4
commit b514d5b
Author: Joe Orton <not...@users.noreply.github.com>
Date: Tue Aug 11 14:15:33 2009 +0000
With the patch applied, syncevolution again works as above in "What
should happen", and cadaver is also much happier:
--8<---------------cut here---------------start------------->8---
$ cadaver https://butters.digitalbrains.com:5232/peter/
Authentication required for Radicale - Password Required on server
`butters.digitalbrains.com':
Username: peter
Password:
dav:/peter/> ls
Listing collection `/peter/': succeeded.
[...]
--8<---------------cut here---------------end--------------->8---
Since this is something that worked fine on Debian stable until some
weeks ago, and then stopped working, I strongly suspect some Debian
stable update introduced a change causing this new
gnutls_certificate_status_t to be passed to neon. Alternatively, an
update to Debian oldstable causing a change in the TLS negotiation on
the server side. I hope this fix can be included in a future point
release for stable!
Thanks for your work on Debian,
Peter
-- System Information:
Debian Release: 10.7
APT prefers stable-updates
APT policy: (990, 'stable-updates'), (990, 'stable'), (610, 'testing'), (600,
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf
Kernel: Linux 5.9.0-0.bpo.2-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libneon27-gnutls depends on:
ii libc6 2.28-10
ii libcom-err2 1.44.5-1+deb10u3
ii libgnutls30 3.6.7-4+deb10u5
ii libgssapi-krb5-2 1.17-3+deb10u1
ii libk5crypto3 1.17-3+deb10u1
ii libkrb5-3 1.17-3+deb10u1
ii libxml2 2.9.4+dfsg1-7+deb10u1
ii zlib1g 1:1.2.11.dfsg-1
Versions of packages libneon27-gnutls recommends:
ii ca-certificates 20200601~deb10u1
libneon27-gnutls suggests no packages.
-- no debconf information
GnuTLS now emits GNUTLS_CERT_MISSING_OCSP_STATUS when OCSP stapling was
requested but the server did not do so. This is not an error, so verification
should not fail.
--- a/src/ne_gnutls.c
+++ b/src/ne_gnutls.c
@@ -972,7 +972,8 @@
NE_DEBUG(NE_DBG_SSL, "ssl: Verification failures = %d (status = %u).\n",
failures, status);
- if (status && status != GNUTLS_CERT_INVALID) {
+ if (status && status != GNUTLS_CERT_INVALID
+ && status != GNUTLS_CERT_MISSING_OCSP_STATUS) {
char *errstr = verify_error_string(status);
ne_set_error(sess, _("Certificate verification error: %s"), errstr);
ne_free(errstr);
