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
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 olde
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
> w
>> 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
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'
> 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 g
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 c
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
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 agr
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 rel
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 signatur
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 q
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 marketsh
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 ser
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
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 pol
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
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 t
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 be
]] 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 enabl
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
com
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 rea
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 De
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
>> >>
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
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,
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 ta
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% base
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 <
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
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 c
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 s
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
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
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?
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.
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 actua
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 follow
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.
>
> ht
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.
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 fi
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 s
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
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.
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 t
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 suppo
> > 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
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
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 wor
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
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 brea
51 matches
Mail list logo
