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
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
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
>
>> 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
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.
>
> 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
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
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
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.
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
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
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
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
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
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
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
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
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
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
]] 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
>
>
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.
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.
>
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
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
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
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
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
> > 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
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
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
51 matches
Mail list logo