Bug#875423: [Pkg-openssl-devel] Bug#875423: Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)

2018-07-09 Thread Sebastian Andrzej Siewior 
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)

2018-07-09 Thread Philippe Metzger 

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)

2017-10-26 Thread Raphael Hertzog 
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: openssl: Please re-enable TLS 1.0 and TLS 1.1

2017-10-07 Thread Sebastian Andrzej Siewior 
On 2017-10-07 02:14:10 [+0200], Gedalya wrote:
> This is affecting EAP with wpa_supplicant.
> See https://bugs.debian.org/877904

You need to do two steps in wpa supplicant:
- Add an option to set minimum TLS version
- if that option is set, forwarded its value (1.0 or 1.1) to
  SSL_CTX_set_min_proto_version() or SSL_set_min_proto_version()

Sebastian

Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1

2017-10-06 Thread Gedalya 

This is affecting EAP with wpa_supplicant.
See https://bugs.debian.org/877904

Bug#875423: [Pkg-openssl-devel] Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)

2017-09-30 Thread Guido Günther 
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)

2017-09-24 Thread Sebastian Andrzej Siewior 
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)

2017-09-23 Thread James Cloos 
> "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)

2017-09-22 Thread Raphael Hertzog 
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)

2017-09-22 Thread Raphael Hertzog 
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)

2017-09-21 Thread Kurt Roeckx 
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)

2017-09-21 Thread Kurt Roeckx 
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)

2017-09-21 Thread Sebastian Andrzej Siewior 
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)

2017-09-11 Thread Philip Hands 
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)

2017-09-11 Thread Raphael Hertzog 
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)

2017-09-11 Thread Philipp Kern 

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)

2017-09-11 Thread Raphaël Hertzog 
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