Re: OpenSSL disables TLS 1.0 and 1.1

[Paul Wise]

On Mon, Aug 7, 2017 at 9:42 AM, Kurt Roeckx wrote:

> This will likely break certain things that for whatever reason
> still don't support TLS 1.2. I strongly suggest that if it's not
> supported that you add support for it, or get the other side to
> add support for it.

This has broken the Python mechanize based script that I use to
connect to my ISP's web interface and extract information about how
much bandwidth quota I have used. I don't have any way to fix my ISP's
web servers.

Will we be disabling TLS 1.0/1.1 in web browsers and other TLS
implementations too?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: OpenSSL disables TLS 1.0 and 1.1

[Raphael Hertzog]

On Thu, 17 Aug 2017, Philipp Kern wrote:
> At the same time holding testing hostage does not feel right to me. I
> applaud the intention, but I strongly dislike the implementation.

+1

Also in the security field (i.e. for Kali Linux as derivative based on
Testing), we like to keep support for older protocols as that's precisely
the kind of thing that you are testing (with tools using libssl) in a
security review.

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/

Re: OpenSSL disables TLS 1.0 and 1.1

[Martin Zobel-Helas]

Hi, 

On Sun Aug 20, 2017 at 21:54:12 +0200, Michael Meskes wrote:
> >> It'd be nice if, after all this discussion, you stated clearly whether
> >> you plan to change something or not.
> > 
> > Isn't that what I just did?
> 
> No, not exactly. You stated what you want to do in *Buster*, but not
> whether it's supposed to stay broken all the way until then. I guess
> this email of yours does make it clear, though.
> 
> I guess we should then move the discussion from "should libssl support
> TLS 1.0/1.1" to "how do we get a system again that works with the
> not-so-up-to-date rest of the world".
> 
> At least I think our social contract demands we offer a *working*" ssl
> setup:
> ...
> We will be guided by the needs of our users and the free software
> community. We will place their interests first in our priorities. We
> will support the needs of our users for operation in many different
> kinds of computing environments.
> ...

+1

-- 
 Martin Zobel-Helas Debian System Administrator
 Debian & GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 

Re: OpenSSL disables TLS 1.0 and 1.1

[Michael Meskes]

>> It'd be nice if, after all this discussion, you stated clearly whether
>> you plan to change something or not.
> 
> Isn't that what I just did?

No, not exactly. You stated what you want to do in *Buster*, but not
whether it's supposed to stay broken all the way until then. I guess
this email of yours does make it clear, though.

I guess we should then move the discussion from "should libssl support
TLS 1.0/1.1" to "how do we get a system again that works with the
not-so-up-to-date rest of the world".

At least I think our social contract demands we offer a *working*" ssl
setup:
...
We will be guided by the needs of our users and the free software
community. We will place their interests first in our priorities. We
will support the needs of our users for operation in many different
kinds of computing environments.
...

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 disables TLS 1.0 and 1.1

[Kurt Roeckx]

On Sun, Aug 20, 2017 at 09:14:47PM +0200, Michael Meskes wrote:
> > I might upload this soon. The intention is still to ship Buster
> > with TLS 1.0 and 1.1 completly disabled.
> 
> Disabled by configuration or disabled by not compiling it in?

With "completly disabled" I mean at build time.

> It'd be nice if, after all this discussion, you stated clearly whether
> you plan to change something or not.

Isn't that what I just did?


Kurt

Re: OpenSSL disables TLS 1.0 and 1.1

[Michael Meskes]

> I might upload this soon. The intention is still to ship Buster
> with TLS 1.0 and 1.1 completly disabled.

Disabled by configuration or disabled by not compiling it in?

It'd be nice if, after all this discussion, you stated clearly whether
you plan to change something or not. Meaning, will we get a libssl
version that allows older TLS version or do you flatly deny the need for
it and keep libssl as is?

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 disables TLS 1.0 and 1.1

[Kurt Roeckx]

On Mon, Aug 07, 2017 at 08:35:52PM +0200, Kurt Roeckx wrote:
> On Mon, Aug 07, 2017 at 05:22:51PM +0200, Joerg Jaspert wrote:
> > I wonder if there is a middle way that ensures that all new stuff does
> > go TLS1.2 (or later, whenever), but does allow older stuff still to
> > work. Which isnt the case if they are just disabled.
> 
> I could change the default settings to set the minimum supported
> version as TLS 1.2. That is, act like
> SSL_CTX_set_min_proto_version() was called with TLS1_2_VERSION.
> That would allow applications to override this this by calling
> SSL_CTX_set_min_proto_version(). But then those are new
> functions in 1.1.0 and they probably aren't supported by many
> applications.

I have a patch for that at:
https://github.com/openssl/openssl/pull/4128

I might upload this soon. The intention is still to ship Buster
with TLS 1.0 and 1.1 completly disabled.


Kurt

Re: OpenSSL disables TLS 1.0 and 1.1

[Hideki Yamane]

Hi,

On Sat, 12 Aug 2017 14:16:25 +0200
Tollef Fog Heen  wrote:
> While I think we might want to ship buster with TLS 1.0 available, I
> think running with it disabled for parts of the development cycle is
> very useful, since it exposes bugs we have in packages that will use
> that version out of the box (isync being referred to elsethread).
> Finding and fixing those bugs is good.

Seconded in Tollef's opinion.

- This affects *only* testing and unstable, not stable release (yet).
  So, most of users are not influenced.
- We *can* revert it before Buster release if it would be too much
  wrong impact for us.
- This is done in early timing for Buster Cycle. We have enough time
  to see what is going on.

So, please file bugs with real world precise examples against affected
packages, and let's fix it first.


And, if it will not be reverted, maybe we can provide alternatives
such as openssh-client-ssh1 does.

> Package: openssh-client-ssh1
> (snip)
> Description: secure shell (SSH) client for legacy SSH1 protocol
> (snip)
>  This package provides the ssh1 and scp1 clients and the ssh-keygen1
>  utility, all built with support for the legacy SSH1 protocol. This
>  protocol is obsolete and should not normally be used, but in some cases
>  there may be no alternative way to connect to outdated servers.
>  .
>  In some countries it may be illegal to use any encryption at all
>  without a special permit.
> ...


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane

Re: OpenSSL disables TLS 1.0 and 1.1

[Philipp Kern]

