Your message dated Thu, 16 Oct 2014 05:42:23 +0200
with message-id <1413430943.4706.42.ca...@scientia.net>
and subject line Re: Bug#765512: general: distrust old crypto algos and
protocols perdefault
has caused the Debian Bug report #765512,
regarding general: distrust old crypto algos and protocols perdefault
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
765512: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765512
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: important
Tags: security
Hi.
Not sure if there is already some concentrated effort, but I think
there should be one, i.e.:
---
To disable crypto algorithms and protocols per default, which are
known to be no longer secure, across Debian.
And ideally, to default to securer versions where possible, e.g.
not using SHA1, or SHA256, if it makes no difference to use SHA512
or maybe in some time Keccak.
---
I see that some people may actually be forced to still use such old
algorithms for whatever reason, but at least per default programs
should no longer accept them and manual admin/user intervention
should be required to re-enable them.
Of course there are some clear exceptions as well, i.e. for a program
like jacksum (in the package of the same name) it makes not sense
to forbid md5 from being calculated.
Further, some programs use some crypto algorithms (especially hash
algos) in a not-so-much security related way.
But care should be taken, since often it's not obvious, whether
something is actually security relevant or not.
For git it's e.g. quite clear that it's use of SHA1 *is* security
relevant.
For mldonkey one might think "well they use it just as an ID".
For some packages there may be simply no alternative, at least
none that Debian (or anything else but upstream) could provide.
An example again would be git,... even if it would be decided one
day, that SHA1 is no longer enough for the way being used in git,
we of course cannot change this alone.
Another example, anything OpenPGP related is inherently bound to
SHA1 (at least in parts), and without a new standard, nothing can
be done about.
In many cases, the respective upstreams already have discussions
about phasing out old algorithms, like in gnupg there is right no
a discussion abot old v3 keys.
But often these upstreams react very slowly and/or only when they
really have no further choice.
Take Mozilla now with the Poodle attack... that SSLv3 is close to
be broken could be seen for years now,... but they left users
vulnerable for no really good reasons.
IIRC, per default they still have rc4 enabled, which is broken
and the argument "that some servers support nothing else" may be
true but it's still a bad one. What people want from https is
"secure" communications (as far as this is possible within the
current X.509/SSL/TLS model) and better no connection at all
than one that anybody can read.
I'm probly not the biggest crypto expert out there, but I guess
most people will agree that following algorithms should be
avoided:
- MD5 (or anything before)
- RC4
- DSA1 with 1024 bit only
- SSLv3 (of course v2 as well)
- depending on where it's used: CBC
- MtE and EaM MACs should be avoided
and ideally:
- SHA1 should be avoided as well, it's not yet broken, sure, but
cracks can be seen
- probably RIPEMD160 should be avoided as well,... I'm not sure
about it's latest status in cryptoanalysis, but being one of
the niche algortihms is another danger
- where possible, new algorithms (e.g. AE ciphers) should be
used per default, GCM and recently ED25519 ChaCha and Poly1305
look promising
- I personally would probably try to avoid the NIST curves in ECC
- where possible prefer (or only allow) algos with PFS
Affected packages/programs (of course this is only a small excerpt):
- major browsers (FF, Chromium, konqueror[0])
- disable SLLv3, anything with MD5 (this includes certificates)
and RC4
IMHO users are better of with failed connections than using any
of them
- set safer preferred algorithm lists
- do this before Mozilla/Google/etc. decide so only because they
already now about an upcoming hole which completely breaks an
algo which is already known to have issues
- smaller browsers (links, lynx, etc.)
basically the same
- curl,... not sure what it actually does, but options only allow
to force a given SSL/TLS versions, not to disallow some
- wget seems to even use SSLv2 per default? (see manpage
--secure-protocol option)
- anything related to secure APT (apt, aptitude, etc.) should no
longer trust MD5, and ideally SHA1 should be phased out as well
actually I'd probably vote for a combination of
SHA2-512 and SHA3-512 in which *both* are validated and if any
of them fails it's considered to be failed.
- http servers should default to not offer SSLv3 at least, and
ideally at least suggest people to restrict even more
- SSH
- anything IPsec
- the countles of Perl, Python, Ruby, etc. packages which can
to https or TLS/SSL
- ...
As one can see, this is probably nothing on person or maintainer
can do alone...
Yet I feel far to often these years that I wake up from time to
time, reading in the news that one was using algos with known
issue till now for no good reasons.
Cheers,
Chris.
[0] Last time I checked Epiphany was still vulnerable to insecure
redirections and thus SSL/TLS is completely disfunctional there.
--- End Message ---
--- Begin Message ---
On Wed, 2014-10-15 at 18:31 -0700, Russ Allbery wrote:
> It feels to me like you're spending lots of time telling other people
> they're wrong and telling other people what they should be spending time
> on, and then arguing with anyone who tells you that how you're going about
> this isn't effective.
Well isn't that somehow the point of discussion and defending one's
opinions? Don't you just do the same?
> One, you're preaching to the choir, and two, I don't understand what
> you're trying to accomplish by haranguing me about this. You seem to have
> entirely missed the point I was trying to get across, which is that many
> upstreams are closely monitoring these issues and have a plan already,
> and, when that's the case, their plan is probably better than something
> Debian would come up with for their software. (As Brian points out, this
> isn't always the case, but that was partly Joey's point: we need to look
> at whether upstream is engaged and has a plan, or whether they're ignoring
> the problem or unaware.)
Uhm,... wasn't you who sparked the discussion about RC4 safety within
Kerberos?
I think originally I didn't mention kerberos at all.
So either I should have interpreted your following answers then as a
that's Russ' PoV and thus I'm expected to change my own opinion
accordingly, or I could take it as an invitation for discussion.
Or did I get anything wrong here?
My original point was merely that we have a lot of packages where the
situation seems completely unclear and other packages where upstream
makes bad decisions (e.g. Mozilla).
Now of course we can argue back and forth whether Mozilla's decisions
are good or not; I'd say they've waited well too long (and would
consider my point proven by POODLE), others would say it was right.
But I'd expect that neither you, nor Ian nor I'm the only one here who
studied computer science, mathematics and worked in the security areas
and cryptography, and probably we'll find people agreeing with your or
my position and even those with a completely different one.
Alas, a waste of time, for all of us - surely not what I've meant to
gain with #765512.
> If you think upstream's plan is wrong, then you need to go argue with
> *them* about that, not with us, unless upstream is *so* wrong that it
> looks like we should just fork. For good upstreams, such as the Kerberos
> upstreams, they generally have crypto expertise in their team already and
> can have a detailed discussion with you about exact threat models and
> timelines for deprecating enctypes. When that sort of expertise exists
> upstream, I'm arguing that this is not the effective place to do
> something. Diverging from upstream has a rather significant cost,
> particularly if we diverge from upstream and then *get it wrong*, which is
> not outside the realm of possibility.
> And then you go on to put words in my mouth, like this:
>
> >> If we were making a security-hardened distribution that chooses
> >> security over interoperability across the board, we may well want to
> >> make other decisions.
>
> > So you suggest against efforts of securing / hardening Debian? What
> > about introduction of hardened compiler flags, apparmor, selinux, etc.?
>
> > I personally don't think that hardening contradicts being a universal
> > OS.
>
> which is just frustrating. I feel like you're turning my opinion into a
> parody of what I said to make it easier to argue with.
Uhm no I really just wanted to understand what you were trying to say.
Your point was (AFAIU) that we're not a specialised distro focusing on
security, right? Next I understood, that we shouldn't place security
above interoperability.
That's why I've asked how that affects those other fields, since usually
all of them mean interoperability problems, or at least that things do
not longer work that straightforward out of the box.
> Of course doing those sorts of things is consistent with being a universal
> operating system. But you'll notice that Debian did hardening roughly
> around the same time (or even a bit later) than other major distributions,
> which was nowhere near as fast as some of the security-focused
> distributions did it. And I'd love to have a solid and reliable SELinux
> setup that we could just turn on, but *everyone* in the Linux distribution
> space has found that extremely difficult to achieve. My point is not
> "don't do security stuff." My point is "Debian is not going to be on the
> cutting edge of disabling features in the name of security."
I see, well that wasn't clear to me, at least from your previous points.
> In other words, if your primary concern is security, Debian is always
> going to be a little slow for you. I don't think that's a problem, nor
> does it imply that Debian should *never* push on security.
But I guess you're aware, that an attacker usually doesn't wait till
software or a distro starts defending itself?
> I just hate to see people wasting
> their time writing long replies to threads like this that are going to go
> nowhere because there's not an effective structure for accomplishing
> anything, which is why I (and several other people here) are trying to
> nudge you in the direction of something more productive and more likely to
> succeed.
Well I think that's a bit unfair towards me.
My original bug (before this was drawn over at d-d) mainly questioned
"what shall we do?" cause right now, it's that we basically do nothing
an hope that the big upstreams just do right and... well I guess no one
really looks at the smart pieces of code.
So it seems you blame me for wasting my (and others time) without any
productive outcome.
OTOH you should see, that what I propose (tighten things up, primarily
looking at security) is rejected... so it seems to me that you basically
say "what you propose is wrong/won't work/is unecessary" but don't come
up with a better solution (except to let things as they are).
Someone has brought up a link before, that Fedora is having some effort
on just this topic (okay I don't know how big and concentrated it
actually is)... but especially when we have so many experts here, like
Ian who said he worked and got promoted in this field, it should be
known that most (responsible) big companies and organisations now have
some folks who basically do nothing but looking into security.
Evaluating the situation and how it can be improved. And those who
didn't have usually ran into troubles.
We have of course the security team, but AFAIU the mostly react on
concrete issues in the sense of security holes.
I just felt like we have nothing as what I've asked for in my original
bug report.
> Anyway, I'm afraid that this whole thread is going to be a waste of
> time, so I'm going to stop responding here.
Since you just told me above that this is mostly nothing Debian should
take care about but rather upstream, Ian agreed with you and since Don
already expressed that he feels it's not right to handle this as a
bug,... I'll think I withdraw myself and apologise to everyone wasting
time about yet another security discussion.
I further think it's appropriate to close #765512, probably I just
overestimated the need for taking action and this is a non-issue.
Anyway,... sorry for causing troubles,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
