Re: openssl/libssl1 in Debian now blocks offlineimap?

[Clint Byrum]

Excerpts from Adam Borowski's message of 2017-08-24 22:10:40 +0200:
> On Thu, Aug 24, 2017 at 01:45:02PM +, Bernhard Schmidt wrote:
> > The point was, even if all Debian based MTAs disabled
> > TLSv1.0/TLSv1.1 leading to delivery issues a very large portion of
> > senders won't fix their servers. They simply won't give a damn. Unless
> > Google and Microsoft do the same, in which case they suddenly cannot
> > reach >50% of their targets anymore and are forced ot fix their side.
> > 
> > The suggested procedure for Buster (disable TLSv1.0/TLSv1.1, then
> > contact everyone who breaks due to this) is not viable for email. This
> > will prevent public servers from testing Buster for the whole time.
> 
> Fortunately, our default MTA uses gnutls, but it's not nice to screw postfix
> users.
> 
> In the real world, refusing mails from even one customer or business
> partner, no matter how pants-on-the-head-retarded their mail setup is, is
> simply not an option.
> 
> Their answer will be "your server is broken as my mail works elsewhere, it's
> your fault", no matter how much you preach TLS safety.
> 

There may be an opportunity for a project to spin up which logs known
servers found to be using sub-standard TLS versions. Nothing like finding
out there's a hacker website which lists you as a prime target to motivate
budget allocations for fixes.

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Adam Borowski]

On Thu, Aug 24, 2017 at 01:45:02PM +, Bernhard Schmidt wrote:
> The point was, even if all Debian based MTAs disabled
> TLSv1.0/TLSv1.1 leading to delivery issues a very large portion of
> senders won't fix their servers. They simply won't give a damn. Unless
> Google and Microsoft do the same, in which case they suddenly cannot
> reach >50% of their targets anymore and are forced ot fix their side.
> 
> The suggested procedure for Buster (disable TLSv1.0/TLSv1.1, then
> contact everyone who breaks due to this) is not viable for email. This
> will prevent public servers from testing Buster for the whole time.

Fortunately, our default MTA uses gnutls, but it's not nice to screw postfix
users.

In the real world, refusing mails from even one customer or business
partner, no matter how pants-on-the-head-retarded their mail setup is, is
simply not an option.

Their answer will be "your server is broken as my mail works elsewhere, it's
your fault", no matter how much you preach TLS safety.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Bernhard Schmidt]

Scott Kitterman  wrote:
>
>
> On August 24, 2017 8:05:20 AM EDT, Bernhard Schmidt  wrote:
>>Kurt Roeckx  wrote:
>>
>>> Disabling the protocols is the only way I know how to identify
>>> all the problems. And I would like to encourage everybody to
>>> contact the other side if things break and get them to upgrade.
>>
>>There is now #873065 on Postfix which suggests MTAs don't fall back to
>>plain SMTP if the SSL handshake fails due to disabling of TLSv1.0 and
>>TLSv1.1. I think this problem will be unsolvable before at least Google
>>and Microsoft do the same on their inbound servers, forcing everyone to
>>change configs.
> The log in that bug shows something connecting to a Postfix smtpd, so
> someone else's inbound isn't relevant to that bug.

Yes and no. The point was, even if all Debian based MTAs disabled
TLSv1.0/TLSv1.1 leading to delivery issues a very large portion of
senders won't fix their servers. They simply won't give a damn. Unless
Google and Microsoft do the same, in which case they suddenly cannot
reach >50% of their targets anymore and are forced ot fix their side.

The suggested procedure for Buster (disable TLSv1.0/TLSv1.1, then
contact everyone who breaks due to this) is not viable for email. This
will prevent public servers from testing Buster for the whole time.

> I need to find more information on it, but that is most likely a case
> of the sender not falling back to plain SMTP and so likely not a
> Postfix issue.

Indeed.

Bernhard

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Scott Kitterman]

