Since the upgrade to 1.1.0f-4 I cannot read EMails via imap from my old ipad anymore (unless I disable encryption). Moving back to 1.1.0f-3 fixes the problem. imap server is dovecot 1:2.2.31-1. Of course I know that tls 1.0 and 1.1 have been dropped on purpose, but that was a bad idea. I won't throw my old devices away, just because tls 1.1 is not as strong as 1.2. Its sufficiently safe for daily use. Surely it is better than having no encryption at all. Please reconsider. Tls 1.1 and older should be disabled by the user in a config file. Regards Harri
is blue mail working? Sebastian
to 1.1.0f-3 fixes the problem for both dovecot and stunnel4 James
So what are we talking about? Android 4 and the internal mail and web client? What happens if you switch to firefox/chrome and k-9 mail/blue mail? Sebastian
My perspective on this, from the client side, doing my routine sysadmin work: When disabling TLSv1 on a server, I'm no longer able to verify that using openssl s_client -tls1, I get "s_client: Option unknown option -tls1". Also I am unable to connect to some old servers supporting only TLSv1. I came across both types of issues just in the past 24 hours. I can always downgrade, or just use a stretch (or older) system for this minor task, but it seems this issue could be rethought. I think hard-disabling at compile time is a little too soon. Thanks, Gedalya
When you run a system for others, you don't get to dictate tools. However, from the complaints it seems to be android 2.3.7 and any embedded system still using openssl 0.9.8, which must be using TLS 1.0 James
I do :) so basically everything old without any (security)support but still functional. Let me see how we deal with this… Sebastian
After this upgrade our mail server no longer accept emails from the American Physical Society, which publishes some of the more important physics journals... This has been a significant problem for my colleagues in the past 2 weeks, both for submitting articles for publication and for refereeing submissions. In this particular case I think accepting the old/broken versions is still necessary. Reverting the upgrade is messy (I run unstable). I tried to compile the packages removing the disable-tls1 disable-tls1_1 in CONFARGS but the build failed in the tests with Test Summary Report ------------------- ../../test/recipes/40-test_rehash.t (Wstat: 256 Tests: 5 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=95, Tests=481, 34 wallclock secs ( 0.52 usr 0.12 sys + 30.14 cusr 2.84 csys = 33.62 CPU) Result: FAIL Makefile:153: recipe for target '_tests' failed make[3]: *** [_tests] Error 1 make[3]: Leaving directory '/tmp/openssl-1.1.0f/build_static' Makefile:151: recipe for target 'tests' failed make[2]: *** [tests] Error 2 make[2]: Leaving directory '/tmp/openssl-1.1.0f/build_static' debian/rules:80: recipe for target 'override_dh_auto_test-arch' failed make[1]: *** [override_dh_auto_test-arch] Error 2 Is there a simple way to fix this?
CC> Reverting the upgrade is messy (I run unstable). I tried to compile the CC> packages removing the disable-tls1 disable-tls1_1 in CONFARGS but the build CC> failed in the tests with You can grab the deb files for version 1.1.0f-3 of openssl, libssl1.1, libssl-dev and libssl-doc from any debian mirror. Eg, files like: http://ftp-nyc.osuosl.org/debian/pool/main/o/openssl/libssl-dev_1.1.0f-3_amd64.deb and use dpkg to install them. Then run: :; apt-mark hold openssl libssl1.1 libssl-dev libssl-doc to prevent them from upgrading past 1.1.0f-3. I had to do that on my MXs, main web site and outgoing smtp machines.
I tried openssl 1.1.0f-5 and it is indeed better with e.g. s_client. However, I've locally built openvpn (and pkcs11-helper) with openssl 1.1.0. I'm not sure whether this is a bug with openvpn or an issue with this latest patch to openssl, but I've tried both these settings: tls-version-min 1.0 tls-version-max 1.0 in an openvpn client config, connecting to an old server supporting only TLS 1.0, and it doesn't work. It did of course work with with openssl 1.1.0f-3. with 1.1.0f-5, I get: OpenSSL: error:141640BF:SSL routines:tls_construct_client_hello:no protocols available TLS_ERROR: BIO read tls_read_plaintext error TLS Error: TLS object -> incoming plaintext read error TLS Error: TLS handshake failed
After the upload I've been wondering if I should change it to default set the minimum version to 1.0 again. openvpn doesn't seem to make use of the SSL_CTX_set_min_proto_version() function yet. I've attached a patch that I didn't even try to compile that I think should do the right thing. Kurt
Thanks for this! It now connects fine with the setting 'tls-version-min 1.0' Everything seems to work fine, including the 5 other tunnels on this box. Perhaps this would be of interest to OpenVPN upstream?
I'm a little confused why you ran into this, it seems that openvpn is Debian is still linked to the libssl1.0.2, not libssl1.1. Did you build it yourself? I'll file a bug about it. Kurt
Yes, I did. OpenVPN and pkcs11-helper build cleanly against libssl1.1 and work fine. Not sure why new uploads haven't been made already. On my end I just wanted to try.
forcemerge 871987 873064 reassign 871987 dovecot 1:2.2.31-1 tags 871987 patch so here is more or less the same thing for dovecot. Just add ssl_lowest_version = TLS1.0 to the config to force min protocol version to be TLS1.0 (or TLS1.1 for the TLS1.1 variant). There are prebuilt binaries at https://breakpoint.cc/openssl-rebuild/dovecot/ Sebastian
This bug affects also Debian stable (Stretch), is there any chance Debian will fix this? Or are these one of those things that won't be touched now Stretch is already released? Dovecot is not working now.
Hi, No, to my understanding Stretch is not affected by this; this is easily verifiable using: openssl s_client -connect localhost:143 -starttls imap -tls1 which works perfectly fine with openssl 1.1.0f-3 and dovecot 1:2.2.27-3+deb9u1 in Stretch. Please do not exaggerate. As far as I can tell dovecot is working for everybody in Stretch and for the majority of users in testing/unstable. That said, I'll see if we can get upstream to support a minimum TLS version setting. Regards, Apollon
Hi Apollon, You're right, I'm sorry. I used the same Dovecot SSL configuration from Debian 7 (which restricted some weak ciphers) which resulted in the same problems discussed in this bug. Reverting it to the defaults of Dovecot in Stretch made it work again.
I can confirm that all the previously failing tools (dovecot, stunnel etc) are working again with 1.1.0g-2 Presumably this also fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875423 James
close 871987 1:2.3.4.1-5 thanks This ancient bug was fixed some time ago. I've confirmed that at least as far back as the first buster stable release contains the fix, so I'll close it as of that version, but I'm pretty sure it was fixed quite a bit earlier than that.