The following discussion in the DCDev hub was most likely the cause of the change(s?):
- [2010-09-01 19:12:10] <Pretorian> KEYP state " followed by a base32-encoded cryptographic hash of either the certificate directly (which is appropriate in the case of a self-signed certificate), or a certificate providing the base of a valid signature chain (which may be more appropriate a CA-signed certificate). " - [2010-09-01 19:12:25] <Pretorian> Do we or don't we need to specify which 'or' is applied? - [2010-09-01 19:14:46] <Pretorian> I'd change the URI to be ":1234/kp=SHA256#foobar" - [2010-09-01 19:15:16] <Pretorian> I dislike to use / as delimiter in this case. - [2010-09-01 19:15:44] <poy> i thought it would always be the first case (hash of the cert itself), since the purpose is to make sure that the cert received is the one we were expecting. how it is signed and by whom can then be checked once the cert has been received. - [2010-09-01 19:30:29] <Quicksilver> a signed cert has no meaning for us ... important is only that the cert shown by the hub is allways the same ... and that its the hub you received the address for ... a ca is only there for binding a virtual entity to a real one.. which we are not interested in ... as we are not companies trying to sell stuff - [2010-09-01 19:31:46] <iceman50> i.e paypal needs ca - [2010-09-01 19:35:58] <Quicksilver> also there were already attacks were CAs were compelled to validate fake certs by a government as valid to allow spying on TLS connections .... - [2010-09-01 19:38:11] <Quicksilver> e.g. an attacker interrupts the connection and shows you a real looking cert signed by CA from bananarepublic A ... attacker pays A money to compell CA to valiudate their cert ... voila attack succeeded.. and your browser will probably not complain as the CA is valid... its just a bit implausible that paypal gets signed for example by some carribean CA ... but your browser won't mind to much... - [2010-09-01 19:38:41] <iceman50> weird - [2010-09-01 19:39:01] <poy> same opinion as me then, so in Pretorian's quote, always choose the first "or" case, right? - [2010-09-01 19:39:01] <Pretorian> iceman50: Hm? - [2010-09-01 19:39:19] <poy> Quicksilver: i thought you proposed KEYP? - [2010-09-01 19:39:51] <iceman50> well unless you specifically check the cert yourself everytime you go through an encrypted channrel - [2010-09-01 19:39:53] <Quicksilver> no not my preposition... and KEYP has nothing to do with CA ... for us KEYP is way better.. - [2010-09-01 19:41:20] <Quicksilver> the trick in all cases is use the CA for the first time to verify a cert.. in all later cases compare the cert to the cert that has been shown to you before i.e. do what KEYP does ... sadly thats not the common case for browsers... thats what you do when you use putty/ ssh client ... comparing current cert to last cert - [2010-09-01 19:42:21] <poy> KEYP's only use is when connecting via a hub list / web site, correct? after that clients can handle that cert comparison themselves. - [2010-09-01 19:42:49] <Quicksilver> yes and no ... - [2010-09-01 19:43:12] <Quicksilver> keyp is a way to store the cert.. just keeping it behind the hub's address... but KEYP is also there for client-client connections.. - [2010-09-01 19:43:32] <Quicksilver> and well yes it bridges the GAP between hub and hublist - [2010-09-01 19:43:47] <Quicksilver> (if the hublist is given to you via https) - [2010-09-01 19:44:22] <Quicksilver> in the ideal case client creaters would store keyp for hublists in the clients... use these to verify the hublists.. whcih give keyp of hubs... voila all validated.. -- 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
