On 2018-07-10 04:05:58 [+0200], Philippe Metzger wrote:
> For now it seems that OpenSSL 1.1.0f-3+deb9u2 available in stretch/security
> force TLS 1.2 only in https when using Apache (whatever SSLProtocol
> Directive specify).
This is not true. Stretch has TLS1.0 and up enabled by default.
> Is th
On Thu, 26 Oct 2017 09:57:06 +0200 Raphael Hertzog wrote:
> Hello Kurt,
>
> On Fri, 22 Sep 2017, Kurt Roeckx wrote:
> > I have to admit that I didn't consider derivatives that take a
> > snapshot of testing, and we also seem to have a large amount of
> > people that do use testing. My intention wa
Hello Kurt,
On Fri, 22 Sep 2017, Kurt Roeckx wrote:
> I have to admit that I didn't consider derivatives that take a
> snapshot of testing, and we also seem to have a large amount of
> people that do use testing. My intention was to target the more
> advanced users, and having it in testing might
On 2017-10-07 02:14:10 [+0200], Gedalya wrote:
> This is affecting EAP with wpa_supplicant.
> See https://bugs.debian.org/877904
You need to do two steps in wpa supplicant:
- Add an option to set minimum TLS version
- if that option is set, forwarded its value (1.0 or 1.1) to
SSL_CTX_set_min_pro
This is affecting EAP with wpa_supplicant.
See https://bugs.debian.org/877904
Hi,
On Fri, Sep 22, 2017 at 12:21:26AM +0200, Kurt Roeckx wrote:
> On Mon, Sep 11, 2017 at 12:30:30PM +0200, Raphael Hertzog wrote:
> > But in Debian testing, we have real end-users (direct and through
> > "rolling" derivatives) and they should not have to be impacted by this
> > experiment IMO.
>
On 2017-09-22 11:12:52 [+0200], Raphael Hertzog wrote:
> Hi,
>
> On Thu, 21 Sep 2017, Sebastian Andrzej Siewior wrote:
> > The changes Kurt asked about is something that openssl upstream supports
> > and is something that openssl 1.1 considers the right way of doing
> > things (in contrast to the
> "KR" == Kurt Roeckx writes:
KR> On Mon, Sep 11, 2017 at 11:33:22AM +0200, Raphaël Hertzog wrote:
>> Or at least I would like a system-wide flag (in a configuration file?) to
>> let me re-enable old protocols easily.
KR> It was my understanding that other people also prefered to do this
KR>
Hi,
On Thu, 21 Sep 2017, Sebastian Andrzej Siewior wrote:
> The changes Kurt asked about is something that openssl upstream supports
> and is something that openssl 1.1 considers the right way of doing
> things (in contrast to the disable TLS-version X thingy which are marked
> deprecated or going
Hi Kurt,
On Fri, 22 Sep 2017, Kurt Roeckx wrote:
> I have to admit that I didn't consider derivatives that take a
> snapshot of testing, and we also seem to have a large amount of
> people that do use testing. My intention was to target the more
> advanced users, and having it in testing might be
On Mon, Sep 11, 2017 at 12:30:30PM +0200, Raphael Hertzog wrote:
> But in Debian testing, we have real end-users (direct and through
> "rolling" derivatives) and they should not have to be impacted by this
> experiment IMO.
I have to admit that I didn't consider derivatives that take a
snapshot of
On Mon, Sep 11, 2017 at 11:33:22AM +0200, Raphaël Hertzog wrote:
> Or at least I would like a system-wide flag (in a configuration file?) to
> let me re-enable old protocols easily.
It was my understanding that other people also prefered to do this
on a per package level and not system wide.
Kur
On 2017-09-11 12:30:30 [+0200], Raphael Hertzog wrote:
> Yes, I'm aware of that but Kurt never said that he would be willing to
> back off from completely disabling it before the buster release and
> I don't see any benefit in modifying all server applications to re-enable
> the protocols that we w
Raphaël Hertzog writes:
...
> Or at least I would like a system-wide flag (in a configuration file?) to
> let me re-enable old protocols easily.
Just because I haven't seen anyone else suggest it:
Would it be practical to have the normal packages drop TLS 1.0/1.1
support as currently planned, b
On Mon, 11 Sep 2017, Philipp Kern wrote:
> https://packages.qa.debian.org/o/openssl/news/20170824T211015Z.html seems to
> have pushed this onto client applications? I.e. it's no longer hard disabled
> but client applications need to explicitly enable them?
Yes, I'm aware of that but Kurt never sai
On 2017-09-11 11:33, Raphaël Hertzog wrote:
I looked back at the debian-devel discussion and it seems to me that
the majority of persons who expressed themselves (including Moritz
Mühlenhoff
of the Debian security team) believe that buster should ship with TLS
1.0
and TLS 1.1 enabled.
Given t
Source: openssl
Version: 1.1.0f-5
Severity: serious
Hello Kurt,
I looked back at the debian-devel discussion and it seems to me that
the majority of persons who expressed themselves (including Moritz Mühlenhoff
of the Debian security team) believe that buster should ship with TLS 1.0
and TLS 1.1
18 matches
Mail list logo
