John S. Giltner, Jr. wrote, in part: >The remote side still has to support SSL/TLS so it know.
This is of course correct, and is where the danger comes from folks thinking "Oh, adding TLS will be good, it's adding security!" Whichever side is seeing the encrypted traffic has to be ready to deal with it. I suspect, for example, that you can't just add AT-TLS to an SMTP connection because the SMTP server you're connecting to is going to expect a STARTTLS keyword to say "Yo, we be gonna encrypt now, let's do the handshake". If you think I'm harping on this, I agree with you. But given the time and effort we spent trying to figure it out when a customer (or rather, their outsourcer) randomly added AT-TLS as a second layer of encryption, I'm'a gonna harp. Understand that from the server (non-z/OS) side in that case, we could see the handshake succeeding--it's just that it was the AT-TLS handshake, and the payload inside that was another handshake. New feature: InfiniteTLS, where the handshake process looks for and handles multiple layers of TLS. YES, I'm joking...I hope. John also wrote: >Unless of course the other side is also z/OS running AT-TLS. Or stunnel (https://www.stunnel.org/) or equivalent. This transparent wrapping is not actually unique to z/OS; what's unique (I think) is that it's at the OS level. I use stunnel to enable a non-TLS-aware Bayesian spam proxy that I've been using for ~20 years, for example. Works great. ...phsiii ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
