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 +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?
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@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/BHYRXVQAP2K46SENTLXEDBVG5E6ZQHD3/
