incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: key signing
Date Thu, 11 Oct 2012 17:38:29 GMT

On 11 Oct 2012, at 17:14, Dennis E. Hamilton wrote:

> @Nick
> I don't understand the supposed attack vector concerning the file digests being of no
value and the WoT being essential.
> - Dennis
> So long as the digest value is obtained from a reliable read-only source, it doesn't
matter where the file comes from, the digest can be verified.  This will protect against and
help detect a poisoned mirror site or a third-party redistribution that substitutes an inauthentic
artifact.  That is, in fact, a very big deal and it defends against exploits that happen too

In saying "a reliable read-only source, you're glossing over the MITM.
My browser may say when in fact it's talking to my
evil ISP's proxy.

> If the reliable read-only source is compromised, that means an adversary has managed
to (1) replace the file in Apache custody, and (2) replace the digest that applies to that

Yes, for those communicating directly with an apache server.
We can improve the security of that using https, but that too is a
weaker security model due not least to the variable quality of the CAs.

>  (Or just replace the digest and make the authentic file look bogus and the poisoned
downloads look authentic.)

Funnily enough I diagnosed a rather similar issue for my mother only yesterday.
A site at which she's shopped before had evidently been compromised, and the
attacker had sent her email she took for genuine, while she was suspicious of a
'confirm your change of password' email that was almost certainly genuine (but
useless).  And the compromise had happened at least a month earlier, as
evidenced by two monthly trojanised 'newsletter's from the attacker.

Anecdotes aside ...

>  If substitution of the file-digest pair is achievable, providing a different external
signature can't be much harder, although the exploit might achieve the intended purpose without
that. Introducing a verifiable external signature that finds a counterfeit public-key certificate
on a key service may extend the ruse a little longer. 

A trojan PGP key is plausible.  Trojanised signatures are possible, though the
bar seems to me to be rising.

But a trojanised chain of trust leading back to a trusted signature?  That raises
the bar a long, long way.  And within the ASF we have a lot of WOT
interconnectedness: to impersonate an ASF key you'd need in effect to
impersonate a whole lot of us.  It's a many-eyes scenario, and those eyes
will tend to route to tech-savvy brains.

I'm at an advantage: when I download an Apache bundle, I can generally
trace a chain of trust back to myself.  If I find something signed by "Dennis
E. Hamilton" but without enough ASF sigs to establish a chain of trust
back to myself, I *will* query it, so an imposter is going to have hijacked
your ASF email if (s)he's going to intercept my query and prevent you or
me raising the alarm.  Add to that other checks (e.g. does the project have
an IRC channel, how old is the key and does that check out, if nothing
checks out then ask the project dev list).  Multiply that by lots of other folks
who check PGP keys carefully, and that's a much higher level of security
than some mere checksum.

> The exploit continues until some Apache folk or security-proficient external party detect
(1) the substitution or (2) a counterfeit external signature or (3) confirms that the external
signature is not verifiable on the substituted file and digest pair.

Not "the signature" .  A whole lot of signatures.  Each with a real person to
notice something is wrong, unlike an unowned checksum.

> I don't see the WoT as much of a factor if this exploit occurs.  It comes down to how
quickly the exploit is detected, the damage detected, and a mitigation put in place.  I assume
that infrastructure defense-in-depth measures have to expose the fact of an exploit, even
if an insider is involved.  At the worst, it might be necessary to recall a release.
> This assumes that the exploit is by exploit against the read-only distribution material
in Apache custody.  
> If the exploit is by tampering with a release prior to its approval, that is an entirely
different problem,

Sure.  If someone we elect as committer smuggles in a trojan, no amount of security
after the event will help.  That's a different issue to the one I thought we were
talking about.

Nick Kew
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message