If Im "Paul"* then can you point me at something that would describe how to become AT-TLS aware in a GSK application? Thanks!
...phsiii *This happens to me *constantly*, like at least once a month. My dad (PHS2) said it never happened to him! Four letters, one syllable, begins with a P and ends with an L but otherwise...?!? -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Timothy Sipples Sent: Wednesday, September 18, 2024 1:48 AM To: [email protected] Subject: Re: Is z/OS FTP encrypted? Paul Gilmartin wrote: >Is it evident in the client terminal window that the connection is >not/is encrypted? (I'm envisioning something like the lock favicon in >a browser window.) Alas, if the mechanism is fully transparent the >encryption condition might not be dectable by that client. John S. Giltner, Jr. wrote: >It is detectable on the non-z/OS side as the non-z/OS side still need >to do SSL/TLS. It's only transparent on the z/OS side and for FTP (client >or server) it is only "semi-transparent." For FTP the z/OS server/client >knows that that SSL/TSL is being used, it is just not using SystemSSL directly. >AT-TLS is making all of the SystemSSL calls and z/OS server/client code >see plain text. Applications on z/OS that use AT-TLS can be divided into three categories: basic, aware, and controlling. Basic means the application has absolutely no idea AT-TLS is in the loop. Such applications are TLS naïve. Aware means the application senses that AT-TLS is (or is not) in the loop, and it may use its awareness for certain purposes such as displaying messages (example: XYZ1234: Connection is secured via z/OS AT-TLS), logging, warning, and/or halting if some baseline security strength is not met. The awareness can be simple or detailed, for example awareness of what cipher suite z/OS AT-TLS negotiates. Controlling means the application explicitly directs z/OS AT-TLSs behaviors in certain ways. z/OS Communications Server must be informed ahead of time that an application is controlling via the ApplicationControlled setting in the AT-TLS policy. The second and third categories require the application to use certain APIs to interact with z/OS AT-TLS. AFAIK the FTP server and client on z/OS are AT-TLS aware applications. For example, you can set the SECURE_FTP REQUIRED configuration statement in the FTP client to require TLS (and SECURE_DATACONN PRIVATE). Paul, if youve had support issues when your customers turn on z/OS AT-TLS with your application then presumably you could make your application AT-TLS aware. You could display a message and/or write something to your log when you detect AT-TLS in use for your application. You cannot stop (nor should stop) a customer from configuring AT-TLS. There are excellent reasons customers do that (read on), but at least you can know when it happens. You may not even get a support phone call when they double TLS your application connections because your customers should be able to check your message/log themselves based on the troubleshooting documentation you provide. Alan Altmark wrote: >Windows native FTP doesn't support FTPS (FTP with RFC 4217 - aka >negotiated or explicit TLS). Filezilla does (and has z/OS support). The >FTP client that comes with PCOMM does (I'm not talking about 3270 file >transfer). There are others. >Don't mess with AT-TLS for this. z/VM and z/OS added the support for >RFC 4217 so that there's no question about what is and isn't encrypted. z/VM is different in certain respects. On z/OS its *imperative* you mess with AT-TLS. With z/OS 2.5 or higher you *must* configure z/OS AT-TLS if you want the z/OS FTP server to operate with TLS (FTPS). (z/OS 2.4 reaches End of Support mere days from now: September 30, 2024. A support extension for z/OS 2.4 is available for up to 3 years for an additional charge.) Although the z/OS FTP client still offers built-in TLS support IBM recommends that you use z/OS AT-TLS with the FTP client, too. The documentation I linked to in my previous message mentions that recommendation. In fact, IBM generally recommends you use z/OS AT-TLS instead of built-in TLS. There are several reasons, but the basic reason is that consolidating TLS-related configuration (including certificates) in one logical place in the operating system helps make network security management and enforcement much easier and helps promote crypto agility. If you must run around to 58+ different application configuration files to look for cipher suites, TLS versions, certificates, etc., etc. its a lot more work (and a lot more security risk) than just checking z/OS AT-TLS for everything. The only remaining application supplied with z/OS Communications Server that can use its own "built-in TLS support is the FTP client. Id take the hint, and for all applications. Unless theres a darn good reason otherwise, and Im curious what that DGR is. Last month NIST formally, officially published new standard quantum-safe algorithms: ML-KEM (formerly CRYSTALS-Kyber), ML-DSA (formerly CRYSTALS-Dilithium), and SLH-DSA (formerly SPHINCS+). Its reasonable to expect an updated TLS standard soon with QS algorithms. Meaning everyone will soon be busy updating TLS configurations and certificates everywhere to move to the new TLS standard as soon as reasonably practical. You can get ready now on z/OS by shifting to AT-TLS if you havent already. Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM Z/LinuxONE, Asia-Pacific [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
