linuxdcpp-team team mailing list archive

[Crise <991342@xxxxxxxxxxxxxxxxxx>]

I will happily elaborate, however, I do say this. He went a bit too
technical for me in some aspects of it (for myself). So enjoy...

Quote 1 (after describing the current implementation):

"Ah. In that case, you’ve failed the KEYP compliance test—I’m not sure
if that matches what I saw upstream (but that code may have changed
upstream after I saw it, I don’t know).

I feel some clarification may be in order here. I can see a potential
problem, and there may have been a miscommunication somewhere along the
line. As you know, I originally drafted it, so…

KEYP most certainly verifies chains; if a KEYP is known for a particular
connection, it has specified, positively and out-of-band, the only
trusted certificate valid for that connection: whether that certificate
may be signing another (where its use, CA, and path-length constraints
allow it to), signed by another key which we don’t care about, any
combination of signer and signee, or entirely self-signed. It specifies
the trust in the key, not the signature. If a KEYP is present, then the
certificate that matches the KEYP should be considered the (only)
trusted root authority for that particular connection.

Let me explain—if we know a valid KP for a connection, check if that KP
doesn't appear in the presented certificate chain first: if not, reject
immediately (regardless of whether or not we would ordinarily trust
it)—as we know what the trust root should be, and it isn’t there (i.e.
this is in fact apparently someone else’s certificate!). If that
matches, then check your TLS signatures, using the KP-trusted
certificate as your only (tautological) authority (ensure no other CAs
are in the list, and screw anything higher if it’s there; you want a
solid chain from this certificate validly signing either itself, or, via
a valid chain of signatures down, the key presented by the server
itself).

In other words, KEYP performs what has lately become known, in web
browsers, as ‘certificate pinning’—the strongest certificate
verification available (and the only one to survive widespread CA
compromises).

The KP for X’s server key is SHA256/<snip>; but I could equally present both that key and the is Root Authority key that signs it (in that order; that is the proper way round for X.509 certificates in TLS, order is important), and specify either X’s keyprint directly, or the is Root Authority key’s KeyPrint (which, by the way, is SHA256/<snip>), which would mark that key as a trusted CA and would trust everything it signed, allowing me to change the server’s key at will as long as it’s got a valid signature over it from my CA." [Editor's remark: this is important since the root certificates, of a chain, are typically valid for longer times... imagine a group of hubs hosted by one person or group of people sharing same custom root certificate but having individual certificates for themselves, originally this came under discussion precisely in this kind of setup]
 
"Examine, if you will, the following psuedocode, to see (broadly speaking) a general methodology that I think may be more appropriate to the task:" 

[Editor's remark: see attachment]

"Substantial deviations from that kind of pattern could cause a
potential problem. For example, the checking loop is done in that kind
of way because a loop that has a data-dependent branch (or break) could
expose a potential timing attack enumerating certificates you think are
valid (without needing a valid signature from that certificate): so if
that’s an issue in the threat model, you need to think about that.
(OpenSSL’s code contains code that compiles to similar structures, and
other branch-balancing or blinding/whitening/snowing timing attack
countermeasures.)

Similarly, if you check the certificate with the CA list before checking
the KP, you’ll happily accept someone else’s certificate (substitution
attack) or a certificate that should have changed but hasn’t, and if you
include your own certificate in the CA list, someone can perform a
reflection attack!"

Quote 2 (after initial fix):

"I’d want to check what happens if you have a KP certificate in a
“phantom chain”:

totally separate self-signed public cert (created by MITM attacker, which they have the matching private key for)
-----
KP public cert, simply concatenated to the above (which attacker does not have the private key for, but which the other side is happy to give them a copy of the cert for during SSL negotiation)

^ This should be rejected, as the key that we’ve actually verified isn’t
actually the key being used for the crypto, and hasn’t signed the key
being used for the crypto either.

(Request: Please do not disclose details of the above attack. I know it
seems kind of, well, obvious, but you would be astonished at some of the
things still vulnerable to it, possibly because they think it’s too
obvious to test.)"

After all of that he on my request set up 3 smoke tests and 4 different
success tests for KEYP which I then used to make an implementation that
works in the highest number of cases (and additionally, granting hub a
trusted status based on whether certificate has been pinned with KEYP or
not) These are not live anymore so including them here is not relevant.

Quote 3:

"For what it’s worth: I did not submit KEYP upstream as an extension
proposal. I wrote a draft up and posted it on your forums; somehow, my
draft spec post just sort of made its way over as a full ADC extension,
and I had no involvement with that process. It came as a surprise to me
when I found out that it had actually been implemented in vanilla; at
first, I had thought that you had implemented it yourselves. I have had
only extremely limited discussions with the authors of vanilla; as you
know, they’re not always the easiest people to work with."

-- 
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/991342

Title:
  KEYP Vulnerability

Status in DC++:
  New

Bug description:
  With the current vulnerability with DC++'s current KEYP implementation
  the underlying issue seems to be this ...

  [2012-04-26 09:24] <Crise> anyways, the thing with keyp is entirely
  different problem... which is basically that it only verifies keyp on
  the peer level certificate and not on the whole chain as it should

  Crise has stated he has another source who knows the exploit but will
  not divulge in who he is.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/991342/+subscriptions