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.