[NXT] NXTInfrastructure committee

[utopianfuture]

Where is EvilDave ? the esteemed head of prestigious Infrastructure Committee ? I would like to discuss the transference of 48380 NXT private bounty for the best Open-Source client for NXT to the Infrastructure Committee.

https://bitcointalk.org/index.php?topic=412138.0

Could InfCom decide the winner (could be multiple) so that I can dispatch the fund. See the link for reference. Thanks.

[1714579825]

1714579825

[1714579825]

1714579825

[EvilDave]

Hey guys, we absolutely need SSL (not self signed) for nxtcrypto.org

My client can no longer connect to nxtcrypto nodes because the SSL is self signed, which browsers don't trust by default. I hope you guys change your mind on this decision.

Btw, this only costs like 68 euros, not 468.

https://www.namecheap.com/security/ssl-certificates/comodo/positivessl-wildcard.aspx?gclid=CM-W4of7pb0CFZShtAod_28Aag

OK, the price isn't really an issue, but we've been thru this discussion with opticalcarrier and came to the same point:
Why do we need SSL? It seems like cosmetic security, rather than giving any actual benefits.
So, why does your client (nice work, btw) need SSL ? And if we provide 'real'SSL on nxtcrypto nodes for your client, are we going to have to provide SSL on all nodes in the NXTwork in order for your client to function?

Have another look at:
https://bitbucket.org/nxtinfrastructure/committee/issue/20/ssl-certificate-for-nxtcryptoorg

I'm tempted to just throw some funds in your direction, but I want some more input from the rest of InfCom (and anyone else with some serious insight on the issue) about this.

[marcus03]

Where is EvilDave ? the esteemed head of prestigious Infrastructure Committee ? I would like to discuss the transference of 48380 NXT private bounty for the best Open-Source client for NXT to the Infrastructure Committee.

https://bitcointalk.org/index.php?topic=412138.0

Could InfCom decide the winner (could be multiple) so that I can dispatch the fund. See the link for reference. Thanks.

If you ask us to, we probably will do it. If you want us to decide, there would be just four, not five people to vote, since I am a client developer myself and also in InfCom and I would absolutely vote for my client, since I think I deserved it. ;-)

[opticalcarrier]

Where is EvilDave ? the esteemed head of prestigious Infrastructure Committee ? I would like to discuss the transference of 48380 NXT private bounty for the best Open-Source client for NXT to the Infrastructure Committee.

https://bitcointalk.org/index.php?topic=412138.0

Could InfCom decide the winner (could be multiple) so that I can dispatch the fund. See the link for reference. Thanks.

If you ask us to, we probably will do it. If you want us to decide, there would be just four, not five people to vote, since I am a client developer myself and also in InfCom and I would absolutely vote for my client, since I think I deserved it. ;-)

Is this committee the right one for software projects?  Is tech a better one?
I specifically declined invitations to this committee because i felt it would be a conlict as i run my nodes funded by domations and i expected to work on other infra projects that would be funded.  So i felt my presence here would present a conflict of interest so I decided not to join the committee

[opticalcarrier]

Hey guys, we absolutely need SSL (not self signed) for nxtcrypto.org

My client can no longer connect to nxtcrypto nodes because the SSL is self signed, which browsers don't trust by default. I hope you guys change your mind on this decision.

Btw, this only costs like 68 euros, not 468.

https://www.namecheap.com/security/ssl-certificates/comodo/positivessl-wildcard.aspx?gclid=CM-W4of7pb0CFZShtAod_28Aag

OK, the price isn't really an issue, but we've been thru this discussion with opticalcarrier and came to the same point:
Why do we need SSL? It seems like cosmetic security, rather than giving any actual benefits.
So, why does your client (nice work, btw) need SSL ? And if we provide 'real'SSL on nxtcrypto nodes for your client, are we going to have to provide SSL on all nodes in the NXTwork in order for your client to function?

Have another look at:
https://bitbucket.org/nxtinfrastructure/committee/issue/20/ssl-certificate-for-nxtcryptoorg

I'm tempted to just throw some funds in your direction, but I want some more input from the rest of InfCom (and anyone else with some serious insight on the issue) about this.

The comittee needs to figure out ssl. ask jlp or cfb of the best method of  supporting client-side signing and if SSL is needed.   my thought is that the committee wouldsubsidize SSL for any vps provider that had proven track record, at least temporarily until SPs really took off and would handle things like that on their own as it sits now none of us vps owners operate as SPs in order to make any money so we would need funds for this assuming that it is needed I thought it was but the main devs would give us a better idea

[EvilDave]

Bounty ANN:: Papers on NXT network security requested.

The Infrastructure Committee (infCom) would like to put out a public request for papers on aspects of NXT network security.
http://107.170.117.237/index.php?topic=49.msg111#msg111

The papers should address the following from both a general P2P and a specifically NXT perspective:

  An analysis/description of the NXT P2P network architecture and the communication within.

  Attacks that could be conducted on Nxt infrastructure (the NXTwork), identification methods and countermeasures that could be used against them,   including : - DoS - Sybil - Poisoning - Eclipse - Tracking - Node Spoofing and any other relevant attack vectors.


InfCom will be rewarding two bounties for submitted papers, the bounties will be somewhere between 10-20,000 NXT per paper.

Deadline is 2 months from now, 24 May 2014.

If you have any questions, post on this thread, the new NxtForums.org thread:
http://107.170.117.237/index.php/topic,102.0.html
 or contact one of the InfCom members via PM.

As inspiration:
http://world-comp.org/p2012/SAM9754.pdf
  

[EvilDave]

reposted from firehose, just so I can find it again.

Please expound.  Really we only need a decision made on whether or not there is benefit if infrastructure committe will pay for my VPSs' SSL certs, or if I should just disable SSL on them.  The committe's response was "no we dont want to pay for SSL just use tor."  well I have previously laid out reasons that NXT has only partial tor support (DNS is still leaked out), plus, like I mentioned, tor is eventually compromised unless very harsh, nearly impossible security methods are taken

Apparently the certs that I am using, that is signed by a private CA, still causes some client-side software to fail, apparently they cannot just ignore the cert warning for some reason.

In the end we'll have clients that prepare and sign transactions completely locally and send them via UDP

