Convince openssl s_client to work non-interactively

[dym...@gmail.com]

Argh! How do I convince openssl s_client to read input from somewhere other than the terminal? All the usual tricks don't work (e.g. define/user sys$input, redirection via PIPE command).

Consider the following to quickly check if the cert chain for an OSU DECthreads HTTPServer is actually configured correctly:

$ openssl s_client -quiet -no_ign_eof -connect localhost:443

Now I have to wait for that to connect, then enter "Q" on a line by itself to make it disconnect. It doesn't matter if I change the command to one of the following three alternatives. I get the same result each time: it always reads from the terminal instead of the redirected I/O stream.

$ pipe echo "Q" | openssl s_client -quiet -no_ign_eof -connect localhost:443

$ pipe openssl s_client -quiet -no_ign_eof -connect localhost:443 < NL:

$ define/user sys$input nl:
$ openssl s_client -quiet -no_ign_eof -connect localhost:443 < NL:

On another OS, I could do something like:

$ openssl s_client -quiet -no_ign_eof -connect x.y.z:443 < /dev/null
depth=0 C = CA, OU = Domain Control Validated, CN = x.y.z
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = CA, OU = Domain Control Validated, CN = x.y.z
verify error:num=21:unable to verify the first certificate
verify return:1
DONE

Or alternatively:

$ echo Q | openssl s_client -quiet -connect x.y.z:443
...

It happily accepts I/O redirection, obeys the EOF, and quits after showing me what I wanted to see. Perfect for being able to script the test and run against a bunch of sites. I only want to be able to do the same on VMS.

Thanks,
Ben

[dym...@gmail.com]

On Tuesday, September 26, 2017 at 11:19:26 AM UTC-3, dym...@gmail.com wrote:
> $ define/user sys$input nl:
> $ openssl s_client -quiet -no_ign_eof -connect localhost:443 < NL:

Oops. I clearly meant this instead:

$ define/user sys$input nl:
$ openssl s_client -quiet -no_ign_eof -connect localhost:443

I retested to make sure. No dice. openssl s_client is still waiting for terminal input and not terminating on hitting the EOF.

[abrsvc]

Have you tried redirecting sys$input to sys$command within a 1 line command procedure? That should retain the "terminal" characteristics without requiring any input from the user.

Dan

[dym...@gmail.com]

On Tuesday, September 26, 2017 at 12:28:58 PM UTC-3, abrsvc wrote:
> Have you tried redirecting sys$input to sys$command within a 1 line command procedure? That should retain the "terminal" characteristics without requiring any input from the user.

Yes. That's one of the things I tried. It's all variations on the same theme, so I didn't mention everything. :)

Example code test.com:

$ define/user sys$input sys$command
$ openssl s_client -quiet -no_ign_eof -connect 'p1':443
$ deck
Q
$ eod

Usage (where x.y.z is a host with https on port 443)

$ @test x.y.z

Still ignores the data provided in deck / eod, and prompts interactively. Here's some more test code, run in batch instead (just had to define the openssl command first, and quiet the output of that, since it turns on verify inside ssl1$utils.com):

$ @ssl1$com:ssl1$utils/out=nl:
$ openssl s_client -quiet -no_ign_eof -connect 'p1':443
$ deck
Q
$ eod

Here's my test execution:

$ submit test.com/noprint/param=google.com

Here's an excerpt from the log showing output/errors from the command:

$ openssl s_client -quiet -no_ign_eof -connect GOOGLE.COM:443
26-Sep-2017 12:49:12 [2026B311] TerminalSocket: SYS$QIO () - 000000AC
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA

verify error:num=20:unable to get local issuer certificate

bad select 38
%DCL-W-SKPDAT, image data (records not beginning with "$") ignored
BG job terminated at 26-SEP-2017 12:49:12.42

Tell you anything about the implementation and why it is so bloody-minded about using the terminal? I certainly wasn't expecting it to use SYS$QIO for such a simple little utility ...

Ben

[Bob Koehler]

In article <b7ffc35c-b9c8-4b75...@googlegroups.com>, dym...@gmail.com writes:
> Argh! How do I convince openssl s_client to read input from somewhere other=
> than the terminal? All the usual tricks don't work (e.g. define/user sys$i=
> nput, redirection via PIPE command).
>

Have you tried redefining sys$command?

If that fails, I'd start by looking at the open source for openssl to
see if it's using stdout or /dev/tty, or what.

[Craig A. Berry]

It's doing a $QIO to SYS$COMMAND, but it's got a pair of sockets shimmed in front, presumably to be able to play nice with the select() in the top-level code. As far as I can see, there is no provision in the VMS-specific code to detect an EOF condition and propagate it to the mainline code. But do check for yourself. See:

apps/vms_term_sock.c: TerminalSocket
apps/apps.c: fileno_stdin
apps/apps.c: raw_read_stdin

at:

<https://github.com/openssl/openssl>

[Arne Vajhøj]

SYS$QIO(W) is device dependent, so all attempts to
assign/define from terminal to a file will fail.

Usual (?) workaround is to run the problematic
program in a separate process attached to
a pseudo terminal (PTD$ routines) and get the file input
send over to that.

Some pre-baked tools for that exist. Including
some old and not particular pretty code of mine.

Arne

[Craig A. Berry]

Wouldn't it be easier to:

1.) Detect whether SYS$COMMAND is a file or device.
2.) If device, call $ASSIGN, else call $OPEN.
3.) Use channel from #2 for $QIO.

?

The code in question does not check the IOSB status in its completion
routine, so it has other problems than redirection. I think that's why
defining SYS$COMMAND as NL: doesn't work. NL: is a device so should work
just as well as a terminal, and I believe a read to it should trigger
SS$_ENDOFFILE. However, the completion routine just blithely queues up
another read and never stops until image run-down.

All this nonsense because select() in the CRTL only works on sockets.

[Arne Vajhøj]

On 9/26/2017 8:18 PM, Craig A. Berry wrote:
> On 9/26/17 2:38 PM, Arne Vajhøj wrote:
>> On 9/26/2017 2:45 PM, Craig A. Berry wrote:
>>> It's doing a $QIO to SYS$COMMAND, but it's got a pair of sockets
>>> shimmed in front, presumably to be able to play nice with the select()
>>> in the top-level code. As far as I can see, there is no provision in the
>>> VMS-specific code to detect an EOF condition and propagate it to the
>>> mainline code. But do check for yourself. See:
>>>
>>> apps/vms_term_sock.c: TerminalSocket
>>> apps/apps.c: fileno_stdin
>>> apps/apps.c: raw_read_stdin
>>>
>>> at:
>>>
>>> <https://github.com/openssl/openssl>
>>
>> SYS$QIO(W) is device dependent, so all attempts to
>> assign/define from terminal to a file will fail.
>>
>> Usual (?) workaround is to run the problematic
>> program in a separate process attached to
>> a pseudo terminal (PTD$ routines) and get the file input
>> send over to that.
>
> Wouldn't it be easier to:
>
> 1.) Detect whether SYS$COMMAND is a file or device.
> 2.) If device, call $ASSIGN, else call $OPEN.
> 3.) Use channel from #2 for $QIO.
>
> ?

The solution I outlined was for no changes to openssl_s.

If willing to change that, then that is of course also
a possible.

But more work is needed than described above.

SYS$OPEN with FAB$M_UFO will give the channel so
SYS$QIOW IO$_ACCESS with FIB block is not needed,
but SYS$QIOW IO$_READVBLK read blocks not lines,
which I assume will not work well without more
changes.

Arne

[dym...@gmail.com]

On Tuesday, September 26, 2017 at 9:49:54 PM UTC-3, Arne Vajhøj wrote:
> The solution I outlined was for no changes to openssl_s.
>
> If willing to change that, then that is of course also
> a possible.
>
> But more work is needed than described above.
>
> SYS$OPEN with FAB$M_UFO will give the channel so
> SYS$QIOW IO$_ACCESS with FIB block is not needed,
> but SYS$QIOW IO$_READVBLK read blocks not lines,
> which I assume will not work well without more
> changes.

Yeah. Looks like the dependency on SYS$QIOW has been there since time eternal (at least since SSLeay).

Not particularly interested in hacks around it. I do think fixing the code is the best way, but don't have the time to invest in it.

OK, since scripting openssl s_client to check for valid certs seems to be a non-starter, I'll be looking at running my automation for cert checking on another platform. Too bad, though, because occasionally, I have very limited connectivity to the systems I want to test, e.g. port 443 isn't open (yet), etc. But for those corner cases, running the tool interactively is acceptable.

Thanks, everyone.

Ben

[Jim]

Any chance that cURL will do it for you?

$ curl "-vI" https://localhost./

[GerMarsh]

If you are just checking the cert chain, you could use something like this where P1 is the "user" cert and P2 the CA cert...

$ openssl verify "-CAfile" 'P2' "-purpose" "sslserver" 'P1'

[Bob Koehler]

In article <8b674bf9-ba22-4201...@googlegroups.com>, "Craig A. Berry" <craig....@gmail.com> writes:
>
> It's doing a $QIO to SYS$COMMAND, but it's got a pair of sockets shimmed in=
> front, presumably to be able to play nice with the select() in the top-lev=
> el code. As far as I can see, there is no provision in the VMS-specific co=
> de to detect an EOF condition and propagate it to the mainline code. But d=
> o check for yourself. See:

OK, so that suggests redirecting sys$command is a better approach
than redirecting sys$input. (Or as often is done, redirecting both
should work).

The usual cheap way to detect EOF from a socket is a 0 return length.

[Arne Vajhøj]

On 9/27/2017 7:04 AM, dym...@gmail.com wrote:
> Not particularly interested in hacks around it. I do think fixing the
> code is the best way, but don't have the time to invest in it.
>
> OK, since scripting openssl s_client to check for valid certs seems
> to be a non-starter,

As I said then all you need is the right tool.

Such tools exist.

If nothing else then my old 1996 toy.

Demo:

$ typ z.in
eve z.z<RET>
A<RET>
BB<RET>
CCC<CTRLZ>
$ mcr []ptd z.in z.out
Username: arne
Password: therealpasswordissecret
$ typ z.z
A
BB
CCC

Arne