Bug#875423: [Pkg-openssl-devel] Bug#875423: Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)
On 2018-07-10 04:05:58 [+0200], Philippe Metzger wrote: > For now it seems that OpenSSL 1.1.0f-3+deb9u2 available in stretch/security > force TLS 1.2 only in https when using Apache (whatever SSLProtocol > Directive specify). This is not true. Stretch has TLS1.0 and up enabled by default. > Is there any way to allow TLS 1 and TLS 1.1 with apache in stable ? This bug is sid only. Testing (as asked by the reported) has TLS1.0+ enabled again. The bug is open because the proper way of getting this fixed is currently in experimental. > Thanks a lot Sebastian
Bug#875423: [Pkg-openssl-devel] Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)
On Thu, 26 Oct 2017 09:57:06 +0200 Raphael Hertzog wrote: > Hello Kurt, > > On Fri, 22 Sep 2017, Kurt Roeckx wrote: > > I have to admit that I didn't consider derivatives that take a > > snapshot of testing, and we also seem to have a large amount of > > people that do use testing. My intention was to target the more > > advanced users, and having it in testing might be affecting more > > people than I thought. > > > > So I am considering to only disable it in unstable and not in > > testing. > > Any progress on this? > > Cheers, > -- > R aphaël Hertzog ◈ Debian Developer > > Support Debian LTS: https://www.freexian.com/services/debian-lts.html > Learn to master Debian: https://debian-handbook.info/get/ > > For now it seems that OpenSSL 1.1.0f-3+deb9u2 available in stretch/security force TLS 1.2 only in https when using Apache (whatever SSLProtocol Directive specify). Is there any way to allow TLS 1 and TLS 1.1 with apache in stable ? Thanks a lot -- *Philippe Metzger* +33 6 12 90 60 97 / +33 1 82 28 56 95
Bug#875423: [Pkg-openssl-devel] Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)
Hello Kurt, On Fri, 22 Sep 2017, Kurt Roeckx wrote: > I have to admit that I didn't consider derivatives that take a > snapshot of testing, and we also seem to have a large amount of > people that do use testing. My intention was to target the more > advanced users, and having it in testing might be affecting more > people than I thought. > > So I am considering to only disable it in unstable and not in > testing. Any progress on this? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#875423: [Pkg-openssl-devel] Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)
Hi, On Fri, Sep 22, 2017 at 12:21:26AM +0200, Kurt Roeckx wrote: > On Mon, Sep 11, 2017 at 12:30:30PM +0200, Raphael Hertzog wrote: > > But in Debian testing, we have real end-users (direct and through > > "rolling" derivatives) and they should not have to be impacted by this > > experiment IMO. > > I have to admit that I didn't consider derivatives that take a > snapshot of testing, and we also seem to have a large amount of > people that do use testing. My intention was to target the more > advanced users, and having it in testing might be affecting more > people than I thought. > > So I am considering to only disable it in unstable and not in > testing. Please do. At least having it in unstable will allow us to use pinning so one can again talk to not up to date services (which there are plenty of). Cheers, -- Guido > > I'm actually surprised how few things broke. > > > Kurt
Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)
On 2017-09-22 11:12:52 [+0200], Raphael Hertzog wrote: > Hi, > > On Thu, 21 Sep 2017, Sebastian Andrzej Siewior wrote: > > The changes Kurt asked about is something that openssl upstream supports > > and is something that openssl 1.1 considers the right way of doing > > things (in contrast to the disable TLS-version X thingy which are marked > > deprecated or going to…). > > Why has it been implemented as a Debian specific patch then? There is nothing Debian specific, except for build options used and the patches are upstream as far as I recall. > I don't think that upstream planned to deprecate TLS 1.0 and TLS 1.1 > at this point yet. Yes, there are methods to control which TLS versions > you accept to use but those are optional and the default is to accept > all TLS versions and this default effectively changed in Debian, forcing > all applications to add code to re-enable all TLS versions. fastly plans to disable TLS <1.2 on June 30 2018 as per PCI SSC: https://www.fastly.com/blog/update-our-tls-10-and-11-deprecation-plan/ which is the extended deadline: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls and Buster should be around mid-end 2019. > > So what problems do those users see? If the package lacks 1.2 support > > then it should be reported & fixed. If the package requries <1.2 support > > because the remote side can't be changed then this should reported and > > patched as well. > > I think the discussions has been rather clear on the fact that the remote > side is not always patchable (old android versions which are not > getting updates, etc.). and for those things where you can not update and you *want* run unpached software and need TLS1.0 you can patch/add a switch the software in Debian to allow TLS < 1.2 but not by default. > > since it is unlikely that things change here. Also it is unwise to make > > such a change two days before the release of Buster. *Now* we have the > > time to act. > > buster should not ship with TLS 1.0 and TLS 1.1 disabled. It is not entirely disabled you just need to add a swtich (if not yet done) to enable TLS 1.[01] on purpose. We talk here about 2019. We already have 3des and RC4 disabled which is something you would not expect after the Jessie release. > Cheers, Sebastian
Bug#875423: [Pkg-openssl-devel] Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)
> "KR" == Kurt Roeckx writes: KR> On Mon, Sep 11, 2017 at 11:33:22AM +0200, Raphaël Hertzog wrote: >> Or at least I would like a system-wide flag (in a configuration file?) to >> let me re-enable old protocols easily. KR> It was my understanding that other people also prefered to do this KR> on a per package level and not system wide. But the other way round. Openssl should by default support >= 1.0, and the individual packages should be the ones to limit it to 1.2 or later. That limit should be run-time and the config files which do it should have comments explaining exactly how to undo it. And packages like MTAs and web servers should have those configs commented out so that they work by default with 1.0+. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)
Hi, On Thu, 21 Sep 2017, Sebastian Andrzej Siewior wrote: > The changes Kurt asked about is something that openssl upstream supports > and is something that openssl 1.1 considers the right way of doing > things (in contrast to the disable TLS-version X thingy which are marked > deprecated or going to…). Why has it been implemented as a Debian specific patch then? I don't think that upstream planned to deprecate TLS 1.0 and TLS 1.1 at this point yet. Yes, there are methods to control which TLS versions you accept to use but those are optional and the default is to accept all TLS versions and this default effectively changed in Debian, forcing all applications to add code to re-enable all TLS versions. > So what problems do those users see? If the package lacks 1.2 support > then it should be reported & fixed. If the package requries <1.2 support > because the remote side can't be changed then this should reported and > patched as well. I think the discussions has been rather clear on the fact that the remote side is not always patchable (old android versions which are not getting updates, etc.). > since it is unlikely that things change here. Also it is unwise to make > such a change two days before the release of Buster. *Now* we have the > time to act. buster should not ship with TLS 1.0 and TLS 1.1 disabled. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#875423: [Pkg-openssl-devel] Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)
Hi Kurt, On Fri, 22 Sep 2017, Kurt Roeckx wrote: > I have to admit that I didn't consider derivatives that take a > snapshot of testing, and we also seem to have a large amount of > people that do use testing. My intention was to target the more > advanced users, and having it in testing might be affecting more > people than I thought. > > So I am considering to only disable it in unstable and not in > testing. Thank you! > I'm actually surprised how few things broke. When an app outside of Debian breaks when trying to connect to a service running on a Debian machine, it's unlikely that said users will report it back to Debian... it's a long chain. Also servers will run stable and the large impact will only be noticeable once this reaches stable. On Fri, 22 Sep 2017, Kurt Roeckx wrote: > On Mon, Sep 11, 2017 at 11:33:22AM +0200, Raphaël Hertzog wrote: > > Or at least I would like a system-wide flag (in a configuration file?) to > > let me re-enable old protocols easily. > > It was my understanding that other people also prefered to do this > on a per package level and not system wide. I don't see why this would be mutually exclusive. We should be able to control the system-wide default and override the values for specific services too. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#875423: [Pkg-openssl-devel] Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)
On Mon, Sep 11, 2017 at 12:30:30PM +0200, Raphael Hertzog wrote: > But in Debian testing, we have real end-users (direct and through > "rolling" derivatives) and they should not have to be impacted by this > experiment IMO. I have to admit that I didn't consider derivatives that take a snapshot of testing, and we also seem to have a large amount of people that do use testing. My intention was to target the more advanced users, and having it in testing might be affecting more people than I thought. So I am considering to only disable it in unstable and not in testing. I'm actually surprised how few things broke. Kurt
Bug#875423: [Pkg-openssl-devel] Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)
On Mon, Sep 11, 2017 at 11:33:22AM +0200, Raphaël Hertzog wrote: > Or at least I would like a system-wide flag (in a configuration file?) to > let me re-enable old protocols easily. It was my understanding that other people also prefered to do this on a per package level and not system wide. Kurt
Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)
On 2017-09-11 12:30:30 [+0200], Raphael Hertzog wrote: > Yes, I'm aware of that but Kurt never said that he would be willing to > back off from completely disabling it before the buster release and > I don't see any benefit in modifying all server applications to re-enable > the protocols that we want to support out-of-the box because there > are (outside of Debian) old applications that will have to connect to > those servers. My understanding is that it will stay as-is and every package that needs TLS < 1.2 needs to add an option and the metioned function to use the lower TLS version. The changes Kurt asked about is something that openssl upstream supports and is something that openssl 1.1 considers the right way of doing things (in contrast to the disable TLS-version X thingy which are marked deprecated or going to…). > I understand we need to fix the client applications that we ship in Debian > so that they work with TLS 1.2-only servers and for this it might be > useful to disable TLS 1.0 and TLS 1.1 by default in unstable for a while. as I said, TLS 1.[01] is supported in unstable if the *set_min_proto_version() is used. I think in the meantime offline imap has been fixed and I sent something for dovecot (but know about its status). > But in Debian testing, we have real end-users (direct and through > "rolling" derivatives) and they should not have to be impacted by this > experiment IMO. So what problems do those users see? If the package lacks 1.2 support then it should be reported & fixed. If the package requries <1.2 support because the remote side can't be changed then this should reported and patched as well. Feel free to Cc the list so I can look and maybe make a patch if I have some spare time. I personaly don't see a reason to keep this bug open since it is unlikely that things change here. Also it is unwise to make such a change two days before the release of Buster. *Now* we have the time to act. > Cheers, Sebastian
Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)
Raphaël Hertzog writes: ... > Or at least I would like a system-wide flag (in a configuration file?) to > let me re-enable old protocols easily. Just because I haven't seen anyone else suggest it: Would it be practical to have the normal packages drop TLS 1.0/1.1 support as currently planned, but have an alternative set of packages (called openssl-obsolescent, or openssl-tls-flawed, or whatever) with the TLS 1.0/1.1 support re-enabled, so that one could do the migration away from TLS 1.0/1.1, but still allow people who notice problems to deal with them by choosing to install this other set of packages? Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)
On Mon, 11 Sep 2017, Philipp Kern wrote: > https://packages.qa.debian.org/o/openssl/news/20170824T211015Z.html seems to > have pushed this onto client applications? I.e. it's no longer hard disabled > but client applications need to explicitly enable them? Yes, I'm aware of that but Kurt never said that he would be willing to back off from completely disabling it before the buster release and I don't see any benefit in modifying all server applications to re-enable the protocols that we want to support out-of-the box because there are (outside of Debian) old applications that will have to connect to those servers. I understand we need to fix the client applications that we ship in Debian so that they work with TLS 1.2-only servers and for this it might be useful to disable TLS 1.0 and TLS 1.1 by default in unstable for a while. But in Debian testing, we have real end-users (direct and through "rolling" derivatives) and they should not have to be impacted by this experiment IMO. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)
On 2017-09-11 11:33, Raphaël Hertzog wrote: I looked back at the debian-devel discussion and it seems to me that the majority of persons who expressed themselves (including Moritz Mühlenhoff of the Debian security team) believe that buster should ship with TLS 1.0 and TLS 1.1 enabled. Given this, I would like to request you to make sure that Debian testing has a version of openssl with TLS 1.0 and TLS 1.1 enabled. The rough consensus seems to be that it's ok for you to use Debian unstable as a test-bed for your experiment to disable TLS 1.0 and TLS 1.1. While that might not be practical to manage when you have to push an update to testing, it's a burden that you should accept since you believe that Debian experimental will not give enough exposure. Please do listen to your fellow developers. Thank you. Cheers, PS: I'm filing this because I would like to not have to fork OpenSSL for Kali. It's counter-productive to go too fast in deprecating old protocols. You will only get less users using the official Debian package with all the risks it involves. Or at least I would like a system-wide flag (in a configuration file?) to let me re-enable old protocols easily. https://packages.qa.debian.org/o/openssl/news/20170824T211015Z.html seems to have pushed this onto client applications? I.e. it's no longer hard disabled but client applications need to explicitly enable them? Kind regards Philipp Kern
Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)
Source: openssl Version: 1.1.0f-5 Severity: serious Hello Kurt, I looked back at the debian-devel discussion and it seems to me that the majority of persons who expressed themselves (including Moritz Mühlenhoff of the Debian security team) believe that buster should ship with TLS 1.0 and TLS 1.1 enabled. Given this, I would like to request you to make sure that Debian testing has a version of openssl with TLS 1.0 and TLS 1.1 enabled. The rough consensus seems to be that it's ok for you to use Debian unstable as a test-bed for your experiment to disable TLS 1.0 and TLS 1.1. While that might not be practical to manage when you have to push an update to testing, it's a burden that you should accept since you believe that Debian experimental will not give enough exposure. Please do listen to your fellow developers. Thank you. Cheers, PS: I'm filing this because I would like to not have to fork OpenSSL for Kali. It's counter-productive to go too fast in deprecating old protocols. You will only get less users using the official Debian package with all the risks it involves. Or at least I would like a system-wide flag (in a configuration file?) to let me re-enable old protocols easily. -- System Information: Debian Release: buster/sid APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information