[MUD-Dev] SSH Encryption on data stream

[Christopher Allen]

Craig H Fry wrote:

> So many games are plagued by packet sniffers I often wondered why
> more companies didn't do a per-session SSH encryption on the data
> stream.  Has anyone tried or is it just assumed the over head for
> packet encryption/decryption would cause a bottleneck?  I'm
> seriously considering using SSH for data encryption for my data
> streams and was curious if it is worth looking into.

I am co-author of the TLS RFC 2246 (i.e. SSL 3.1 standard) and
released the SSL 3.0 reference implementation. One of the reasons
why we liked SSL way back when was that it could be used to secure
any TCP/IP stream, not just HTTP. We even had a "groupware" product
that was really a disguised MUD that we were going to secure with
SSL.

However, now that I actually have a game software company, we
encountered some issues with using public cryptography to encrypt
game streams. One of the biggest issues is what we call in the
security software industry the "Monday Morning Problem". In game
terms, if there is a blip in a major part of the net, or the game
crashes, when it restarts every user is going to try to reestablish
a connection to the server at roughly the same time, each requiring
multiple public key operations, and bringing the server to a
halt. In web transactions this is less of an issue because you don't
have persistent connections, and those problems you do have can be
addressed by load balancing the web servers.  It is significantly
harder to load balance a MMORPG.

There are other issues -- SSL and SSH are both TCP, whereas a lot of
games prefer UDP, and there are a variety of problems in securing
UDP. There are firewall issues -- personall I prefer SSL because
almost every firewall understands SSL and will let it tunnel
through. Also, both SSL and SSH really are not very good at "passing
off" the secure connection to other machines, i.e.  if there are
multiple machines involved (which is true a lot with MMPORGs) each
must redo the public key operations all over again.

You also really need to be careful and not try to design your own
security protocol -- security protocols are extremely difficult to
design much less vette. Remember, SSL 1.0 was broken in one hour
after it was presented at Crypto! Early SSH's had major problems as
well. This doesn't even include issues of security problems in the
code.

I've talked with some cryptographers about how to adapt/leverage SSL
for games.  IMHO, the key issue to take advantage of in games is
that games require good latency. If the attacker can be delayed in
such a way that their latency is increased significantly, then the
attack/cheat is less viable. We've come up with a couple of good
ideas, but nothing that is ready for proposal yet. In summary, we
used hash tricks rather then public key cryptography for the key
exchange, but otherwise preserve SSL record layer so that firewalls
will think it is normal SSL traffic. This has the advantage of
taking advantage of the proven SSL record layer for the transport,
and then only the weird hash key exchange technique has to be
vetted.

I'm not actively working on this right now, but if someone was
seriously interested in pursuing it further, I could be persuaded to
pick it up again ;-)

-- Christopher Allen

------------------------------------------------------------------------
.. Christopher Allen <ChristopherA at skotos.net>       Skotos Tech Inc. ..
..                2342 Shattuck Ave Ste #512, Berkeley, CA 94704-1517 ..
.. <http://www.skotos.net>           o510/647-2760x202  f510/849-1717 ..
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev