Re: SMPE Receive Order post May 1st
On 5/12/2021 1:51 PM, Dave Jousma wrote: We are still broke since the 5/1 TLSv1.2 cutover on your end. We are assuming its a problem on our end. We do have ticket open with ATTLS support group at IBM. We do have HTTPS service working, but continue to pursue, as not sure if TESTCASE.boulder.ibm.com has same TLS requirement (havent tried that yet). Glad to hear you're using HTTPS for your software downloads. Regarding the TESTCASE servers, I'm told TLS 1.2 is NOT REQUIRED. It is enabled, but not required at this time. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE Receive Order post May 1st
On 5/13/2021 8:54 AM, Michael Babcock wrote: Oh, and the AT-TLS error was 402. BPXF024I (STSYSLOG) May 12 20:26:41 X/TCPIP TCPIP 256 TTLS[280]: 15:26:41 TCPIP EZD1286I TTLS Error GRPID: 0017 ENVID: 008B CONNID: C6AD LOCAL: xxx.xxx.xxx.xxx..7199 REMOTE: 170.225.15.117..21 JOBNAME: RECV USERID: RULE: Secure_FTP_Client_9921 RC: 402 Initial Handshake 0052FDA4BC90 Which is "402: An SSL cipher suite could not be agreed upon between the client and server. " Sorry you're still having trouble Michael, but this is now beyond my level of expertise. I suggest you contact IBM Support if you have not done so already. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE Receive Order post May 1st
Oh, and the AT-TLS error was 402. BPXF024I (STSYSLOG) May 12 20:26:41 X/TCPIP TCPIP 256 TTLS[280]: 15:26:41 TCPIP EZD1286I TTLS Error GRPID: 0017 ENVID: 008B CONNID: C6AD LOCAL: xxx.xxx.xxx.xxx..7199 REMOTE: 170.225.15.117..21 JOBNAME: RECV USERID: RULE: Secure_FTP_Client_9921 RC: 402 Initial Handshake 0052FDA4BC90 Which is "402: An SSL cipher suite could not be agreed upon between the client and server. " On 5/12/2021 3:47 PM, Michael Babcock wrote: Kurt, Unless I'm doing something wrong, my testing does not bear that out. The only cipher in the list was: # Allow only AES ciphers V3CipherSuites TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 PAGENT was refreshed. Here’s the DEBUG ALL output. SC0588 initConnection: Calling getaddrinfo() with deliverycb-bld.dhe.ibm.com SC0627 initConnection: getaddrinfo() returned. SC0798 initNamedConnection: entered SC0960 initIPv4Connection: entered CY3336 access_via_socks_server: entered Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21. SC3362 getReply: entered SC4549 getNextReply: entered with waitForData = TRUE 220-IBM's internal systems must only be used for conducting IBM's SC4549 getNextReply: entered with waitForData = TRUE 220-business or for purposes authorized by IBM management. SC4549 getNextReply: entered with waitForData = TRUE 220- SC4549 getNextReply: entered with waitForData = TRUE 220-Use is subject to audit at any time by IBM management. SC4549 getNextReply: entered with waitForData = TRUE 220- SC4549 getNextReply: entered with waitForData = TRUE 220- SC4549 getNextReply: entered with waitForData = TRUE 220 dhebpcb01 secure FTP server ready. SC4241 getLastReply: entered SC4241 getLastReply: entered SC4241 getLastReply: entered SC7601 update_cntl_appldata: entered GU5351 ftpSetApplData: entered FC0259 ftpAuth: entered FC0294 ftpAuth: security values: mech=TLS, tlsmech=ATTLS, tlsreuse=N, sFTP=R, sCC=P, sDC=P FC2895 ftpAuthAttls: entered FC2971 ftpAuthAttls: AT-TLS policy set as application controlled. FU2410 printAttlsPolicyNames: entered FU2420 TTLSRule: Secure_FTP_Client_9921 FU2426 TTLSGroupAction: grp_Production FU2432 TTLSEnvironmentAction: Secure_FTP_Client_Env_Ext FU2439 TTLSConnectionACtion: Secure_FTP_Conn_Ext SC2899 sendCmd: entered >>> AUTH TLS SC3362 getReply: entered SC4549 getNextReply: entered with waitForData = TRUE 234 SSLv23/TLSv1 SC4241 getLastReply: entered FC3101 authServerAttls: entered SC4405 getFNDELAY: entered SC4440 setFNDELAY: entered FC3140 authServerAttls: Start Handshake FC3149 authServerAttls: ioctl() failed on SIOCTTLSCTL - EDC8121I Connection reset. (errno2=0x77A9733D) SC4440 setFNDELAY: entered Authentication negotiation failed SC4289 inSession: entered *** Control connection with dispby-117.boulder.ibm.com dies. SC4332 SETCEC code = 10 SC3610 endSession: entered (sn=1BE35B18) SC2776 dataClose: entered SC3693 endSession: recv() failed - EDC8121I Connection reset. (errno2=0x76650446) CZ1459 ftpClose: entered SC4289 inSession: entered SC4367 setLoggedIn: entered You must first issue the 'OPEN' command The rest of the ciphers were re-added and PAGENT refreshed. # Allow only AES ciphers V3CipherSuites TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 V3CipherSuites TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 V3CipherSuites TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA V3CipherSuites TLS_RSA_WITH_AES_256_GCM_SHA384 V3CipherSuites TLS_RSA_WITH_AES_256_CBC_SHA256 V3CipherSuites TLS_RSA_WITH_AES_256_CBC_SHA V3CipherSuites TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 V3CipherSuites TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 V3CipherSuites TLS_ECDH_RSA_WITH_AES_256_CBC_SHA V3CipherSuites TLS_DHE_RSA_WITH_AES_256_CBC_SHA V3CipherSuites TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 V3CipherSuites TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 V3CipherSuites TLS_DH_RSA_WITH_AES_256_CBC_SHA V3CipherSuites TLS_DH_RSA_WITH_AES_256_CBC_SHA256 V3CipherSuites TLS_DH_RSA_WITH_AES_256_GCM_SHA384 V3CipherSuites TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA V3CipherSuites TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 V3CipherSuites TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 V3CipherSuites TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA V3CipherSuites TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 V3CipherSuites TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 } Here’s the DEBUG ALL output for that. As you can see the 009D cipher was picked. It did not pick one of the stronger ciphers even though TLSv1.2 was used. SC0588 initConnection: Calling getaddrinfo() with deliverycb-bld.dhe.ibm.com SC0627 initConnection: getaddrinfo() returned. SC0798 initNamedConnection: entered SC0960 initIPv4Connection: entered CY3336 access_via_socks_server: entered Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21. SC3362 getReply: entered SC4549 getNextReply: entered with waitForData = TRUE 220-I
Re: SMPE Receive Order post May 1st
Kurt, Unless I'm doing something wrong, my testing does not bear that out. The only cipher in the list was: # Allow only AES ciphers V3CipherSuites TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 PAGENT was refreshed. Here’s the DEBUG ALL output. SC0588 initConnection: Calling getaddrinfo() with deliverycb-bld.dhe.ibm.com SC0627 initConnection: getaddrinfo() returned. SC0798 initNamedConnection: entered SC0960 initIPv4Connection: entered CY3336 access_via_socks_server: entered Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21. SC3362 getReply: entered SC4549 getNextReply: entered with waitForData = TRUE 220-IBM's internal systems must only be used for conducting IBM's SC4549 getNextReply: entered with waitForData = TRUE 220-business or for purposes authorized by IBM management. SC4549 getNextReply: entered with waitForData = TRUE 220- SC4549 getNextReply: entered with waitForData = TRUE 220-Use is subject to audit at any time by IBM management. SC4549 getNextReply: entered with waitForData = TRUE 220- SC4549 getNextReply: entered with waitForData = TRUE 220- SC4549 getNextReply: entered with waitForData = TRUE 220 dhebpcb01 secure FTP server ready. SC4241 getLastReply: entered SC4241 getLastReply: entered SC4241 getLastReply: entered SC7601 update_cntl_appldata: entered GU5351 ftpSetApplData: entered FC0259 ftpAuth: entered FC0294 ftpAuth: security values: mech=TLS, tlsmech=ATTLS, tlsreuse=N, sFTP=R, sCC=P, sDC=P FC2895 ftpAuthAttls: entered FC2971 ftpAuthAttls: AT-TLS policy set as application controlled. FU2410 printAttlsPolicyNames: entered FU2420 TTLSRule: Secure_FTP_Client_9921 FU2426 TTLSGroupAction: grp_Production FU2432 TTLSEnvironmentAction: Secure_FTP_Client_Env_Ext FU2439 TTLSConnectionACtion: Secure_FTP_Conn_Ext SC2899 sendCmd: entered >>> AUTH TLS SC3362 getReply: entered SC4549 getNextReply: entered with waitForData = TRUE 234 SSLv23/TLSv1 SC4241 getLastReply: entered FC3101 authServerAttls: entered SC4405 getFNDELAY: entered SC4440 setFNDELAY: entered FC3140 authServerAttls: Start Handshake FC3149 authServerAttls: ioctl() failed on SIOCTTLSCTL - EDC8121I Connection reset. (errno2=0x77A9733D) SC4440 setFNDELAY: entered Authentication negotiation failed SC4289 inSession: entered *** Control connection with dispby-117.boulder.ibm.com dies. SC4332 SETCEC code = 10 SC3610 endSession: entered (sn=1BE35B18) SC2776 dataClose: entered SC3693 endSession: recv() failed - EDC8121I Connection reset. (errno2=0x76650446) CZ1459 ftpClose: entered SC4289 inSession: entered SC4367 setLoggedIn: entered You must first issue the 'OPEN' command The rest of the ciphers were re-added and PAGENT refreshed. # Allow only AES ciphers V3CipherSuites TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 V3CipherSuites TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 V3CipherSuites TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA V3CipherSuites TLS_RSA_WITH_AES_256_GCM_SHA384 V3CipherSuites TLS_RSA_WITH_AES_256_CBC_SHA256 V3CipherSuites TLS_RSA_WITH_AES_256_CBC_SHA V3CipherSuites TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 V3CipherSuites TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 V3CipherSuites TLS_ECDH_RSA_WITH_AES_256_CBC_SHA V3CipherSuites TLS_DHE_RSA_WITH_AES_256_CBC_SHA V3CipherSuites TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 V3CipherSuites TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 V3CipherSuites TLS_DH_RSA_WITH_AES_256_CBC_SHA V3CipherSuites TLS_DH_RSA_WITH_AES_256_CBC_SHA256 V3CipherSuites TLS_DH_RSA_WITH_AES_256_GCM_SHA384 V3CipherSuites TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA V3CipherSuites TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 V3CipherSuites TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 V3CipherSuites TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA V3CipherSuites TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 V3CipherSuites TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 } Here’s the DEBUG ALL output for that. As you can see the 009D cipher was picked. It did not pick one of the stronger ciphers even though TLSv1.2 was used. SC0588 initConnection: Calling getaddrinfo() with deliverycb-bld.dhe.ibm.com SC0627 initConnection: getaddrinfo() returned. SC0798 initNamedConnection: entered SC0960 initIPv4Connection: entered CY3336 access_via_socks_server: entered Connecting to: dispby-117.boulder.ibm.com 170.225.15.117 port: 21. SC3362 getReply: entered SC4549 getNextReply: entered with waitForData = TRUE 220-IBM's internal systems must only be used for conducting IBM's SC4549 getNextReply: entered with waitForData = TRUE 220-business or for purposes authorized by IBM management. SC4549 getNextReply: entered with waitForData = TRUE 220- SC4549 getNextReply: entered with waitForData = TRUE 220-Use is subject to audit at any time by IBM management. SC4549 getNextReply: entered with waitForData = TRUE 220- SC4549 getNextReply: entered with waitForData = TRUE 220- SC4549 getNextReply: entered with waitForData = TRUE 220 dhebpcb01 secure
Re: SMPE Receive Order post May 1st
>This was confirmed by an individual that supports the server. The >ciphers mentioned on the IBM Support page are a subset of the ciphers >actually enabled. >https://www.ibm.com/support/pages/node/6417233 >I hope this helps. Is anyone still having trouble connecting? >Kurt Quackenbush -- IBM, SMP/E Development >Chuck Norris never uses CHECK when he applies PTFs. We are still broke since the 5/1 TLSv1.2 cutover on your end. We are assuming its a problem on our end. We do have ticket open with ATTLS support group at IBM. We do have HTTPS service working, but continue to pursue, as not sure if TESTCASE.boulder.ibm.com has same TLS requirement (havent tried that yet). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE Receive Order post May 1st
On 5/10/2021 4:57 PM, Michael Babcock wrote: I did some testing on our sandbox (I commented out all ciphers except the one I was interested in and refreshed policy agent) and here’s what I found. The ECDHE ciphers were rejected but the TLS_RSA_WITH_AES_256_CBC_SHA did work (I didn’t try the TLS_RSA_WITH_AES_128_CBC_SHA cipher). In spite of what the IBM Support page says, my tests show the following ciphers enabled on the delivercb-bld.dhe.ibm.com server: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA This was confirmed by an individual that supports the server. The ciphers mentioned on the IBM Support page are a subset of the ciphers actually enabled. https://www.ibm.com/support/pages/node/6417233 I hope this helps. Is anyone still having trouble connecting? Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE Receive Order post May 1st
I did some testing on our sandbox (I commented out all ciphers except the
one I was interested in and refreshed policy agent) and here’s what I found.
According to https://www.ibm.com/support/pages/node/6417233
The cipher suites that will be enabled for AT-TLS for using FTPS are:
· TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
· TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
· TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
· TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
· TLS_RSA_WITH_AES_128_CBC_SHA
· TLS_RSA_WITH_AES_256_CBC_SHA
The ECDHE ciphers were rejected but the TLS_RSA_WITH_AES_256_CBC_SHA did
work (I didn’t try the TLS_RSA_WITH_AES_128_CBC_SHA cipher).
What gives IBM?
On Sun, May 9, 2021 at 1:01 PM Cieri, Anthony <
02d7f4ec1fff-dmarc-requ...@listserv.ua.edu> wrote:
>
> While I agree with your recommendations, the FTPS job does not
> work without the ciphers I listed below. Apparently IBM needs to make some
> adjustments first.
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf
> Of Michael Babcock
> Sent: Wednesday, May 05, 2021 2:58 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMPE Receive Order post May 1st
>
> [[ SEI WARNING *** This email was sent from an external source. Do not
> open attachments or click on links from unknown or suspicious senders. ***
> ]]
>
>
> I would highly discourage the use of the ciphers listed. I would use
> these more secure ciphers (I'm sure there are others that are acceptable).
>
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
>
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
>
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
>
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
>
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
>
> On 5/5/2021 12:58 PM, Cieri, Anthony wrote:
> > Dave,
> > Here you go:
> >
> > ##
> > # #
> > # Secure FTP Application #
> > # #
> > ###
> >
>
> > TTLSRule secure_ftp_client_rule
> > {
> >RemotePortRange 21 # This should be set to the port the FTP
> > # listening on
> >Direction Outbound
> >TTLSGroupActionRef secure_ftp_client_group
> >TTLSEnvironmentActionRef secure_ftp_client_env
> > }
> >
>
> > TTLSGroupAction secure_ftp_client_group
> > {
> >TTLSEnabled On
> >Trace 7
> > }
> >
>
> > TTLSEnvironmentAction secure_ftp_client_env
> > {
> >TTLSKeyringParms
> >{
> > Keyring /u/ftps/zos17dbf.kdb
> > KeyringStashFile /u/ftps/zos17dbf.sth
> >}
> >HandshakeRole Client
> > TTLSEnvironmentAdvancedParms
> >{
> > ApplicationControlledOn
> > SecondaryMap On
> > SSLV3Off
> > TLSV1Off
> > TLSV1.1 Off
> > TLSV1.2 On
> >}
> >TTLSCipherParmsRef ftp_client_ciphers # to cust ciphers
> > }
> >
>
> > TTLSCipherParms ftp_client_ciphers
> > {
> > # Sample ciphers. Should be customized!
> > V3CipherSuitesTLS_RSA_WITH_AES_256_CBC_SHA
> > V3CipherSuitesTLS_RSA_WITH_3DES_EDE_CBC_SHA
> > V3CipherSuitesTLS_RSA_WITH_NULL_SHA
> > }
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List On
> > Behalf Of Dave Jousma
> > Sent: Wednesday, May 05, 2021 1:13 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: SMPE Receive Order post May 1st
> >
> > [[ SEI WARNING *** This email was sent from an external source. Do not
> > open attachments or click on links from unknown or suspicious senders.
> > *** ]]
> >
> >
> >> Well, for what it's worth, I just tried it and my job was
> >> successful, however, I also received the SSLv23/TLSv1 messages. So I
> >> used the standard job that IBM provided (RFNJOBS) and I turned on Debug
> SEC.
> >> Here is w
Re: SMPE Receive Order post May 1st
While I agree with your recommendations, the FTPS job does not work
without the ciphers I listed below. Apparently IBM needs to make some
adjustments first.
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Michael Babcock
Sent: Wednesday, May 05, 2021 2:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE Receive Order post May 1st
[[ SEI WARNING *** This email was sent from an external source. Do not open
attachments or click on links from unknown or suspicious senders. *** ]]
I would highly discourage the use of the ciphers listed. I would use these
more secure ciphers (I'm sure there are others that are acceptable).
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
On 5/5/2021 12:58 PM, Cieri, Anthony wrote:
> Dave,
> Here you go:
>
> ##
> # #
> # Secure FTP Application #
> # #
> ###
>
>
> TTLSRule secure_ftp_client_rule
> {
>RemotePortRange 21 # This should be set to the port the FTP
> # listening on
>Direction Outbound
>TTLSGroupActionRef secure_ftp_client_group
>TTLSEnvironmentActionRef secure_ftp_client_env
> }
>
>
> TTLSGroupAction secure_ftp_client_group
> {
>TTLSEnabled On
>Trace 7
> }
>
>
> TTLSEnvironmentAction secure_ftp_client_env
> {
>TTLSKeyringParms
>{
> Keyring /u/ftps/zos17dbf.kdb
> KeyringStashFile /u/ftps/zos17dbf.sth
>}
>HandshakeRole Client
> TTLSEnvironmentAdvancedParms
>{
> ApplicationControlledOn
> SecondaryMap On
> SSLV3Off
> TLSV1Off
> TLSV1.1 Off
> TLSV1.2 On
>}
>TTLSCipherParmsRef ftp_client_ciphers # to cust ciphers
> }
>
>
> TTLSCipherParms ftp_client_ciphers
> {
> # Sample ciphers. Should be customized!
> V3CipherSuitesTLS_RSA_WITH_AES_256_CBC_SHA
> V3CipherSuitesTLS_RSA_WITH_3DES_EDE_CBC_SHA
> V3CipherSuitesTLS_RSA_WITH_NULL_SHA
> }
>
>
> -Original Message-----
> From: IBM Mainframe Discussion List On
> Behalf Of Dave Jousma
> Sent: Wednesday, May 05, 2021 1:13 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: SMPE Receive Order post May 1st
>
> [[ SEI WARNING *** This email was sent from an external source. Do not
> open attachments or click on links from unknown or suspicious senders.
> *** ]]
>
>
>> Well, for what it's worth, I just tried it and my job was
>> successful, however, I also received the SSLv23/TLSv1 messages. So I
>> used the standard job that IBM provided (RFNJOBS) and I turned on Debug SEC.
>> Here is what I got
> (snip)
>
> Hey Tony, Thanks for this. For some reason we are still struggling.
> Would you be willing to share what your pagent policy for these items:
>
> FU2420 TTLSRule: secure_ftp_client_rule
> FU2426 TTLSGroupAction: secure_ftp_client_group
> FU2432 TTLSEnvironmentAction: secure_ftp_client_env
>
> looks like? I dont think there is anything sensitive, and if you'd rather,
> you can send to me off-list (david.jou...@53.com)
>
> --
> 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: SMPE Receive Order post May 1st
Nevermind, found this in the latest book *TLSMECHANISM* Use this statement to specify whether TLS is implemented by AT-TLS or by FTP.*ATTLS indicates TLS processing is performed by AT-TLS, and must be specified in order to support TLS 1.2 which is required by IBM's download server.* On Thu, May 6, 2021 at 7:46 AM Kurt Quackenbush wrote: > On 5/5/2021 1:13 PM, Dave Jousma wrote: > > > ... For some reason we are still struggling. > For anyone still struggling to connect with FTPS to IBM's download > server after the May 1 server update, please, please, PLEASE consider > telling SMP/E to use HTTPS for the downloads instead of FTPS. It is a > very simple update to your SMP/E job and for the vast majority of folks > requires much less finagling with your firewall settings than for FTP. > > The short version: add downloadmethod and downloadkeyring to your > specification, like this: > > downloadmethod=”https” >downloadkeyring=”javatruststore” >javahome="/usr/lpp/java/J8.0" >> > > > If you need more details, see the SMP/E User's Guide, here: > > https://www.ibm.com/docs/en/zos/2.4.0?topic=guide-preparing-secure-internet-delivery > > Kurt Quackenbush -- IBM, SMP/E Development > Chuck Norris never uses CHECK when he applies PTFs. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE Receive Order post May 1st
What’s the secret decoder ring/handshake to make FTP work? We need AT-TLS? Or can we make updates to the FTPDATA DD (using TLSMECHANISM FTP)? On Thu, May 6, 2021 at 7:46 AM Kurt Quackenbush wrote: > On 5/5/2021 1:13 PM, Dave Jousma wrote: > > > ... For some reason we are still struggling. > For anyone still struggling to connect with FTPS to IBM's download > server after the May 1 server update, please, please, PLEASE consider > telling SMP/E to use HTTPS for the downloads instead of FTPS. It is a > very simple update to your SMP/E job and for the vast majority of folks > requires much less finagling with your firewall settings than for FTP. > > The short version: add downloadmethod and downloadkeyring to your > specification, like this: > > downloadmethod=”https” >downloadkeyring=”javatruststore” >javahome="/usr/lpp/java/J8.0" >> > > > If you need more details, see the SMP/E User's Guide, here: > > https://www.ibm.com/docs/en/zos/2.4.0?topic=guide-preparing-secure-internet-delivery > > Kurt Quackenbush -- IBM, SMP/E Development > Chuck Norris never uses CHECK when he applies PTFs. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE Receive Order post May 1st
I was easier for me to setup and get permission from the security folks and our network folks, the only additional setting we needed were the proxy statements adding my LAN ID and password to pass thru the proxy Carmen Vitullo -Original Message- From: Kurt To: IBM-MAIN Date: Thursday, 6 May 2021 7:46 AM CDT Subject: Re: SMPE Receive Order post May 1st On 5/5/2021 1:13 PM, Dave Jousma wrote: > ... For some reason we are still struggling. For anyone still struggling to connect with FTPS to IBM's download server after the May 1 server update, please, please, PLEASE consider telling SMP/E to use HTTPS for the downloads instead of FTPS. It is a very simple update to your SMP/E job and for the vast majority of folks requires much less finagling with your firewall settings than for FTP. The short version: add downloadmethod and downloadkeyring to your specification, like this: If you need more details, see the SMP/E User's Guide, here: https://www.ibm.com/docs/en/zos/2.4.0?topic=guide-preparing-secure-internet-delivery Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- 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: SMPE Receive Order post May 1st
On 5/5/2021 1:13 PM, Dave Jousma wrote: ... For some reason we are still struggling. For anyone still struggling to connect with FTPS to IBM's download server after the May 1 server update, please, please, PLEASE consider telling SMP/E to use HTTPS for the downloads instead of FTPS. It is a very simple update to your SMP/E job and for the vast majority of folks requires much less finagling with your firewall settings than for FTP. The short version: add downloadmethod and downloadkeyring to your specification, like this: If you need more details, see the SMP/E User's Guide, here: https://www.ibm.com/docs/en/zos/2.4.0?topic=guide-preparing-secure-internet-delivery Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE Receive Order post May 1st
On 5/5/2021 2:58 PM, Michael Babcock wrote: I would highly discourage the use of the ciphers listed. I would use these more secure ciphers (I'm sure there are others that are acceptable). TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 I rise in agreement with my good friend Mr. Babcock. Anything less than AES256/SHA384, you're asking for trouble. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE Receive Order post May 1st
I would highly discourage the use of the ciphers listed. I would use
these more secure ciphers (I'm sure there are others that are acceptable).
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
On 5/5/2021 12:58 PM, Cieri, Anthony wrote:
Dave,
Here you go:
##
# #
# Secure FTP Application #
# #
###
TTLSRule secure_ftp_client_rule
{
RemotePortRange 21 # This should be set to the port the FTP
# listening on
Direction Outbound
TTLSGroupActionRef secure_ftp_client_group
TTLSEnvironmentActionRef secure_ftp_client_env
}
TTLSGroupAction secure_ftp_client_group
{
TTLSEnabled On
Trace 7
}
TTLSEnvironmentAction secure_ftp_client_env
{
TTLSKeyringParms
{
Keyring /u/ftps/zos17dbf.kdb
KeyringStashFile /u/ftps/zos17dbf.sth
}
HandshakeRole Client
TTLSEnvironmentAdvancedParms
{
ApplicationControlledOn
SecondaryMap On
SSLV3Off
TLSV1Off
TLSV1.1 Off
TLSV1.2 On
}
TTLSCipherParmsRef ftp_client_ciphers # to cust ciphers
}
TTLSCipherParms ftp_client_ciphers
{
# Sample ciphers. Should be customized!
V3CipherSuitesTLS_RSA_WITH_AES_256_CBC_SHA
V3CipherSuitesTLS_RSA_WITH_3DES_EDE_CBC_SHA
V3CipherSuitesTLS_RSA_WITH_NULL_SHA
}
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Dave Jousma
Sent: Wednesday, May 05, 2021 1:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE Receive Order post May 1st
[[ SEI WARNING *** This email was sent from an external source. Do not open
attachments or click on links from unknown or suspicious senders. *** ]]
Well, for what it's worth, I just tried it and my job was successful,
however, I also received the SSLv23/TLSv1 messages. So I used the
standard job that IBM provided (RFNJOBS) and I turned on Debug SEC.
Here is what I got
(snip)
Hey Tony, Thanks for this. For some reason we are still struggling. Would
you be willing to share what your pagent policy for these items:
FU2420 TTLSRule: secure_ftp_client_rule
FU2426 TTLSGroupAction: secure_ftp_client_group
FU2432 TTLSEnvironmentAction: secure_ftp_client_env
looks like? I dont think there is anything sensitive, and if you'd rather,
you can send to me off-list (david.jou...@53.com)
--
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
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE Receive Order post May 1st
>Dave, Here you go: >## ># # > ># Secure FTP Application # > ># # > >### Thank you, Sir! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE Receive Order post May 1st
Dave,
Here you go:
##
# #
# Secure FTP Application #
# #
###
TTLSRule secure_ftp_client_rule
{
RemotePortRange 21 # This should be set to the port the FTP
# listening on
Direction Outbound
TTLSGroupActionRef secure_ftp_client_group
TTLSEnvironmentActionRef secure_ftp_client_env
}
TTLSGroupAction secure_ftp_client_group
{
TTLSEnabled On
Trace 7
}
TTLSEnvironmentAction secure_ftp_client_env
{
TTLSKeyringParms
{
Keyring /u/ftps/zos17dbf.kdb
KeyringStashFile /u/ftps/zos17dbf.sth
}
HandshakeRole Client
TTLSEnvironmentAdvancedParms
{
ApplicationControlledOn
SecondaryMap On
SSLV3Off
TLSV1Off
TLSV1.1 Off
TLSV1.2 On
}
TTLSCipherParmsRef ftp_client_ciphers # to cust ciphers
}
TTLSCipherParms ftp_client_ciphers
{
# Sample ciphers. Should be customized!
V3CipherSuitesTLS_RSA_WITH_AES_256_CBC_SHA
V3CipherSuitesTLS_RSA_WITH_3DES_EDE_CBC_SHA
V3CipherSuitesTLS_RSA_WITH_NULL_SHA
}
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Dave Jousma
Sent: Wednesday, May 05, 2021 1:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMPE Receive Order post May 1st
[[ SEI WARNING *** This email was sent from an external source. Do not open
attachments or click on links from unknown or suspicious senders. *** ]]
> Well, for what it's worth, I just tried it and my job was successful,
>however, I also received the SSLv23/TLSv1 messages. So I used the
>standard job that IBM provided (RFNJOBS) and I turned on Debug SEC.
>Here is what I got
(snip)
Hey Tony, Thanks for this. For some reason we are still struggling. Would
you be willing to share what your pagent policy for these items:
FU2420 TTLSRule: secure_ftp_client_rule
FU2426 TTLSGroupAction: secure_ftp_client_group
FU2432 TTLSEnvironmentAction: secure_ftp_client_env
looks like? I dont think there is anything sensitive, and if y
Re: SMPE Receive Order post May 1st
> Well, for what it's worth, I just tried it and my job was successful, > however, I also received the SSLv23/TLSv1 messages. So I used the standard > job that IBM provided (RFNJOBS) and I turned on Debug SEC. Here is what I got (snip) Hey Tony, Thanks for this. For some reason we are still struggling. Would you be willing to share what your pagent policy for these items: FU2420 TTLSRule: secure_ftp_client_rule FU2426 TTLSGroupAction: secure_ftp_client_group FU2432 TTLSEnvironmentAction: secure_ftp_client_env looks like? I dont think there is anything sensitive, and if you'd rather, you can send to me off-list (david.jou...@53.com) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMPE Receive Order post May 1st
Well, for what it's worth, I just tried it and my job was successful, however, I also received the SSLv23/TLSv1 messages. So I used the standard job that IBM provided (RFNJOBS) and I turned on Debug SEC. Here is what I got: 220 dhebpcb01 secure FTP server ready. FC0294 ftpAuth: security values: mech=TLS, tlsmech=ATTLS, tlsreuse=N, sFTP=R, s C=C, sDC=P FC2971 ftpAuthAttls: AT-TLS policy set as application controlled. FU2420 TTLSRule: secure_ftp_client_rule FU2426 TTLSGroupAction: secure_ftp_client_group FU2432 TTLSEnvironmentAction: secure_ftp_client_env >>> AUTH TLS 234 SSLv23/TLSv1 FC3140 authServerAttls: Start Handshake FC3171 authServerAttls: FIPS140 not enabled FC3208 authServerAttls: Using TLSv1.2 protocol FC3226 authServerAttls: SSL cipher: 0035 FU2135 getCtrlConnCertAttls: Request certificate, size 1581 FU2755 getSessionIdAttls: Issuing SIOCTTLSCTL to get decoded AT-TLS Session ID Authentication negotiation succeeded FC2028 setdlevel: entered FC2197 setpbsz: entered >>> PBSZ 0 200 PBSZ=0 >>> PROT P 200 Command PROT okay. Data connection protection is private NAME (deliverycb-bld.dhe.ibm.com:SCNS03T): > P8r12142 >>> USER P8r12142 331 Password required for P8r12142. PASSWORD: > *** >>> PASS 230 virtual user P8r12142 logged in from /12.31.24.5:6457. Command: > CCC > BINARY FC1559 ccc: entered FC1757 setclevel: entered >>> CCC 200 Command Channel Cleared. FU2364 clear_connection_attls: Issue Stop request Control connection protection is clear Command: Command: CG1018 find_hfs_file: stat() failed on /u/smpe/smpnts/OSP08132/GIMPAF.XML - EDC 129I No such file or directory. (errno2=0x053B006C) >>> EPSV 229 Entering Passive Mode (|||65525|) >>> RETR 2021042900039/PROD/GIMPAF.XML 150 Opening BINARY mode data connection for 2021042900039/PROD/GIMPAF.XML. FU1678 protDataConnAttls: Issuing SIOCTTLSCTL to query policy state FU1720 protDataConnAttls: AT-TLS policy set as application controlled. FU2420 TTLSRule: secure_ftp_client_rule FU2426 TTLSGroupAction: secure_ftp_client_group FU2432 TTLSEnvironmentAction: secure_ftp_client_env FU1834 protDataConnAttls: Issuing SIOCTTLSCTL to start handshake FU1866 protDataConnAttls: FIPS140 not enabled FU1907 protDataConnAttls: Using TLSv1.2 protocol <<-TLSv1.2 FU1924 protDataConnAttls: SSL cipher: 0035 FU2255 compareCertAttls: Reque
Re: SMPE Receive Order post May 1st
I should have commented that the HTTPS method is working fine. And my last successful FTPs download was last week Monday April 26th. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
