[crossfire] encrypting the connection

[Kevin Zheng]

On 10/21/2017 12:10, Mark Wedel wrote:
> On 10/20/2017 05:22 PM, Preston Crow wrote:
>> Would it make sense to encrypt the connection between the client and
>> the server?  I'm particularly concerned about the sending of passwords
>> in plaintext, as they're probably the same as other user passwords in
>> most cases.
>>
>> It would be fairly simple to wrap the server side with stunnel, but
>> without built-in client support, this wouldn't do any good.
>>
>> I've never used openssl or similar libraries, but that would seem like
>> the right approach.  I doubt that the added overhead would cause
>> latency or cpu load issues.
> 
>  One issues is that most servers are unlikely to get official SSL
> certificates, thus having self signed ones, so while encrypted, you'd
> still have the problem on a 'non verified' connections.
> 
>  Also, the way crossfire buffers and sends data may not be ideal (it
> basically writes the data to the OS as it is generated, and lets the OS
> combine the data into larger packets).  That may not be ideal for
> encryption or compression.  And since non encrypted connections have to
> be maintained for clients that don't support it, the number of encrypted
> connections may not be that high for quite a while.

It's certainly possible to wrap things in STARTTLS. An implementation
for the client and server that can be disabled at compile time would
certainly be welcome.

>  As you note, the real issue is with the password. I can't think of much
> else in the connection anyone would really care about.
> 
>  And one issue with the password is that it is stored on the server,
> plaintext IIRC.  So if the server is compromised, someone could grab the
> password and if able to associate with the real person (probably due to
> server logs) could try to use it elsewhere.

Currently the passwords are hashed with crypt() on Linux and in
plaintext on BSD and Windows (due to a legacy #ifdef). There are
eventual plans to get them hashed with scrypt() or bcrypt() on all
platforms with a path for migration.

-- 
Kevin Zheng
kevinz5000 at gmail.com | kevinz at berkeley.edu | PGP: 0xC22E1090