Hmm. Yeah, our code uses GSK directly, so I don't think the ioctl stuff applies. Sounds like you're suggesting a separate tester app that *would* use the ioctl stuff and that it could thus detect AT-TLS. Part of the problem with that (besides it being more work than I think I want to invest) is that a customer might be fine and then get a wild hare/hair* and enable it. So "Your product stopped working", not "We're doing an install and it's not working". In the latter case, "Run this diagnostic program" would be more likely to occur to us.
Ah, here's a thought: since one of the first things we do via https is just a GET, a telnet to port 443 would actually appear to connect if AT-TLS is in place, yes? Now, that requires the customer to have telnet available on z/OS, but that's not a crazy requirement. And it's "free". I already have folks using telnet to test for basic connectivity--"Can we even get to the server?" If you telnet to 443, let it time out, and look at the messages; and then telnet to 442 and do the same, the messages will differ IFF you're actually getting to the server. The analogy is the difference between calling someone, them answering, and you never responding (the connection happens but since you're using telnet, you never do a TLS handshake) and calling someone and it never getting answered. This is surprisingly useful for the many sites who don't have a good handle on their z/OS-to-other-boxes connectivity. Of course as I've said, we've seen this exactly twice, and would hopefully be quicker to recognize it, were it to happen a third time. So maybe this isn't worth worrying about a whole lot; I was kinda hoping that the simple addition of a "Hey AT-TLS, it's me, Margaret" might let us give an error saying "Don't do that!" Appreciate the info, and will definitely keep it in case it does seem worth pursuing! ...phsiii *There seems to be disagreement about which of these the idiom really intends. -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Timothy Sipples Sent: Thursday, September 19, 2024 12:40 AM To: [email protected] Subject: Is z/OS FTP encrypted? Phil Smith III wrote: >If I?m "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...?!? Sorry, Phil. Paul commented in this thread, and I thought he had experienced the support issue. It?s hard to be too precise about implementation details since I?m not familiar with your application. z/OS AT-TLS aware applications use the SIOCTTLSCTL ioctl interfaces. Here?s the general entry point into the relevant z/OS 3.1 documentation (link subject to change): https://www.ibm.com/docs/en/zos/3.1.0?topic=tls-using-siocttlsctl-ioctl I?m speculating, but maybe you could include an embedded or separate ?IVP-style? initial program step that tests/?pings? a connection that?s otherwise identical to your GSK-based connection (same IP address, port, etc.) If the test reveals that AT-TLS is configured by policy for the connection then that?d be useful information to report. Ideally when you detect AT-TLS in use (meeting certain baseline capabilities perhaps) you?d issue a message/log and proceed with the non-TLS connection logic in your application ? assuming you have that logic. (?XYZ1234: Connection secured with z/OS AT-TLS. TLS settings in MYPROD.PARM ignored.?) But I suppose in a ?Phase 0? initial implementation you could issue a message/log and stop. ????? 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