On August 24, 2017 8:05:20 AM EDT, Bernhard Schmidt  wrote:
>Kurt Roeckx  wrote:
>
>> Disabling the protocols is the only way I know how to identify
>> all the problems. And I would like to encourage everybody to
>> contact the other side if things break and get them to upgrade.
>
>There is now #873065 on Postfix which suggests MTAs don't fall back to
>plain SMTP if the SSL handshake fails due to disabling of TLSv1.0 and
>TLSv1.1. I think this problem will be unsolvable before at least Google
>and Microsoft do the same on their inbound servers, forcing everyone to
>change configs.

The log in that bug shows something connecting to a Postfix smtpd, so someone 
else's inbound isn't relevant to that bug.

I need to find more information on it, but that is most likely a case of the 
sender not falling back to plain SMTP and so likely not a Postfix issue.

This does highlight problems with the current situation with openssl.  I can't 
think of a case where no encryption is a better result than use of TLS.

Scott K

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Bernhard Schmidt]

Kurt Roeckx  wrote:

> Disabling the protocols is the only way I know how to identify
> all the problems. And I would like to encourage everybody to
> contact the other side if things break and get them to upgrade.

There is now #873065 on Postfix which suggests MTAs don't fall back to
plain SMTP if the SSL handshake fails due to disabling of TLSv1.0 and
TLSv1.1. I think this problem will be unsolvable before at least Google
and Microsoft do the same on their inbound servers, forcing everyone to
change configs.

Bernhard

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Wouter Verhelst]

On Sun, Aug 20, 2017 at 11:03:33PM +0200, Hanno Rince' Wagner wrote:
> Hi Jonas!
> > Question is if Debian _force_ only TLS 1.2 so that no services _can_ use 
> > anything else.
> 
> IMHO we should have the default at TLS 1.2, but be able to configure
> 1.0. But this has to be an opt-in value, not an opt-out.

Yes, exactly, that's what Jonas was arguing too. The problem is,
however, that this is not what we're currently getting.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Jonas Smedegaard]

Quoting Hanno Rince' Wagner (2017-08-20 22:01:51)
> On Fri, 18 Aug 2017, Tollef Fog Heen wrote:
> 
> > I think you're wrong on this point, having Debian make this change makes
> > it a lot easier for me to go to company management and explain that TLS
> > v1.2 is the only way forward and that we need to spend engineering
> > resources to make sure any users on platforms where support for that is
> > lacking get a proper notification and a chance to move to something
> > newer.  «We need to do this because this change is coming, whether we
> > want it or not.»
> 
> If you need more "firepower" for management: The BSI (german
> governmental organisation for security in information technology) has
> guidelines regarding cryptography, see 
> 
> https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf
> 
> They say in their technical guidelines that TLS 1.1 is not recommended
> anymore and TLS 1.0 is not recommended at all.
> SSLv2 and SSLv3 are not recommended.
> 
> So, if managers want to have somewhere "officially" written that
> TLS1.0 and 1.1 shouldn't be used anymore, this is a guideline I can
> recommend.
> 
> And IMHO we as debian should support all people going for stronger
> encryption by enabling it as good as possible and make it default. If
> someone wants or needs to use older ciphers, he should be able to, but
> it shouldn't be default...

I believe noone in this thread disagree with _recommending_ only TLS 1.2 
and that no services _should_ use anything else.

Question is if Debian _force_ only TLS 1.2 so that no services _can_ use 
anything else.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Michael Meskes]

> pretty poor choice.  Providing people with the possibility to fall back
> to less secure solutions sounds like a much better choice, just like

Problem is, where is this possibility right now?

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Wouter Verhelst]

On Sun, Aug 20, 2017 at 01:51:16PM +0200, Tollef Fog Heen wrote:
> Arguing for keeping TLS 1.0 support means you're arguing for providing
> users with a default-insecure setup.

No.

Arguing for keeping TLS1.0 *enabled by default* does. But arguing for
*allowing* it to be re-enabled (without requiring a recompile of
OpenSSL), as opposed to the "it's not even compiled in" stuff that we're
getting now, does not.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Adrian Bunk]

