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

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

On Wed, 2014-10-15 at 15:18 -0400, Joey Hess wrote: 
> I've talked about this with the git developers before, and while they
> seemed to have some ideas for how to handle a conversion to a different
> hash, they're not keen on doing it until forced by SHA1 being more
> broken than it is now.
Well,... I guess one could foresee that this will sooner or later become
an issue, right after git came out :-(

Hopefully, they will make this generic in the future... and ideally
retain the old IDs as well (but not using them on verification), so that
textual references to old commit IDs can still be used.

> I think that's a pity, especially because they could be adding a more
> secure hash to git now, and use both hashes, and avoid a massive flag
> day later.
Yep,... and as you said,... they rather seem to want to wait till the
last minute... :(
Really sad, especially since it was always also pointed out to be such a
great security benefit of git...

> Anyway, Debian obviously cannot go it on its own and change the hash
> used by git, we need git to be useful for the things people use git for.
Sure,... which is why I've listed git as one of the examples where we
can't do much

> Instead, it makes sense to adapt workflows that do not trust git hashes,
> which mostly means making signed tags and commits, and checking the
> signatures. This is something Debian could improve in many areas, I'm
> sure.
Uhm... well maybe I misunderstand you somehow,... but just trusting on
some unverified hash alone was never enough as it never proved anything
but integrity (not authenticity).
So singing was always necessary and always will be, even with SHA3 or
anything even "better".

> In general, I think that Debian needs to identify upstreams that are
> being proactive about dropping old crypto algos, and those that are not.
Not sure if this alone is enough... but I also have no real clue on how
one should actually organise such a crypto consolidation...
Perhaps with a website, that tracks packages using crypto, marking which
known-to-be-vulnerable stuff they still use/allow, which
we-rather-want-to-avoid-it-even-if-not-yet-broken stuff they
use/allow... and what their defaults in terms of algos are

Right now the whole seems like a big haystack to me,... sure it's easy
to talk about the big browsers,... but finding all the countless small
programs/libs which do https/TLS/SSL/etc... some of them even ignoring
certificate validations per default...

> Major browsers, openssh upstream, etc are going to be more on top of
> this than we are, and make better decisions.
Aha,... well I can't sign that... just look at Mozilla, they default to
RC4 being still allowed though it's known to be broken for months now,
and known to have issues for even longer.
Until not so many versions ago, they even defaulted to still allow
unsafe TLS renegotiations, IIRC.

> Web servers probably have
> user pressure to keep old crypto available, in order to support broken
> clients that some users care about, and Debian might be able to improve
> the defaults in such cases.
IMHO the big ones like webservers and browsers, are actually "less" of
an issue:
I mean either you have a security conscious admin/user and then he will
probably know about the most important stuff in crypto... or you have
someone who doesn't care,... and well... these people often even don't
upgrade their stuff regularly.

I'm not saying that it wouldn't be great if we could ship with better
defaults (and disable broken/questionable stuff) there as well,... I
just mean that I'm far more scared on all the small packages and little
tools one often easily forgets about, that they may actually be a
critical point in security.


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

Reply to: