Re: F29 System Wide Change: Strong crypto settings: phase 2
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 some >> sites forward too >> >> https://www.theregister.co.uk/2018/06/20/paypal_security_upgrade/ > > > That appears to be incorrect though - only TLS 1.1 is required > from June 30 although 1.2 is strongly encouraged. See: > > https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls Maybe it's Paypal that's enforcing 1.2, it's purely a FYI, I don't care that much (more don't have the time to care that much because thankfully I don't currently have to deal with PCI-DSS) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2SKLI63CUNBCMNPD4QW3KM4D3J7Q3SQA/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 https://www.theregister.co.uk/2018/06/20/paypal_security_upgrade/ That appears to be incorrect though - only TLS 1.1 is required from June 30 although 1.2 is strongly encouraged. See: https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/J6FZVJ7OUOJJQ46ITTVPL5UXOKSEEW5L/
Re: F29 System Wide Change: Strong crypto settings: phase 2
>>> 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. >>> >>> I would personally first try and disable TLS 1.0 in f29 and see how >>> much >>> problems that generates. Then in f30 or f31 disable TLS 1.1. >> >> >> Except from the internet website statistics the TLS-1.1 only or as >> maximum TLS version is not deployed. The sites are either TLS-1.0 max >> version or they support also TLS-1.2. So this will not make almost any >> difference and the impact on compatibility will be practically the same >> as disabling even TLS-1.1. > > > Today a document was submitted to the TLS WG to phase out TLS 1.0 and 1.1: > > https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00 > > I guess it all depends on the lifetime of old cheap android devices :P 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 https://www.theregister.co.uk/2018/06/20/paypal_security_upgrade/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BUCE6MPMCDQ6XBZX7UDWPV24X3PGL7YB/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 requirements cannot even allow TLS 1.3 with ephemeral DH on their network. I would personally first try and disable TLS 1.0 in f29 and see how much problems that generates. Then in f30 or f31 disable TLS 1.1. Except from the internet website statistics the TLS-1.1 only or as maximum TLS version is not deployed. The sites are either TLS-1.0 max version or they support also TLS-1.2. So this will not make almost any difference and the impact on compatibility will be practically the same as disabling even TLS-1.1. Today a document was submitted to the TLS WG to phase out TLS 1.0 and 1.1: https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00 I guess it all depends on the lifetime of old cheap android devices :P Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VZAJCPXLWPGNP2JGNZOOVFXILCLBFR5G/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 > > even allow TLS 1.3 with ephemeral DH on their network. > > > > I would personally first try and disable TLS 1.0 in f29 and see how > > much > > problems that generates. Then in f30 or f31 disable TLS 1.1. > > Except from the internet website statistics the TLS-1.1 only or as > maximum TLS version is not deployed. The sites are either TLS-1.0 max > version or they support also TLS-1.2. So this will not make almost any > difference and the impact on compatibility will be practically the same > as disabling even TLS-1.1. This is similar for client capabilities. Disabling TLS 1.0 makes servers hosted on Fedora inaccessible for Android up to 5.0. Which means 15% of all Android devices – about 300 million devices. Disabling TLS 1.1 has no significant impact on top of that. Resources: - https://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers – https://developer.android.com/about/dashboards/ -- Tomasz Torcz 72->| 80->| xmpp: zdzich...@chrome.pl 72->| 80->| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4U74RPH6RB5G7HD7CB23WJTKJU65HHWA/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 browser setup, and thus it > > makes > > sense (to me), to be more careful. > > Your legacy interaction will also be much larger. Like connecting to > your home wifi router's webgui. > > > Can we afford to break a significant part of our users? Of course > > not, > > but I think that this change is eventually happening, especially > > with > > TLS1.3 expected to be deployed widely, and it seems to me that we > > only > > wait to see who will do the first step. > > 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. > > I would personally first try and disable TLS 1.0 in f29 and see how > much > problems that generates. Then in f30 or f31 disable TLS 1.1. Except from the internet website statistics the TLS-1.1 only or as maximum TLS version is not deployed. The sites are either TLS-1.0 max version or they support also TLS-1.2. So this will not make almost any difference and the impact on compatibility will be practically the same as disabling even TLS-1.1. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KTJ64X46W5B37VYDDBV3KNKDRANJU3WA/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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. Your legacy interaction will also be much larger. Like connecting to your home wifi router's webgui. Can we afford to break a significant part of our users? Of course not, but I think that this change is eventually happening, especially with TLS1.3 expected to be deployed widely, and it seems to me that we only wait to see who will do the first step. 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. I would personally first try and disable TLS 1.0 in f29 and see how much problems that generates. Then in f30 or f31 disable TLS 1.1. But I suspect fedora itself not to be the problem. The real problems will hit RHEL/CentOS in the enterprise deployments. So even with a success in fedora, I would be very careful with drawing any conclusions for enterprise use. Paul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HF6BSBVUYOW5SQZPQ6X3JQHEFVA7N7I7/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 defaults, then I'm compromising > > > that > > > host's security for anything/everything its used for until it's > > > taken > > > back off LEGACY and returned to whatever the non-LEGACY is > > > called. > > > Do I > > > have it right now? > > > > Yes, except one thing. Just by switching to LEGACY it does not mean > > you're compromising the host's security. The protocol negotiation > > and > > ciphersuite ordering still applies and it will use the best > > available > > protocol and ciphersuite and not some random insecure protocol > > version > > and ciphersuite. The insecure protocols and ciphersuites will be > > used > > only in the case the other end does not know anything better. > > Could switching to LEGACY allow some man-in-the-middle downgrade > attacks, in which an attacker manipulates the initial phases of > handshakes, and tricks the parties to use a weaker protocol? No, that would be a bug in the implementation or protocol design. But there should be no such issue with the current implementations. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JOJZOK3N4GL3B6NXIKZKDXJORSHZ7BTZ/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 its used for until it's taken >> back off LEGACY and returned to whatever the non-LEGACY is called. >> Do I >> have it right now? > > Yes, except one thing. Just by switching to LEGACY it does not mean > you're compromising the host's security. The protocol negotiation and > ciphersuite ordering still applies and it will use the best available > protocol and ciphersuite and not some random insecure protocol version > and ciphersuite. The insecure protocols and ciphersuites will be used > only in the case the other end does not know anything better. Could switching to LEGACY allow some man-in-the-middle downgrade attacks, in which an attacker manipulates the initial phases of handshakes, and tricks the parties to use a weaker protocol? Kai ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NL36VBZ7FSCXDGABTZXIJHIJEA5FJQB2/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 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. > > > > > > > > > > > > Yes, a fallback option is a no-way. You can switch the > > > > > > system > > > > > > policy to > > > > > > LEGACY, however that does not necessarily mean that some > > > > > > very > > > > > > old > > > > > > legacy HW will start to work with Firefox or another web > > > > > > browser, > > > > > > because with newer versions of the browsers and newer > > > > > > versions > > > > > > of > > > > > > TLS/crypto libraries some very old and insecure algorithm > > > > > > and > > > > > > protocol > > > > > > support is being also removed. > > > > > > > > > > > > > > > > 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 some old live image > > > > > just to > > > > > do > > > > > some routine config change. It seems the industry has room > > > > > for > > > > > improvement here. > > > > > > > > Use a virtual machine with some old live image for such > > > > insecure > > > > communication? > > > > > > > > I do not think any "improvement" that involves changing the > > > > defaults to > > > > be more lenient even if accompanied with some big warning when > > > > such > > > > old > > > > insecure connection is established would be a good idea. Оnly > > > > if > > > > the > > > > users really have to boot some old live image or do some > > > > similar > > > > unpleasant task it will really force the old HW out of > > > > production > > > > where > > > > it should belong. Or we can forget about security based on > > > > cryptographic protocols altogether. > > > > > > > > Note that we are talking about SSLv2, MD4 or similar long long > > > > time > > > > ago > > > > obsolete stuff. Not things that were just "recently" found as > > > > insecure. > > > > > > Oh! I didn't realize the proposal was covering stuff /that/ > > > old. > > > Somehow TLS 1.1 just didn't equate in my memory with that era. > > > Thank > > > you > > > Tomas for the clarification. > > > > No, this is misunderstanding. The change proposal is about newer > > stuff > > but the proposal allows for easy revert by setting the crypto > > policy to > > LEGACY. > > > > What I was talking in this tread starting with my message from Tue, > > 05 > > Jun 2018 18:25:57 +0200 was about things that possible very old > > legacy > > devices might require for communication that are not present in the > > TLS > > libraries anymore. > > > > 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 its used for until it's taken > back off LEGACY and returned to whatever the non-LEGACY is called. > Do I > have it right now? Yes, except one thing. Just by switching to LEGACY it does not mean you're compromising the host's security. The protocol negotiation and ciphersuite ordering still applies and it will use the best available protocol and ciphersuite and not some random insecure protocol version and ciphersuite. The insecure protocols and ciphersuites will be used only in the case the other end does not know anything better. They are removed from the DEFAULT policy only as a precautionary measure and to make you to do a conscious decision whether you want to communicate with legacy devices or not. Also note that some of the more insecure things such as SSLv2 support, RC4 support or <1024 bit DH key support is completely disabled so even with LEGACY mode you cannot use these. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 +, 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 can switch the system > policy to > LEGACY, however that does not necessarily mean that some very > old > legacy HW will start to work with Firefox or another web > browser, > because with newer versions of the browsers and newer versions > of > TLS/crypto libraries some very old and insecure algorithm and > protocol > support is being also removed. > 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 some old live image just to do some routine config change. It seems the industry has room for improvement here. >>> Use a virtual machine with some old live image for such insecure >>> communication? >>> >>> I do not think any "improvement" that involves changing the >>> defaults to >>> be more lenient even if accompanied with some big warning when such >>> old >>> insecure connection is established would be a good idea. Оnly if >>> the >>> users really have to boot some old live image or do some similar >>> unpleasant task it will really force the old HW out of production >>> where >>> it should belong. Or we can forget about security based on >>> cryptographic protocols altogether. >>> >>> Note that we are talking about SSLv2, MD4 or similar long long time >>> ago >>> obsolete stuff. Not things that were just "recently" found as >>> insecure. >> Oh! I didn't realize the proposal was covering stuff /that/ old. >> Somehow TLS 1.1 just didn't equate in my memory with that era. Thank >> you >> Tomas for the clarification. > No, this is misunderstanding. The change proposal is about newer stuff > but the proposal allows for easy revert by setting the crypto policy to > LEGACY. > > What I was talking in this tread starting with my message from Tue, 05 > Jun 2018 18:25:57 +0200 was about things that possible very old legacy > devices might require for communication that are not present in the TLS > libraries anymore. > 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 its used for until it's taken back off LEGACY and returned to whatever the non-LEGACY is called. Do I have it right now? -- John Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MSDDSIVEFGXR7J54L5FGPU6LI4HCHRUC/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 experimenting with it: > > > > https://lists.debian.org/debian-devel/2017/08/msg00166.html > > But OpenSSL is not used by browsers. That's right. In that case they would most likely have to handle issues like, tool A and B don't work with that server, though it works in firefox. The fedora proposal has a different challenge, if something doesn't work it wouldn't work anywhere. > > 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. > > You previously said in this thread that the system policy *will* be > used by browsers. Right, the plan is to have a policy to be default for everyone, including browsers which run in the OS. > I would not be concerned if we had a separate policy that was > suitable > for use by browsers, which could be used by Firefox, glib- > networking, etc. But we don't, and it's not proposed here. That's correct. I don't think it makes sense to have separate policies per application. regards, Nikos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7ZWS3GTBB7IA6OG2SCMSCJLN2IYR6FFN/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 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 can switch the system > > > > policy to > > > > LEGACY, however that does not necessarily mean that some very > > > > old > > > > legacy HW will start to work with Firefox or another web > > > > browser, > > > > because with newer versions of the browsers and newer versions > > > > of > > > > TLS/crypto libraries some very old and insecure algorithm and > > > > protocol > > > > support is being also removed. > > > > > > > > > > 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 some old live image just to > > > do > > > some routine config change. It seems the industry has room for > > > improvement here. > > > > Use a virtual machine with some old live image for such insecure > > communication? > > > > I do not think any "improvement" that involves changing the > > defaults to > > be more lenient even if accompanied with some big warning when such > > old > > insecure connection is established would be a good idea. Оnly if > > the > > users really have to boot some old live image or do some similar > > unpleasant task it will really force the old HW out of production > > where > > it should belong. Or we can forget about security based on > > cryptographic protocols altogether. > > > > Note that we are talking about SSLv2, MD4 or similar long long time > > ago > > obsolete stuff. Not things that were just "recently" found as > > insecure. > > Oh! I didn't realize the proposal was covering stuff /that/ old. > Somehow TLS 1.1 just didn't equate in my memory with that era. Thank > you > Tomas for the clarification. No, this is misunderstanding. The change proposal is about newer stuff but the proposal allows for easy revert by setting the crypto policy to LEGACY. What I was talking in this tread starting with my message from Tue, 05 Jun 2018 18:25:57 +0200 was about things that possible very old legacy devices might require for communication that are not present in the TLS libraries anymore. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EUHD4ZM53RHK4AHFANN4LE2LD7XZGUX6/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 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 can switch the system policy to LEGACY, however that does not necessarily mean that some very old legacy HW will start to work with Firefox or another web browser, because with newer versions of the browsers and newer versions of TLS/crypto libraries some very old and insecure algorithm and protocol support is being also removed. 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 some old live image just to do some routine config change. It seems the industry has room for improvement here. Use a virtual machine with some old live image for such insecure communication? I do not think any "improvement" that involves changing the defaults to be more lenient even if accompanied with some big warning when such old insecure connection is established would be a good idea. Оnly if the users really have to boot some old live image or do some similar unpleasant task it will really force the old HW out of production where it should belong. Or we can forget about security based on cryptographic protocols altogether. Note that we are talking about SSLv2, MD4 or similar long long time ago obsolete stuff. Not things that were just "recently" found as insecure. Oh! I didn't realize the proposal was covering stuff /that/ old. Somehow TLS 1.1 just didn't equate in my memory with that era. Thank you Tomas for the clarification. Also, I just found this neat[0] table that seems to present a good high-level view of the various TLS levels. [0] https://en.wikipedia.org/wiki/Transport_Layer_Security#Cipher ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5BEYIJLDWIHXQVTUZRQ6AN3RKASFOP2Z/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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. Anyway, > > > implementing it seems way out of scope for the crypto policy. > > > > Yes, a fallback option is a no-way. You can switch the system > > policy to > > LEGACY, however that does not necessarily mean that some very old > > legacy HW will start to work with Firefox or another web browser, > > because with newer versions of the browsers and newer versions of > > TLS/crypto libraries some very old and insecure algorithm and > > protocol > > support is being also removed. > > > > 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 some old live image just to do > some routine config change. It seems the industry has room for > improvement here. Use a virtual machine with some old live image for such insecure communication? I do not think any "improvement" that involves changing the defaults to be more lenient even if accompanied with some big warning when such old insecure connection is established would be a good idea. Оnly if the users really have to boot some old live image or do some similar unpleasant task it will really force the old HW out of production where it should belong. Or we can forget about security based on cryptographic protocols altogether. Note that we are talking about SSLv2, MD4 or similar long long time ago obsolete stuff. Not things that were just "recently" found as insecure. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QJRRPYEIHGADBY3U6I3OPGZD7JY733XV/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 embedded https server, > > but > > it would kind of suck to have to boot some old live image just to > > do > > some routine config change. It seems the industry has room for > > improvement here. > > Firefox has a white list for domain names: > security.tls.insecure_fallback_hosts. I do not think this actually works at all even with the current FF and Fedora. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TQIQG62DVHQMIVTGTSVEJN2ILC67JN7V/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 > https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/W > yGIpevBV1s > which suggests they are still using 1024. Yes, they are using 1024 bits as minimum now. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FY6FMRZPQMSDOSZADTOAIWD4VPXVCANW/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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: https://lists.debian.org/debian-devel/2017/08/msg00166.html But OpenSSL is not used by browsers. 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. You previously said in this thread that the system policy *will* be used by browsers. I would not be concerned if we had a separate policy that was suitable for use by browsers, which could be used by Firefox, glib-networking, etc. But we don't, and it's not proposed here. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QWP2MRLDBDGS4IS5C6NJHXCQDJSM4BQL/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 would kind of suck to have to boot some old live image just to do some routine config change. It seems the industry has room for improvement here. Firefox has a white list for domain names: security.tls.insecure_fallback_hosts. Okay, that's good to know. As long as that continues to work should this proposal go in effect that seems like a great compromise of having sound security by default but allowing manual, per-site overrides where necessary. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UPLPXB5H3V2S53SBW7O2LSDMSRU5CMBV/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 some old live image just to do > some routine config change. It seems the industry has room for > improvement here. Firefox has a white list for domain names: security.tls.insecure_fallback_hosts. -- Petr ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LAQ3KCXRV7Y6YBLATE5ALGKVTEW7W7ZG/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 defaults for all software, or for none. > > Nikos, I'm really surprised to see you commenting here without > saying anything for or against the change. > Surely this will break a large number of websites? 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: https://lists.debian.org/debian-devel/2017/08/msg00166.html > And, if not, then surely we should be able to first convince > upstream > Firefox and Chrome to drop support for TLS 1.0 and 1.1? I would not > have any objections if these upstreams were to take the step first. > Yet that seems extremely unlikely. 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. Can we afford to break a significant part of our users? Of course not, but I think that this change is eventually happening, especially with TLS1.3 expected to be deployed widely, and it seems to me that we only wait to see who will do the first step. regards, Nikos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DG6SUTE6PJIJ5PYLUM6ZSMEHFTO2SSO3/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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. Anyway, > > > implementing it seems way out of scope for the crypto policy. > > > > Yes, a fallback option is a no-way. You can switch the system > > policy to > > LEGACY, however that does not necessarily mean that some very old > > legacy HW will start to work with Firefox or another web browser, > > because with newer versions of the browsers and newer versions of > > TLS/crypto libraries some very old and insecure algorithm and > > protocol > > support is being also removed. > > > > 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, Isn't this what we are actually doing to fedora? We keep options which we know they are insecure in the default settings to achieve compatibility. This change is about switching to secure mode by default. regards, Nikos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JRLMUVA7DDDYWATWMQHMX2VSIP4F6GKB/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 effort and on what basis? > > Totally agree! >> >> Slightly off topic as an anecdote, but the Payment Card Industry Data >> Security Standard (PCI DSS) is only calling for the end to TLS 1.0 >> support at the end of this month, recommending TLS 1.2 but permitting >> TLS 1.1. This is the spec for transmitting people's credit card >> magnetic stripe/chip information for payment authorizations. Now maybe >> that's a bit eyebrow raising, but if they're willing to take the risk >> of allowing TLS 1.1 for such a use case, I hardly think Fedora should >> be jumping the gun. > > That's why there's transaction fees. Oops! Oh well, here's a few million > to deal with that. They advertise like they can't get rid of the money fast > enough. I always figured the Visa "Magic Moments" were something like hot > database redirection where some transactions fell off the end of the cable, > landed on the floor and turned into customer's lucky day simply due to the > timing. Like it was easier/cheaper to give away the fruits rather than fix > the real problem. Yes that's true, and so the analogy fails on this point, they're effectively dragging everyone into an insurance racket. But the contra argument is Fedora isn't providing guarantees or charging fees, and we're not on questionable footing by following the lead of upstreams on the issue of security. > I doubt it's actually like that, but I do bet they have more luxury than > Fedora does. While I'd prefer the best security, I don't want it at the > risk of things being broken. I don't have the confidence that my work > around is as safe as an older more trusting Fedora. When I see those cipher > suite strings my head just goes into a tailspin. I think second guessing any upstream is fair. But it also comes with burden of making a really compelling argument that upstream is isn't adequately serving Fedora community interests. And that argument needs to be dropped in the lap of the upstream so they have a chance of responding to the criticism. Maybe it makes more sense Fedora is aggressive on security by default, and we push flatpak versions of Firefox (or other browser) configured to support TLS 1.0 and 1.1 as the way to provide legacy support. But my first instinct is that Fedora's in parity with upstream, and the Security spin folks can produce the more aggressively secure variant. *shrug* -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IN7CZESP6Q4RBAS4O7CGGMPYNTWN66ZB/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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. Yes, a fallback option is a no-way. You can switch the system policy to LEGACY, however that does not necessarily mean that some very old legacy HW will start to work with Firefox or another web browser, because with newer versions of the browsers and newer versions of TLS/crypto libraries some very old and insecure algorithm and protocol support is being also removed. 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 some old live image just to do some routine config change. It seems the industry has room for improvement here. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3J6I2UK3QPE6THJBJVYNLTX3ZTF5WIAM/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 anecdote, but the Payment Card Industry Data Security Standard (PCI DSS) is only calling for the end to TLS 1.0 support at the end of this month, recommending TLS 1.2 but permitting TLS 1.1. This is the spec for transmitting people's credit card magnetic stripe/chip information for payment authorizations. Now maybe that's a bit eyebrow raising, but if they're willing to take the risk of allowing TLS 1.1 for such a use case, I hardly think Fedora should be jumping the gun. That's why there's transaction fees. Oops! Oh well, here's a few million to deal with that. They advertise like they can't get rid of the money fast enough. I always figured the Visa "Magic Moments" were something like hot database redirection where some transactions fell off the end of the cable, landed on the floor and turned into customer's lucky day simply due to the timing. Like it was easier/cheaper to give away the fruits rather than fix the real problem. I doubt it's actually like that, but I do bet they have more luxury than Fedora does. While I'd prefer the best security, I don't want it at the risk of things being broken. I don't have the confidence that my work around is as safe as an older more trusting Fedora. When I see those cipher suite strings my head just goes into a tailspin. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BQ54WDRZ3F4ATFGFYCJSMI6NY2BNNVCU/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 which suggests they are still using 1024. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UGWSYDWBCTALCQ5B2MKYXFLKE47S7BCM/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 Standard (PCI DSS) is only calling for the end to TLS 1.0 support at the end of this month, recommending TLS 1.2 but permitting TLS 1.1. This is the spec for transmitting people's credit card magnetic stripe/chip information for payment authorizations. Now maybe that's a bit eyebrow raising, but if they're willing to take the risk of allowing TLS 1.1 for such a use case, I hardly think Fedora should be jumping the gun. The Secure Spin folks could make a different decision for their Firefox if they want, or maybe a flatpak of Firefox could have more aggressive security by default. But I don't see the value in departing from the upstreams and confusing users. Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ISOX36KH7Z7FN6QRCQS6YGROOOILNHRC/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 Change owner should be responsible for > > > figuring out: making at least a reasonable effort to evaluate which > > > important (particularly release-critical) software and workflows will > > > be affected by the change and proposing plans for testing them. "we > > > should check curl behaves as expected" just doesn't really cut it as a > > > test plan. > > > > Should we add a QA review step to the change process to address this? > > That's, er, sort of what I'm doing. The Change has been proposed. I'm > reviewing it. :P Sorry, I was being a bit loose for the purpose of flippancy there :P I should make it clear that it's not just *me* reviewing it. We (QA) review and discuss the proposed Changes for each release in our group meetings. My comments on this change and the grub menu change were not just my personal thoughts but me relaying the outcome of our discussions about those Changes. You can see this in the minutes and logs of our meeting this week: https://meetbot-raw.fedoraproject.org/teams/fedora-qa/fedora-qa.2018-06-04-15.00.html https://meetbot-raw.fedoraproject.org/teams/fedora-qa/fedora-qa.2018-06-04-15.00.log.html -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MLJCQC6U354Q6Z5YQ3OVXDX4SGTBY3PU/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 a reasonable effort to evaluate which > > important (particularly release-critical) software and workflows will > > be affected by the change and proposing plans for testing them. "we > > should check curl behaves as expected" just doesn't really cut it as a > > test plan. > > Should we add a QA review step to the change process to address this? That's, er, sort of what I'm doing. The Change has been proposed. I'm reviewing it. :P > IMHO we cannot expect Change owners to know this or have the same eye > for detail as quality engineers have, therefore the best approach is to > provide them guidance. Or can we assume that the open discussion here > where this can be pointed out is enough? There is a brief mention in the Changes policy page: "Fedora QA reviews announced changes on the devel-announce list to commit to testing of the change, or adjust release criteria as necessary." https://fedoraproject.org/wiki/Changes/Policy -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VHNWYAZE7PJE242BWQKQDS4LMMKUUV5D/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 Kurik wrote: > > > > > = Proposed System Wide Change: Strong crypto settings: phase 2 > > > > > = > > > > > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 > > > > > > > > > > > > How about clients for networking with other OSes - e.g. Samba > > > > clients, > > > > and the tools for enrolling systems as Active Directory domain > > > > members? > > > > Do those respect the system policy? If so, have we considered the > > > > impact of these changes on those configurations? > > > > > > Do these clients use TLS? > > > > 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 (particularly release-critical) software and workflows will > > be affected by the change and proposing plans for testing them. "we > > should check curl behaves as expected" just doesn't really cut it as > > a > > test plan. > > Do we have a list of the release-critical software and functionality? Sure: refer to the release criteria and the release validation tests. https://fedoraproject.org/wiki/Basic_Release_Criteria https://fedoraproject.org/wiki/Fedora_29_Beta_Release_Criteria https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteria https://fedoraproject.org/wiki/Template:Installation_test_matrix https://fedoraproject.org/wiki/Template:Base_test_matrix https://fedoraproject.org/wiki/Template:Server_test_matrix https://fedoraproject.org/wiki/Template:Cloud_test_matrix https://fedoraproject.org/wiki/Template:Desktop_test_matrix -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EKMYQ3CTBBOZPQM22VAU7PS76QSQKUTK/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 commenting here without saying anything for or against the change. Surely this will break a large number of websites? And, if not, then surely we should be able to first convince upstream Firefox and Chrome to drop support for TLS 1.0 and 1.1? I would not have any objections if these upstreams were to take the step first. Yet that seems extremely unlikely. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AQ5G7JYTQQHCXV6OEWUZ26YT35NCAX7M/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 settings: phase 2 > > > > = > > > > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 > > > > > > > > > How about clients for networking with other OSes - e.g. Samba > > > clients, > > > and the tools for enrolling systems as Active Directory domain > > > members? > > > Do those respect the system policy? If so, have we considered the > > > impact of these changes on those configurations? > > > > Do these clients use TLS? > > 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 (particularly release-critical) software and workflows will > be affected by the change and proposing plans for testing them. "we > should check curl behaves as expected" just doesn't really cut it as > a > test plan. Do we have a list of the release-critical software and functionality? Of course verifying that all the packages in Fedora still work (in what sense?) is a quite bit unrealistic requirement. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JODSHUPXNLSEXFFJQBH5EDYGDEAP4CIQ/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 can switch the system policy to LEGACY, however that does not necessarily mean that some very old legacy HW will start to work with Firefox or another web browser, because with newer versions of the browsers and newer versions of TLS/crypto libraries some very old and insecure algorithm and protocol support is being also removed. -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4YGCDHY6W7G66YPP4QIJL23AOXKDNPYF/
Re: F29 System Wide Change: Strong crypto settings: phase 2
"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 unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VJGXNB66WVRQVPG5XKXUPAT6QRCVEUPY/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 (particularly release-critical) software and workflows will > be affected by the change and proposing plans for testing them. "we > should check curl behaves as expected" just doesn't really cut it as a > test plan. Should we add a QA review step to the change process to address this? IMHO we cannot expect Change owners to know this or have the same eye for detail as quality engineers have, therefore the best approach is to provide them guidance. Or can we assume that the open discussion here where this can be pointed out is enough? Kind regards Till ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CTGJIDTEIEEK46TTWB5BERAF5MGLICW4/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 = > > > https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 > > > > > > How about clients for networking with other OSes - e.g. Samba > > clients, > > and the tools for enrolling systems as Active Directory domain > > members? > > Do those respect the system policy? If so, have we considered the > > impact of these changes on those configurations? > > Do these clients use TLS? 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 (particularly release-critical) software and workflows will be affected by the change and proposing plans for testing them. "we should check curl behaves as expected" just doesn't really cut it as a test plan. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KISDZLKOQB4B3AKKJXYYZ3VQ2RL4Z66U/
Re: F29 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 SHA-1. On 06/02/2018 05:57 AM, Christian Stadelmann wrote: >> 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 my > personal browsing behavior. Fedora's infrastructure works fine with TLS 1.0 > and 1.1 disabled. Essential parts of the eclipse.org infrastructure is still > on historic crypto levels, including its wiki, git server and marketplace. > This DEFAULT policy probably will break the eclipse marketplace client in > Fedora. > > I haven't found perfect data but SSLLabs' "SSL Pulse" [1] gives some hints. > Applying their current metric, any server without TLS 1.2 support will be > rewarded with grade C or worse. See [2] for an example. Assuming that > grade-F-sites are broken beyond any repair, there's still 7.7% grade C and a > few grade D pages resulting in up to 7.8% of all websites still using TLS < > 1.2. Without good data on this I highly recommend not disabling TLS <1.2 by > default on F29. > > [1] https://www.ssllabs.com/ssl-pulse/ > [2] https://www.ssllabs.com/ssltest/analyze.html?d=marketplace.eclipse.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Z6RXR5W6KH4NODRINVJFEBIBQRX4I6HP/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BPNMA54WJ5B7QMBTEMPDVDGOHCIHQDHN/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 OSes - e.g. Samba > clients, > and the tools for enrolling systems as Active Directory domain > members? > Do those respect the system policy? If so, have we considered the > impact of these changes on those configurations? Do these clients use TLS? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZGHNNM2KKFXIKSXA5ZEQVTKBDCD5F6SZ/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 ? > > Yeah... this has been discussed on this list before. If this change > is > made, then we will need to drop our glib-networking patch that > causes > glib-networking to respect Fedora's system crypto policy, since we > simply cannot afford to be more restrictive than major browsers. 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. regards, Nikos ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FQYOX5LB2E4NENAHO3A2XOTPY4FBM3YK/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 little worryingly > barebones: > > "Applications which follow the system-wide policy (e.g., curl,wget) > should be tested: > > * whether they can connect to legacy (TLS1.0, TLS1.1) servers when > system is in legacy mode > * whether the previous connection breaks when system is in default mode > * whether the system can connect to TLS 1.2 servers when in default, > legacy or future mode." > > That "e.g., curl,wget" especially is pretty slapdash. We (QA) would > suggest it's incumbent on the Change owners here to do a better job of > identifying things that respect the system-wide policy, especially > considering release-critical components. For instance, does Firefox > respect the policy? I believe the answer is "yes", but this should be > something the Change owners look into. For another instance, do > components of FreeIPA respect the policy, and if so, have we considered > how this will affect those when e.g. an F29 system is enrolled as a > member of a FreeIPA domain where the server is running on an older > Fedora, or RHEL, or something? > > How about clients for networking with other OSes - e.g. Samba clients, > and the tools for enrolling systems as Active Directory domain members? > Do those respect the system policy? If so, have we considered the > impact of these changes on those configurations? The other bits to consider are core bits like dnf/PackageKit/gnome-software and what happens if a mirror that supports https but not the required version of TLS does the user fails to get updates? Does it error out with useful errors for the end user? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LIDEYMT6X6BGPGD3ZKZSYMB3COXGF7WP/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 system-wide policy (e.g., curl,wget) should be tested: * whether they can connect to legacy (TLS1.0, TLS1.1) servers when system is in legacy mode * whether the previous connection breaks when system is in default mode * whether the system can connect to TLS 1.2 servers when in default, legacy or future mode." That "e.g., curl,wget" especially is pretty slapdash. We (QA) would suggest it's incumbent on the Change owners here to do a better job of identifying things that respect the system-wide policy, especially considering release-critical components. For instance, does Firefox respect the policy? I believe the answer is "yes", but this should be something the Change owners look into. For another instance, do components of FreeIPA respect the policy, and if so, have we considered how this will affect those when e.g. an F29 system is enrolled as a member of a FreeIPA domain where the server is running on an older Fedora, or RHEL, or something? How about clients for networking with other OSes - e.g. Samba clients, and the tools for enrolling systems as Active Directory domain members? Do those respect the system policy? If so, have we considered the impact of these changes on those configurations? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Q6WUF2FGZCRUOCGUI3R7FWC2AZGXA2TI/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 radical change. I'd rather delay this change to F30. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MZIK7Z4ZZPHX2MTIJOC6IZAPHQPDHFE4/
Re: F29 System Wide Change: Strong crypto settings: phase 2
> 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 my personal browsing behavior. Fedora's infrastructure works fine with TLS 1.0 and 1.1 disabled. Essential parts of the eclipse.org infrastructure is still on historic crypto levels, including its wiki, git server and marketplace. This DEFAULT policy probably will break the eclipse marketplace client in Fedora. I haven't found perfect data but SSLLabs' "SSL Pulse" [1] gives some hints. Applying their current metric, any server without TLS 1.2 support will be rewarded with grade C or worse. See [2] for an example. Assuming that grade-F-sites are broken beyond any repair, there's still 7.7% grade C and a few grade D pages resulting in up to 7.8% of all websites still using TLS < 1.2. Without good data on this I highly recommend not disabling TLS <1.2 by default on F29. [1] https://www.ssllabs.com/ssl-pulse/ [2] https://www.ssllabs.com/ssltest/analyze.html?d=marketplace.eclipse.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Z6RXR5W6KH4NODRINVJFEBIBQRX4I6HP/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 apps/libs build with @MYNAME,SYSTEM priority but never define @MYNAME themselves, so it gives the local sysadmin to customize the app/lib in isolation if they so wish, but out of the box still respects @SYSTEM. If @SYSTEM is changed as proposed, then glib-networking must not out-of-the-box respect @SYSTEM, because it needs to out-of-the-box work. :) So I guess we should just not use @SYSTEM then, yes? I wonder what Tomas intends here. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UXJ6VAWQPN35HUHUCES4DKOQL32LWI5Y/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 > > handle > > the kind of scenario you describe. > > > > https://www.berrange.com/posts/2016/11/15/new-tls-algorithm-priority-config-for-libvirt-with-gnutls-on-fedora-25/ > > > > eg in libvirt we now use the string "@LIBVIRT,SYSTEM" in Fedora builds > > which > > tells GNUTLS to find the policy "LIBVIRT" and if that is not present, > > fall > > back to the "SYSTEM" policy. > > > > We do this so libvirt respects system policy by default, but admins can > > then set an alternative system wide policy for libvirt connections that > > uses something stricter (or weaker), without affecting TLS usage for > > non-libvirt connections. We've done the same for QEMU which > > "@QEMU,SYSTEM" > > as its default policy now, for VNC and its other TLS services. > > OK... so we could add a @GLIBNETWORKING,SYSTEM policy, I suppose, and > install a file /etc/crypto-policies/local.d/gnutls-glib-networking.config. > The difference is that file would need to be packaged, not controlled by the > system administrator. Seems almost like an abuse of a local.d? 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 apps/libs build with @MYNAME,SYSTEM priority but never define @MYNAME themselves, so it gives the local sysadmin to customize the app/lib in isolation if they so wish, but out of the box still respects @SYSTEM. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/O6DJNBJYYNN2CLDZIOTZMK7OZVN3OJBA/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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. https://www.berrange.com/posts/2016/11/15/new-tls-algorithm-priority-config-for-libvirt-with-gnutls-on-fedora-25/ eg in libvirt we now use the string "@LIBVIRT,SYSTEM" in Fedora builds which tells GNUTLS to find the policy "LIBVIRT" and if that is not present, fall back to the "SYSTEM" policy. We do this so libvirt respects system policy by default, but admins can then set an alternative system wide policy for libvirt connections that uses something stricter (or weaker), without affecting TLS usage for non-libvirt connections. We've done the same for QEMU which "@QEMU,SYSTEM" as its default policy now, for VNC and its other TLS services. OK... so we could add a @GLIBNETWORKING,SYSTEM policy, I suppose, and install a file /etc/crypto-policies/local.d/gnutls-glib-networking.config. The difference is that file would need to be packaged, not controlled by the system administrator. Seems almost like an abuse of a local.d? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IVHDIPPI4BNACLRQS6TKJ5LA5QT4KMSJ/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 ? > > Yeah... this has been discussed on this list before. If this change is made, > then we will need to drop our glib-networking patch that causes > glib-networking to respect Fedora's system crypto policy, since we simply > cannot afford to be more restrictive than major browsers. I believe the > system crypto policy developers should consider how this is really intended > to work, because there's no point in having a system policy if software > stops using it. > > It could be doable if glib-networking was able to specify a priority string > like @SYSTEMLEGACY insetad of just @SYSTEM, but the current design of the > system crypto policy prevents applications from choosing between the three > policies. 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. https://www.berrange.com/posts/2016/11/15/new-tls-algorithm-priority-config-for-libvirt-with-gnutls-on-fedora-25/ eg in libvirt we now use the string "@LIBVIRT,SYSTEM" in Fedora builds which tells GNUTLS to find the policy "LIBVIRT" and if that is not present, fall back to the "SYSTEM" policy. We do this so libvirt respects system policy by default, but admins can then set an alternative system wide policy for libvirt connections that uses something stricter (or weaker), without affecting TLS usage for non-libvirt connections. We've done the same for QEMU which "@QEMU,SYSTEM" as its default policy now, for VNC and its other TLS services. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EXNUSAZ4VQTKDUDTX7DOYVO3ZLLK2ML6/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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, then we will need to drop our glib-networking patch that causes glib-networking to respect Fedora's system crypto policy, since we simply cannot afford to be more restrictive than major browsers. I believe the system crypto policy developers should consider how this is really intended to work, because there's no point in having a system policy if software stops using it. It could be doable if glib-networking was able to specify a priority string like @SYSTEMLEGACY insetad of just @SYSTEM, but the current design of the system crypto policy prevents applications from choosing between the three policies. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/A64V3LCMZALUDK4BFBKIXTEG2QC3EZVM/
Re: F29 System Wide Change: Strong crypto settings: phase 2
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 disable > legacy cryptographic protocols (TLS 1.0 and TLS 1.1) and weak > Diffie-Hellman key exchange sizes (1024 bit) [snip] 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 ? The actual change page does mention it in passing, but not in a convincing manner "User Experience Given the existing deployment of TLS 1.2 on the internet, there should not be significant user experience degradation, although that's a speculation." Are there any internet scan survey results looking at TLS versions on servers, that can make this more compelling than just speculation ? I've found some via google, but they're four+ years old already so won't mention them as it is likely oudated & misleading. Surely someone has got scan results looking at this from 2017/2018 though ? NB, I'm not objecting to switch to 1.2 by default - I just like to see a more evidence based change proposal. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TMXLAXZMTFNF4OOXHSNQPCXZKBF4OEBS/
F29 System Wide Change: Strong crypto settings: phase 2
= 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 Diffie-Hellman key exchange sizes (1024 bit) == Detailed description == Fedora includes several cryptographic components who's security doesn't remain constant over time. Algorithms such as (cryptographic) hashing and encryption typically have a lifetime after which they are considered either too risky to use or plain insecure. That would mean we need to phase out such algorithms from the default settings, or completely disable if they could cause irreparable issue. While in the past we did not disable algorithms in a consistent way (different applications utilized different policies), today we have a system-wide policy followed by a large part of Fedora components. That allows us to move consistently and deprecate algorithms system-wide. For rationale see RFC 7457 for a more complete list of attacks taking advantage of legacy crypto algorithms. The changes for default policy are: * Keep only TLS 1.2 (and TLS 1.3 when available) as enabled protocols and move the TLS 1.x, x<=1 to legacy level. * Require finite field parameters (RSA, Diffie-Hellman) of 2048 and more in the default settings That is a policy of: LEGACY MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc) Curves: all prime >= 255 bits (including bernstein curves) Signature algorithms: SHA-1 hash or better (not RIPEMD) Ciphers: all available > 112-bit key, >= 128-bit block (no rc4, but with 3DES) key exchange: ECDHE, RSA, DHE DH params size: >=1023 RSA params size: >=1023 TLS protocols: TLS >= 1.0 DEFAULT MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc) Curves: all prime >= 255 bits (including bernstein curves) Signature algorithms: with SHA-1 hash or better (not DSA) Ciphers: >= 128-bit key, >= 128-bit block (aes, camellia, chacha20, including aes-cbc) key exchange: ECDHE, RSA, DHE DH params size: >= 2048 RSA params size: >= 2048 TLS protocols: TLS >= 1.2 FUTURE MACs: All HMAC with SHA256 or better + all modern MACs (poly1305 etc) Curves: all prime >= 384 bits (including bernstein curves) Signature algorithms: SHA-384 hash or better (not DSA) Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated Encryption (AE) ciphers key exchange: ECDHE, DHE DH params size: >= 3072 RSA params size: >= 3072 TLS protocols: TLS >= 1.2 == Scope == * Proposal owners: The policies include in crypto-policies package need to be updated. * Other developers: * Crypto policies are updated to the settings above * https://bugzilla.redhat.com/show_bug.cgi?id=1487607 OpenSSL is updated to allow setting policies for TLS versions * Release engineering: Copied from F28 change - no impact https://pagure.io/releng/issue/7235 #7235 ** List of deliverables: * Crypto policies are updated to the settings above * OpenSSL, NSS, GnuTLS and all applications covered under the Fedora Crypto Policies follow the new crypto settings. * Policies and guidelines: No changes to packaging or other guidelines is needed. * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/B4YAC3KZOJUT4V6B3EVYZIDKHELU5NRA/
F29 System Wide Change: Strong crypto settings: phase 2
= 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 Diffie-Hellman key exchange sizes (1024 bit) == Detailed description == Fedora includes several cryptographic components who's security doesn't remain constant over time. Algorithms such as (cryptographic) hashing and encryption typically have a lifetime after which they are considered either too risky to use or plain insecure. That would mean we need to phase out such algorithms from the default settings, or completely disable if they could cause irreparable issue. While in the past we did not disable algorithms in a consistent way (different applications utilized different policies), today we have a system-wide policy followed by a large part of Fedora components. That allows us to move consistently and deprecate algorithms system-wide. For rationale see RFC 7457 for a more complete list of attacks taking advantage of legacy crypto algorithms. The changes for default policy are: * Keep only TLS 1.2 (and TLS 1.3 when available) as enabled protocols and move the TLS 1.x, x<=1 to legacy level. * Require finite field parameters (RSA, Diffie-Hellman) of 2048 and more in the default settings That is a policy of: LEGACY MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc) Curves: all prime >= 255 bits (including bernstein curves) Signature algorithms: SHA-1 hash or better (not RIPEMD) Ciphers: all available > 112-bit key, >= 128-bit block (no rc4, but with 3DES) key exchange: ECDHE, RSA, DHE DH params size: >=1023 RSA params size: >=1023 TLS protocols: TLS >= 1.0 DEFAULT MACs: All HMAC with SHA1 or better + all modern MACs (poly1305 etc) Curves: all prime >= 255 bits (including bernstein curves) Signature algorithms: with SHA-1 hash or better (not DSA) Ciphers: >= 128-bit key, >= 128-bit block (aes, camellia, chacha20, including aes-cbc) key exchange: ECDHE, RSA, DHE DH params size: >= 2048 RSA params size: >= 2048 TLS protocols: TLS >= 1.2 FUTURE MACs: All HMAC with SHA256 or better + all modern MACs (poly1305 etc) Curves: all prime >= 384 bits (including bernstein curves) Signature algorithms: SHA-384 hash or better (not DSA) Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated Encryption (AE) ciphers key exchange: ECDHE, DHE DH params size: >= 3072 RSA params size: >= 3072 TLS protocols: TLS >= 1.2 == Scope == * Proposal owners: The policies include in crypto-policies package need to be updated. * Other developers: * Crypto policies are updated to the settings above * https://bugzilla.redhat.com/show_bug.cgi?id=1487607 OpenSSL is updated to allow setting policies for TLS versions * Release engineering: Copied from F28 change - no impact https://pagure.io/releng/issue/7235 #7235 ** List of deliverables: * Crypto policies are updated to the settings above * OpenSSL, NSS, GnuTLS and all applications covered under the Fedora Crypto Policies follow the new crypto settings. * Policies and guidelines: No changes to packaging or other guidelines is needed. * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík JBoss EAP Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B4YAC3KZOJUT4V6B3EVYZIDKHELU5NRA/
