[DGD]DGD network io, SSL encryption and unix sockets

[Christopher Allen]

From: "Brett McCormick" <brett at mail.flyingcroc.net>:
> This is problematic..  Unless there is some "magic string" sent to the
> client or server to initiate the handshake, which doesn't exactly turn
> me on.

There have been a number of IETF standards on how to do this, so that you
don't have to use a separate port for them as you do now. For IMAP, POP, and
ACAP see <http://www.imap.org/docs/rfc2595.html>, for SMTP see
<http://www.cis.ohio-state.edu/htbin/rfc/rfc2487.html>. There is also an
internet-draft that is approaching finalization at
<http://www.normos.org/ietf/draft/draft-ietf-tls-http-upgrade-05.txt>. Any
of these approaches could be used to step up a non-encrypted connection to
an secure one.

I suggest looking at them, and they have been fairly rigourously evaluated.

> > SSL is not very secure anymore.  If you want to base your implementation
> > on an existing standard, I suggest starting with the SSH protocol.
>
> SSL is just as secure as SSH, since they both use RSA public key
> cryptography.  I'm not an expert though, so you could very well be
> right, but last I heard, SSL wasn't going anywhere.

I'm biased, as I am one of the authors of the TLS 1.0 protocol, which is the
standards based successor to SSL (basically it is SSL 3.1). However, I think
all experts agree that SSL 3.0 is more secure then SSH. What SSH offered
that SSL didn't offer was the ability to to port mapping (which has security
issues), and to do RSA Anonymous (which SSL/TLS could do but didn't because
of security concerns.)

> > I intend to fundamentally rewrite connections handling, both at the
> > top layer and bottom layers, sometime in the next 6 months, making it
> > easier to extend in the process.
>
> I'll probably wait then since there are plenty of other interesting
> things to do in the mean time.

There are other issues to be concerned about -- if your goal is a high
number of users, the crypto operations of SSL/TLS or SSH can really slow
down the machine. The worst problem known as the "monday morning problem",
which is when everyone tries to connect to the server at the same time (say
after a crash, or first thing monday morning) the system will slow to a
crawl or even fail.

I have considered for years the issues of securing MUD connections,
including evaluation of alternative public key algorithms such as elliptic
curves to lower the cost of the crypto handshake. No clear answer has
emerged.

I'm now leaning toward securing admin and dev connections to the server, and
player connections using a shared-secret keying technique that is reasonably
secure for player connections. If separate server is available for
authentication, there are also some approaches in "Addition of Kerberos
Cipher Suites to Transport Layer Security (TLS) (RFC 2712)"
<ftp://ftp.isi.edu/in-notes/rfc2712.txt> that allow you to use a TLS machine
for authentication which then gives a kerboros ticket to the mud server
machine.

------------------------------------------------------------------------
. Christopher Allen                                 Skotos Tech Inc. ..
.                           1512 Walnut St., Berkeley, CA 94709-1513 ..
. <http://www.Skotos.net>               o510/649-4030  f510/649-4034 ..



List config page:  http://list.imaginary.com/mailman/listinfo/dgd