On Wed, Jun 20, 2018 at 9:53 AM, Tom Hughes wrote:
> On 20/06/18 09:46, Peter Robinson wrote:
>
>> There's also requirements by PCI (Payment Card Industry, not the
>> interconnect tech) for sites doing financial transactions to be
>> HTTP/1.1 and TLS 1.2 by June 30 too so no doubt that'll spur
On 20/06/18 09:46, Peter Robinson wrote:
There's also requirements by PCI (Payment Card Industry, not the
interconnect tech) for sites doing financial transactions to be
HTTP/1.1 and TLS 1.2 by June 30 too so no doubt that'll spur some
sites forward too
>>> I don't think TLS 1.3 will see a wide deployment immediately. Sure,
>>> the
>>> famous top websites and top browsers will, but enterprises will not.
>>> And
>>> especially those with any kind of loggin/auditing requirements cannot
>>> even allow TLS 1.3 with ephemeral DH on their network.
>>>
On Thu, 14 Jun 2018, Tomas Mraz wrote:
On Wed, 2018-06-13 at 00:45 -0400, Paul Wouters wrote:
I don't think TLS 1.3 will see a wide deployment immediately. Sure,
the
famous top websites and top browsers will, but enterprises will not.
And
especially those with any kind of loggin/auditing
On Thu, Jun 14, 2018 at 03:28:31PM +0200, Tomas Mraz wrote:
> > I don't think TLS 1.3 will see a wide deployment immediately. Sure,
> > the
> > famous top websites and top browsers will, but enterprises will not.
> > And
> > especially those with any kind of loggin/auditing requirements cannot
> >
On Wed, 2018-06-13 at 00:45 -0400, Paul Wouters wrote:
> On Wed, 6 Jun 2018, Nikos Mavrogiannopoulos wrote:
>
> > I think the debate here is whether fedora (and in general operating
> > systems) can afford to be stricter than the browsers. As an OS our
> > attack surface is much larger than the
On Wed, 6 Jun 2018, Nikos Mavrogiannopoulos wrote:
I think the debate here is whether fedora (and in general operating
systems) can afford to be stricter than the browsers. As an OS our
attack surface is much larger than the browser setup, and thus it makes
sense (to me), to be more careful.
On Tue, 2018-06-12 at 16:01 +0200, Kai Engert wrote:
> On 06/11/18 15:14, Tomas Mraz wrote:
> > > Okay, so IIUC now, this is an all-or-nothing kind of change. If
> > > I
> > > elect/need to use LEGACY to administer some old hardware that I
> > > cannot
> > > otherwise connect to using the
On 06/11/18 15:14, Tomas Mraz wrote:
>> Okay, so IIUC now, this is an all-or-nothing kind of change. If I
>> elect/need to use LEGACY to administer some old hardware that I
>> cannot
>> otherwise connect to using the defaults, then I'm compromising that
>> host's security for anything/everything
On Sat, 2018-06-09 at 20:49 -0400, John Florian wrote:
> On 06/08/2018 04:07 AM, Tomas Mraz wrote:
> > On Thu, 2018-06-07 at 16:13 -0400, John Florian wrote:
> > > On 06/07/2018 08:44 AM, Tomas Mraz wrote:
> > > > On Tue, 2018-06-05 at 16:34 -0400, John Florian wrote:
> > > > > On 06/05/2018 12:25
On 06/08/2018 04:07 AM, Tomas Mraz wrote:
> On Thu, 2018-06-07 at 16:13 -0400, John Florian wrote:
>> On 06/07/2018 08:44 AM, Tomas Mraz wrote:
>>> On Tue, 2018-06-05 at 16:34 -0400, John Florian wrote:
On 06/05/2018 12:25 PM, Tomas Mraz wrote:
> On Tue, 2018-06-05 at 16:11 +,
On Wed, 2018-06-06 at 09:45 -0500, mcatanz...@gnome.org wrote:
> On Wed, Jun 6, 2018 at 4:39 AM, Nikos Mavrogiannopoulos
> wrote:
> > I am actually very curious about the results of such a move, and
> > know
> > whether it is going to have a significant impact today. Debian has
> > already tried
On Thu, 2018-06-07 at 16:13 -0400, John Florian wrote:
> On 06/07/2018 08:44 AM, Tomas Mraz wrote:
> > On Tue, 2018-06-05 at 16:34 -0400, John Florian wrote:
> > > On 06/05/2018 12:25 PM, Tomas Mraz wrote:
> > > > On Tue, 2018-06-05 at 16:11 +, Christian Stadelmann wrote:
> > > > > "Fallback
On 06/07/2018 08:44 AM, Tomas Mraz wrote:
On Tue, 2018-06-05 at 16:34 -0400, John Florian wrote:
On 06/05/2018 12:25 PM, Tomas Mraz wrote:
On Tue, 2018-06-05 at 16:11 +, Christian Stadelmann wrote:
"Fallback option" always smells like "protocol downgrade attack".
This would undermine the
On Tue, 2018-06-05 at 16:34 -0400, John Florian wrote:
> On 06/05/2018 12:25 PM, Tomas Mraz wrote:
> > On Tue, 2018-06-05 at 16:11 +, Christian Stadelmann wrote:
> > > "Fallback option" always smells like "protocol downgrade attack".
> > > This would undermine the idea of a crypto policy.
On Wed, 2018-06-06 at 12:05 +, Petr Pisar wrote:
> On 2018-06-05, John Florian wrote:
> > Makes sense, but what is the best way to deal with such old HW if
> > you're
> > stuck with it? I don't want to compromise my workstation for all
> > my
> > normal needs just to deal with some ancient
On Tue, 2018-06-05 at 11:54 -0500, mcatanz...@gnome.org wrote:
> On Fri, Jun 1, 2018 at 6:40 AM, Jan Kurik wrote:
> > and weak
> > Diffie-Hellman key exchange sizes (1024 bit)
>
> What size is currently required by upstream Firefox and Chrome?
>
> The most recent reference I could find is
>
On Wed, Jun 6, 2018 at 4:39 AM, Nikos Mavrogiannopoulos
wrote:
I am actually very curious about the results of such a move, and know
whether it is going to have a significant impact today. Debian has
already tried experimenting with it:
On 06/06/2018 08:05 AM, Petr Pisar wrote:
On 2018-06-05, John Florian wrote:
Makes sense, but what is the best way to deal with such old HW if you're
stuck with it? I don't want to compromise my workstation for all my
normal needs just to deal with some ancient embedded https server, but
it
On 2018-06-05, John Florian wrote:
> Makes sense, but what is the best way to deal with such old HW if you're
> stuck with it? I don't want to compromise my workstation for all my
> normal needs just to deal with some ancient embedded https server, but
> it would kind of suck to have to boot
On Tue, 2018-06-05 at 11:41 -0500, mcatanz...@gnome.org wrote:
> On Tue, Jun 5, 2018 at 4:14 AM, Nikos Mavrogiannopoulos
> wrote:
> > Note that this change, if applied, includes browsers shipped by
> > fedora
> > (i.e., firefox). That is pretty much all or nothing plan, either we
> > bump the
On Tue, 2018-06-05 at 16:34 -0400, John Florian wrote:
> On 06/05/2018 12:25 PM, Tomas Mraz wrote:
> > On Tue, 2018-06-05 at 16:11 +, Christian Stadelmann wrote:
> > > "Fallback option" always smells like "protocol downgrade attack".
> > > This would undermine the idea of a crypto policy.
On Tue, Jun 5, 2018 at 2:27 PM, John Florian wrote:
> On 06/05/2018 12:55 PM, Chris Murphy wrote:
>>
>> I don't understand the motivation of departing from upstreams, which
>> by their nature are on a knife's edge balancing security and practical
>> use in the real world. Why second guess that
On 06/05/2018 12:25 PM, Tomas Mraz wrote:
On Tue, 2018-06-05 at 16:11 +, Christian Stadelmann wrote:
"Fallback option" always smells like "protocol downgrade attack".
This would undermine the idea of a crypto policy. Anyway,
implementing it seems way out of scope for the crypto policy.
On 06/05/2018 12:55 PM, Chris Murphy wrote:
I don't understand the motivation of departing from upstreams, which
by their nature are on a knife's edge balancing security and practical
use in the real world. Why second guess that effort and on what basis?
Totally agree!
Slightly off topic as an
On Fri, Jun 1, 2018 at 6:40 AM, Jan Kurik wrote:
and weak
Diffie-Hellman key exchange sizes (1024 bit)
What size is currently required by upstream Firefox and Chrome?
The most recent reference I could find is
https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/WyGIpevBV1s
I don't understand the motivation of departing from upstreams, which
by their nature are on a knife's edge balancing security and practical
use in the real world. Why second guess that effort and on what basis?
Slightly off topic as an anecdote, but the Payment Card Industry Data
Security
On Tue, 2018-06-05 at 09:47 -0700, Adam Williamson wrote:
> On Tue, 2018-06-05 at 17:59 +0200, Till Maas wrote:
> > On Tue, Jun 05, 2018 at 08:08:00AM -0700, Adam Williamson wrote:
> >
> > > I don't know, but it seems worth considering, and my basic point here
> > > is this is something the
On Tue, 2018-06-05 at 17:59 +0200, Till Maas wrote:
> On Tue, Jun 05, 2018 at 08:08:00AM -0700, Adam Williamson wrote:
>
> > I don't know, but it seems worth considering, and my basic point here
> > is this is something the Change owner should be responsible for
> > figuring out: making at least
On Tue, 2018-06-05 at 18:29 +0200, Tomas Mraz wrote:
> On Tue, 2018-06-05 at 08:08 -0700, Adam Williamson wrote:
> > On Tue, 2018-06-05 at 11:16 +0200, Nikos Mavrogiannopoulos wrote:
> > > On Mon, 2018-06-04 at 11:46 -0700, Adam Williamson wrote:
> > > > On Fri, 2018-06-01 at 13:40 +0200, Jan
On Tue, Jun 5, 2018 at 4:14 AM, Nikos Mavrogiannopoulos
wrote:
Note that this change, if applied, includes browsers shipped by fedora
(i.e., firefox). That is pretty much all or nothing plan, either we
bump the defaults for all software, or for none.
Nikos, I'm really surprised to see you
On Tue, 2018-06-05 at 08:08 -0700, Adam Williamson wrote:
> On Tue, 2018-06-05 at 11:16 +0200, Nikos Mavrogiannopoulos wrote:
> > On Mon, 2018-06-04 at 11:46 -0700, Adam Williamson wrote:
> > > On Fri, 2018-06-01 at 13:40 +0200, Jan Kurik wrote:
> > > > = Proposed System Wide Change: Strong crypto
On Tue, 2018-06-05 at 16:11 +, Christian Stadelmann wrote:
> "Fallback option" always smells like "protocol downgrade attack".
> This would undermine the idea of a crypto policy. Anyway,
> implementing it seems way out of scope for the crypto policy.
Yes, a fallback option is a no-way. You
"Fallback option" always smells like "protocol downgrade attack". This would
undermine the idea of a crypto policy. Anyway, implementing it seems way out of
scope for the crypto policy.
___
devel mailing list -- devel@lists.fedoraproject.org
To
On Tue, Jun 05, 2018 at 08:08:00AM -0700, Adam Williamson wrote:
> I don't know, but it seems worth considering, and my basic point here
> is this is something the Change owner should be responsible for
> figuring out: making at least a reasonable effort to evaluate which
> important
On Tue, 2018-06-05 at 11:16 +0200, Nikos Mavrogiannopoulos wrote:
> On Mon, 2018-06-04 at 11:46 -0700, Adam Williamson wrote:
> > On Fri, 2018-06-01 at 13:40 +0200, Jan Kurik wrote:
> > > = Proposed System Wide Change: Strong crypto settings: phase 2 =
> > >
Not just web sites. Changes in Firefox and Chrome have already made
working with embedded devices such as DRAC and storage servers nearly
impossible. IMO there needs to be a fallback option to still allow
access to "insecure" sites that still use TLS 1.0 or older certificates
that still use
On Mon, 2018-06-04 at 11:46 -0700, Adam Williamson wrote:
> On Fri, 2018-06-01 at 13:40 +0200, Jan Kurik wrote:
> > = Proposed System Wide Change: Strong crypto settings: phase 2 =
> > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
>
>
> How about clients for networking with other
On Fri, 2018-06-01 at 10:25 -0500, mcatanz...@gnome.org wrote:
> On Fri, Jun 1, 2018 at 8:06 AM, Daniel P. Berrangé
> wrote:
> > What is the availibility of TLS 1.2 vs 1.1/1.0 on the internet ?
> > ie how likely is this to break the ability of users to access
> > websites
> > they care about ?
>
On Mon, Jun 4, 2018 at 7:46 PM, Adam Williamson
wrote:
> On Fri, 2018-06-01 at 13:40 +0200, Jan Kurik wrote:
>> = Proposed System Wide Change: Strong crypto settings: phase 2 =
>> https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
>
> The "how to test" section for this Change seems a
On Fri, 2018-06-01 at 13:40 +0200, Jan Kurik wrote:
> = Proposed System Wide Change: Strong crypto settings: phase 2 =
> https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
The "how to test" section for this Change seems a little worryingly
barebones:
"Applications which follow the
I just saw that SSL pulse has data on TLS versions supported under the
"Protocol Support" section. It shows that 8.1% of all websites don't have TLS
1.2 support. Surely, this data is not weighted by real-world usage nor by how
it will affect people, but it does sort of speak against this
> On Fri, Jun 01, 2018 at 01:40:58PM +0200, Jan Kurik wrote:
> What is the availibility of TLS 1.2 vs 1.1/1.0 on the internet ?
> ie how likely is this to break the ability of users to access websites
> they care about ?
There is quite a lot, sadly. I'd say about 0.1…1% of all internet sites of
On Fri, Jun 1, 2018 at 11:55 AM, Daniel P. Berrangé
wrote:
Yeah if you add the gnutls-glib-networking.config file in the RPM,
that
defeats the point IMHO, as it'll never fallback to use @SYSTEM if this
file always exists with @GLIBNETWORKING defined in it.
The idea of the mechanism was that
On Fri, Jun 01, 2018 at 11:49:51AM -0500, mcatanz...@gnome.org wrote:
> On Fri, Jun 1, 2018 at 10:34 AM, Daniel P. Berrangé
> wrote:
> > IIUC, glib-networking uses GNUTLS. If so, a while ago I added ability
> > to
> > specify an ordered list of named priority aliases to GNUTLS that might
> >
On Fri, Jun 1, 2018 at 10:34 AM, Daniel P. Berrangé
wrote:
IIUC, glib-networking uses GNUTLS. If so, a while ago I added
ability to
specify an ordered list of named priority aliases to GNUTLS that
might handle
the kind of scenario you describe.
On Fri, Jun 01, 2018 at 10:25:42AM -0500, mcatanz...@gnome.org wrote:
> On Fri, Jun 1, 2018 at 8:06 AM, Daniel P. Berrangé
> wrote:
> > What is the availibility of TLS 1.2 vs 1.1/1.0 on the internet ?
> > ie how likely is this to break the ability of users to access websites
> > they care about ?
On Fri, Jun 1, 2018 at 8:06 AM, Daniel P. Berrangé
wrote:
What is the availibility of TLS 1.2 vs 1.1/1.0 on the internet ?
ie how likely is this to break the ability of users to access websites
they care about ?
Yeah... this has been discussed on this list before. If this change is
made,
On Fri, Jun 01, 2018 at 01:40:58PM +0200, Jan Kurik wrote:
> = Proposed System Wide Change: Strong crypto settings: phase 2 =
> https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
>
>
> Owner(s):
> * Tomáš Mráz
>
>
> We update the current system-wide crypto policy to further
= Proposed System Wide Change: Strong crypto settings: phase 2 =
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
Owner(s):
* Tomáš Mráz
We update the current system-wide crypto policy to further disable
legacy cryptographic protocols (TLS 1.0 and TLS 1.1) and weak
= Proposed System Wide Change: Strong crypto settings: phase 2 =
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
Owner(s):
* Tomáš Mráz
We update the current system-wide crypto policy to further disable
legacy cryptographic protocols (TLS 1.0 and TLS 1.1) and weak
51 matches
Mail list logo
