• Content count

  • Joined

  • Last visited

About Ophite

  • Rank

Contact Methods

  • ICQ
  1. DHT bootstrap error

    The lesson: donâ
  2. DHT Cloud is Growing

    I can't help but feel you fundamentally misunderstand the nature of a small-worlds network like DC, Big Muscle, where we have circles of friends with each other, and so-called "super-peers" connecting those circles. It's actually a time-honoured design for a reasonâ
  3. DHT Cloud is Growing

    Specifically as addressed above, you do, in fact, tell them that, at least in terms of numbers. Hub count, op/registered/unregistered. Right there in the tag and BINF.
  4. DHT Cloud is Growing

    I have some severe misgivings about this feature. This is a fundamental change in network design; this builds one big P2P network, not the small-worlds network DC has always been up until now. This is a VERY BIG switch in paradigm. It may violate pre-existing user expectations of the software. This feature really must not be hidden away in a changelog, otherwise users may inadvertently be sharing things with the whole world that they only meant to share with a select few. Are you, Big Muscle, prepared to accept responsibility for exposing them to that potentially severe risk? There must be a clear off switch, and I would argue, it should be off by default in Apex, certainly for a while at least. (Do all DC users want to share with everyone? If they did, why are they using a small-worlds network like DC and not the many existing wide P2P networks like public torrent sites, eMule, or Gnutella? Isn't being small-worlds one of DC's characteristic advantages?) Note that even Bittorrent includes ways to let the trackers tell it that public DHT publication is undesirable, and this field is very commonly used in the wild, for example to allow trackers to restrict access to the general public! Where is the analog here? There isn't one, at all. A client who's on the DHT may leak any downloading or shared file to the public inadvertently, without even being aware of it. Note that the client does announce to the hub how many other hubs it's on, and the hub is already free to make decisions based on that. The client should, therefore, announce to the hub that it is on the DHTâ
  5. Released: ApexDC++ 1.2.0 Final

    Evergreen: Because it was unfinished, inefficient, nowhere near as comprehensive as something like PeerGuardian, and most importantly didn't merge cleanly with the newer StrongDC branch. It was, broadly, felt better to take the feature out rather than leave it broken. Use PeerGuardian if you feel you absolutely must have... something like PeerGuardian. ...besides which, your hub allows banned IPs in it? Not a very good hub...
  6. Works just the same with 7 as with Vista for me.
  7. Share size

    When adding files to the share after a /refresh or restart (and after they have hashed), the share size posted to the hub isn't updated on an NMDC hub until the client is reloaded or you reconnect to the hub. I'm not sure if that's a bug as such, or simply an intended oversight to avoid info-flooding NMDC hubs, but felt you should be aware of the behaviour because another /refresh (after the hashing, and after the filelist has actually been updated and the files are available) still doesn't update the value. Disconnecting from the hub and reconnecting does seem to update the value. I haven't tested with ADC yet.
  8. KEYP - KeyPrint (Draft Proposal)

    Fine with me, go for it. I'm also wondering about the specific implementation details of the KeyPrint myself; I'm exploring all reasonable options while figuring out what the most elegant implementation of this might be. As per arne's comments, I'm leaning now more towards using the X509_digest() function in OpenSSL with whatever hash we choose (because X.509 has very carefully defined what should and shouldn't get hashed, so getting your cert signed won't break anything, but no-one can try to make your RSA key material into invalid ECDSA key material either). That said, I'm solidly against using MD5 or SHA-1 for this, they're broken. But SHA-256 might be convenient to implement, given that it's in OpenSSL already (TTH isn't, though TIGER192 is) and it isn't much longer at all; here's a mockup example: adcs://hub.example.com:12345/?kp=SHA256/7KGKGB44A5AEPZXTNLVBIAE4HLNVBUO42ONIELL2XYFS4RTPMIYT And, indeed openssl x509 -noout -fingerprint -sha256 < mykey.crt will output the fingerprint in coloned-hex form; if you converted that to base32 and plonked SHA256/ on the front, that'd be a plausible SHA256 KeyPrint. I rather like that idea, and how naturally that would fit, and am therefore leaning towards the second draft for KEYP switching to SHA256 instead of TTH as the default, and specifying the KeyPrint broadly as an X.509 fingerprint converted to base32, i.e., encode_base32(X509_digest(key, EVP_sha256(), ...))
  9. KEYP - KeyPrint (Draft Proposal)

    I'll flesh it out a bit more later. In particular we probably want to avoid agreeing known-weak algorithms in the TLS handshake (the ancient 40-bit "export" algorithms are definitely out-of-bounds, but though I will explicitly check, I wouldn't be surprised if avoiding all that is OpenSSL's default behaviour). Basically, the hub implements a perfectly normal SSL (well, TLS) listener using, for example, OpenSSL. This could be as well as or instead of the unencrypted port; it'd make a lot more sense to have it on a different port and we're probably better off, in the light of "traffic management" problems, not specifying a default port and allowing hub admins free reign in that. The only new parts are: A KEYP field added to the TSUP, indicating we support this. (Do we even need this?) A new KP field (43 bytes payload, 46 bytes total extra) in the TINF broadcasts sent by supporting clients to ADC hubs using encryption they trust. (This would be ignored by any non-supporting clients.) The "kp" parameter, with the hub's keyprint, optionally added to an adcs: URL. The hub doesn't need any modification in its behaviour whatsoever if it already supports SSL; this is already supported, for example, in luadch/luadchjit which I have been using to test with. By all means track that down if you're curious on how the hub might actually support TLS; it really doesn't need much. In all respects the TLS connections are entirely normal connections as per the TLS 1.0, 1.1 or 1.2 standards, and this is by design. The only thing that this proposal affects on top of what already exists is that it provides a mechanism for specifying a hub's trusted certificate fingerprint in the URL, and a client's trusted certificate fingerprint in their KP field, which could be picked up by a client which supports it, and would be happily and freely ignored by any client which doesn't. This seems much easier for the handling of client certificates than a system whereby to be secure you'd have to download the certificate of every client and plonk it in your trusted folder (although if you did do that even with Apex 1.1, I do believe it would work). The point cologic makes is entirely valid; in theory DC++ can indeed do this already at a basic level. As for the basic point of trust design; indeed, whomever passes around adcs: URLs including a kp parameter would be the point of trust in this scheme (and the hub owners to a certain extent as well). I contend that an existing trust relationship already exists there, and that it is not inappropriate to extend that to key distribution. Anyone who uses a hublist or accepts a hub link off someone is already trusting them to give them addresses of hubs, and not Evil Honeypots of Doom
  10. KEYP - KeyPrint (Draft Proposal)

    Thanks for the comments so far. I'll try to address them as we go and work out any kinks in this. That's what suggests
  11. (Also known as project Pavlova. This is only a draft write-up; a request for comments, if you will. I hope to present patches implementing this proposal for Apex soon in the hope that this can appear in a version in the near future, and to submit it as a patch for StrongDC and for vanilla DC++, as well as an official ADC extension. -O1) KEYP - KeyPrint, fingerprint-based TLS authentication for adcs: (Draft) 1. Synopsis This extension adds a simple, but secure way to protect against man-in-the-middle attacks against ADC when wrapped with TLS (1.0 or later). It does not require setting up a CA or signing keys, but you still can if you want to. Specifically, we introduce a "KeyPrint" - the hash of either the certificate signing the server certificate (in a CA-style key-signing configuration) or, simply, the server certificate itself (in a self-signed configuration). We add this KeyPrint (or simply, KP) to the hub's adcs: URL in a URL-parameter, so that any attempted certificate substitution attack on a TLS hub connection to the hub will be detected. Additionally, clients should publish their own certificates' KeyPrint in a "KP" string in the ADC "INF" broadcast. Assuming one trusts the hub enough not to maliciously change the KeyPrints en route (a reasonable assumption given the hub's existing position of trust), and given that the connection to the hub has been similarly authenticated (either as above or via a directly downloaded trusted certificate), client-client connections are also protected against attempted man-in-the-middle attacks - without messing around having to get everyone's certificates signed in advance. 2. KeyPrint Specification 2.1. A KeyPrint consists of a hash name, followed by a / (forward slash), 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). 2.2. It is suggested that TTH, which is the Tiger Tree Hash exactly as defined in the [TIGR] extension to ADC, be used for this, as it marks a readily-available, convenient, yet secure baseline[1]. We use "TTH" to specify this; again, in the same way it is specified in [TIGR]. 2.3. In a secure ADC (adcs:) hub URL, we add the KeyPrint to the URL as a URL parameter named "kp", encoded (for example) as follows:- adcs://hub.example.com:12345/?kp=TTH/USNVXMWXL5MSQHR4ITYJITVFY75RUGIDCBQ3BZQ 2.4. Clients which have generated a TLS certificate for secure client-client communication (which in this protocol need not be signed, so this should probably be done by default!) should publish their own KeyPrints (as above) as a string field named KP in their INF broadcast to ADC hubs. 2.5. If a client receives a KP field in an FINF broadcast via a hub to it is connected using adcs: and a trusted key as above (or otherwise), it should be regarded as the valid and correct KeyPrint for that client's IP/port/hub combination, replacing any earlier KeyPrint for that IP/port/hub combination. 3. KeyPrint Verification 3.1. When initiating a TLS handshake with a remote host where we know their KeyPrint, we can verify that a man-in-the-middle attack is not occurring by checking if the hash given in the KeyPrint matches exactly: a root certificate presented in a valid signature chain which covers the certificate presented during the handshake by the remote host; or the entire certificate presented during the handshake by the remote host. 3.2. If we know a remote host's KeyPrint, and in connecting to that remote host, we are presented with a certificate which does not match, and which also does not have form the root of a valid signature chain covering that certificate: then we have detected a certificate substitution attack and we MUST abort the connection with a user-visible, non-modal error stating, for example "Crypto error: Detected attempted man-in-the-middle attack, aborting". (This error quite possibly represents a real attempted attack that has been foiled; we may try auto-reconnecting but we should NEVER ignore it, or it will succeed. We may wish to avoid stating the KeyPrint of the certificate that was actually received) 3.3. Optionally, when receiving a TLS handshake, if we know what the remote host's KeyPrint ought to be, we could also verify this, though it is pointed out that only the initiating side needs to check this for the man-in-the-middle protection to be valid; specifically the hub doesn't need to remember, or even understand, clients' KeyPrints. 4. Security Considerations 4.1. Client-Hub 4.1.1. The KeyPrint in the adcs: url prevents a clandestine man-in-the-middle (certificate substitution) attack on the TLS session with the hub, if and only if the kp parameter hasn't been modified by an attacker. 4.1.2. Suggested countermeasures against this include the following:- Even if otherwise unprotected, an attacker would likely only have a maximum of one opportunity to make the substitution (by changing the kp parameter when the URL is first sent to the user); if it's changed later, it will be detected. ("Casual first-use" security, as often used in SSH.) Checking the fingerprint or transferring the hub URL out-of-band (for example by telephone, or in person) could reveal or thwart man-in-the-middle attacks; something's wrong if you don't have the same URL as the hub operator gives out. (PGP-style "sneakernet" security.) We would be protected if the URL were in a file signed by some secure means by a party we have already decided we trust not to change the URLs maliciously. Encryption would not be necessary, only a signature to ensure no untrusted party has modified the KP fields. (A signed hublist, possibly.) Finally, we would be protected were the hublist/URL retrieved from an https: site signed by a CA we trust not to issue signatures for any domain to someone who doesn't own that domain, and the owner of that domain trusted not to modify the KP fields. (SSL-style security.) 4.2. Client-Client 4.2.1. We are, in particular, trusting the hub not to maliciously modify the KP fields sent by the clients through their TINF broadcasts. However:- the hub would gain nothing from swapping the KeyPrints of its users, as it would not gain anything from mounting a man-in-the-middle attack on its own users that it does not already have the ability to do, as it's the hub; and if we do not trust them enough not to maliciously modify the data, why are we choosing to connect to them and transmit our IP address through them? it could be detected by cross-checking with other clients/hubs, as connecting through a malicious hub would clearly show you to have a different KeyPrint to any other hub; therefore any hub doing this would obviously be quickly removed from hublists. 4.3. General 4.3.1. The certificates, including the name fields, are sent in the clear during the initial handshake. Therefore it is recommended to avoid identifying marks in the certificates CommonName fields (for example) that would clearly single them out as being TLS keys used by adcs:, and the CID field most definitely should not appear. Quite possibly no name fields should appear, or they should be blank. Bibliography: [TIGR] - ADC specification, §7.1 - TIGR - Tiger tree hash support: http://adc.sourceforge.net/ADC.html#_tigr_...ee_hash_support Footnotes: [1] Regarding the choice of TTH as a baseline hash; it is both convenient - being already present in the TIGR extension and in practice available in all ADC clients - and not insecure - having no known practical second-preimage attacks. It is most certainly not weaker than MD5 or SHA-1, which are often widely used elsewhere in TLS/SSL. We note further that if a problem arose, then as with the rest of ADC, we could switch to another hash such as SHA-256, or a future SHA-3 algorithm.
  12. New beta testers

    Looking forward to breaking the beta and examining both pieces