Thanks for the info Alan. I will open an ETR with IBM about the incorrect message tomorrow.
I have Telnet setup to negotiate sessions (TLS) now so I have done the setup both ways. going to stick with negotiated for Telnet and ftp. It took me 2 days, but I got it. :). Again, Thanks for your time. D. Tyler Koyl Management Analyst (Embedded image moved to file: pic04313.gif) Viterra Tel (306) 569-6122 Fax (306) 569-4382 mailto:tyler.k...@viterra.ca http://www.viterra.ca Alan Altmark <alan_altm...@us.ib m.com> To Sent by: The IBM IBMVM@LISTSERV.UARK.EDU z/VM Operating cc System <ib...@listserv.uar Subject K.EDU> Re: SSL Server on z/VM 5.4 RSU 802 - Static SSL vs Dynamic SSL\TLS 03/11/2009 01:58 PM Please respond to The IBM z/VM Operating System <ib...@listserv.uar K.EDU> On Wednesday, 03/11/2009 at 02:17 EDT, Tyler Koyl <tyler.k...@viterra.ca> wrote: > My next question is whether I should be going with Static SSL or Dynamic SSL/TLS > connections? That depends on your client capability. Some older telnet clients can't negotiate a secure connection. > PORT > 23 TCP INTCLIEN SECURE ZVMCER01 ; TELNET SERVER > INTERNALCLIENTPARMS > SECURECONNECTION REQUIRED > ENDINTERNALCLIENTPARMS > So at this point I am assuming that my telnet sessions are secure (or more > secure). However, I do get the following disturbing message in the TCPIP log at > initialization: > > DTCSTM305I Telnet server: Secure Connections are REQUIRED > DTCSTM309I Telnet server: TLS Label is <none> > DTCSTM335E Telnet server: Unable to handle secure connections, no TLS label > specified > . > > I believe this means that the telnet server itself will not handle the secure > connections (Dynamic SSL\TLS) but rather TCPIP will forward the request for the > secure port to the SSLSERV (Static SSL). Please call it in. The following are wrong: - The text should say "Unable to negotiate secure connections with clients, no TLS label specified." - The explanation in Msgs & Codes should be updated to say that static connections are not affected. The REQUIRED parameter means that a session must be negotiated to be secure OR it be statically protected. If a connection has been statically protected, the telnet server knows and will not negotate a secure connection. So as it is now, DTC335E is overstating the case IF there is a label present on the PORT statement. Of course, you won't really know if a static connection has a hope of working until you try it. (BTW, for those who care, "static SSL" is the same function that z/OS calls "AT-TLS" - Application Transparent TLS.) The general rule is that negotiating and non-negotating clients cannot go to the same port as, typically, the client will only connect in a single way rather than try both. I don't know of any client that will try to establish a TLS session first and then, if that fails, try to negotiate a TLS session on the same port. So to handle both static and negotiating telnet clients: - Add the same TLS label to the InternalClientParms as you have on the PORT statement - Add a second PORT entry for another INTCLIEN, e.g. 10023 - Add "port 23 port 10023" to the InternalClientParms - Decide whether most of telnet client negotiate or if they require a static connection. This decides whether port 23 will require static connections. - If majority are static, leave port 23 as you have it. - If majority negotiate, move the SECURE option from port 23 to port 10023. - Assuming the telnet client software isn't smart enough to try both ways, the set of clients that lost the race for port 23 must change their configuration to go to port 10023. > Wondering if I am going box myself in here when I go to secure FTP connections > and PERFSVM web access. FTP will most likely be negotiated, though I have seen static clients. A word about static FTP clients: - Only inbound connections are secured, so 'passive' ftp is required - A special form of the PORT statement is required. See the book. - You cannot use CCC to revert the command connection to clear-text. Firewalls cannot see the PASV or PORT commands and will not open a hole. So... - You must use the PassivePortRange FTP server configuration statement and pre-define the port numbers that the FTP server will use to accept data connections, and... - You must force those same port numbers open in the firewall. This can be a death blow to the use of non-negotiating FTP clients or those that negotiate but do not support CCC. Which brings me to a point about the support for CCC (Clear Command Channel) that was added in z/VM 5.4. If you have SECURECONTROL REQUIRED in the ftp server configuration, the ftp cannot use CCC. Likewise, if you have SECUREDATA REQUIRED, the client cannot use the (new) CLEAR subcommand to in order to transfer data without encryption. [NB. The TCP/IP admin book has some unfortunate misspellings under SECURECONTROL. Where it says 'NOW allowed' it means 'NOT allowed'.] For PERFSVM, see the Performance Toolkit Guide, pp. 49-50. Static SSL is the only method available, but you must do more than just alter the PORT statement. Alan Altmark z/VM Development IBM Endicott This e-mail and any attachment(s) are confidential and may be privileged. If you are not the intended recipient please notify me immediately by return e-mail, delete this e-mail and do not copy, use or disclose it.
