sockets and encryption

[Michael Stenner]

On Sun, Nov 24, 2002 at 10:54:53PM +0100, Paul Nilsson wrote:
> On Wed, 20 Nov 2002 16:49:27 -0500, an infinite amount of monkeys
> hijacked the computer of Michael Stenner <mstenner at phy.duke.edu> and
> wrote:

Hey now...  I resent that!

> >Would SSL work for you?  That's basically made to do exactly what you
> >describe, no?
> 
> Doesn't ssl involve getting a certificate? I'm also not sure of other
> restraints that may be present, such as non ascii data. I'd rather
> just open a socket and push a raw bytestream without having to conform
> to a standard :)

I know this has mostly been cleared up.  I just wanted to point out
that SSL (which stands for Secure Socket Layer) is really intended to
be a drop-in socket replacement*, and can basically do everything
regular sockets can do.  As a sidenote, it is the way most of the S
protocols get their S, https, simap, pop3s.

The problem with simply encrypting traffic is that you're still
vulnerable to Man-in-the-Middle attacks.  That's where the certs come
in.  They are for authenticating the server.  If you're not worried
about that, then you can just have your client ignore it.  And as
mentioned by others, you can generate your own certs.  So-called
"self-signed certs" are actually pretty common on the web and it
shouldn't be hard to figure out how to make them.

If what you really want is something that looks and acts like a
socket, but is encrypted, then SSL is really the Right Thing(tm).

					-Michael

* OK, it's not a replacement per se, but another layer (hence the L)
  "inside" a regular socket, whose "inner interface" is again
  socketlike.
-- 
  Michael Stenner                       Office Phone: 919-660-2513
  Duke University, Dept. of Physics       mstenner at phy.duke.edu
  Box 90305, Durham N.C. 27708-0305