[Info-vax] "bad select 38" (OpenSSL on VMS)

Tue Sep 20 07:37:17 EDT 2016

Den tisdag 20 september 2016 kl. 03:01:22 UTC+2 skrev RobertsonEricW:
> On Monday, September 19, 2016 at 7:58:23 PM UTC-4, Richard Levitte wrote:
> > > So if I run s_client through popen() or otherwise through a pipe such as 
> > > being launched by GNV Bash it will fail?
> > 
> > Probably, but also probably just because it assigns a channel to SYS$COMMAND.  When calling a program with popen or through a pipe launched by GNV Bash, is there a SYS$INPUT?  What happens if that's used instead of SYS$COMMAND?
> > 
> > Gods, it's been way too long since I did this kind of stuff...
> > 
> > Cheers,
> > Richard
> 
> Richard, you are correct. It does not work correctly with GNV Bash. some extraneous output appears in the piped output as a result of using SYS$COMMAND:
> 
> 
> openssl s_client  -connect evn.crm.em2.oraclecloud.com:443
> CONNECTED(00000006)
> depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
> verify error:num=20:unable to get local issuer certificate
> ---
> Certificate chain
>  0 s:/C=US/ST=CA/L=Redwood Shores/O=Oracle Corporation/OU=Content Management Services IT/CN=*.crm.em2.oraclecloud.com
>    i:/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2
>  1 s:/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2
>    i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
>  2 s:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
>    i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
> ---
> Server certificate
> -----BEGIN CERTIFICATE-----
> MIIFozCCBIugAwIBAgIUJqSsQcjAxLRBtHzCHsF449Qe14QwDQYJKoZIhvcNAQEL
> BQAwgY0xCzAJBgNVBAYTAk5MMRIwEAYDVQQHEwlBbXN0ZXJkYW0xJTAjBgNVBAoT
> HFZlcml6b24gRW50ZXJwcmlzZSBTb2x1dGlvbnMxEzARBgNVBAsTCkN5YmVydHJ1
> c3QxLjAsBgNVBAMTJVZlcml6b24gQWthbWFpIFN1cmVTZXJ2ZXIgQ0EgRzE0LVNI
> QTIwHhcNMTYwNTAzMDk0MTM5WhcNMTcwNTAzMDk0MTM5WjCBnTELMAkGA1UEBhMC
> VVMxCzAJBgNVBAgTAkNBMRcwFQYDVQQHEw5SZWR3b29kIFNob3JlczEbMBkGA1UE
> ChMST3JhY2xlIENvcnBvcmF0aW9uMScwJQYDVQQLEx5Db250ZW50IE1hbmFnZW1l
> bnQgU2VydmljZXMgSVQxIjAgBgNVBAMMGSouY3JtLmVtMi5vcmFjbGVjbG91ZC5j
> b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDTNjum0DDy9YS1bqsy
> rSA6kdN1lY5fkyFwpirY4ci/M5Gkd1kMdMqT664bscQ1xUhdoAf7cfTLHMhZ9m1B
> PPlAoPS4AEDdGwc3ZHIB53PsSsvxWPJ3m6wWvhKB1M6LaX0/gQvmiQgF0BoNN9Km
> G46tWaCrVWX3ytCFJ/q43c4RVMqpNNPs9wb1+mzMJsiMyFjKNUXxPlhEmOvuNy8e
> NqTbOd9MpTLwfan7eUehwhFbQ3ejvKCEodR3D7sxrwg0V6T3kZ4UMAkbUAw8yG9E
> EVhoL1vYotgodKnWoLkNkapf/Hk/czt+ocWUsNnyM2RtS1187KyfROC6Bsg9L6y1
> IgV1AgMBAAGjggHnMIIB4zAMBgNVHRMBAf8EAjAAMEwGA1UdIARFMEMwQQYJKwYB
> BAGxPgEyMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vc2VjdXJlLm9tbmlyb290LmNv
> bS9yZXBvc2l0b3J5MIGvBggrBgEFBQcBAQSBojCBnzAtBggrBgEFBQcwAYYhaHR0
> cDovL3Zhc3NnMTQyLm9jc3Aub21uaXJvb3QuY29tMDYGCCsGAQUFBzAChipodHRw
> czovL2NhY2VydC5hLm9tbmlyb290LmNvbS92YXNzZzE0Mi5jcnQwNgYIKwYBBQUH
> MAKGKmh0dHBzOi8vY2FjZXJ0LmEub21uaXJvb3QuY29tL3Zhc3NnMTQyLmRlcjAk
> BgNVHREEHTAbghkqLmNybS5lbTIub3JhY2xlY2xvdWQuY29tMA4GA1UdDwEB/wQE
> AwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwHwYDVR0jBBgwFoAU
> +L36r3N3xscb+UtNEafRM6+vchEwPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDovL3Zh
> c3NnMTQyLmNybC5vbW5pcm9vdC5jb20vdmFzc2cxNDIuY3JsMB0GA1UdDgQWBBQ5
> 2ttvTVNcmHbgTUnjk9+qE//QWjANBgkqhkiG9w0BAQsFAAOCAQEARUSJX5f2UgHr
> /WVwiEB5gbONg79MIduBjnKQDy1kREl1LdCvQIlqBP1BQNwe650GpQevnKwY/BnI
> rC8nSZWVUcS6VCQrLbZ6+dnR/+kyzPiiL4uTfbvhjBguKD5wl/9+c98m/aYbaExy
> tRoDofxqJj5Sx4eYKnWdCeZpUD7ZrS+rymqxCrfOPERcGeht+YnUGvsBTdgXxjYB
> nW5xh2zjX9ElfLnECllHnjlMyVedLM9uzWxvfGsFKFw0Wda0b+4WAEzaaMar3uLn
> NI/lOCT3wA6IXPaOa0O/Qfs8FoMHE+xWdyeMpkRkUBigjzJYudW92BUKv0ItG1BK
> IeMWytKjUA==
> -----END CERTIFICATE-----
> subject=/C=US/ST=CA/L=Redwood Shores/O=Oracle Corporation/OU=Content Management Services IT/CN=*.crm.em2.oraclecloud.com
> issuer=/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2
> ---
> No client certificate CA names sent
> Peer signing digest: SHA512
> Server Temp Key: ECDH, P-256, 256 bits
> ---
> SSL handshake has read 4495 bytes and written 326 bytes
> Verification error: unable to get local issuer certificate
> ---
> New, SSLv3, Cipher is ECDHE-RSA-AES256-SHA
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
>     Protocol  : TLSv1.2
>     Cipher    : ECDHE-RSA-AES256-SHA
>     Session-ID: 8FF534B3E4E16E9579815E8CAEC02B1002A504129DC351D22A47794C51C3FE4A
>     Session-ID-ctx:
>     Master-Key: 41413D09E6D1E5E44FFFC803388C62BC548CBC2C8B5BF373CC7015E2318AD6424C16E20B1C87DC4980517E0126D6D407
>     PSK identity: None
>     PSK identity hint: None
>     SRP username: None
>     TLS session ticket lifetime hint: 7200 (seconds)
>     TLS session ticket:
>     0000 - 3f df d4 3e 8d f5 43 ee-55 61 49 4c 39 7e 94 ed   ?..>..C.UaIL9~..
>     0010 - c7 c5 f8 d7 a5 ee 47 c6-b3 0d 75 47 20 d4 96 e6   ......G...uG ...
>     0020 - a8 0c 63 3e 0c c7 92 32-c2 fb 29 c7 a4 fc a7 22   ..c>...2..)...."
>     0030 - f0 ad 61 14 ee 3b 30 2f-41 c4 11 6e 79 3b 8c f0   ..a..;0/A..ny;..
>     0040 - 98 72 3f 5b db 5c 7d c8-c0 f2 47 74 4b 69 a6 6a   .r?[.\}...GtKi.j
>     0050 - 71 a6 80 22 3e 7b 04 10-ee 84 be c0 c3 c5 8a 4d   q..">{.........M
>     0060 - 8e c7 b5 8d bb 12 37 8f-d9 6f f9 37 6d af 8b 20   ......7..o.7m..
>     0070 - 3c b9 98 bf 9c ce f8 11-9e b6 aa 23 61 18 2d 9b   <..........#a.-.
>     0080 - 00 e3 aa 9f 70 00 fb 1f-5f 9c a8 ff 56 c7 47 76   ....p..._...V.Gv
>     0090 - c9 a2 bc 83 12 d2 04 17-b5 97 a0 b0 4c 98 d3 76   ............L..v
> 
>     Start Time: 1474332985
>     Timeout   : 7200 (sec)
>     Verify return code: 20 (unable to get local issuer certificate)
>     Extended master secret: no
> ---
> closed
> ROBERTSON at srvr1:~/openssl-1_1_0 > openssl s_client  -connect evn.crm.em2.oraclecloud.com:443 | grep "Master-Key:"
> depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
> verify error:num=20:unable to get local issuer certificate
>     Master-Key: E24EAC787E42548EB97E002DED67AFB98A9D01807BC4297B66D4348B86FE67477E916CDC9ED5CB3F3FEF0649FDC32A94
> ROBERTSON at srvr1:~/openssl-1_1_0 >

That's a different issue.  'openssl s_client' outputs to stdout using normal means.  Why grep outputs several lines is a good question, but hopefully not an OpenSSL issue (if it is, I sure would like to know!).

The issue we're talking about here is about input to s_client.  What happens if you, for example, try this in GNV bash?

    (echo "HEAD / HTTP/1.0"; echo "Host: www.openssl.org"; echo) | openssl s_client -connect www.openssl.org:443

I'm sure it's going to fail...  However, if you go into apps/vms_term_sock.c and change "SYS$COMMAND" to "SYS$INPUT", rebuild OpenSSL and try again, will you get a different behaviour?

(quite frankly, I don't know at all what to expect.  I just tried the above command on Linux, and the result was frankly disappointing...  the input was simply ignored.  I'll have to check why)

Cheers,
Richard