Peter wrote: >I have a general question here. When you don't have crypto processor, So >when a ATTLS traffic is enabled does the encryption and decryption handled >by Started task TCPIP or the general processor?
I’ve seen some of the follow-up messages, and it seems like you’re trying to troubleshoot a performance/throughput-related issue. Or at least you’d like to understand what changed, why you may be observing an elongation in your transaction times from CICS’s perspective. “Crypto processor” could refer to the CP Assist for Cryptographic Functions (CPACF) or to the IBM Crypto Express hardware security modules (HSMs). CPACF is an integral part of every main processor that’s on every modern IBM Z and all IBM LinuxONE machine models. You need to have Feature Code 3863 installed to enable CPACF’s full set of cryptographic algorithms. So just make sure that feature code is installed on all your machines. CPACF is an integral part of your main processors that supports additional instructions that accelerate lots of cryptographic operations. IBM Crypto Express HSMs are optional (but strongly recommended!) features that are installed as cards in your IBM Z or IBM LinuxONE server’s PCI slots. In recent models there are two variants of the IBM Crypto Express cards: “single port” and “dual port.” Dual port means that there are two physical HSMs per card. It’s simply a higher density card that allows you to support more HSM domains and modes within a smaller physical space, analogous to the difference between a fully populated processor drawer and a partially populated one. Whether you get the single port or dual port variant (or some of both), their role is to protect secrets, especially private encryption keys. They have their own onboard processors to execute cryptographic operations, and you need them to move beyond “clear key” cryptography. Clear key cryptography means your private encryption keys inhabit main memory, the same memory that the operating system, middleware, and applications inhabit. Conceivably that memory could be accessed — via a dump that hasn’t been redacted, for example — to obtain the private keys. The vast majority of non-IBM Z/LinuxONE systems that support TLS are operating with clear key, but “we can do better.” And we do: Crypto Express facilitates protected key and secure key operations. Get them, use them, love them. :-) But let’s leave that HSM point aside for the moment and just focus on z/OS AT-TLS and what you may be observing. If you’re actually seeing longer transaction times — if you’ve got reasonable evidence this one change (changing an unencrypted connection to a TLS encrypted connection) made the difference — then there are likely one or two basic reasons why. One likely reason is that you’re not getting a good match between z/OS AT-TLS and CPACF. That is, z/OS AT-TLS (and specifically the z/OS System SSL component that AT-TLS uses) isn’t exploiting CPACF as much as it could. For example, AT-TLS and the other party to the network connection may have mutually negotiated a cipher suite that’s less than ideal for CPACF exploitation. Generally you should “encourage” (or even require) one of the AES GCM cipher suites, and you can do that by configuring AT-TLS to prefer certain cipher suites and outright reject several. And of course you should use only TLS 1.2 or higher, with weak cipher suites disabled. So... check your cipher suite(s). Next, do you have the appropriate software levels that can exploit CPACF well on your machine? ICSF and System SSL are quite important, so check those levels especially. Do you see newer releases (or PTFs) with better CPACF exploitation? Get them on if you can. There are some tools and traces you can use to figure out how much CPACF exploitation you’re getting. Finally, you could be observing the natural effects of non-persistent TLS connections. When you establish a new TLS connection there’s an initial handshake, a negotiation that takes place to establish the secure connection before the two systems exchange real data. If you’re comparing non-persistent TLS connections to unencrypted connections then you should see double the number of network roundtrips: one set of roundtrips to establish the TLS connection, then the real data-bearing roundtrips over the TLS connection. And these extra hops may be OK! It may be just the “cost of doing business” when you turn on TLS to secure your network connections. Non-persistent TLS connections are not much of a direct processor utilization concern if you’ve got CPACF instructions exploited well, but it may be a latency concern. Greater latency, in turn, could have some secondary processor utilization effects. If you’re concerned about the extra network roundtrips that TLS handshaking requires then you can check whether you can establish persistent connections instead. And a persistent connection could be TLS, IPSec/IKEv2, or a SSH tunnel. Another possible option is to relocate the other party closer (in network latency terms) to z/OS AT-TLS. Let’s suppose for example you’re connecting from CICS to an OpenLDAP server running on another machine in another data center. You could install, configure, and run an instance of OpenLDAP on the z/OS Container Extensions (zCX) within the same LPAR running your CICS transactions. That z/OS-hosted OpenLDAP server can replicate with other OpenLDAP servers elsewhere so that it’s kept in sync. And then your CICS application has a much shorter, much lower latency network path because it can connect to the local OpenLDAP instance inside the same LPAR. Does this background help and give you some areas to check? ————— Timothy Sipples Senior Architect Digital Assets, Industry Solutions, and Cybersecurity IBM Z/LinuxONE, Asia-Pacific sipp...@sg.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