good info, ill go ahead and disable SSL on them then. (it would still be good to get SSL on wiki and on whatever forums DNS name they come up with for http://107.170.117.237 forums site.  If the community decided the new forums to be on nxtcrypto.org then a wildcard would be the way to go anyways, otherwise 2 different certs are needed.

Unless the wiki and forums operator are willing to purchase it out of their own pocket.

Users of Wesley's client that sign transactions client-side will have their privacy compromised without SSL, even though the transactions and their password will be secure (assuming he is verifying the bytes before signing). I do see the value of SSL in this use case, because it is much simpler for the end user than setting up tor, and we are targeting users who presumably are not sophisticated enough to be running the Java server themselves.

My opinion was that SSL is not needed, and in fact cannot be used, for communications between nodes, and also that we cannot distribute an SSL certificate with the Nxt package itself. But for communications between thin clients and a public node, SSL is easier than tor for the end user for the purpose of preserving privacy - that is, from a spying ISP or government, not from the owner of the public node itself.

Can I summarise the SSL situation as:

 No SSL on nodes. Not needed.

 SSL on forums/wiki may be useful, if only as security theater.

 Wesleys client must have SSL in order to function securely. http://nxtra.org/nxt-client/

Correct me if i'm wrong.

My client doesn't need SSL to function securely (No passwords are sent to the server). Jean-luc talks about privacy. Not sure what he means by that though. However if you want to forge, the API requires that you send your password so that does needs SSL.

SSL on forums/wiki is needed though, since otherwise pw's are sent in the clear.

Users of Wesley's client that sign transactions client-side will have their privacy compromised without SSL, even though the transactions and their password will be secure (assuming he is verifying the bytes before signing). I do see the value of SSL in this use case, because it is much simpler for the end user than setting up tor, and we are targeting users who presumably are not sophisticated enough to be running the Java server themselves.

My opinion was that SSL is not needed, and in fact cannot be used, for communications between nodes, and also that we cannot distribute an SSL certificate with the Nxt package itself. But for communications between thin clients and a public node, SSL is easier than tor for the end user for the purpose of preserving privacy - that is, from a spying ISP or government, not from the owner of the public node itself.

But how long do we expect before we change from TCP to UDP?  Once that happens we cannot use SSL at all.  So if its soon, do we just want to do things in the clear until then, since its going to be in the clear anyways?  Or perhaps you want to revisit going to UDP in the first place since you cannot get security that way?

wait, nevermind, I think I get it.  the UDP migration will only be for p2p, right?  The API will still reside on TCP and thus can use SSL?

SSL is needed to ensure that javascript client is not manipulated during transmission

Right. But the user is getting the javascript from nxtra.org, which I presume is under Wesley's control. If so, user has to trust him (and still use SSL so it is not modified in transit), but he already is trusting him that the client he maintains is not malicious.

Now, if there is a copy of Wesley's javascript available for example at https://wallet.nxtcrypto.org, which is not under Wesley's control, we are back to where we started, the user has to absolutely trust the owner of nxtcrypto.org, as indeed even the javascript could have been modified.

If you use SSL, at least you are protecting the client privacy from the ISP and anyone who can spy along the route.

This is very easy to attack. A simple correlation between a SSL encyrpted HTTP package of matching size and the timestamp of the transaction will let a third party correlate a transaction with the originator IP. You also have to trust the node operator, since he owns the SSL certificate.

For forums and wiki SSL is indeed essential, unless we all start signing each of our posts and PMs with GPG.

+1

It does make sense to protect the Wiki and forum with SSL (I previously missed that you have to login into the Wiki) and as such, I think InfCom should fund the SSL certificate. The NRS nodes should however not use SSL.

Users of Wesley's client that sign transactions client-side will have their privacy compromised without SSL, even though the transactions and their password will be secure (assuming he is verifying the bytes before signing). I do see the value of SSL in this use case, because it is much simpler for the end user than setting up tor, and we are targeting users who presumably are not sophisticated enough to be running the Java server themselves.

I beg to differ:

• Their privacy is easily compromised to 3rd parties even with SSL (see above).
• Their privacy is always compromised to the node operator since he owns the SSL certificate, thus this is still not a trustless solution.
• If privacy is needed, Tor can deliver.
• I've added support for Tor in my client in like 2 hours (version not yet released). It will come with the tor.exe client and my NXT client simply starts the Tor client if Tor is not running already and shuts it down again on exit if it was started by my client.
  All the end user has to do is set the checkbox to use Tor. I also have proposed a bounty for client developers who implement support for Tor (https://bitbucket.org/nxtinfrastructure/committee/issue/33/tor-enabled-capable-nxt-clients) since this would solve the privacy issue very efficiently.

....and we are targeting users who presumably are not sophisticated enough to be running the Java server themselves.

Well, then we exclude these users from forging, since we can't really encourage them to send account secrets to public NRS nodes (even with Tor and SSL used).

I fear that the secretPhrase parameter for forging will backfire on us some day. IMHO, forging (and anything else that needs a secretPhrase parameter) should only be possible when the request comes from localhost.

being able to correlate a single transaction like you describe is an extremely bold claim.  Maybe now its not so terribly difficult, but once NXT transactions start to pop it will definitely be impossible. And of course a light client ALWAYS has to trust the node operator.  This is the case whether or not you use either SSL or TOR (or not use either/both of them).  So just take this argument away.

Like I said before, depending on tor for a home user is just not feasable.  I find it extremely hard to believe that you see the SSL correlation such a risk yet completely ignore TOR correlation that is possible unless, like I said previously, the user takes EXTREME steps, nearing on the impossible.  Without these drastic extreme steps, eventually tor is correlated.  It just takes time.

But whatever, just ignore the dev.  Hint, you might want to do a little research about tor correlation, before you depend on it yourself though.  In fact, unless you go do your research on it, Im going to assume that not only do you not care about it for yourself, but you also dont care about it for others.  IMO this is not exactly the way things should be done, but, oh well, you guys in the committee are supposed to be the experts, after all.

For the user who was asking about wildcard SSL (I think it was xyzzyx) the cost to do it anonymosly is fairly high, almost 500 euro.  So unless someone knows that rapidssl/comodo/someoneElse will allow purchase with either anonymous or with known-to-be-not-real ID (startssl is very strict about real names, address, TN, etc) then thats the way to go.

[opticalcarrier]

The point is that with or without SSL you have to trust the vps operator.  By only using tor you must trust every single tor exit node out there and you know this tons of them out there have FBI CIA or NSA sniffers.  Ssl removes this

[marcus03]

Here's a copy of my answer from the now dead monster thread:

being able to correlate a single transaction like you describe is an extremely bold claim.  Maybe now its not so terribly difficult, but once NXT transactions start to pop it will definitely be impossible.

IMHO you've just made a bolder claim than I did.

And of course a light client ALWAYS has to trust the node operator.  This is the case whether or not you use either SSL or TOR (or not use either/both of them).  So just take this argument away.

Why is that?

Like I said before, depending on tor for a home user is just not feasable.  

Have you read that it took just 2 hours to implement support for Tor in my client and all that the end user has to do is ticking a checkbox? Why is this not feasable?

I find it extremely hard to believe that you see the SSL correlation such a risk yet completely ignore TOR correlation that is possible unless, like I said previously, the user takes EXTREME steps, nearing on the impossible.  Without these drastic extreme steps, eventually tor is correlated.  It just takes time.

The SSL correlation is not my main problem with SSL.

My main problem is that the way I would attack privacy and security of NTX is like this:

1.) Set up and run lots of NRS nodes.
2.) Protect it by SSL and make sure I myself stay anonymous.
3.) Encourage NXT user to use the nodes under my management, because they are more secure than others due to SSL.
4.) I'd end up with a substantial amount of the NXT client<->NRS communication under my control.