On Sun, Aug 20, 2017 at 01:51:16PM +0200, Tollef Fog Heen wrote:
> ]] Adrian Bunk 
>...
> > Think of the "TLS 1.2 not working with WPA" discussed earlier here that 
> > might still affect half a billion active Android devices at the buster
> > release date.[1]
> > 
> > The online banking app running on such a device will support TLS 1.2
> 
> Maybe, maybe not.  Depending on how it's implemented, it's non-trivial
> to get TLS 1.2 support in there.  Just doing HTTP or TLS yourself is
> easy enough, but if you want to use a webview, you're at the mercy of
> the TLS libs of the OS.
>...

TLS 1.1 and 1.2 are supported for client sockets
in Android since 2012.

TLS 1.1 and 1.2 are enabled by default for client sockets
in Android since 2014.

In other words:
When buster gets released, there will still be few hundred million 
Android devices in use that do support TLS 1.1 and 1.2 but have it 
disabled by default.

If you are a bank, then using TLS 1.2 in your online banking app
is not a problem on these devices.

The situation can be less rosy when a user tries to open a link to
https://www.debian.org in the default browser.

The recent trend of using HTTPS everywhere has the nasty side effect of 
TLS 1.0 being mandatory for public parts of webservers for as long as 
users continue to use browsers that don't support anything more recent.

Even a bank that might want/have to restrict the online banking part of 
their website to TLS 1.2 and secure ciphers will still have a huge 
commercial incentive to support everything no matter how weak for HTTPS
access to the public parts of their website where they advertise their 
services to potential new customers.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Tollef Fog Heen]

]] Adrian Bunk 

> On Fri, Aug 18, 2017 at 10:07:49PM +0200, Tollef Fog Heen wrote:
> > ]] Adrian Bunk 
> >... 
> > The PCI consortium extended the deadline until June
> > 2018.  Assuming that deadline holds, people with older machines will not
> > be able to access services such as online banking or pay online in
> > general.
> 
> That's wrong.

I'm not sure which bit of the quoted text you think is wrong.

> Think of the "TLS 1.2 not working with WPA" discussed earlier here that 
> might still affect half a billion active Android devices at the buster
> release date.[1]
> 
> The online banking app running on such a device will support TLS 1.2

Maybe, maybe not.  Depending on how it's implemented, it's non-trivial
to get TLS 1.2 support in there.  Just doing HTTP or TLS yourself is
easy enough, but if you want to use a webview, you're at the mercy of
the TLS libs of the OS.

> The PayPal app currently requires Android >= 4.0.3, released in 2011.

I'd not be surprised if that gets bumped, but that's just my guess, I
have no knowledge into what their actual plans are.

[...]

> >...
> > to make sure any users on platforms where support for that is
> > lacking get a proper notification and a chance to move to something
> > newer.
> >...
> 
> Imagine Debian running on the AP providing the WiFi for a Cafe.
> 
> What you are saying is that the staff working at the Cafe should explain 
> to their customers that they have to buy a new phone if they want to use 
> the WiFi.

Why would that be the case?  They're likely to just be using WPA2 or
have an open network, neither of which require TLS.

Arguing for keeping TLS 1.0 support means you're arguing for providing
users with a default-insecure setup.  In today's world, I think that's a
pretty poor choice.  Providing people with the possibility to fall back
to less secure solutions sounds like a much better choice, just like
it's possible to install an telnetd providing unencrypted logins, but it
requires you to actively go out and install it.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Sven Hartge]

Adrian Bunk  wrote:

> [1] I haven't investigated how widespread this specific problem 
> actually is, or whether it can be mitigated - the point is that
> it is unrelated to TLS versions supported by PayPal or online 
> banking apps running on the device

I asked on the freeradius-users list, if there is an easy way to log the
SSL/TLS version a client uses during the PEAP/TTLS handshake, to get a
better understanding of the situation on my universities wireless
networks, but unfortunately this was not easily possible.

http://lists.freeradius.org/pipermail/freeradius-users/2017-August/088521.html

