is required by client or server. An application can decide which
certificate chain to present based on arbitrary criteria: for example
supported signature algorithms. Add very simple example to s_server.
This fixes many of the problems and restrictions of the existing client
certificate callback: for example you can now clear existing certificates
and specify the whole chain.
PR: 338
Here's the description, submitted by Gisle Vanem <giva@bgnett.no>:
1. sock_init() renamed to ssl_sock_init() in ./apps/s_socket.c due
to name-clash with Watt-32.
2. rand() renamed to Rand() in ./crypto/bn/divtest.c due to name-clash
with <stdlib.h>
3. Added calls to dbug_init()/sock_init() in some demo programs.
4. Changed cflags/lflags in configure. Watt-32 install root now taken
from $WATT_ROOT.
"unsigned int".
- Remove redundant processing with machine->ssl is NULL.
- Remove compiler warnings about uninitialised 'ctx' (it's not used
uninitialised, but gcc can't see that).
- tidy up some output,
- print a warning when running an SSL server with no cert,
- only log each connect/disconnect if the new "-out_conns" switch is used.
manually declare the include directory /usr/include at the same time
as the macro PROTOTYPES is defined with the value 1. Besides,
/usr/include is the standard include directory anyway, so there's no
need to specify it explicitely.
possible problems.
- New file breakage.c handles (so far) missing functions.
- Get rid of some signed/unsigned/const warnings thanks to solaris-cc
- Add autoconf/automake input files, and helper scripts to populate missing
(but auto-generated) files.
This change adds a configure.in and Makefile.am to build everything using
autoconf, automake, and libtool - and adds "gunk" scripts to generate the
various files those things need (and clean then up again after). This means
that "autogunk.sh" needs to be run first on a system with the autotools,
but the resulting directory should be "configure"able and compilable on
systems without those tools.
sure they are available in opensslconf.h, by giving them names starting
with "OPENSSL_" to avoid conflicts with other packages and by making
sure e_os2.h will cover all platform-specific cases together with
opensslconf.h.
I've checked fairly well that nothing breaks with this (apart from
external software that will adapt if they have used something like
NO_KRB5), but I can't guarantee it completely, so a review of this
change would be a good thing.
well (and is a good demonstration of how encapsulating the SSL in a
memory-based state machine can make it easier to apply to different
situations).
The change implements a new command-line switch "-flipped <0|1>" which, if
set to 1, reverses the usual interpretation of a client and server for SSL
tunneling. Normally, an ssl client (ie. "-server 0") accepts "cleartext"
connections and conducts SSL/TLS over a proxied connection acting as an SSL
client. Likewise, an ssl server (ie. "-server 1") accepts connections and
conducts SSL/TLS (as an SSL server) over them and passes "cleartext" over
the proxied connection. With "-flipped 1", an SSL client (specified with
"-server 0") in fact accepts SSL connections and proxies clear, whereas an
SSL server ("-server 1") accepts clear and proxies SSL. NB: most of this
diff is command-line handling, the actual meat of the change is simply the
line or two that plugs "clean" and "dirty" file descriptors into the item
that holds the state-machine - reverse them and you get the desired
behaviour.
This allows a network server to be an SSL client, and a network client to
be an SSL server. Apart from curiosity value, there's a couple of possibly
interesting applications - SSL/TLS is inherently vulnerable to trivial DoS
attacks, because the SSL server usually has to perform a private key
operation first, even if the client is authenticated. With this scenario,
the network client is the SSL server and performs the first private key
operation, whereas the network server serves as the SSL client. Another
possible application is when client-only authentication is required (ie.
the underlying protocol handles (or doesn't care about) authenticating the
server). Eg. an SSL/TLS version of 'ssh' could be concocted where the
client's signed certificate is used to validate login to a server system -
whether or not the client needs to validate who the server is can be
configured at the client end rather than at the server end (ie. a complete
inversion of what happens in normal SSL/TLS).
NB: This is just an experiment/play-thing, using "-flipped 1" probably
creates something that is interoperable with exactly nothing. :-)
will not support EDH cipher suites). The parameters can either be loaded
from a file (via "-dh_file"), generated by the application on start-up
("-dh_special generate"), or be standard DH parameters (as used in
s_server, etc).
* Seal off some buffer functions so that only the higher-level IO functions
are exposed.
* Using the above change to buffer, add support to tunala for displaying
traffic totals when a tunnel closes. Useful in debugging and analysis -
you get to see the total encrypted traffic versus the total tunneled
traffic. This shows not only how much expansion your data suffers from
SSL (a lot if you send/receive a few bytes at a time), but also the
overhead of SSL handshaking relative to the payload sent through the
tunnel. This is controlled by the "-out_totals" switch to tunala.
* Fix and tweak some bits in the README.
Eg. sample output of "-out_totals" from a tunnel client when tunneling a brief
"telnet" session.
Tunnel closing, traffic stats follow
SSL (network) traffic to/from server; 7305 bytes in, 3475 bytes out
tunnelled data to/from server; 4295 bytes in, 186 bytes out