No, this is not an accusation that this is what you are trying to do. I'm personally very grateful for what you do for NXT.

However, I would like to prevent that the general perception is that SSL has a real security/privacy benefit for client<->NRS communication.

But whatever, just ignore the dev.  Hint, you might want to do a little research about tor correlation, before you depend on it yourself though.  In fact, unless you go do your research on it, Im going to assume that not only do you not care about it for yourself, but you also dont care about it for others.  IMO this is not exactly the way things should be done, but, oh well, you guys in the committee are supposed to be the experts, after all.

• You are not being ignored. You previously failed to follow-up on InfCom comments and questions. If you had answered my last post in the InfCom thread regarding the SSL for the Wiki with just "but what about the username/password" pairs, which I previously missed, you'd had me in your boat within 5 seconds.
• You seem to have the idea that InfCom consists of five infrastructure gods/super-heros. This is not the case. We are as good and qualified as everyone else. This is why we ask you to make your case. And this also means that we are not above you or anyone else in the NXT community, so there is really no reason to play the "but whatever, just ignore the dev/average user/small investor/whatever" card.
• Regarding me not caring, I'll keep my mouth shut on this. Just note please, that committees are not there to run NXT and decide for the NXT community. It's the job of everyone, so if you think Tor stinks, please do the research yourself and make your case. The issue I've created for it is here: https://bitbucket.org/nxtinfrastructure/committee/issue/33/tor-enabled-capable-nxt-clients  It needs feedback.

For the user who was asking about wildcard SSL (I think it was xyzzyx) the cost to do it anonymosly is fairly high, almost 500 euro.  So unless someone knows that rapidssl/comodo/someoneElse will allow purchase with either anonymous or with known-to-be-not-real ID (startssl is very strict about real names, address, TN, etc) then thats the way to go.

Wouldn't it be possible to let someone like rickyjames make the order for the (non-anonymous) SSL certificate?

[opticalcarrier]

You seem to believe Im taking this personally, Im not the "dev" I was referring to; I was referring to JLP.  Its apparent to me that the case is you guys dont really understand how tor works.  Its either that or you are simply now really stretching to find a way to not have to admit that your original decision on SSL was wrong, in order to "save face".  That being said, except for the trusting of the node operator, Im not going to bother responding to any of the points you just tried to make.

You are the one that originally brought up that a user would have to trust the node operator as an argument against if we used SSL.  My response to that was that this is indeed the case *regardless* of if tor is or is not used, *and regardless* of if ssl is or is not used.  The simple fact is that when a user uses a light client, HE IMPLICITLY TRUSTS THAT THE VPS OPERATOR WILL NOT EVER TELL ANYONE THAT THE USERS ACCOUNT NUMBER BELONGS TO A CERTAIN IP AT A CERTAIN TIME.

And yes, please remember that way back, I suggested that my group of VPSs *NOT* be the only ones used in our model, to provide decentralization.

Look at my post just before this one.  If you guys are OK with forcing users to send unencrypted data over tor as our "security" model then it means that you are OK with our users being FORCED to trust THOUSANDS of unknown tor exit node operators who will have 100% immediate account/IP correlation.  And yes, the NSA, CIA, FBI does run tor exit nodes around the world for this very purpose.

The bottom line is:
1) regardless of tor and/or ssl, you always trust the end node you are sending your data to
2) that if you use tor, you HAVE to use SSL

If you do not understand these 2 facts, then not only do you not understand the tech behind ssl and tor, but you also dont even understand the POINT of tor, and you need to do a lot of research

[marcus03]

Ok, here's my effort in ignoring the personal accusations and your assumption you make in your post.

The bottom line is:
1) regardless of tor and/or ssl, you always trust the end node you are sending your data to
2) that if you use tor, you HAVE to use SSL

Which data do you think needs to be encrypted using SSL and thus be protected from the node operator (and the exit node operator when using Tor)?

Can you please name what you are trying to protect with SSL? Is it transaction data? Is it the accountSecret parameter in URLs? Is it the IP number of the NXT client end user?


EDIT: I've read your post again and I think you are trying to protect the IP of the NXT client end user:

The simple fact is that when a user uses a light client, HE IMPLICITLY TRUSTS THAT THE VPS OPERATOR WILL NOT EVER TELL ANYONE THAT THE USERS ACCOUNT NUMBER BELONGS TO A CERTAIN IP AT A CERTAIN TIME.

With Tor, neither the exit node operator nor the NRS node operator know the IP address of the end user.

[opticalcarrier]

...Which data do you think needs to be encrypted using SSL and thus be protected from the node operator...

you keep bringing this up.  but the node operator gets the correlation data, regardless of if ssl is or is not used.  Besides,Its not the node operators that I need anyone is concerned with.

Can you please name what you are trying to protect with SSL? Is it transaction data? Is it the accountSecret parameter in URLs? Is it the IP number of the NXT client end user? ...EDIT: I've read your post again and I think you are trying to protect the IP of the NXT client end user...
With Tor, neither the exit node operator nor the NRS node operator know the IP address of the end user.

It is the correlation data between account/IP address. Your point where you state "With Tor, neither the exit node operator nor the NRS node operator know the IP address of the end user." isnt true for all cases of all time - this is why I referenced the near-impossible requirements of an end user implementing tor correctly in some previous posts.  When it comes down to it, tor isnt a simple 100% obfuscated cloud with a user on 1 side and a random exit node on the other.  The research shows the correlation is possible unless the user never uses the same home location.  Perhaps whoever does your research paper bounty offer will provide more info for you on this.

I think there was a link posted in the firehose thread that had a fairly good description on the "proper" use of tor, and the near-impossible method of proper implementation, but given that firehose thread, I dont think Ill be able to find it.

[marcus03]

I had an answer ready, then read it again and had the feeling that everything has been said already and we are not getting anywhere.

I think I have made my points. I disagree strongly with you about node operators not being of any concern, but I'll leave it at this.

While I don't follow your statements regarding Tor, I agree that the pros and cons should be checked again.

I agree that the SSL certificate for the Wiki and the forum make sense and you have my vote for funding from InfCom.

Regarding, if it has to be an anonymous certificate, I'll back out and let the other members of the commitee decide.

I'll update the InfCom issue at https://bitbucket.org/nxtinfrastructure/committee/issue/20/ssl-certificate-for-nxtcryptoorg accordingly in a minute.

[marcus03]

This thread is no longer being followed by InfCom.

Please go to http://nxtforum.org/index.php?board=4.0 to get in touch with us.