I don't know one way or the other, but what about IBM's PVM? -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Tim Joyce Sent: Friday, May 09, 2008 8:13 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM TCP/IP Secure Telnet
I think the problem is, TUBES really is taking control of port 23. One of the procedures to setup TUBES telnet, is to take (comment) out the PORT 23 statement from PROFILE TCPIP. So, there is no way of letting TCPIP know that port 23 is a SECURE port. I think the fact that Macro4 says secure telnet IS NOT supported, indicates secure telnet will not work. I think we have figured out a way around this. We have a limited number of users required to be PCI compliant, so we are planning to have them secure telnet directly to the VSE machine (using CSI TCPIP for VSE secure telnet) and then cross domain to VM TUBES. Not exactly ideal, but the goal is to keep the users in familiar territory. They are used to TUBES! There are many scripts set up in TUBES that automatically signon CMS and CICS and take end users directly to applications etc... Macro 4 indicated it does not plan to add support for secure telnet in the future! Whatever happened to supporting the customer anyway! If TUBES cannot grow with the needs of the customer, I think we will eventually need to move away from TUBES. Thanks for the responses, Tim -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Thursday, May 08, 2008 6:58 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM TCP/IP Secure Telnet > Well I got my SSLSERV up and started to update my PROFILE TCPIP to add a > secure port to test with, then I remembered our session manager (Macro 4 > - TUBES) intercepts port 23 for telnet and uses the port for TUBES. They may not support it in TUBES, but the stack is doing all the work anyway, so I suspect it won't matter. SSLSERV operates before any application that uses the stack gets the data, the TCP app (ie, TUBES in this case) never knows that the SSL encryption happened -- it just sees normal TCP packet traffic post-encryption/decryption. That was the appeal of doing implicit SSL -- no application changes are necessary, and the application doesn't even know it is happening. Since most users now have programmable workstations rather than dumb terminals, most people just drop the session manager altogether and just open multiple windows on the workstation. There are good and bad arguments, but free vs whatever nonzero cost for a session manager is pretty hard to argue with. Keep in mind the limited number of SSL session that SSLSERV (even with the current patches) can support will affect this decision, so keeping Tubes might be a good idea in that it will let you limit the number of incoming TCP sessions that need encryption.