It would be really interesting to gather some long term statistics about
this to see a trend of the adoption of newer TLS versions over time.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Adrian Bunk]

On Fri, Aug 18, 2017 at 10:07:49PM +0200, Tollef Fog Heen wrote:
> ]] Adrian Bunk 
>... 
> The PCI consortium extended the deadline until June
> 2018.  Assuming that deadline holds, people with older machines will not
> be able to access services such as online banking or pay online in
> general.

That's wrong.

Think of the "TLS 1.2 not working with WPA" discussed earlier here that 
might still affect half a billion active Android devices at the buster
release date.[1]

The online banking app running on such a device will support TLS 1.2

The PayPal app currently requires Android >= 4.0.3, released in 2011.

> ... but they're pragmatic.
> As they write in their press release: “…in the field a lot of business
> issues surfaced…” said Stephen Orfei, General Manager, PCI SSC. “We want
> merchants protected against data theft but not at the expense of turning
> away business, ...

Corollary:

It is permitted to run your online banking app on an Android device 
with a 5 year old firmware with no security updates ever available.

>...
> to make sure any users on platforms where support for that is
> lacking get a proper notification and a chance to move to something
> newer.
>...

Imagine Debian running on the AP providing the WiFi for a Cafe.

What you are saying is that the staff working at the Cafe should explain 
to their customers that they have to buy a new phone if they want to use 
the WiFi.

cu
Adrian

[1] I haven't investigated how widespread this specific problem 
actually is, or whether it can be mitigated - the point is that
it is unrelated to TLS versions supported by PayPal or online 
banking apps running on the device

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Clint Byrum]

Excerpts from Tollef Fog Heen's message of 2017-08-18 22:07:49 +0200:
> ]] Adrian Bunk 
> 
> > Or did this start as a coordinated effort of several major Linux
> > distributions covering all TLS implementations?
> 
> While not speaking for Kurt, there's been a move towards getting rid of
> TLS < 1.2 for quite some time, by reasonably important players such as
> the PCI-DSS consortium which announced in 2015 that June 2016 would be
> the deadline for disabling older TLS versions.  As we all know, we're
> past that date now, and TLS < 1.2 is still around and entirely too
> well-supported.  The PCI consortium extended the deadline until June
> 2018.  Assuming that deadline holds, people with older machines will not
> be able to access services such as online banking or pay online in
> general.
> 
> I'm hoping they won't extend the deadline again, but they're pragmatic.
> As they write in their press release: “…in the field a lot of business
> issues surfaced…” said Stephen Orfei, General Manager, PCI SSC. “We want
> merchants protected against data theft but not at the expense of turning
> away business, so we changed the date.”
> 
> > Nothing that Debian does alone will have any measurable impact
> > on TLS 1.0 usage.
> 
> I think you're wrong on this point, having Debian make this change makes
> it a lot easier for me to go to company management and explain that TLS
> v1.2 is the only way forward and that we need to spend engineering
> resources to make sure any users on platforms where support for that is
> lacking get a proper notification and a chance to move to something
> newer.  «We need to do this because this change is coming, whether we
> want it or not.»
> 

Businesses assess risk on every level as part of operating a business. If
replacing Debian is cheaper than replacing whatever requires TLS 1.0,
some companies will absolutely choose the former.

It may not be wise to make business people choose between Debian and
money.

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Tollef Fog Heen]

]] Adrian Bunk 

> Or did this start as a coordinated effort of several major Linux
> distributions covering all TLS implementations?

While not speaking for Kurt, there's been a move towards getting rid of
TLS < 1.2 for quite some time, by reasonably important players such as
the PCI-DSS consortium which announced in 2015 that June 2016 would be
the deadline for disabling older TLS versions.  As we all know, we're
past that date now, and TLS < 1.2 is still around and entirely too
well-supported.  The PCI consortium extended the deadline until June
2018.  Assuming that deadline holds, people with older machines will not
be able to access services such as online banking or pay online in
general.

