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 _______________________________________________ Mailing list: https://launchpad.net/~linuxdcpp-team Post to : [email protected] Unsubscribe : https://launchpad.net/~linuxdcpp-team More help : https://help.launchpad.net/ListHelp
