On 05/06/2014 10:34 PM, Geoff Thorpe wrote:
> The "-unix <path>" argument allows s_server and s_client to use a unix
> domain socket in the filesystem instead of IPv4 ("-connect", "-port",
> "-accept", etc). If s_server exits gracefully, such as when "-naccept"
> is used and the requested number of SSL/TLS connections have occurred,
> then the domain socket file is removed. On ctrl-C, it is likely that
> the stale socket file will be left over, such that s_server would
> normally fail to restart with the same arguments. For this reason,
> s_server also supports an "-unlink" option, which will clean up any
> stale socket file before starting.
>
> If you have any reason to want encrypted IPC within an O/S instance,
> this concept might come in handy. Otherwise it just demonstrates that
> there is nothing about SSL/TLS that limits it to TCP/IP in any way.
>
> (There might also be benchmarking and profiling use in this path, as
> unix domain sockets are much lower overhead than connecting over local
> IP addresses).
>
> Signed-off-by: Geoff Thorpe <ge...@openssl.org>
> ---
>
> This is just a request for comments. Anyone think this is worth
> putting in? Eg.
I think having unix-domain sockets available in s_client/s_server is a
great idea.
Heading in this direction of generic abstractions, it could also be nice
to enable s_client and s_server just use an arbitrary file descriptor.
This would enable, for example, a privileged process to open a
restricted port, drop privileges, and then exec s_server with the
appropriate argument for what file descriptor to use.
--dkg
signature.asc
Description: OpenPGP digital signature
