[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#765512: general: distrust old crypto algos and protocols perdefault

On Wed, 2014-10-15 at 21:55 +0200, Jonas Meurer wrote: 
> While I appreciate your efforts to raise security-relevant topics within
> the Debian distribution, I have to admit that exactly the same happens
> to quite a few of your "meta-bugreports" as well. There's a lot of
> discussion and a few changes here and there, but then the bugreport is
> forgotten and nobody cares anymore.
Sure, Jonas, I know,... and basically nothing has changed,... or well
not much at least... and the same with the discussion about secure APT,
downgrade/blocking attacks, the stuff about package downloaders, etc..

I mean that's just the problem what I try to explain every time
again,... it won't just work if you have some lone knights trying to do
this on their own, given the vast number of packages and software
affected, it's rather something a larger group would need to do.
Or even better, having guidelines, set up by such expert group, and
maintainers of packages should need to check through them... just like
proper auditing works.

But here comes the difficult part:
It's usually not easy to get people into a security conscious thinking,
so one won't find many people fighting this quest along one's side.
In practise it's even worse,... not rarely you have to fight maintainers
like windmills, endless discussions about what can be considered enough
secure, or whether it's more important to have stuff just being
colourful™ and working out-of-the-box™, rather then secure.

And these are only the problem's to the point, when you may break
peoples' setups which actually should break, because they're highly
That's just as with the SSLv3 thingy... Mozilla for sure would argue
"well we had to keep it that long for interoperability".

When you then come to actual technical issues, as there *may* be with my
request to considerably shorten the validity times for Release files...
it's even more difficult to get something going.
Of course the respective developers have their own projects they want to
follow, but of course it should also be clear that one single person
(like me) cannot easily get fully involved in dozens of complex projects
like APT (and the security stuff - at least when one wants to do it
right - usually requires deep knowledge).

So you're absolutely right, when you say that not much comes out,... but
I guess for a single person it's not easily possible to do more than
constantly pointing at such issues, trying to start organising efforts
and then helping along.

> If you feel like keeping track of those distro-wide changes, I think a
> properly maintained wiki page is much more appropriate for that purpose.
Well I had that once[0] ... but the problems above remains,... if there
aren't more people that jump on the train - especially the affected
maintainers - you drive into a dead end

> In most cases your claim is true, but in some cases there might be
> reasons for keeping support for old/broken algorithms.
And as I wrote, I fully agree,... I mean this is basically what Russ
said in the other post:

On Wed, 2014-10-15 at 12:55 -0700, Russ Allbery wrote:
>For another example, upstream for both Heimdal and MIT Kerberos know
>very well what the situation is with the RC4 use in the Kerberos
>protocol and are making well-informed decisions based on compatibility
>with existing clients

Okay what does that mean? AFAIU it means: well there are still so many
people with outdated software out there, we can't just disable RC4, even
if it's broken.

I see it a bit differently:
RC4 is broken. Full stop.
Therefore new versions clients and servers should per default not
use/enable/accept it.

Of course Russ is right, that this would cause interoperability
issues,... but IMHO that should be manually decided by the admins/users.
If an kerberos admin says "well I still want/need to provide/trust RC4"
he should manually need to enable in the configs.
Same for a user/client, the other way round.

So I'm not saying that old broken/algos should be thrown out
completely[1] - they should just not come into use without user/admin

> I suggest to file
> individual bugreports against particular packages, ideally already with
> suggestions/patches on how to fix them.
Mhh... nah I don't agree here. Discussing that with every package
maintainer is actually what makes it impossible to ever finish... I
rather think there should be project wide guidelines how to deal with
such questions.
Nothing that needs to be cut in stone and where one cannot make
exceptions in valid cases.

If there was consensus on how we actually want to handle security (here
in the sense of cryto strength: strong, medium, weak, none) then it
makes sense to move to the next step an actually implement it.

But as we've just seen... people's views already differ too much here to
have a staring point: One says interoperability is important and one
musn't break working systems just for security... another one like me
says rather break stuff (and let people then decide what they actually
want) but to hell with MD5, SHA1 and ideally even distrust the NIST
ECDSA curves ;-)

As you can see from Jonathan's mail, we even cannot agree on whether
having broking algos is a bug or just meta-bug ;-)


[0] https://wiki.debian.org/AdvancedStartupShutdownWithMultilayeredBlockDevices
[1] actually I was quite surprised before, when doing some tests with
openssl s_client,... and it really didn't support -ssl2 anymore (even
though still in the --help and manpage)

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: