The case for TLSv1 or greater (with basic recommendations):
Though the site does not include any kind of financial function, it does provide a form of reputation to those users who have elected to identify themselves in some way. In particular those players ranked fairly highly (i.e. 2000 and over).
There has also been at least one report[1] in the forums of behaviour indicating an account was compromised, leading to games played with the intent of reducint that player's rating. Similar action against more prominent players aimed at having them declared to be cheaters have the potential to cause a great deal of trouble to those players, especially where chess is their livelihood. An important step in preventing this is providing a secure means of logging into the server and not requiring authentication data to be transmitted in clear text.
The best solution would almost certainly be one or two SSL certificates which support wildcard entries for subdomains. Ideally you want one which is already included with all the popular browsers in order minimise the need for end user intervention. Avoiding the use of self-signed certificates is wise for the same reasons.
Even without necessarily having the correct web socket support for the Scala/Play framework, it should still be possible to maintain secure connections to the web servers (front-end processors), even if the internal lichess networking drops that within the lichess network. This should be enough to prevent attacks aimed at compromising the accounts of prominent players or administrators and with alternatives[2] for maintaining security within the lichess network or between servers.
This issue has cropped up from time to time, but with no apparent resolution. Workarounds do exist, at least to the extent of providing certain protections to user accounts. Even if it was not good enough for, for example, full PCI-DSS compliance.
There are also presently a number of major updates on the verge of release or which have just been released. Is SSLv3/TLSv1+ one of those due for an imminent release and, if not, will it be considered for deployment in the next release? Any information regarding a timeframe for the future deployment of SSLv3/TLSv1 would be appreciated.
1. http://en.lichess.org/forum/general-chess-discussion/bughack
2. A VPN would be ideal here since the lila API and other functions don't need to do anything, it's just a function of internal routing.
Though the site does not include any kind of financial function, it does provide a form of reputation to those users who have elected to identify themselves in some way. In particular those players ranked fairly highly (i.e. 2000 and over).
There has also been at least one report[1] in the forums of behaviour indicating an account was compromised, leading to games played with the intent of reducint that player's rating. Similar action against more prominent players aimed at having them declared to be cheaters have the potential to cause a great deal of trouble to those players, especially where chess is their livelihood. An important step in preventing this is providing a secure means of logging into the server and not requiring authentication data to be transmitted in clear text.
The best solution would almost certainly be one or two SSL certificates which support wildcard entries for subdomains. Ideally you want one which is already included with all the popular browsers in order minimise the need for end user intervention. Avoiding the use of self-signed certificates is wise for the same reasons.
Even without necessarily having the correct web socket support for the Scala/Play framework, it should still be possible to maintain secure connections to the web servers (front-end processors), even if the internal lichess networking drops that within the lichess network. This should be enough to prevent attacks aimed at compromising the accounts of prominent players or administrators and with alternatives[2] for maintaining security within the lichess network or between servers.
This issue has cropped up from time to time, but with no apparent resolution. Workarounds do exist, at least to the extent of providing certain protections to user accounts. Even if it was not good enough for, for example, full PCI-DSS compliance.
There are also presently a number of major updates on the verge of release or which have just been released. Is SSLv3/TLSv1+ one of those due for an imminent release and, if not, will it be considered for deployment in the next release? Any information regarding a timeframe for the future deployment of SSLv3/TLSv1 would be appreciated.
1. http://en.lichess.org/forum/general-chess-discussion/bughack
2. A VPN would be ideal here since the lila API and other functions don't need to do anything, it's just a function of internal routing.
Another option, as discussed on #lichess on Freenode earlier, would be to use HTTPS for initial authentication and account management, but use OAuth2 for other functions. Really, though, that would depend on whether TLS added too much overhead to be able to play bullet games without trouble. The real problem is still the cost of the snake oil ... I mean the certificate authorising the TLS keys.
I think using HTTPS should be added without question! People are entering usernames and passwords. If you don't add HTTPS make sure that when people are signing up that they know they are entering the usernames and passwords over an insecure connection. People could be potentially using their email usernames/passwords
Yes, I think that if the site is not going to implement HTTPS, that should be clearly advertised during the sign-up process. E.g. "This site is not served over SSL. You should use a unique password for this account."