What you're asking is a very wide subject, so the best advice I can
give you is to purchase the O'Reilly book (Network Security with
OpenSSL). I don't know if there's a new (2nd, 3rd?) edition out (I got
it a long time ago) but even when you get the first edition, it's VERY
useful to learn the SSL API; anything I could explain here would be
less than half the quality of theirs anyhow.
Elaboration:
s_client/s_server are good examples in that all the
wicked-yet-important bits are in there; they are bad examples because
it's kinda cluttered at places. As you find s_server/s_client complex,
the O'Reilly book is definitely for you.
Make a note for yourself to remember later on (because this is what I
find most people discard when implementing apps with OpenSSL (or other
SSL stacks) and it causes lockups you can't get out of: "make sure you
handle SSL_WANT_READ and SSL_WANT_WRITE 'error codes' (rather: warning
codes) coming out of SSLread()/write()". When you write a very basic
bit of code, it will seem to work without these. Then suddenly people
will report spurious errors when you put it in production. Better be
prepared.
Ad BIO's:
BIO's are a bit akin to C run-time library 'FILE *' I/O handles, but
that is a /very/ rude comparison. Additionally, you can 'stack' BIO
handlers so that you create a sort of filter chain processing your
input and output data. the SSL core protocol is one set of filters;
TCP socket processing is another. It's stackable filter chains for
streamed data; the 'FILE *' analogy does not offer 'stacking filters'.
Check the man pages for better/more info.
Ad *.cpp:
I am not aware of the status of serv.cpp / cli.cpp but I seem to
recall those haven't been up to snuff always, while I consider
s_server.c/s_client.c part of the 'core examples' set; they may not be
the nicest stuff for newcomers, but they at least show a lot of the
material described in the manual pages. Again, if you want/need more
info on the SSL*() functions, I can't stress the importance of the
book enough: you can work without it if you feel at each with stuff
like s_client/s_server and even then there are bits in there that make
you go 'a-ha!'.
Ad certificates and keys an' all:
Creating certificates, keys, etc.? That's a different subject and I
think you should read up on what they mean and their purposes before
producing some.
For a test environment, one might wish to start by rolling their own
'certificate chain': that starts with a pair of [RSA] keys (one
private, one public) 'self-signed root certificate' (lost of info on
that on the site, FAQ, documentation _and_ the history of this mailing
list, by the way; just look for 'self signed' and 'root certificate'
and you'll be devastated ;-) ).
Once you've got a 'root certificate', you can try to create a 'server
certificate', based on the root cert. This 'server cert' can be fed to
s_server so you can play with it: using s_server and s_client.as a
single-peer-2-peer chat line: type line in either to see at the other.
You can also have a try (see openssl tool manpage et al) at using
s_server as a VERY basic HTTPS server by using a web browser instead
of s_client and starting s_server with a few extra options (see man
page).
Once you got confident over that, try to make a 'client cert' too, so
you get both server and client-side authentication up. All this is in
the man pages and FAQ; all the required tools are included in the
apps/ directory. ('req' et al)
Try anonymous connections and custom crypto stuff only after you've
completed this path.
On sharing keys between client and server: that's only 'good' for
symmetric cryptography (DES et al) and generally strongly discouraged
as you'll have two points of failure regarding key discovery (=
security risk). The point of the certificates and public-key crypto is
that each node (= person / machine / ...) has its own PRIVATE key in a
single place and shares his public key with the world: that's what the
certificates are carrying (though take heed: there are private-key
carrying certs as well). To establish trust, you've got the 'trusted
third party' in the form of the 'Certificate Authority' a.k.a. CA,
who's (of course) got HIS OWN private key nobody else is ever going to
see: his 'trust' however is represented by his publicly available
'root certificate' and your certificates being 'signed' by this CA.
When we trust the CA it means we very probably trust you as well.
(leaving out lots of details here)
Depending on the crypto algorithms you pick (generally RSA for public
key crypto, but there's more of 'em: DSA, etc. - see the OpenSSL gen*
tools; all are also packaged within the 'openssl' tool by the way and
available in apps/ ) you generate a set of keys (1 priv + 1 pub) for
each node. The 'symmetric keys' are usually generated on the fly by
SSL (a fresh one for every connection at least). You only 'roll your
own' and share the keys between client and server when you are going
to use symmetric crypto in a custom (***controlled***!) environment.
This may sound vague and it's not entirely accurate either, so please
read up on this in the OpenSSL book (plus the Bruce Schneier book
or/and other sources, al lot of which are on-line but have much
varying quality of content) -- it may look like that's 'too much work'
but I wouldn't even *touch* SSL or other crypto-related material
without at least a reasonable understanding of public key crypto and
secret key crypto and the consequences of using them.
When you use crypto you are playing with live grenades and the pin is
already out. So you'd better know how to handle ordnance.
Right now, my take is your best path forward is reading up on the
subject matter and testing/playing with the openssl toolset in apps/ .
Can't do that in a few emails, sorry.
Take care,
Ger
On Thu, Sep 4, 2008 at 9:42 AM, Manuel Sahm <[EMAIL PROTECTED]> wrote:
> Hello, thank you,
>
> could you please help me setting up small my programm.
> I lokked at the files s_server.c and s_client.c. They are too
> complicated______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