I'm hoping they won't extend the deadline again, but they're pragmatic.
As they write in their press release: “…in the field a lot of business
issues surfaced…” said Stephen Orfei, General Manager, PCI SSC. “We want
merchants protected against data theft but not at the expense of turning
away business, so we changed the date.”

> Nothing that Debian does alone will have any measurable impact
> on TLS 1.0 usage.

I think you're wrong on this point, having Debian make this change makes
it a lot easier for me to go to company management and explain that TLS
v1.2 is the only way forward and that we need to spend engineering
resources to make sure any users on platforms where support for that is
lacking get a proper notification and a chance to move to something
newer.  «We need to do this because this change is coming, whether we
want it or not.»

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Wouter Verhelst]

On Tue, Aug 15, 2017 at 05:04:50PM +0200, Kurt Roeckx wrote:
> My problem is that if we don't do something, TLS 1.0 will be used
> for an other 10 year, and that's just not acceptable.

My problem is that the cause you're fighting, while laudable, should not
be fought in Debian.

Debian is a general-purpose operating system, not a security-focused
one. If we were, people would be right to expect that there might
sometimes be problems with the software they're using in support of the
"security" goal. Since we're not, people would rightly be upset if the
complex environments they're trying to support are suddenly broken in
the name of "security".

> So I would like to do something so that hopefully by the time Buster
> releases you can disable TLS 1.0 by default, and that almost no users
> would need to enable it again.
> 
> Having TLS 1.0 (and 1.1) enabled by default itself is not a
> problem, it's actually using it that's a problem. There are
> clearly still too many that don't support TLS 1.2, but it's
> getting better.

So ship a version of OpenSSL that ships with TLS1.0 and TLS1.1 (aka
TLS1.old) disabled, but *allow people to re-enable it* if things break
(without requiring them to compile their own version). By shipping a
version of OpenSSL that has TLS1.old not even compiled in, you're not
doing that.

I have seen suggestions that the goal of this would be to re-enable
TLS1.old before buster releases. If that is true, I fail to see the
point; I think it makes *much* more sense to ship buster with TLS1.old
disabled by default, but to allow for re-enabling it on a
per-application basis. Having a policy configuration that can be
modified by the system administrator through a mechanism inside libssl
that cannot be disabled and that can be configured on a per-application
basis would seem to be a much more interesting way to do this.
 
> Disabling the protocols is the only way I know how to identify
> all the problems. And I would like to encourage everybody to
> contact the other side if things break and get them to upgrade.

That latter part is certainly a good idea; and while "get the other side
to upgrade" is often a reasonable course of action, just as often it is
not, and then you need to have a way out. By not even compiling in the
code to support TLS1.old, you're depriving people of that "way out".

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Nicolas Sebrecht]

On Tue, Aug 15, 2017 at 05:04:50PM +0200, Kurt Roeckx wrote:

> My problem is that if we don't do something, TLS 1.0 will be used
> for an other 10 year, and that's just not acceptable.

The usage of TLS in the wild does not rely on you. Neither its does to
Debian, IMHO.

Now, when talking about the users of Debian I'm fine with such
statements. Actually, I'm not a user of Debian myself for good reasons.

>   So I would
> like to do something so that hopefully by the time Buster releases
> you can disable TLS 1.0 by default, and that almost no users would
> need to enable it again.

What do you mean by *you*? The users? They don't seem to have any
choice.

> Having TLS 1.0 (and 1.1) enabled by default itself is not a
> problem, it's actually using it that's a problem.

Well, there is a lot of problems in the world. Not being able to use a
protocol anymore because a maintainer decided to disable the feature can
be one of them.

>   There are
> clearly still too many that don't support TLS 1.2, but it's
> getting better.

So this policy is neglecting the users needs in the hope this will force
third-parties to move...

> Disabling the protocols is the only way I know how to identify
> all the problems.

There is a gap between forcefully disabling a protocol and disabling it
with the possibility to manually re-enable it when really required.

If we even admit that the "forcefully disallow protocols for our users"
policy is a good alternative to change the world, it's well known that
all the providers won't upgrade any time soon. So, the Busters users are
taken hostage.

