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-TLS’s 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 you’ve 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 it’s *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. it’s 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. I’d take the hint, and for all applications. Unless there’s a “darn good reason” otherwise, and I’m 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+). It’s 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 haven’t 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
