Hi Alan, I completely agree with everything you said. One of the things that drives me nuts is that FTP has been labeled as being "bad", so it has to be encrypted. Meanwhile just about ANY other file transfer protocol doesn't (shared Windows network drives, Samba, NJE spooling, 3270 transfers using IND$FILE, etc. etc.). If we were using just about ANY other protocol we wouldn't even have to deal with this.
SSL/TLS is working perfectly (and yes, it took a little work, but once you get it set up correctly you really don't have to worry about it - unless you are using certificates with short lives and plan on constantly updating them). I think we're just going to have to dig in our heels and say "Sorry, if you want to FTP to/from our VM/CMS system you MUST support SSL/TLS". PS: Thanks to Ray Mrohs for the lead on MOVEit, which COULD be used as an intermediate server to accept SSH and retransmit using SSL/TLS: http://www.stdnet.com/products/?category_number=3&subcategory_number=1 Unfortunately this would introduce tremendous overhead, delivery delays (many of our files are >2GB each) and programming changes that don't make it a good candidate for us (but it might be useful for others who find themselves in a similar situation where SSH has been mandated for use, despite the fact that SSL/TLS is the supported process for VM/CMS). -Mike -----Original Message----- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Wednesday, December 17, 2008 4:42 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SSH For z/VM On Wednesday, 12/17/2008 at 11:57 EST, Michael Coffin <michaelcof...@mccci.com> wrote: > Yes. It's not a "technical problem" so much as a "policy problem". > SSL/TLS works perfectly (well, maybe 1 bug that I know of) on VM/CMS, > it's not the problem. FWIW, there is exactly ONE requirement open for SSH on VM and it is for inbound support of "ssh3270". > A client of mine (you know who I mean Alan) somehow came to the > conclusion that Tectia is an "Enterprise-wide secure FTP solution", > perhaps based on all the spin it has been getting lately (including in > z/Journal). So, without REALLY knowing WHAT the "Enterprise" > consisted of, they went forth and procured this product and have > mandated that "all FTP shall be via Tectia secure FTP". Just one tiny > little problem, Tectia is ENTIRELY SSH-based (no SSL/TLS support), and > has neither a client nor server component for VM/CMS. That doesn't sound like a security policy so much as a "certified parts list". > So there's my problem in a nutshell. ALL FTP clients and servers > OUTSIDE of VM/CMS are going to be SSH-based Tectia. They won't be > able to talk to us, and we won't be able to talk to them. :( Needless to say, I detest security policies that are nothing more than a description of a particular implementation of the policy. I cannot keep security policies from exceeding the capabilities of all platforms to which it will be applied. That is the job of those who review said policies. Since you can't get blood from a stone, I guess Management will have to select from the available options: - Make the security policy state the SECURITY REQUIREMENT, not the IMPLEMENTATION, so that the implementation can change as technology changes. (If SSL/TLS is so bad, why is it ok for http? Oh. So it's not a security issue? It's just about enforcing a fave interactive and file transfer protocol standard? OK, but don't do it under color of authority.) - File an exception and use SSL/TLS - Write or contract for your own ssh implementation on VM - Use an intermediary (more RYO or contracting) - Transfer data using https using a pull model Alan Altmark z/VM Development IBM Endicott
