Re: [openssl-users] s_server (and maybe s_client) misbehaves with binary data

There have always been special commands making s_client unsuitable for this usage - for example R followed by a newline will renegotiate, and Q will quit. According to the docs these can be disabled by -quiet and -ign_eof though I've never tested that myself. Cheers Rich. On 2 November 2015 at

Re: [openssl-users] s_server (and maybe s_client) misbehaves with binary data

On 2 November 2015 at 15:36, Richard Moore wrote: > > > On 2 November 2015 at 15:33, Jakob Bohm wrote: > >> On 02/11/2015 16:13, Richard Moore wrote: >> >> There have always been special commands making s_client unsuitable for >> this usage - for

[openssl-users] s_server (and maybe s_client) misbehaves with binary data

As with most other "apps" in the openssl binary, the s_server and s_client commands are useful for multiple purposes: 1. As debug tools 2. As a way to do one-off operations without writing any code. 3. As back ends for small programs written in scripting languages that cannot really call

Re: [openssl-users] s_server (and maybe s_client) misbehaves with binary data

On 02/11/2015 16:13, Richard Moore wrote: There have always been special commands making s_client unsuitable for this usage - for example R followed by a newline will renegotiate, and Q will quit. According to the docs these can be disabled by -quiet and -ign_eof though I've never tested that

Re: [openssl-users] s_server (and maybe s_client) misbehaves with binary data

On 2 November 2015 at 15:33, Jakob Bohm wrote: > On 02/11/2015 16:13, Richard Moore wrote: > > There have always been special commands making s_client unsuitable for > this usage - for example R followed by a newline will renegotiate, and Q > will quit. According to the

Re: [openssl-users] s_server (and maybe s_client) misbehaves with binary data

> It would thus be useful for s_server (and if applicable > s_client) to accept the "-binary" option (already provided by the cms/smime > commands), to turn off this behavior and provide a clean data pass through > to/from the other end. This is a good idea, thanks!