I'm replying to multiple messages in one message in chronological order.
On 9/28/24 20:00, Steve Estle wrote:
Hmm - Interesting conversation. The account I'm supporting uses
Tectia for ZOS product set (SSH.COM) which allows for proxy to be
setup to convert all ZOS FTP to SFTP without any script changes.
Interesting.
It's my understanding that the `sftp` command was intended to be a drop
in replacement for the `ftp` command for interactive and scripted
interactive use. As in steps were taken to make `sftp` behave as
similar to `ftp` as possible. But that's a client swap.
What you're describing is -- effectively -- a monkey in the middle doing
a protocol translation from clear-text / unencrypted FTP to SFTP or FTP
over SSH.
I would have naively assumed that the Tectia product did unencrypted /
clear-text FTP to encrypted / cypher-text FTP over SSL -> TLS. But I'll
take your word for it.
This product was already in place when I arrived so I was not involved
in the decisions to procure or rationale other than it was needed
to be properly "secure". But I am now wondering from a security /
audit perspective if a secondary software product such as Tectia
is truly required to provide a secure and audit proof FTP, Telnet,
TN3270 environment or is the correct answer is it is just a matter
of properly configuring ZOS Comm Server, FTP, & ATTLS properly which
in essence fully secures the FTP service adequately?
I wonder if it's more a line of business reasoning than it is a
technological reasoning. As in the external system, combined with
proper firewalling can guarantee that no unencrypted / clear-text FTP,
etc. is sent and that ONLY encrypted / cypher-text data is allowed to
leave the secure LAN / environment.
This is similar to some reasons why I've seen people REQUIRE that the
TLS encryption is done on system instead of external systems. When done
on system, it's possible for software to verify that the traffic is
encrypted. Conversely, software running on the system may have trouble
differentiating between traffic that was encrypted to the external
system and unencrypted to the local program vs traffic that came to the
local program directly in an unencrypted form.
That ability to say "it's not possible for unencrypted / clear-text
traffic to get to / leave from the system" checks some more boxes than
"(we think) we configured all the processes to use encryption".
On 9/29/24 10:23, Radoslaw Skorupka wrote:
1. People are lazy or reluctant to make changes "because it works".
Sometimes we inherit old setup with tons of obsoleted settings,
etc. And it is a psychological challenge to change old things (with
some risk of mistake - as always), convince managers, etc.
I think there is something to be said for inertia of a system and the
perceived need to change *EVERYTHING* to use the new configuration *ALL*
*AT* *THE* *SAME* *TIME*.
Conversely something that can be changed one part at a time is more
likely to have individual parts changed out.
3. Distributed systems world tend to prefer sftp over ftps. However
sftp implementation on z/OS lacks some features.
I know from a firewalling point of view encrypted FTPS is a PITA. With
FTP's use of multiple ports, the firewall needs knowledge of the
ephemeral ports to be able to dynamically alter itself to allow the
traffic through. When the FTP control traffic is encrypted, it's much
more difficult if not neigh impossible for a bump-in-the-wire firewall
to be able to learn the ephemeral ports.
Conversely encrypted SFTP over SSH is a single port and thus much, Much,
MUCH easier to deal with from a firewalling point of view.
On 9/29/24 14:58, Phil Smith III wrote:
Can you elaborate? If via AT-TLS I'd be surprised. Unless there's
some additional login majicks (2FA?) that you're referring to?
I'm surprised by the combination of AT-TLS ans SFTP. Does AT-TLS
support SFTP / SCP / SSH? -- A quick search doesn't seem to indicate
that AT-TLS has gained support for SFTP / SCP / SSH since I last looked.
-- Please elaborate.
--
Grant. . . .
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