>   And I would like to encourage everybody to
> contact the other side if things break and get them to upgrade.

Sure. This does not prevent from providing a plan B: manually re-enable
a "won't be supported anymore" feature.

I tend to think that in the end this is all about consideration to your
users. Of course, it's up to you to go your own way.

-- 
Nicolas Sebrecht

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Kurt Roeckx]

On Tue, Aug 15, 2017 at 10:43:08AM -0700, Michael Lustfield wrote:
> I don't think it was answered... Is there an actual reason that this needs
> to be handled urgently? Is TLSv1.0/v1.1 considered broken?

Yes.


Kurt

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Michael Lustfield]

On Aug 15, 2017 08:05, "Kurt Roeckx"  wrote:


> Do you really think that big companies like cable provides give a
>  about what Debian deprecates?  I was personally fighting with similar
> problems in Firefox and the internal side at my university.

My problem is that if we don't do something, TLS 1.0 will be used
for an other 10 year, and that's just not acceptable. So I would


Nobody said we should do nothing, but it should be clear by this point that
this total removal is going to cause a lot of problems for admins and users.

like to do something so that hopefully by the time Buster releases
you can disable TLS 1.0 by default, and that almost no users would
need to enable it again.


If Debian is going to be the only motivating factor for change then the
pressure that causes the change will be from system admins hosting
applications. These admins will *NEED* to re-enable older versions.

Companies might not listen to customers, but vendors listen to the money
providers. It's rarely a fast change, though. It's usually a ticket tossed
into the wishlist pile until enough people make noise.


I'm currently working on a project with a client to replace TLSv1.0 with
TLSv1.2. We're hoping to have this rolled out in a lab in the next four
months, but it's been a "priority" project for over two years.

It's not for lack of motivation or effort; there are a lot of interesting
roll-out issues. This is when motivation to change already exists. "Some
distro disabled support for it" is going to lead to vendors outright
saying, "use a different distro and wait until we get around to it."

I imagine users would be more inclined to just switch to a different
distribution that doesn't break their chrome/firefox/internet's. If a
client came to us and said their agent broke because their OS dropped that
support, our choice would be to say tough luck.

Having TLS 1.0 (and 1.1) enabled by default itself is not a
problem, it's actually using it that's a problem. There are
clearly still too many that don't support TLS 1.2, but it's
getting better.


I don't think it was answered... Is there an actual reason that this needs
to be handled urgently? Is TLSv1.0/v1.1 considered broken? Is there a
reason there was no discussion on this list before the decision was made
and pushed?

Disabling the protocols is the only way I know how to identify
all the problems. And I would like to encourage everybody to
contact the other side if things break and get them to upgrade.


It might be the only way you know, but this list has lots of admin types
that could probably help out. Perhaps you could upload a fixed openssl so
we can open that discussion about what's appropriate?


I've already suggested dropping it from all default configs for a release
cycle. It's not until the next release that we can assume a majority of
pro-active admins will have been made aware that we(Debian) are deprecating
older TLS versions.

Dropping out-of-the box support sounds like a great idea, but the back-out
option needs to be easy and should be able to be toggled per-application,
giving people a chance to react to this change instead of making them
scramble for a patch.

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Adrian Bunk]

On Tue, Aug 15, 2017 at 05:04:50PM +0200, Kurt Roeckx wrote:
> On Tue, Aug 15, 2017 at 10:49:05PM +0900, Norbert Preining wrote:
>...
> > Do you really think that big companies like cable provides give a 
> >  about what Debian deprecates?  I was personally fighting with similar 
> > problems in Firefox and the internal side at my university.
> 
> My problem is that if we don't do something, TLS 1.0 will be used
> for an other 10 year, and that's just not acceptable.
>...

Who is "we"?

Is this the majestic plural used by the maintainer
of one TLS imlementation in one distribution?

Or did this start as a coordinated effort of several major Linux 
distributions covering all TLS implementations?