On 16.08.2017 23:16, Moritz Mühlenhoff wrote:
> Marco d'Itri  schrieb:
>>> The only thing you would achieve would be to force people to move
>>> away from Debian to distributions that are still able to interact
>>> with devices running ancient and highly insecure Android firmwares.
>> +1
> 
> I agree it's not something that should end up in a stable release
> (and it's even unfortunate it propagated to testing already), but
> it makes a lot of sense to disable it in unstable for a few months
> to iron out the deficiencies in the applications we ship in
> Debian (such as #802658).

You'd think that you could also find issues such as the one you
referenced by doing test rebuilds and reporting bugs off that. In fact
that particular bug did not need the ongoing breakage to be found - it
was found years ago.

At the same time holding testing hostage does not feel right to me. I
applaud the intention, but I strongly dislike the implementation.

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Re: OpenSSL disables TLS 1.0 and 1.1

[Moritz Mühlenhoff]

Marco d'Itri  schrieb:
>> The only thing you would achieve would be to force people to move
>> away from Debian to distributions that are still able to interact
>> with devices running ancient and highly insecure Android firmwares.
> +1

I agree it's not something that should end up in a stable release
(and it's even unfortunate it propagated to testing already), but
it makes a lot of sense to disable it in unstable for a few months
to iron out the deficiencies in the applications we ship in
Debian (such as #802658).

Once that is completed, we can blame old Android releases.

Cheers,
Moritz

Re: OpenSSL disables TLS 1.0 and 1.1

[Marco d'Itri]

On Aug 16, Adrian Bunk  wrote:

> The only thing you would achieve would be to force people to move
> away from Debian to distributions that are still able to interact
> with devices running ancient and highly insecure Android firmwares.
+1

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: OpenSSL disables TLS 1.0 and 1.1

[Colin Tuckley]

On 16/08/17 09:47, Adrian Bunk wrote:

> The only thing you would achieve would be to force people to move
> away from Debian to distributions that are still able to interact
> with devices running ancient and highly insecure Android firmwares.

The situation is actually *worse* than that. I, and quite a few other
Debian Developers I suspect, will be giving up with testing and unstable
until this is fixed.

Adrian, since you seem to be leading this debate, perhaps it should be
you that files a RC bug against openssl asking for the TLS 1.0 and 1.1
change to be reverted.

regards, Colin

-- 
Colin Tuckley| +44(0)1223 830814 |  PGP/GnuPG Key Id
Debian Developer | +44(0)7799 143369 | 0xFA0C410738C9D903





signature.asc
Description: OpenPGP digital signature

Re: OpenSSL disables TLS 1.0 and 1.1

[Adrian Bunk]

On Fri, Aug 11, 2017 at 04:11:16PM +0200, Kurt Roeckx wrote:
> On Fri, Aug 11, 2017 at 01:34:53PM +0200, Sven Hartge wrote:
> > Marco d'Itri  wrote:
> > > On Aug 09, Sven Hartge  wrote:
> > 
> > >> Looking at https://developer.android.com/about/dashboards/index.html
> > >> there is still a marketshare of ~25% of smartphones based on Android
> > >> 5.0 and 5.1 and 16% based on 4.4. So this change would (at the
> > >> moment) block ~40% of Android smartphones from connecting to any WLAN
> > >> using PEAP or TTLS.
> > 
> > > Android 5.x should support TLS 1.2:
> > > http://caniuse.com/#search=TLS
> > 
> > The Browser, yes. But not the components doing the WPA stuff:
> > 
> > ,
> > | Aug  9 20:09:13 ds9 radiusd[4179992]: (12924) Login incorrect (eap_ttls: 
> > TLS Alert write:fatal:protocol version): [owehxperia] (from client ap01 
> > port 54 cli 30-39-26-xx-xx-xx)
> > | Aug  9 20:09:24 ds9 radiusd[4179992]: (12928) eap_ttls: ERROR: TLS Alert 
> > write:fatal:protocol version
> > | Aug  9 20:09:24 ds9 radiusd[4179992]: tls: TLS_accept: Error in error
> > `
> > 
> > Only recompiling openssl with TLS1.0 and TLS1.1 enabled allowed my phone
> > to connect successfully.
> 
> Any idea if this actually works with newer android phones?
> 
> Could someone report this to Google? I consider everything broken
> by this a security issue

You are working based on assumptions that are unfortunately not true.

Let me give you some data:

According to Google, as of today 9% of Android devices run Android
releases first released in 2012 or earlier that are no longer
supported by Google.[1]

According to Google, there are more than 2 billion active Android 
devices.[2]

Do the math, and you end up at nearly 200 million devices running 
Android releases no longer supported by Google.

Extrapolating the above numbers in the growing smartphone market,
half a billion active Android devices with the above WPA problem
when buster releases in mid-2019 might be a low estimate.[3]

> and hope that Google will fix it in all releases they still support.

An update from Google for an Android release does not automatically 
result in firmware updates being available for all devices running
this Android release.

The situation regarding the speed of firmware updates, and whether they
are available at all, is bad for many high-end Android devices.

And for cheap Android devices there might be no updates available at all.

For many people in the first world and most people elsewhere even
a cheap € 100 smartphone is a major investment, not something that
will be thrown away after 2 years.

All this is a very unfortunate situation, but nothing Debian can change.

Everyone providing a service that is also used by Android phones
(e.g. webserver, wireless access point) faces the reality that
a significant share of the customers is using ancient Android
releases with a firmware that are several years old.

It doesn't matter whether something works with newer Android phones,
or what you consider a security issue.

The only thing you would achieve would be to force people to move
away from Debian to distributions that are still able to interact
with devices running ancient and highly insecure Android firmwares.

> Kurt

cu
Adrian

[1] https://developer.android.com/about/dashboards/index.html
[2] https://twitter.com/Google/status/864890655906070529
[3] this assumes all devices with Android < 6 are affected
by this specific problem

-- 

   "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 disables TLS 1.0 and 1.1

[Adrian Bunk]

On Fri, Aug 11, 2017 at 02:52:56PM +0200, Marco d'Itri wrote:
> On Aug 11, Marco d'Itri  wrote:
> 
> > but I see on your link that Android pre-5.x still has a ~25% market 
> > share, so unless it will drop a lot in the next year I do not think that 
> > we can cut them off from Debian-based web servers.
> OTOH if the PCI council says that TLS < 1.2 has to go by june 2018 then 
> this will probably not be such a big deal:
> 
> https://www.fastly.com/blog/phase-two-our-tls-10-and-11-deprecation-plan/
>...

Based on the PCI document they are linking to[1], the claim that the
PCI council said that TLS 1.1 also has to go by june 2018 is not true:

  The best response is to disable SSL entirely and migrate to a more 
  modern encryption protocol, which at the time of publication is a
  minimum of TLS v1.1, although entities are strongly encouraged to 
  consider TLS v1.2.

> ciao,
> Marco

cu
Adrian

[1] 
https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information%20Supplement_v1.pdf

-- 

   "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: Re: OpenSSL disables TLS 1.0 and 1.1

[Kamil Jońca]

Sven Hartge  writes:

[...]
>
> Not everything is regulated by the PCI council.
>
> If, after upgrading to Buster, suddenly 25% of the students of my
> university can no longer connect to the wireless network, it will be
> hell on earth for me and my support staff.
>
> It is nice to say "well, then get the other side to upgrade to a new
> device", but as it has already been said in this discussion: The real
> world does not work that way.

My 3¢: as I said in bug comment
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871477#30
and on debian-user:
my Win7 and Win8 (strictly: Win8.1) laptops cannot authenticate against
freeradius with this version.

KJ

Re: OpenSSL disables TLS 1.0 and 1.1

[Ondřej Surý]

Which is definitely worse than HTTPS with even SSLv3.


Here I disagree, with HTTP you know you are using inherently insecure 
transport layer and you can take other precautions.


With SSLv3, you might be fooled by feeling of security...

Apart from that, I think we need a system-wide default policy with 
sufficiently difficult way how to re-enable older but still secure (for 
some level of security) TLS protocols. And this needs to apply for all 
crypto libraries.


O.


On 11 August 2017 16:15:43 Christian Seiler  wrote:


Hi,

Am 2017-08-11 15:09, schrieb Sven Hartge:

Unless it has been proven that TLS1.0 and TLS1.1 are as broken as SSL3,
please keep the support for them enabled in OpenSSL, and just change
the
defaults in the application to only use TLS1.2 (unless changed by the
administrator).


I remember a talk at Debconf15 about Fedora's system-wide policy for
Crypto stuff:

https://summit.debconf.org/debconf15/meeting/252/enforcement-of-a-system-wide-crypto-policies/

I haven't rewatched the talk, but if I remember correctly, the
whole thing was designed in a way that the administrator could
change both the system-wide policy and also override it per
application.

If we follow through on this, we could then disable anything but
TLS 1.2 in the default system-wide policy - the default settings
would then be more secure while users could then still change the
policy for compatibility reasons if so required. It would also
provide a central nob for the future for users who don't have to
worry about compatibility and perhaps want to disable TLS 1.2 in
favor of 1.3 (which will be part of OpenSSL 1.1.1).


Btw. speaking of this issue: a friend of mine who's an administrator
at a university has had the problem that he can't use the HTTPS
interface of some NAS devices (and I'm talking 19" rack-mounted
storage with internal and external SAS interface) anymore since the
interface only supports either older SSL versions or older ciphers
that modern browsers simply don't accept anymore. (Not even with
about:config options.) And there are no firmware updates for these
devices anymore, so he's now administering these devices via
unencrypted HTTP. Which is definitely worse than HTTPS with even
SSLv3. In his case it's not too bad, because they are in a separate
network that isn't routed to the public (using ssh -D to a gateaway
to access them), but this shows what problems can arise from this.

Don't get me wrong: I do believe it's a huge problem that vendors
of said appliances don't provide updates for these kind of things,
and I wish that we could indeed drop everything except TLS 1.2, but
the real world is unfortunately more complicated, and I think
Debian would do a huge disservice to users if it removed TLS 1.0
and 1.1 from OpenSSL in Buster without a well-documented
possibility for the admin to reenable it.

Regards,
Christian

Re: OpenSSL disables TLS 1.0 and 1.1

[Ondřej Surý]

This is a really good idea!


On 12 August 2017 15:56:26 Tollef Fog Heen  wrote:


]] Russ Allbery


That doesn't mean we can't make it very easy to disable TLS 1.0/1.1 or
encourage people to do that when possible, of course.  It would be great
for us to try to lead the way and push things forward a bit.  But I think
we're still going to have to make it very easy to enable TLS 1.0/1.1 for a
lot of people and applications for a bit longer.


While I think we might want to ship buster with TLS 1.0 available, I
think running with it disabled for parts of the development cycle is
very useful, since it exposes bugs we have in packages that will use
that version out of the box (isync being referred to elsethread).
Finding and fixing those bugs is good.

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

Re: OpenSSL disables TLS 1.0 and 1.1

[Adrian Bunk]

On Mon, Aug 07, 2017 at 03:42:39AM +0200, Kurt Roeckx wrote:
>...
> I've just uploaded a version of OpenSSL to unstable that disables
> the TLS 1.0 and 1.1 protocol. This currently leaves TLS 1.2 as the
> only supported SSL/TLS protocol version.
>...

Has prior to this change any effort been made to create a coherent 
policy for buster for all packages that contain a TLS implementation?

> 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 disables TLS 1.0 and 1.1

[Daniel Reichelt]

On 08/12/2017 02:16 PM, Tollef Fog Heen wrote:
> While I think we might want to ship buster with TLS 1.0 available, I
> think running with it disabled for parts of the development cycle is
> very useful, since it exposes bugs we have in packages that will use
> that version out of the box (isync being referred to elsethread).
> Finding and fixing those bugs is good.
> 

This got me thinking... how about a split of the generated binary
packages to generate a (default) set with only TLS 1.2 available and a
fallback set with the current configuration?


One would have to work out a convention for whether

1) the fallback set would have both Provides and Conflicts set or

2)  both sets should cooperate with each other and how
2.1) via alternatives
2.2) a more fine-grained approach to select an appropriately configured
library on a per-application basis (e.g. LD_PRELOAD?)


Cheers
Daniel



signature.asc
Description: OpenPGP digital signature

Re: OpenSSL disables TLS 1.0 and 1.1

[Tollef Fog Heen]

]] Russ Allbery 

> That doesn't mean we can't make it very easy to disable TLS 1.0/1.1 or
> encourage people to do that when possible, of course.  It would be great
> for us to try to lead the way and push things forward a bit.  But I think
> we're still going to have to make it very easy to enable TLS 1.0/1.1 for a
> lot of people and applications for a bit longer.

While I think we might want to ship buster with TLS 1.0 available, I
think running with it disabled for parts of the development cycle is
very useful, since it exposes bugs we have in packages that will use
that version out of the box (isync being referred to elsethread).
Finding and fixing those bugs is good.

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

Re: OpenSSL disables TLS 1.0 and 1.1

[Russ Allbery]

Marco d'Itri  writes:

> But as it has been noted there is more than HTTP, so totally removing
> support for 1.0/1.1 may still not be appropriate.

Adding a data point here, my employer (Dropbox) is reasonably aggressive
about SSL configuration, but based on the usage we see, we've not yet been
comfortable with dropping TLS 1.0 and 1.1.  Maybe we will be by the end of
the buster release cycle, but that isn't entirely clear to me.  Google,
Amazon, Microsoft, and the EFF all also still support TLS 1.0/1.1 on their
primary web sites, for whatever that's worth.

A good external validation for when industry best practice is willing to
drop TLS 1.0/1.1 support is when Qualys SSL Labs
(https://www.ssllabs.com/ssltest/) starts lowering the grade below A+ for
sites that have TLS 1.0/1.1 enabled.  They still haven't been willing to
take that step, and I think they're a reasonable lagging indicator for
current accepted best SSL practice.

That doesn't mean we can't make it very easy to disable TLS 1.0/1.1 or
encourage people to do that when possible, of course.  It would be great
for us to try to lead the way and push things forward a bit.  But I think
we're still going to have to make it very easy to enable TLS 1.0/1.1 for a
lot of people and applications for a bit longer.

-- 
Russ Allbery (r...@debian.org)   

Re: OpenSSL disables TLS 1.0 and 1.1

[Marc Haber]

On Fri, 11 Aug 2017 18:20:22 +0200, Sven Hartge 
wrote:
>Christian Seiler  wrote:
>> Don't get me wrong: I do believe it's a huge problem that vendors of
>> said appliances don't provide updates for these kind of things, and I
>> wish that we could indeed drop everything except TLS 1.2, but the real
>> world is unfortunately more complicated, and I think Debian would do a
>> huge disservice to users if it removed TLS 1.0 and 1.1 from OpenSSL in
>> Buster without a well-documented possibility for the admin to reenable
>> it.
>
>I'd go one step further and say that Debian would disqualify itself as a
>distribution usable for any real world application.

What Sven says, yes.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: OpenSSL disables TLS 1.0 and 1.1

[Sven Hartge]

Christian Seiler  wrote:

> Don't get me wrong: I do believe it's a huge problem that vendors of
> said appliances don't provide updates for these kind of things, and I
> wish that we could indeed drop everything except TLS 1.2, but the real
> world is unfortunately more complicated, and I think Debian would do a
> huge disservice to users if it removed TLS 1.0 and 1.1 from OpenSSL in
> Buster without a well-documented possibility for the admin to reenable
> it.

I'd go one step further and say that Debian would disqualify itself as a
distribution usable for any real world application.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: OpenSSL disables TLS 1.0 and 1.1

[Sven Hartge]

Kurt Roeckx  wrote:
> On Fri, Aug 11, 2017 at 01:34:53PM +0200, Sven Hartge wrote:
>> Marco d'Itri  wrote:
>>> On Aug 09, Sven Hartge  wrote:
 
>> >> Looking at https://developer.android.com/about/dashboards/index.html
>> >> there is still a marketshare of ~25% of smartphones based on Android
>> >> 5.0 and 5.1 and 16% based on 4.4. So this change would (at the
>> >> moment) block ~40% of Android smartphones from connecting to any WLAN
>> >> using PEAP or TTLS.
>> 
>> > Android 5.x should support TLS 1.2:
>> > http://caniuse.com/#search=TLS
>> 
>> The Browser, yes. But not the components doing the WPA stuff:
>> 
>> ,
>> | Aug  9 20:09:13 ds9 radiusd[4179992]: (12924) Login incorrect (eap_ttls: 
>> TLS Alert write:fatal:protocol version): [owehxperia] (from client ap01 port 
>> 54 cli 30-39-26-xx-xx-xx)
>> | Aug  9 20:09:24 ds9 radiusd[4179992]: (12928) eap_ttls: ERROR: TLS Alert 
>> write:fatal:protocol version
>> | Aug  9 20:09:24 ds9 radiusd[4179992]: tls: TLS_accept: Error in error
>> `
>> 
>> Only recompiling openssl with TLS1.0 and TLS1.1 enabled allowed my phone
>> to connect successfully.

> Any idea if this actually works with newer android phones?

It works with Android 6.0 on my tablet and with 7.1.1 on my newer phone.

> Could someone report this to Google? I consider everything broken by
> this a security issue and hope that Google will fix it in all releases
> they still support.

Given the track record of vendors of Android-based phones on shipping
*any* updates Google provides, I'd say the chance of those fixes
actually reaching the end-user are slim to none.

(My Samsung tablet for example got *two* updates in its whole 4 year
life span: one to 5.1 and one to 6.0. Monthy security fixes: none.)

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: OpenSSL disables TLS 1.0 and 1.1

[Wouter Verhelst]

On Fri, Aug 11, 2017 at 04:24:03PM +0200, Kurt Roeckx wrote:
> On Fri, Aug 11, 2017 at 08:41:10AM -0400, Wouter Verhelst wrote:
> > On Mon, Aug 07, 2017 at 08:35:52PM +0200, Kurt Roeckx wrote:
> > > On Mon, Aug 07, 2017 at 05:22:51PM +0200, Joerg Jaspert wrote:
> > > > I wonder if there is a middle way that ensures that all new stuff does
> > > > go TLS1.2 (or later, whenever), but does allow older stuff still to
> > > > work. Which isnt the case if they are just disabled.
> > > 
> > > I could change the default settings to set the minimum supported
> > > version as TLS 1.2. That is, act like
> > > SSL_CTX_set_min_proto_version() was called with TLS1_2_VERSION.
> > > That would allow applications to override this this by calling
> > > SSL_CTX_set_min_proto_version(). But then those are new
> > > functions in 1.1.0 and they probably aren't supported by many
> > > applications.
> > > 
> > > An other alternative is to use the deprecated SSL_CTX_set_options
> > > options (SSL_OP_NO_TLSv1 | SSL_OP_NO_TLSv1_1) by default, but then
> > > there is probably no software that has support for clearing those
> > > with SSL_CTX_clear_options()
> > 
> > Would it instead be possible to create an item in the openssl.conf file
> > to disable TLS1.2 by default? That way, users can re-enable TLS1.{0,1}
> > in cases where that's required, and you can drop TLS1.0 and 1.1 (and
> > possibly 1.2 even, if 1.3 has enough traction) in bullseye.
> 
> I prefer this to be enabled on application basis, which is why I
> suggested the above ways.

Sure. If I read "man 5 config" correctly though, openssl should allow
per-application configuration file snippets to be read. A proper howto
page on the wiki or elsewhere could then explain users how they should
add such a snippet for their applications (and *only* for those
applications where it is required).

I'm afraid that if you leave this to application developers, some
applications will not do it, leading uninformed users to simply
recompile OpenSSL themselves (with TLS1.0 and TLS1.1 enabled), thereby
resulting in a system with reduced security for *all* applications,
rather than just the one where they need TLS1.0.

> OpenSSL has support for setting such a mimimum in a config file,
> I'm just not sure if it reads any section related to it by
> default, I think it doesn't.

That might be a good feature request then, I suppose.

Alternatively, you could make the default in the absense of any
configuration file be to *not* enable TLS1.2, but allow it to be enabled
by an openssl configuration change (which AIUI is not the current state
of affairs). That would work too.

-- 
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 disables TLS 1.0 and 1.1

[Kurt Roeckx]

On Fri, Aug 11, 2017 at 08:41:10AM -0400, Wouter Verhelst wrote:
> On Mon, Aug 07, 2017 at 08:35:52PM +0200, Kurt Roeckx wrote:
> > On Mon, Aug 07, 2017 at 05:22:51PM +0200, Joerg Jaspert wrote:
> > > I wonder if there is a middle way that ensures that all new stuff does
> > > go TLS1.2 (or later, whenever), but does allow older stuff still to
> > > work. Which isnt the case if they are just disabled.
> > 
> > I could change the default settings to set the minimum supported
> > version as TLS 1.2. That is, act like
> > SSL_CTX_set_min_proto_version() was called with TLS1_2_VERSION.
> > That would allow applications to override this this by calling
> > SSL_CTX_set_min_proto_version(). But then those are new
> > functions in 1.1.0 and they probably aren't supported by many
> > applications.
> > 
> > An other alternative is to use the deprecated SSL_CTX_set_options
> > options (SSL_OP_NO_TLSv1 | SSL_OP_NO_TLSv1_1) by default, but then
> > there is probably no software that has support for clearing those
> > with SSL_CTX_clear_options()
> 
> Would it instead be possible to create an item in the openssl.conf file
> to disable TLS1.2 by default? That way, users can re-enable TLS1.{0,1}
> in cases where that's required, and you can drop TLS1.0 and 1.1 (and
> possibly 1.2 even, if 1.3 has enough traction) in bullseye.

I prefer this to be enabled on application basis, which is why I
suggested the above ways.

OpenSSL has support for setting such a mimimum in a config file,
I'm just not sure if it reads any section related to it by
default, I think it doesn't.


Kurt

Re: OpenSSL disables TLS 1.0 and 1.1

[Christian Seiler]

Hi,

Am 2017-08-11 15:09, schrieb Sven Hartge:

Unless it has been proven that TLS1.0 and TLS1.1 are as broken as SSL3,
please keep the support for them enabled in OpenSSL, and just change 
the

defaults in the application to only use TLS1.2 (unless changed by the
administrator).


I remember a talk at Debconf15 about Fedora's system-wide policy for
Crypto stuff:

https://summit.debconf.org/debconf15/meeting/252/enforcement-of-a-system-wide-crypto-policies/

I haven't rewatched the talk, but if I remember correctly, the
whole thing was designed in a way that the administrator could
change both the system-wide policy and also override it per
application.

If we follow through on this, we could then disable anything but
TLS 1.2 in the default system-wide policy - the default settings
would then be more secure while users could then still change the
policy for compatibility reasons if so required. It would also
provide a central nob for the future for users who don't have to
worry about compatibility and perhaps want to disable TLS 1.2 in
favor of 1.3 (which will be part of OpenSSL 1.1.1).


Btw. speaking of this issue: a friend of mine who's an administrator
at a university has had the problem that he can't use the HTTPS
interface of some NAS devices (and I'm talking 19" rack-mounted
storage with internal and external SAS interface) anymore since the
interface only supports either older SSL versions or older ciphers
that modern browsers simply don't accept anymore. (Not even with
about:config options.) And there are no firmware updates for these
devices anymore, so he's now administering these devices via
unencrypted HTTP. Which is definitely worse than HTTPS with even
SSLv3. In his case it's not too bad, because they are in a separate
network that isn't routed to the public (using ssh -D to a gateaway
to access them), but this shows what problems can arise from this.

Don't get me wrong: I do believe it's a huge problem that vendors
of said appliances don't provide updates for these kind of things,
and I wish that we could indeed drop everything except TLS 1.2, but
the real world is unfortunately more complicated, and I think
Debian would do a huge disservice to users if it removed TLS 1.0
and 1.1 from OpenSSL in Buster without a well-documented
possibility for the admin to reenable it.

Regards,
Christian

Re: OpenSSL disables TLS 1.0 and 1.1

[Kurt Roeckx]

On Fri, Aug 11, 2017 at 01:34:53PM +0200, Sven Hartge wrote:
> Marco d'Itri  wrote:
> > On Aug 09, Sven Hartge  wrote:
> 
> >> Looking at https://developer.android.com/about/dashboards/index.html
> >> there is still a marketshare of ~25% of smartphones based on Android
> >> 5.0 and 5.1 and 16% based on 4.4. So this change would (at the
> >> moment) block ~40% of Android smartphones from connecting to any WLAN
> >> using PEAP or TTLS.
> 
> > Android 5.x should support TLS 1.2:
> > http://caniuse.com/#search=TLS
> 
> The Browser, yes. But not the components doing the WPA stuff:
> 
> ,
> | Aug  9 20:09:13 ds9 radiusd[4179992]: (12924) Login incorrect (eap_ttls: 
> TLS Alert write:fatal:protocol version): [owehxperia] (from client ap01 port 
> 54 cli 30-39-26-xx-xx-xx)
> | Aug  9 20:09:24 ds9 radiusd[4179992]: (12928) eap_ttls: ERROR: TLS Alert 
> write:fatal:protocol version
> | Aug  9 20:09:24 ds9 radiusd[4179992]: tls: TLS_accept: Error in error
> `
> 
> Only recompiling openssl with TLS1.0 and TLS1.1 enabled allowed my phone
> to connect successfully.

Any idea if this actually works with newer android phones?

Could someone report this to Google? I consider everything broken
by this a security issue and hope that Google will fix it in all
releases they still support.


Kurt

Re: OpenSSL disables TLS 1.0 and 1.1

[Sven Hartge]

Marco d'Itri  wrote:
> On Aug 11, Marco d'Itri  wrote:

>> but I see on your link that Android pre-5.x still has a ~25% market
>> share, so unless it will drop a lot in the next year I do not think
>> that we can cut them off from Debian-based web servers.

> OTOH if the PCI council says that TLS < 1.2 has to go by june 2018
> then this will probably not be such a big deal:

> https://www.fastly.com/blog/phase-two-our-tls-10-and-11-deprecation-plan/

> But as it has been noted there is more than HTTP, so totally removing 
> support for 1.0/1.1 may still not be appropriate.

Not everything is regulated by the PCI council.

If, after upgrading to Buster, suddenly 25% of the students of my
university can no longer connect to the wireless network, it will be
hell on earth for me and my support staff.

It is nice to say "well, then get the other side to upgrade to a new
device", but as it has already been said in this discussion: The real
world does not work that way.

Unless it has been proven that TLS1.0 and TLS1.1 are as broken as SSL3,
please keep the support for them enabled in OpenSSL, and just change the
defaults in the application to only use TLS1.2 (unless changed by the
administrator).

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: OpenSSL disables TLS 1.0 and 1.1

[Marco d'Itri]

On Aug 11, Marco d'Itri  wrote:

> but I see on your link that Android pre-5.x still has a ~25% market 
> share, so unless it will drop a lot in the next year I do not think that 
> we can cut them off from Debian-based web servers.
OTOH if the PCI council says that TLS < 1.2 has to go by june 2018 then 
this will probably not be such a big deal:

https://www.fastly.com/blog/phase-two-our-tls-10-and-11-deprecation-plan/

But as it has been noted there is more than HTTP, so totally removing 
support for 1.0/1.1 may still not be appropriate.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: OpenSSL disables TLS 1.0 and 1.1

[Wouter Verhelst]

On Mon, Aug 07, 2017 at 08:35:52PM +0200, Kurt Roeckx wrote:
> On Mon, Aug 07, 2017 at 05:22:51PM +0200, Joerg Jaspert wrote:
> > I wonder if there is a middle way that ensures that all new stuff does
> > go TLS1.2 (or later, whenever), but does allow older stuff still to
> > work. Which isnt the case if they are just disabled.
> 
> I could change the default settings to set the minimum supported
> version as TLS 1.2. That is, act like
> SSL_CTX_set_min_proto_version() was called with TLS1_2_VERSION.
> That would allow applications to override this this by calling
> SSL_CTX_set_min_proto_version(). But then those are new
> functions in 1.1.0 and they probably aren't supported by many
> applications.
> 
> An other alternative is to use the deprecated SSL_CTX_set_options
> options (SSL_OP_NO_TLSv1 | SSL_OP_NO_TLSv1_1) by default, but then
> there is probably no software that has support for clearing those
> with SSL_CTX_clear_options()

Would it instead be possible to create an item in the openssl.conf file
to disable TLS1.2 by default? That way, users can re-enable TLS1.{0,1}
in cases where that's required, and you can drop TLS1.0 and 1.1 (and
possibly 1.2 even, if 1.3 has enough traction) in bullseye.

Thanks,

-- 
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 disables TLS 1.0 and 1.1

[Sven Hartge]

Marco d'Itri  wrote:
> On Aug 09, Sven Hartge  wrote:

>> Looking at https://developer.android.com/about/dashboards/index.html
>> there is still a marketshare of ~25% of smartphones based on Android
>> 5.0 and 5.1 and 16% based on 4.4. So this change would (at the
>> moment) block ~40% of Android smartphones from connecting to any WLAN
>> using PEAP or TTLS.

> Android 5.x should support TLS 1.2:
> http://caniuse.com/#search=TLS

The Browser, yes. But not the components doing the WPA stuff:

,
| Aug  9 20:09:13 ds9 radiusd[4179992]: (12924) Login incorrect (eap_ttls: TLS 
Alert write:fatal:protocol version): [owehxperia] (from client ap01 port 54 cli 
30-39-26-xx-xx-xx)
| Aug  9 20:09:24 ds9 radiusd[4179992]: (12928) eap_ttls: ERROR: TLS Alert 
write:fatal:protocol version
| Aug  9 20:09:24 ds9 radiusd[4179992]: tls: TLS_accept: Error in error
`

Only recompiling openssl with TLS1.0 and TLS1.1 enabled allowed my phone
to connect successfully.

> but I see on your link that Android pre-5.x still has a ~25% market 
> share, so unless it will drop a lot in the next year I do not think that 
> we can cut them off from Debian-based web servers.

It is far more than 25%. Lollipop, Kitkat and Jelly Bean add up to ~52%
of marketshare and I don't think this number will drop significantly
below 25% in the next 2 to 3 years.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: OpenSSL disables TLS 1.0 and 1.1

[Marco d'Itri]

On Aug 09, Sven Hartge  wrote:

> Looking at https://developer.android.com/about/dashboards/index.html
> there is still a marketshare of ~25% of smartphones based on Android 5.0
> and 5.1 and 16% based on 4.4. So this change would (at the moment) block
> ~40% of Android smartphones from connecting to any WLAN using PEAP or
> TTLS.
Android 5.x should support TLS 1.2:
http://caniuse.com/#search=TLS

but I see on your link that Android pre-5.x still has a ~25% market 
share, so unless it will drop a lot in the next year I do not think that 
we can cut them off from Debian-based web servers.
Everybody please remember that our own personal hardware is not 
representative of the market... :-)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: OpenSSL disables TLS 1.0 and 1.1

[Stephan Seitz]

On Mo, Aug 07, 2017 at 08:52:41 +0200, Marco d'Itri wrote:

I think that I live in a real enough world (commercial web hosting), and
my customers have been asking for a while to disable at least TLS 1.0


Well, if I understand it correctly, apache/openssl in SLES11 SP4 only 
support TLSv1.


Long term support for SP4 ends in 2022.

Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: OpenSSL disables TLS 1.0 and 1.1

[Sven Hartge]

Marco d'Itri  wrote:
> On Aug 07, Joerg Jaspert  wrote:

>> Thats nice for any environment where on can freely define that
>> everything works like this.
>> 
>> Unfortunately real world doesnt work like it.

> Can you describe some examples of what still requires 1.0/1.1 on a
> client or a server?

I just found out that because of that change my older Android 5.1 based
smartphone can no longer connect to my WPA-Enterprise WLAN.

Looking at https://developer.android.com/about/dashboards/index.html
there is still a marketshare of ~25% of smartphones based on Android 5.0
and 5.1 and 16% based on 4.4. So this change would (at the moment) block
~40% of Android smartphones from connecting to any WLAN using PEAP or
TTLS.

And when I look at other wireless-enabled things, the ratio for support
for TLS1.2-only might be even worse and less quick to change.

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

Re: OpenSSL disables TLS 1.0 and 1.1

[Vincent Lefevre]

On 2017-08-08 13:26:52 +0200, Stephan Seitz wrote:
> On Mo, Aug 07, 2017 at 11:18:38 -0500, Michael Lustfield wrote:
> > Is there an actual need for the removal of TLS v1.{0,1}? Are either
> > considered broken or unsupported by upstream? If not, I'd be much more
> 
> That’s I like to know as well.

BTW, IMHO, as it can break things, this change should be announced
in NEWS.Debian, together with known problems with other Debian
software, and so on.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: OpenSSL disables TLS 1.0 and 1.1

[Attila Szalay]

Hi,

My concern is less about https (hello iloms), but other kind of protocols.
Ssl vpn, rdp servers, voip, etc. And embedded devices implements this
protocols.

On Aug 8, 2017 7:35 AM, "Stephan Seitz" 
wrote:

> On Mo, Aug 07, 2017 at 11:18:38 -0500, Michael Lustfield wrote:
>
>> Is there an actual need for the removal of TLS v1.{0,1}? Are either
>> considered broken or unsupported by upstream? If not, I'd be much more
>>
>
> That’s I like to know as well.
>
> Doing a quick check on my appliances I could find the following TLSv1-only
> devices:
> - some iDRAC (Dell)
> - Netapp Filer
> - Cisco Web Security Appliances
>
> And what about mail appliances? If they offer only TLSv1 then the Debian
> mailserver will fallback to unencrypted transfer. I don’t think this is a
> good idea.
>
> Shade and sweet water!
>
> Stephan
>
> --
> | Public Keys: http://fsing.rootsland.net/~stse/keys.html |
>

Re: OpenSSL disables TLS 1.0 and 1.1

[Stephan Seitz]

On Mo, Aug 07, 2017 at 11:18:38 -0500, Michael Lustfield wrote:

Is there an actual need for the removal of TLS v1.{0,1}? Are either
considered broken or unsupported by upstream? If not, I'd be much more


That’s I like to know as well.

Doing a quick check on my appliances I could find the following 
TLSv1-only devices:

- some iDRAC (Dell)
- Netapp Filer
- Cisco Web Security Appliances

And what about mail appliances? If they offer only TLSv1 then the Debian 
mailserver will fallback to unencrypted transfer. I don’t think this is 
a good idea.


Shade and sweet water!

Stephan

--
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: isync/mbsync's TLS config (was Re: OpenSSL disables TLS 1.0 and 1.1)

[Ralph Amissah]

On 2017-08-07 20:12, James McCoy wrote:
> On Mon, Aug 07, 2017 at 03:11:18PM -0400, Ralph Amissah wrote:
> > I believe this is the reason I am currently unable to backup my
> > gmail account with isync/ mbsync
> 
> That's because isync defaults to TLSv1 unless you tell it to do
> otherwise.
> 
> https://sources.debian.net/src/isync/1.2.1-2/src/drv_imap.c/?hl=2675#L2877
> 
> Add "SSLVersions TLSv1.2" to your IMAPAccount stanza and it will start
> working again.
> 

Perfect. Thanks for taking the trouble.

Thanks,
Ralph

P.S. For my (fairly old) config originally from Arch wiki there I had to add
two lines:

SSLType IMAPS
SSLVersions TLSv1.2

and to remove two others:

# UseIMAPS yes
# CertificateFile /etc/ssl/certs/ca-certificates.crt

There were messages about configuration settings being mutually exclusive
and others depreciated.

> Cheers,
> -- 
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

isync/mbsync's TLS config (was Re: OpenSSL disables TLS 1.0 and 1.1)

[James McCoy]

On Mon, Aug 07, 2017 at 03:11:18PM -0400, Ralph Amissah wrote:
> I believe this is the reason I am currently unable to backup my
> gmail account with isync/ mbsync

That's because isync defaults to TLSv1 unless you tell it to do
otherwise.

https://sources.debian.net/src/isync/1.2.1-2/src/drv_imap.c/?hl=2675#L2877

Add "SSLVersions TLSv1.2" to your IMAPAccount stanza and it will start
working again.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Re: OpenSSL disables TLS 1.0 and 1.1

[Ralph Amissah]

On Mon, Aug 7, 2017 at 2:59 PM, Colin Tuckley  wrote:
> On Mon, Aug 7, 2017 at 2:38 PM, Kurt Roeckx  wrote:
>
>> If I upload things to experimental and ask people to test it,
>> I will get no feedback at all.
>
> None the less, that is the correct thing to do.
>
> After an upload to unstable the first thing that will happen is that
> every DD will file an RC bug against it to stop it transitioning to
> testing citing no testing and massive breakage of depending packages
> with no fix available.
>
> Colin
>
> --
> Colin Tuckley| +44(0)1223 830814 |  PGP/GnuPG Key Id
> Debian Developer | +44(0)7799 143369 | 0xFA0C410738C9D903
>

Greetings,

I believe this is the reason I am currently unable to backup my
gmail account with isync/ mbsync

Not only valuable for me as a backup, this makes mail available for
use with notmuch with both emacs and mutt.

Of course if this persuades gmail to update soon, great.

Anyhow, assuming this to be the reason for my inability to download
mail today, what an effort to reply to these emails I am now stuck in
the bloody browser again, no vim, no emacs ...

Ralph

On Mon, Aug 7, 2017 at 2:59 PM, Colin Tuckley  wrote:
> On 07/08/17 19:38, Kurt Roeckx wrote:
>
>> If I upload things to experimental and ask people to test it,
>> I will get no feedback at all.
>
> None the less, that is the correct thing to do.
>
> After an upload to unstable the first thing that will happen is that
> every DD will file an RC bug against it to stop it transitioning to
> testing citing no testing and massive breakage of depending packages
> with no fix available.
>
> Colin
>
> --
> Colin Tuckley| +44(0)1223 830814 |  PGP/GnuPG Key Id
> Debian Developer | +44(0)7799 143369 | 0xFA0C410738C9D903
>

Re: OpenSSL disables TLS 1.0 and 1.1

[Colin Tuckley]

On 07/08/17 19:38, Kurt Roeckx wrote:

> If I upload things to experimental and ask people to test it,
> I will get no feedback at all.

None the less, that is the correct thing to do.

After an upload to unstable the first thing that will happen is that
every DD will file an RC bug against it to stop it transitioning to
testing citing no testing and massive breakage of depending packages
with no fix available.

Colin

-- 
Colin Tuckley| +44(0)1223 830814 |  PGP/GnuPG Key Id
Debian Developer | +44(0)7799 143369 | 0xFA0C410738C9D903

Re: OpenSSL disables TLS 1.0 and 1.1

[Marco d'Itri]

On Aug 07, Joerg Jaspert  wrote:

> Thats nice for any environment where on can freely define that
> everything works like this.
> 
> Unfortunately real world doesnt work like it.
I think that I live in a real enough world (commercial web hosting), and 
my customers have been asking for a while to disable at least TLS 1.0 
(thank you, Paypal!).
This is also the default for our newer servers and nobody has ever 
complained.
Can you describe some examples of what still requires 1.0/1.1 on 
a client or a server?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: OpenSSL disables TLS 1.0 and 1.1

[Kurt Roeckx]

On Mon, Aug 07, 2017 at 05:53:07PM +0200, Michael Meskes wrote:
> > > This will likely break certain things that for whatever reason
> > > still don't support TLS 1.2. I strongly suggest that if it's not
> > > supported that you add support for it, or get the other side to
> > > add support for it.
> > 
> > In many cases this isnt possible.
> 
> Wouldn't it make sense to start with experimental and test/file bug
> reports on stuff that doesn't? Let's make this clear, if you install
> the new packages chances are nearly 100% that something will break, at
> least that's my experience.

If I upload things to experimental and ask people to test it,
I will get no feedback at all.


Kurt

Re: OpenSSL disables TLS 1.0 and 1.1

[Kurt Roeckx]

On Mon, Aug 07, 2017 at 05:22:51PM +0200, Joerg Jaspert wrote:
> I wonder if there is a middle way that ensures that all new stuff does
> go TLS1.2 (or later, whenever), but does allow older stuff still to
> work. Which isnt the case if they are just disabled.

I could change the default settings to set the minimum supported
version as TLS 1.2. That is, act like
SSL_CTX_set_min_proto_version() was called with TLS1_2_VERSION.
That would allow applications to override this this by calling
SSL_CTX_set_min_proto_version(). But then those are new
functions in 1.1.0 and they probably aren't supported by many
applications.

An other alternative is to use the deprecated SSL_CTX_set_options
options (SSL_OP_NO_TLSv1 | SSL_OP_NO_TLSv1_1) by default, but then
there is probably no software that has support for clearing those
with SSL_CTX_clear_options()


Kurt

Re: OpenSSL disables TLS 1.0 and 1.1

[Michael Lustfield]

On Aug 7, 2017 8:23 AM, "Joerg Jaspert"  wrote:

On 14757 March 1977, Kurt Roeckx wrote:

> This will likely break certain things that for whatever reason
> still don't support TLS 1.2. I strongly suggest that if it's not
> supported that you add support for it, or get the other side to
> add support for it.

In many cases this isnt possible.


I can think of a lot of "enterprise" tools that have been built for older
versions of Java. In most cases, the vendors have no interest in doing
anything required to get away from a TLSv1.0 requirement. I'm also aware
some of the well-known search engine bots that support only TLSv1.0.

Is there an actual need for the removal of TLS v1.{0,1}? Are either
considered broken or unsupported by upstream? If not, I'd be much more
concerned about what's going to start breaking by making this change.

Shouldn't a change like this at least start with packages such as nginx,
apache, etc. and seeing if they can drop those from the default
configuration? Heck, I'm sure we could even include a comment along the
lines of "if you need to re-enable older TLS versions due to application
compatibility, please respond to bug #123".

I'm not sure what exactly would be a better idea, but disabling globally
with no easy workaround sounds like a recipe for pain and very angry users.

Re: OpenSSL disables TLS 1.0 and 1.1

[Michael Meskes]

> > This will likely break certain things that for whatever reason
> > still don't support TLS 1.2. I strongly suggest that if it's not
> > supported that you add support for it, or get the other side to
> > add support for it.
> 
> In many cases this isnt possible.

Wouldn't it make sense to start with experimental and test/file bug
reports on stuff that doesn't? Let's make this clear, if you install
the new packages chances are nearly 100% that something will break, at
least that's my experience.

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 disables TLS 1.0 and 1.1

[Kurt Roeckx]

On Mon, Aug 07, 2017 at 09:59:20AM +0200, Leon Klingele wrote:
> Does this also apply for libssl?

This applies to libssl1.1 package and everything making use of it.


Kurt

Re: OpenSSL disables TLS 1.0 and 1.1

[Joerg Jaspert]

On 14757 March 1977, Kurt Roeckx wrote:

> I've just uploaded a version of OpenSSL to unstable that disables
> the TLS 1.0 and 1.1 protocol. This currently leaves TLS 1.2 as the
> only supported SSL/TLS protocol version.

Thats nice for any environment where on can freely define that
everything works like this.

Unfortunately real world doesnt work like it.

> This will likely break certain things that for whatever reason
> still don't support TLS 1.2. I strongly suggest that if it's not
> supported that you add support for it, or get the other side to
> add support for it.

In many cases this isnt possible.

> OpenSSL made a release 5 years ago that supported TLS 1.2. The
> current support of the server side seems to be around 90%. I hope
> that by the time Buster releases the support for TLS 1.2 will be
> high enough that I don't need to enable them again.

I wonder if there is a middle way that ensures that all new stuff does
go TLS1.2 (or later, whenever), but does allow older stuff still to
work. Which isnt the case if they are just disabled.

-- 
bye, Joerg

Re: OpenSSL disables TLS 1.0 and 1.1

[Sebastian Andrzej Siewior]

On 2017-08-07 09:59:20 [+0200], Leon Klingele wrote:
> Does this also apply for libssl?
Yes, libssl1.1 and all its users to be exact. libssl1.0 does not have
this change but we plan to have it removed for Buster.

Sebastian

Re: OpenSSL disables TLS 1.0 and 1.1

[Leon Klingele]

Does this also apply for libssl?

> Am 07.08.2017 um 03:42 schrieb Kurt Roeckx :
> 
> Hi,
> 
> I've just uploaded a version of OpenSSL to unstable that disables
> the TLS 1.0 and 1.1 protocol. This currently leaves TLS 1.2 as the
> only supported SSL/TLS protocol version.
> 
> This will likely break certain things that for whatever reason
> still don't support TLS 1.2. I strongly suggest that if it's not
> supported that you add support for it, or get the other side to
> add support for it.
> 
> OpenSSL made a release 5 years ago that supported TLS 1.2. The
> current support of the server side seems to be around 90%. I hope
> that by the time Buster releases the support for TLS 1.2 will be
> high enough that I don't need to enable them again.
> 
> 
> Kurt
>