linuxdcpp-team team mailing list archive

[Fredrik Ullner <ullner@xxxxxxxxx>]

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