Re: SSL Confusion
> I just did the same with stunnel provided with SLES10. It seems to work > fine. Now what are the disadvantages compared to SSLSERV? Not an exhaustive list: Stunnel positives: Uses OpenSSL, so the crypto engines work Reference implementation of SSL, so more likely to be familiar to non-mainframe people Available on multiple platforms (common operations and knowledge). Stunnel negative: Not transparent (requires setup for each port) Not dynamic (can't handle FTP) Unwraps traffic short of the application (may violate some regulatory requirements) Requires ports for non-encrypted service to be open (no firewall capability on VM TCP stack) Not supported by IBM IBM SSLSERV positives: Supported by IBM Dynamic (can handle FTP) Transparent to apps Does not require open ports for non-encrypted services IBM SSLSERV negatives: Doesn't use crypto engines (based on non-crypto aware implementation) Delivers encryption all the way to destination application Difficult to configure and maintain. Available only on VM We have appliance versions of both approaches.
Re: SSL Confusion
On Aug 14, 2007, at 12:26 PM, Alan Altmark wrote: On Tuesday, 08/14/2007 at 11:26 EDT, "Mrohs, Ray" <[EMAIL PROTECTED]> wrote: I just did the same with stunnel provided with SLES10. It seems to work fine. Now what are the disadvantages compared to SSLSERV? It's the same as the pre-z/VM 5.3 support, requiring the client to establish the SSL session before it starts sending protocol data. - you'll need clients that support that model (not defined by RFC) - it works for inbound connections only Not so much disadvantages as they are restrictions. There's another one. You may well have exceptionally boneheaded security auditors, who insist that unencrypted communications are always BAD and WRONG and EVIL, and no amount of explaining to them that the cleartext network path is actually *entirely inside* the z/VM image will get them to see the light. Adam
Re: SSL Confusion
On Tuesday, 08/14/2007 at 11:26 EDT, "Mrohs, Ray" <[EMAIL PROTECTED]> wrote: > I just did the same with stunnel provided with SLES10. It seems to work > fine. Now what are the disadvantages compared to SSLSERV? It's the same as the pre-z/VM 5.3 support, requiring the client to establish the SSL session before it starts sending protocol data. - you'll need clients that support that model (not defined by RFC) - it works for inbound connections only Not so much disadvantages as they are restrictions. Alan Altmark z/VM Development IBM Endicott
Re: SSL Confusion
I just did the same with stunnel provided with SLES10. It seems to work fine. Now what are the disadvantages compared to SSLSERV? Ray Mrohs U.S. Department of Justice 202-307-6896 > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey Barnard > Sent: Friday, August 10, 2007 4:07 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: SSL Confusion > > Tom, > > Using Linux to proxy an SSL connection is easy. The Linux can be a PC > behind your firewall, a Linux on z system, whatever ... > > Symbion SSL Proxy (open source for Linux/Unix/Unixware) > > to start the proxy > > ./ssl_proxy -m -s -c address (client address )> -C -K > > for example > ./ssl_proxy -m 50 -s 192.168.1.226:2023 -c 172.16.0.10:23 -C > sslproxy.pem -K sslproxy.key > > This will listen on port 2023 for an SSL connection and proxy > it in the > clear to port 23. This example creates an easy to use SSL > TN3270(E) connection. > > You can do the same thing for an MQ Series and other types of > connections. Just change the IP addresses and port numbers. > > Regards, > Jeff > -- > Jeffrey C Barnard > Barnard Software, Inc. http://www.bsiopti.com > BSI 407-323-4773 Support 407-688-7123 >
Re: SSL Confusion
Tom, Using Linux to proxy an SSL connection is easy. The Linux can be a PC behind your firewall, a Linux on z system, whatever ... Symbion SSL Proxy (open source for Linux/Unix/Unixware) to start the proxy ./ssl_proxy -m -s -c-C -K for example ./ssl_proxy -m 50 -s 192.168.1.226:2023 -c 172.16.0.10:23 -C sslproxy.pem -K sslproxy.key This will listen on port 2023 for an SSL connection and proxy it in the clear to port 23. This example creates an easy to use SSL TN3270(E) connection. You can do the same thing for an MQ Series and other types of connections. Just change the IP addresses and port numbers. Regards, Jeff -- Jeffrey C Barnard Barnard Software, Inc. http://www.bsiopti.com BSI 407-323-4773 Support 407-688-7123
Re: SSL Confusion
On Aug 10, 2007, at 2:52 PM, Tom Duerbusch wrote: 1. Are there two varients to the SSL/Linux world a. z/VM way as documented b. Perhaps a zLinux way where we connect directly into Linux first and then a clear text session is sent to the 390 side? I didn't catch if there was multiple methods that were being discussed in the past threads. 2. Adam has a Debian server packaged. Does that play with "a" or "b" above, or something different? It's "A"; however doing "B" with stunnel is also pretty easy and straightforward. Buy me some beer and I'll show you how after work some day (that's a general offer to list members, too, btw, although I don't think many of you are also resident in St. Louis). When we move the SSL enabler to the 5.3 codebase, we may go with CentOS rather than Debian as the underlying distro. This would make it a much easier packaging job from our perspective, but it will increase the size of the download substantially (from 250 cylinders towell, I don't know how minimal I can get CentOS, but probably closer to 1000). Is this going to pose a real problem for anyone? Adam
Re: SSL Confusion
The SSLSERV package from Sine Nomine works rather well with your a) choic e. I would stay away from your b) choice because you tend to get into having userids on the z/Linux and all the attendant administrative/auditing/security overhead. You do not need a z/VM userid to connect to the z/VM stack, get a logo, and dial VTAM. /Tom Kern /301-903-2211 On Fri, 10 Aug 2007 14:52:44 -0500, Tom Duerbusch <[EMAIL PROTECTED]> wrote: >In the last month, there has been several threads on SSL servers. I lightly read them, but didn't think it was something of interest, here, i n the near term. > >Well, things change. Time to get ahead of the curve. > >We might be headed towards TN3270 sessions with SSL. > >I searched on SSL on the z/VM 5.2 manuals. Except for the TCP/IP Installation and Customization, not much in the overview to go on. > >On the 390 side, our logical network path is: > >client >| > OSA >| > z/VM >| > v/Switch >| > TCPIP (guest machine) > TN3270 > Dial VTAM (VM/VTAM) Get USSTAB menu >| > VCTCA >| > VSE >| > VCTCA >| > VSE/VTAM >| > CICS > >1. Are there two varients to the SSL/Linux world > a. z/VM way as documented > b. Perhaps a zLinux way where we connect directly into Linux first and then a clear text session is sent to the 390 side? > >I didn't catch if there was multiple methods that were being discussed i n the past threads. > >2. Adam has a Debian server packaged. Does that play with "a" or "b" above, or something different? > >3. We might test with the SSL capability with the TCP/IP stack from CSI stack if all else fails. > >Thanks > >Tom Duerbusch >THD Consulting
SSL Confusion
In the last month, there has been several threads on SSL servers. I lightly read them, but didn't think it was something of interest, here, in the near term. Well, things change. Time to get ahead of the curve. We might be headed towards TN3270 sessions with SSL. I searched on SSL on the z/VM 5.2 manuals. Except for the TCP/IP Installation and Customization, not much in the overview to go on. On the 390 side, our logical network path is: client | OSA | z/VM | v/Switch | TCPIP (guest machine) TN3270 Dial VTAM (VM/VTAM) Get USSTAB menu | VCTCA | VSE | VCTCA | VSE/VTAM | CICS 1. Are there two varients to the SSL/Linux world a. z/VM way as documented b. Perhaps a zLinux way where we connect directly into Linux first and then a clear text session is sent to the 390 side? I didn't catch if there was multiple methods that were being discussed in the past threads. 2. Adam has a Debian server packaged. Does that play with "a" or "b" above, or something different? 3. We might test with the SSL capability with the TCP/IP stack from CSI stack if all else fails. Thanks Tom Duerbusch THD Consulting
