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