Search only on encrypted hubs/ADC(S) hubs

[iceman50]

Allow a user to specify in a search if the search should only be sent to
1) Hubs with a secure connection (ADCS) which includes only users supporting secure connections.

2) To ADC hubs only.

The proposed way it should look in the 'Hubs' portion of the search frame...
 _
|_| Only where I'm OP
|_| Only in secure (encrypted) hubs
|_| Only in ADC based hubs

[Fredrik Ullner (ullner)]

This adds the new option "Only secure (encrypted) hubs". I am wary of adding ADC vs NMDC specific content into the view frame, given the confusing nature for most users. I suppose encrypted only works on ADC, but the phrasing and use is a little easier to grasp.

[eMTee (realprogger)]

This is a very good idea, however as long as searches and responds on UDP aren't encrypted, this option could actually increase the false belief that searches are also safe in all cases on an ADCS hub.
There was a discussion and mutual agreement about making searches optionally encrypted in the future and then to add global setting options to allow/disallow certain type of unencrypted communication.
Until this has been done, I'd recommend adding this feature only if it also forces passive only searches on those encrypted hubs, regardless of what the actual connection setup suggests.

[Fredrik Ullner (ullner)]

While I think your idea is fine, the option is really a shorthand version of just selecting those hubs yourself. What you are proposing would change the nature of normal searches (i.e. it doesn't matter if the user uses the "only secure hubs" option or not).

By the way, searches are not typically done on UDP. It is only the response that is/might be.

[poy (poy)]

the feature is nice and well coded - i'd like to have it even without secure searches. maybe by tweaking the phrasing some to be more explicit? eg "only encrypted transfers"?
also, i think there is a huge step between searching and actually downloading...

[eMTee (realprogger)]

Information leaking is the same, whatever function you use. And of course, it's not the searches it's the responds that's leaking. But from the searcher's point of view it's indifferent. Anyone listening will see what search results a searcher gets, with clear file identification information (TTH)...

[eMTee (realprogger)]

... and ny proposal doesn't would not change the nature of normal searches at all. This needs just utilize a feature other clients optionally have for very long time. In this case DC++ would do it automatically and only for searches initiated when the secure hubs option is on.
This would also add a temporary and also very easy solution for a discrepancy ADCS has since its beginning without the need of new protocol elements and such...

[Fredrik Ullner (ullner)]

eMTee: Your proposal is different from iceman's. Right now, the option is (as per requested by iceman) "quick-check those hubs that are marked as 'secure'". You are proposing that the option in *combination* with a particular hub (with/without the quick-check?) should do something different than just a particular hub. I have no issue with the request per se, but it is not, I believe, the original intended feature request.

What does other clients do in this scenario? How do they address this? I checked with a few clients, and there is no such option as requested here. And as poy pointed out, in the end it will be secure transfers, not necessarily secure searches/responses. The few clients I checked does have a switch in advanced settings to force secure transfers -- does this option also address search/response?

[Fredrik Ullner (ullner)]

By the way, maybe I'm spazzing out, but how can the client require that others only send encrypted UDP responses?

[eMTee (realprogger)]

Nobody talking about here encryted UDP or UDP at all. If you send a passive search request, the results go back through the hub connection, which is encrypted in ADCS.
It's ok to add forcing passive searches for ADCS as a separate setting, though most users will probably not find it and won't understand its need.
I just feel really odd thst you are going to add a feature labeled "secure searching" and it would be anything but secure.

[Fredrik Ullner (ullner)]

This patch will add an option in the security settings, "Require that are searches and responses are secure"; this will cause the client in an secure hub (i.e. ADCS) to send passive searches (no U4/I6 flag).

This should take care of eMTee's concerns. This patch is not dependant on the other patch here and vice versa.

[poy (poy)]

t_t

how far are we from properly securing search responses?

is there no other way to achieve this atm than to shut down the whole UDP communication? (what if another feature of the protocol relies on UDP?)

and to get back to eMTee - wouldn't you be fine if we just changed the label? for example:
- Hubs where I am op
- Hubs with secure transfers

later on, we should actually improve that hub selector (columns about the op / secure status for example...).

[eMTee (realprogger)]

I am fine with the label change since it turned out that my recommendation actually not easy to implement as unlike in NMDC the active/passive search mode (U4 field) is decided upon initialization of an ADC hub connection.

[Fredrik Ullner (ullner)]

poy: It is not possible, as far as I know, to require non-UDP responses or require encrypted UDP-responses (is that even possible?). No other feature, as far as I know, require UDP. By the way, UDP responses are not a requirement for responding in active mode, it is simply done to decrease the strain of the hub. I'll push that patch if you sign off on it.

I will push the patch of the search frame (with aformentioned label change) as all parties seem to like it.

[poy (poy)]

cool. could you rename to the labels i suggested in #11? it removes "only", which translates to long words in French...

i'd prefer we hold on to the passive patch for now, and maybe think about UDP encryption instead (i have no idea how far we are, but i'm sure thoughts had been written down at one point?).

[Fredrik Ullner (ullner)]

Done.

[Fredrik Ullner (ullner)]

I've created https://bugs.launchpad.net/dcplusplus/+bug/1481668 for tracking the secure search/response (basically so we can close this report and use that one).

[poy (poy)]

Fixed in DC++ 0.860.