Re: FTP-SSL from z/OS client to Linux
I have to remember to look at the IBM-MAIN list rather than the archives. Thanks, everybody, for your help. I'm glad to have another means of tracing for the (shudder) next time around. Steve Steve Pryor DTS Software, LLC st...@dtssoftware.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP-SSL from z/OS client to Linux
Well, after considerable struggle involving setting up a completely new FTP server and experimenting with virtually every possible setting on both sides, it seems that this can occur if the TLS level used by the z/OS client isn't supported by the Linux ProFTPD server. Some settings rejiggering fixes it. But talk about a misleading message... Steve Steve Pryor DTS Software, LLC st...@dtssoftware.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP-SSL from z/OS client to Linux
Re: "The format is gsktrace > gskfile.trc > gsk.out " John is right--it's just gsktrace gskfile.trc > gsk.out Sorry guys. Wendell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP-SSL from z/OS client to Linux
I've always just did: gskstrace gsktrace.trc > gsktrace.txt But I do generally use the gsktrace to try and figure out issues with ssl negotiation. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP-SSL from z/OS client to Linux
It looks to me like "550 T" is the start of the FTP message type 550, Requested action not taken. Doesn't seem like something the server should be sending in the middle of a CLIENT-HELLO negotiation. But I'm no expert. Is it safe to assume that non-z/OS clients are successfully connecting to this server? From: IBM Mainframe Discussion List on behalf of John S. Giltner, Jr. Sent: Monday, March 1, 2021 4:49 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: FTP-SSL from z/OS client to Linux Well in the data you sent out on the client hello I only see two x'35', on is at byte 3,which is part of the length field. The other is at 2C which really starts at 2B which is cipher x'0035' In your 1st post the trace showed part of a error message that I think you were receiving which as "550 T". Were you receiving that message and if so what was the full message. You know it just hit me that "5" in HEX (ASCII) is x'35'. Maybe the client is sending the error message that starts "550 T" and your side it interpreting that error message as part of the TLS negotiation and it has no idea what a x'35' is. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP-SSL from z/OS client to Linux
Well in the data you sent out on the client hello I only see two x'35', on is at byte 3,which is part of the length field. The other is at 2C which really starts at 2B which is cipher x'0035' In your 1st post the trace showed part of a error message that I think you were receiving which as "550 T". Were you receiving that message and if so what was the full message. You know it just hit me that "5" in HEX (ASCII) is x'35'. Maybe the client is sending the error message that starts "550 T" and your side it interpreting that error message as part of the TLS negotiation and it has no idea what a x'35' is. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP-SSL from z/OS client to Linux
Hi Steve.
I've found the SSL trace information written into a USS file to be somewhat
easier to use. You can turn on GSK_TRACE flags and specify a trace file using
STDENV similar to the example below IF you specify the
PARM=('ENVAR("_CEE_ENVFILE_S=DD:STDENV") (the _S is crucial or the DD * input
won't work):
//FTPS EXEC PGM=FTP,REGION=4M,
// PARM=('ENVAR("_CEE_ENVFILE_S=DD:STDENV")/ftp.linuxsite.com 21 -e')
//STDENV DD *
GSK_PROTOCOL_TLSV1_2=ON
GSK_TRACE=0x
GSK_TRACE_FILE=/tmp/gskfile.trc
//*
//SYSFTPD DD *,SYMBOLS=(JCLONLY)
CLIENTERRCODES EXTENDED
EPSV4 TRUE
EXTENSIONSAUTH_TLS
FWFRIENDLYTRUE
KEYRING /
PASSIVEIGNOREADDR TRUE
SECUREIMPLICITZOSFALSE
SECURE_FTPREQUIRED
SECURE_MECHANISM TLS
SECURE_DATACONN PRIVATE
SECURE_CTRLCONN PRIVATE
SECURE_HOSTNAMEREQUIRED
TLSMECHANISM FTP
TLSRFCLEVEL RFC4217
//* TRACE
//* DEBUG SEC
//* You can also add other debugging or trace options to SYSFTPD
//OUTPUT DD SYSOUT=*
//INPUTDD *,SYMBOLS=(JCLONLY)
ftpuid
ftppwd
etc
QUIT
//*
The above step doesn't require AT-TLS changes or changes to your FTPDATA
datasets, but I don't think the changes you've alreayd made there will prevent
you from specifying the GSK options via STDENV.
With the GSK_TRACE flags set, the SSL information will be written to the file
you specify in GSK_TRACE_FILE. There is a USS utility named gsktrace that you
will need to read the trace file and interpret it into something you can read.
The format is gsktrace > gskfile.trc > gsk.out
The gsktrace output will be pretty detailed, but you can usually find an error
of some kind.
These manuals, especially the first one, will probably help:
SC14-7495-30 Cryptographic Services System Secure Sockets Layer Programming
SC27-3651-30 IP Configuration Reference
GC27-3652-30 IP Diagnosis Guide
Wendell
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FTP-SSL from z/OS client to Linux
I thought perhaps that was it, since I didn't (previously) have the entire CA certificate chain on the keyring and I don't think the certificate was being presented. But I've corrected that and it seems to be using the correct certificate according to the trace below. But I'm still getting the same ' Content type 53 is not supported' error. Perhaps I'm not understanding something in the trace? Steve Pryor DTS Software, LLC st...@dtssoftware.com S0W1 MESSAGE 0001 03:04:16.329604 SSL_ENTRY Job SJP1 Process 050102AA Thread 0001 gsk_get_default_label Handle 1FCA4AF0 S0W1 MESSAGE 0002 03:04:16.330203 SSL_EXIT Job SJP1 Process 050102AA Thread 0001 gsk_get_default_label Exit status (0) Default label 'ExaVault FTP Server' S0W1 MESSAGE 0008 03:04:16.330770 SSL_INFO Job SJP1 Process 050102AA Thread 0001 gsk_secure_socket_init Using client certificate 'ExaVault FTP Server' S0W1 MESSAGE 0008 03:04:16.331372 SSL_INFO Job SJP1 Process 050102AA Thread 0001 gsk_query_security_level Security level 0x0007 S0W1 MESSAGE 0008 03:04:16.331945 SSL_INFO Job SJP1 Process 050102AA Thread 0001 edit_ciphers Initial SSL V2 cipher specs: 34 S0W1 MESSAGE 0008 03:04:16.332537 SSL_INFO Job SJP1 Process 050102AA Thread 0001 edit_ciphers SSL V2 cipher specs: 34 S0W1 MESSAGE 0008 03:04:16.38 SSL_INFO Job SJP1 Process 050102AA Thread 0001 edit_ciphers Initial SSL V3 2-character cipher specs: S0W1 MESSAGE 0008 03:04:16.333903 SSL_INFO Job SJP1 Process 050102AA Thread 0001 edit_ciphers 3538392F3233 S0W1 MESSAGE 0008 03:04:16.335928 SSL_INFO Job SJP1 Process 050102AA Thread 0001 edit_ciphers SSL V3 cipher specs: 3538392F3233 S0W1 MESSAGE 0008 03:04:16.336795 SSL_INFO Job SJP1 Process 050102AA Thread 0001 default_setsocketoptions FIONBIO turned off for socket 1 S0W1 MESSAGE 0008 03:04:16.337704 SSL_INFO Job SJP1 Process 050102AA Thread 0001 default_setsocketoptions TCP_NODELAY set for socket 1 S0W1 MESSAGE 0008 03:04:16.338294 SSL_INFO Job SJP1 Process 050102AA Thread 0001 gsk_perform_v3_client_handshake Performing SSL V3 client handshake with 67.208.93.232.21. S0W1 MESSAGE 0001 03:04:16.338944 SSL_ENTRY Job SJP1 Process 050102AA Thread 0001 crypto_generate_random_bytes Length 32 S0W1 MESSAGE 0002 03:04:16.339510 SSL_EXIT Job SJP1 Process 050102AA Thread 0001 crypto_generate_random_bytes Exit status (0) S0W1 MESSAGE
Re: FTP-SSL from z/OS client to Linux
It's been awhile, but it looks like the Linux server is requesting your SSL certificate as a client, but is not passing a list of CA's that it trusts. When the server requests the client to send it's client cert, it supposed to tell the client what CA's is trusts. Some clients will ignore the fact that the server did not do this, and just send the default cert it has on it's keyring. The IBM client will not. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FTP-SSL from z/OS client to Linux
I'm sure I must be missing something here. I'm trying to FTPS from the z/OS 2.2 client to a linux system but failing the handshake. The FTP session indicates: SC2852 sendCmd: entered EZA1701I >>> AUTH TLS SC3315 getReply: entered SC4502 getNextReply: entered with waitForData = TRUE 234 AUTH TLS successful SC4194 getLastReply: entered FC1000 authServer: entered FC1013 authServer: secure_socket_open() SC4358 getFNDELAY: entered FC1085 HSNOTIFY rc: 0 FC1090 authServer: secure_socket_init() FU0941 secureWrite: entered FU0841 secureRead: entered SC4393 setFNDELAY: entered FC1103 authServer: secure_socket_init failed with rc = 410 (SSL message format is incorrect) FC1579 endSecureConn: entered EZA2897I Authentication negotiation failed FC1611 endSecureEnv: entered SC4242 inSession: entered CZ0731 SETCEC code = 17 EZA2898I Unable to successfully negotiate required authentication It wasn't quite clear what the 410 indicates, so I got an SSL trace: S0W1 MESSAGE 0008 01:49:34.380195 SSL_INFO Job SJP1 Process 0501028D Thread 0001 send_v3_client_hello Sent V3 CLIENT-HELLO message S0W1 DUMP 0020 01:49:34.380878 SSL_ASCII_DUMP Job SJP1 Process 0501028D Thread 0001 send_v3_client_hello V3 CLIENT-HELLO message : 0135 03016038 53AEFEE4 0E3FA5C1 *...5...8S?..* 0010: 738D1174 97B11A6C 48D50A52 9ED8C9F6 *s..t...lH..R* 0020: 19AF4C56 C20D 0E00FF00 35003800 *..LV5.8.* 0030: 39002F00 32003301 00 *9./.2.3.. * S0W1 MESSAGE 0008 01:49:34.381607 SSL_INFO Job SJP1 Process 0501028D Thread 0001 gsk_write_v3_record Calling write routine for 62 bytes S0W1 MESSAGE 0008 01:49:34.383039 SSL_INFO Job SJP1 Process 0501028D Thread 0001 gsk_write_v3_record 62 bytes written S0W1 MESSAGE 0008 01:49:34.383763 SSL_INFO Job SJP1 Process 0501028D Thread 0001 gsk_read_v3_record Calling read routine for 5 bytes S0W1 MESSAGE 0008 01:49:34.467030 SSL_INFO Job SJP1 Process 0501028D Thread 0001 gsk_read_v3_record 5 bytes received S0W1 MESSAGE 0004 01:49:34.467943 SSL_ERROR Job SJP1 Process 0501028D Thread 0001 gsk_read_v3_record Content Type 53 is not supported S0W1 DUMP 0020 01:49:34.468808 SSL_ASCII_DUMP Job SJP1 Process 0501028D Thread 0001 gsk_read_v3_record SSL record header : 35353020 54 *550 T * S0W1 MESSAGE 0004 01:49:34.469667 SSL_ERROR Job SJP1
