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 +0000, 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx/message/MSDDSIVEFGXR7J54L5FGPU6LI4HCHRUC/
