Task #1374
closednfd-status: enable verification of the data received from NFD
0%
Description
nfd-status may need to verify data that is received from NFD
Updated by Alex Afanasyev over 10 years ago
I'm not sure. Yes, I would be nice to have, but question is what is the base for this verification. How does nfd-status knows NFD's public key?
Updated by Chengyu Fan over 10 years ago
Since the Interests sent by nfd-status just use prefix "/localhost", I assume that the nfd-status is running on the same machine.
So why not just parse the configuration file to get the NFD's public key?
Updated by Alex Afanasyev over 10 years ago
nfd-status not necessarily knows where the config file is located. There are pre-defined locations, but anybody can change that. The only thing that nfd-status can know is how to connect to the running NFD (the socket address is either pre-configured or updated in ~/.ndn/client.conf
).
Instead of verification, I would just print out NFD's public key certificate information.
Btw. This is for HTML output. CCNx had a nice trick of setting background color of HTML page partially based on the daemon's public key. This way, different colors would mean different instances of NFD. We could do a similar trick.
Updated by Junxiao Shi over 10 years ago
- NFD configuration file not necessarily readable by
nfd-status
, because NFD is started by root, andnfd-status
may be called from a web server that runs undernobody
. - NFD's public key is not in NFD configuration file.
A malicious app can send unsolicited Data under ndn:/localhost/nfd/status
namespace, hoping one of them would satisfy a request from nfd-status
.
However, we should assume localhost does not contain any malicious app.
Updated by Chengyu Fan over 10 years ago
If the NFD can publish its public key using a local name, then all local apps can get it directly.
Data and Interest from apps must go through NFD, it has the ability to stop local malicious data injection, doesn't it?
Updated by Alex Afanasyev over 10 years ago
NFD can (and probably should) publish, but this doesn't fix the problem. How would you verify that the publishing thing is correct. And if you can verify that, then we can verify nfd-status, but this is kind of a contradiction...
Updated by Beichuan Zhang over 10 years ago
If there's a way to learn the socket address to connect to, why not use the same way to learn NFD's public key filename?
Updated by Alex Afanasyev over 10 years ago
There isn't really NFD's public key file anywhere. What we have now is public key certificate that NRD is using to send commands (they happen to be the same right now, but it is not necessarily the case, unless we decide to make it the same). Even so, there is no standard filename for it, thus there is no default, and this file must be specified in the config file (right now it is really optional and you would need it only in exceptional cases).
Updated by Junxiao Shi over 10 years ago
- Status changed from New to Rejected
20140515 conference call decides that verification is unnecessary because /var/run/nfd.sock
should be trusted. There is also no secure way to retrieve the public key of NFD.