Ive created a git hub https://github.com/colinpaicemq/ATTLS-Sample/blob/main/README.md of some code I have been writing to illustrate how to use AT-TLS to interact with the session. It extracts and displays the AT-TLS session information. It also extra.. .cts the certificate and uses pthread_security_applid_np to switch userids to the certificate's userid. ( I think it works!)
It is a work in progress, and I am intending to write a blog post about how to do it, but haven't got round to it yet. Please email me privately if you would like to discuss it/use it Colin On Fri, 20 Sept 2024 at 06:20, Timothy Sipples <[email protected]> wrote: > Phil Smith III wrote: > >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.... > > Or a "tester" routine that runs at application startup. > > >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? > > I don't quite follow, but I'll attempt another explanation. The relevant > question is whether your customer has configured an AT-TLS policy for > *your* application's network connection(s). Not whether they're using > AT-TLS at all. They surely will be using AT-TLS, or at least they will be > if they care at all about security. Myriad other applications on z/OS such > as the FTP server use AT-TLS if they use TLS at all. > > So what I'm suggesting as a possibility is to test your network > connection(s) at startup using AT-TLS aware interfaces. If you detect > AT-TLS in use on "your" connections then you proceed without your > "built-in" TLS. From your application's point of view, you establish > unencrypted connections. AT-TLS then handles the TLS part. If you don't > detect AT-TLS in use for your connection(s), you proceed as today. If this > approach is technically viable, of course. > > If you happen to know or find someone who's more familiar with AT-TLS > programming than I am, you could ask that person if what I'm suggesting is > viable and how best to do it. And maybe even publish a nice blog article > about it. :-) Colin Paice frequently writes about z/OS AT-TLS and might > have some further suggestions. > > It occurs to me that it'd be a good idea for z/OS AT-TLS to provide a > "What if?" interface if it doesn't already. That is, you could > programmatically ask AT-TLS, "If I *were* to try to establish a connection > with these parameters, what (if anything) would you do with it? Do you have > a policy to negotiate TLS for this connection if I were to open it? And > what cipher suites would you try to negotiate?" If you'd like to have an > AT-TLS policy inquiry interface, and if it doesn't already exist, you'd > file a feature enhancement request with the z/OS Communications Server > developers via https://ideas.ibm.com. > > (But should an application be able to get answers to AT-TLS policy > inquiries? Or is the policy itself too sensitive, or could it be? I'm not > sure.) > > >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. > > Well, once is a fluke, twice is a trend. :-) AT-TLS use is only going to > get more common over time. > > ????? > 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
