Public API nodes could support SSL for privacy purposes.

[ferment]

Opticalcarrier requested funds for buying a SSL cert and good discussion starts here: https://bitcointalk.org/index.php?topic=506757.msg5651541#msg5651541

NxtMinnow added some good comments about privacy here: https://bitcointalk.org/index.php?topic=506757.msg5668307#msg5668307

This is issue to not address opticalcarrier's request but rather to brainstorm the need and implementation of SSL on public API nodes for privacy (not trust) concerns.

Investigating a solution based on self-signed certs would be interesting for wider deployment across any public api node.

[marcus03]

Since I argued against it before: SSL for the sake of privacy (3rd parties not being able to connect a transaction with an IP number) is a very valid request, at least for some countries.

Self-signed certificates or one common certificate distributed together with NRS would be enough here.

The majority of people do run NRS locally and do not use thin clients, so this is not just an issue of protecting communication between clients and public nodes, but also the communication between nodes (=all NRS communication).

I will ask Jean-Luc what he thinks about this. (I gave him write access to our repository, btw.)

[Jean-Luc Picard]

For communication between clients and "official" or well-known public nodes, SSL makes sense for privacy, so that indeed account owners cannot be identified by IP.

For node to node communications, there is no need for SSL because the blockchain is already public, and because there is no way to keep the private key for the SSL certificate private, yet distribute it so that all the nodes have it. For the same reason, we cannot distribute a self-signed certificate with the NRS that people could use to connect to their own nodes, because it will provide no security at all, anyone that has it will be able to perform a man in the middle attack. But we could distribute the public certificates of well known public nodes, self-signed or not, so that people could connect to those nodes with their thin clients.

[marcus03]

@JeanLucPicard: Thanks for your feedback! I previsouly totally missed the point you make about not being able to distribute the certificate with NRS.

Regarding client vs. server: there is often confusion about this. As of today there are only two light clients available. Most users still run NRS locally (some don't even realize it, because the client starts it and it's more or less hidden). So from a user perspective, the communication between his NRS node and other nodes does matter regarding his privacy.

If I take a step back, I wonder if SSL is the right solution for the problem of privacy and deniability for end users. This is an important feature for users in some countries, but in these countries even simply being able to show that a user's IP addresses send some data to a NRS node, which is possible even with SSL, might already be a problem for the user.

IMHO, SSL is not the right solution in this case, but clients with (probably built-in) support for TOR would be needed.

[marcus03]

Feedback from Jean-Luc:

(quote)

You cannot even trust that the NRS nodes you connect to are not controlled by somebody who wants to spy on you. Even if you manually set well known nodes, you don't control what peer addresses they will feed to you.
We try hard to prevent the possibility of linking IP to accounts, e.g. when a block is forged or transaction is sent, the node that receives it from you doesn't know if your node generated it, or your node received it from another node. But doing global network traffic analysis it is still possible to figure out the origin node of a block or transaction. So indeed, running over TOR is needed for the extra cautious. It is already possible to use TOR and I always do it when forging, you just need to define socks proxy host and port on the java command line:

java -DsocksProxyHost=localhost -DsocksProxyPort=9050 -cp nxt.jar:lib/*:conf nxt.Nxt

I remember opticalc mentioning that this still leaks DNS requests outside TOR, haven't tried to test it myself. But forging and sending transactions over TOR works for me.

(end of quote)

[marcus03]

I've creating a new issue #33 regarding TOR enabled/capable clients.

[Ian Ravenscroft]

So essentially are we saying that SSL is pointless and we need ToR for privacy and therefore we close this with a 'No' for SSL?

[marcus03]

@chanc3r: I would agree to that. For me SSL is perceived security/privacy only. I think we can do better.

[Ian Ravenscroft]

Vote to say 'No' for SSL - 3 votes and its closed or comment against?

[marcus03]

I'd say give at least 24-48 hours for everyone to comment, even if we are at 3 votes already.

Voted to say No.

[marcus03]

I'm suggesting the following reply for opticalcarrier's funding application:

"InfCom has decided not to fund opticalcarrier's application for an SSL certificate for the NRS nodes he runs/manages under the nxtcrypto.org domain. NXT and the NRS implementation are architectured to be a trustless system and InfCom thinks that there is no security benefit when using SSL for client/server connections.

From the privacy perspective, while 3rd parties would not be able to connect a transaction to an IP number by intercepting communication packackes with SSL, this relies on the private key of the SSL certificate not being known by 3rd parties - however it is of course known to the owner of the SSL certificate. InfCom does not want to support an application that in the end would introduce a new party that users would need to trust (the SSL certificate owner).

InfCom thinks that there are better ways to achieve privacy within or on-top of NXT than using SSL certificates."

[Ian Ravenscroft]

4 votes for some time - only 3 needed - shall we close? Who does the feedback is it EvilEd?

[EvilDave]

EvilEd? I'm voting for a 'no' on this one. I'll give optical a PM in my role as spokesperson, let him know that we've made a decision on it, if he hasn't already seen it. Anyone else need to be notified?

I'm also thinking about giving weekly feedback on InfCom decisions on the main "firehose' thread, so feel free to remind me to actually do it. I think the weekend would be a good time to sort that out, given my other commitments at the momnet.

[EvilDave]

My PM to optical:

*Optical: After a lot of debate, InfCom has come to the conclusion that although SSL would help with the perception of security, it wouldn't add that much more actual security/privacy.

The concensus seems to be that we should concentrate on using NXT over TOR for added security.

So, in my role as InfCom spokesbeast: thats a "no" to your SSL funding request. Sorry.

U can see the decision-making process here: https://bitbucket.org/nxtinfrastructure/committee/issue/30/public-api-nodes-could-support-ssl-for Feel completely free to object if you like.

Good luck, keep up the good work,

EvilDave.*

[marcus03]

Since this was discussed in our thread, I'd say post it there, too.

I'll close this issue and will make an entry in our logbook in the wiki.

@Evildave: You can also use the logbook entries for status updates in the monster thread.

[marcus03]

Decided, documented and closed.