If Debian does its own thing here, then it's just not acceptable for
users to use the one broken distribution that doesn't work with whatever
devices they have to interact with - it would force them to either stay
at stretch or switch to a different distribution.

And any Debian-specific OpenSSL-modifications to allow applications
to opt into using TLS 1.0/1.1 would result in tons of Debian-specific
usually not-upstreamable changes, while not changing the amount of
TLS 1.0/1.1 using software in Debian substantially.

Nothing that Debian does alone will have any measurable impact
on TLS 1.0 usage.

> Kurt

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Kamil Jońca]

Kurt Roeckx  writes:

[...]
>
> Disabling the protocols is the only way I know how to identify
> all the problems. And I would like to encourage everybody to
> contact the other side if things break and get them to upgrade.

And who pay for new windows licenses (And I do not know if ever windows
10 supprost wpa auth with tls1.2), or new android phones?
KJ

-- 
http://wolnelektury.pl/wesprzyj/teraz/
I used to be disgusted, now I find I'm just amused.
-- Elvis Costello

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Michael Meskes]

> Disabling the protocols is the only way I know how to identify
> all the problems. And I would like to encourage everybody to
> contact the other side if things break and get them to upgrade.

So you make the decision that everyone should talk to their providers
etc.? I can actually understand your point but I strongly disagree with
action. I would actually be fine with it, if we were able to solve all
problems in Debian, but we are not.

Therefore my ssl packages are on hold and will be as long as needed.
Unstable should not be mis-used this way.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Kurt Roeckx]

On Tue, Aug 15, 2017 at 10:49:05PM +0900, Norbert Preining wrote:
> Hi Kurt,
> 
> I read your announcement on d-d-a, but due to moving places
> I couldn't answer.
> 
> I consider the unconditional deprecation of TLS 1.0 and 1.1
> a very wrong move.
> 
> Be strict with what you are sending out, but relaxed with what
> you receive.

https://tools.ietf.org/html/draft-thomson-postel-was-wrong-01

Also, if I would be strict in what I'm sending out, I would not
support TLS 1.0 and 1.1 for outgoing connections, only for incomming
connections? For the offlineimap case that would still be a
problem.

TLS doesn't actually work this way, but it's my best guess to
what you mean.

> This paradigm is hurt by this move and our users at Debian are hurt.
> In many cases they will not have a way to force the mail server to
> upgrade, and thus are bound to *not* reading emails or using 
> docker/downgrading/
> home-compiled solutions, which is the worst we can wish for.
> 
> Do you really think that big companies like cable provides give a 
>  about what Debian deprecates?  I was personally fighting with similar 
> problems in Firefox and the internal side at my university.

My problem is that if we don't do something, TLS 1.0 will be used
for an other 10 year, and that's just not acceptable. So I would
like to do something so that hopefully by the time Buster releases
you can disable TLS 1.0 by default, and that almost no users would
need to enable it again.

Having TLS 1.0 (and 1.1) enabled by default itself is not a
problem, it's actually using it that's a problem. There are
clearly still too many that don't support TLS 1.2, but it's
getting better.

Disabling the protocols is the only way I know how to identify
all the problems. And I would like to encourage everybody to
contact the other side if things break and get them to upgrade.


Kurt

Re: openssl/libssl1 in Debian now blocks offlineimap?

[Norbert Preining]

Hi Kurt,

I read your announcement on d-d-a, but due to moving places
I couldn't answer.

I consider the unconditional deprecation of TLS 1.0 and 1.1
a very wrong move.

Be strict with what you are sending out, but relaxed with what
you receive.

This paradigm is hurt by this move and our users at Debian are hurt.
In many cases they will not have a way to force the mail server to
upgrade, and thus are bound to *not* reading emails or using docker/downgrading/
home-compiled solutions, which is the worst we can wish for.

Do you really think that big companies like cable provides give a 
 about what Debian deprecates?  I was personally fighting with similar 
problems in Firefox and the internal side at my university.

It is hurting our users and does not any good. There *must* be a way
to re-enable it.

Please re-consider your steps.

Thanks

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13