On 10 Mar 2022, at 12:22, Michael Grom <macbaer@...> wrote:

safeguarded by 2-Way TLS for the 3270 comms (or any other inbound/outbound comms)?
by using stunnel4.?

Hi Michael,

It would be really nice if you could share your stunnel4 setup with us here. It is an oft overlooked fact that running tn3270 sessions over the internet is not a prime example of good data security - I ran a Wireshark on my own network recently and saw the VM passwords pass by - and maybe more people can safeguard their sessions if pointed in the right way.

Best regards,

搁别苍é.

On 10 Mar 2022, at 12:22, Michael Grom <macbaer@...> wrote:

safeguarded by 2-Way TLS for the 3270 comms (or any other inbound/outbound comms)
by using stunnel4.

?

Dear René, dear Gregg,

of course I will share my setup with the community asap. Just give me some time to prep things. For using stunnel4, one needs X.509 certificates which can be easily produced with "easy RSA". But more on this later.?

@Gregg: A ssh tunnel is a viable option, however, it needs a user identy / account on the server side. If you don't want users of the mainframe system to be users of the hosting linux / unix / whatever system, I reckon that stunnel is the easier way.?
For sure we know that hercules and the hosted mainframe OSes? like VM/370 and MVS can't deal with TLS. This is where the server nature of stunnel4 comes to help. The inbound TLS connection is proxied unecrypted to the 3270 (or other comms) ports.? Usually, x3270 can deal with SSL connections, but on the Macintosh, the x3270 seems to be utterly broken or I haven't figured out how it works on a Mac with the system keystore etc. I use stunnel4 on the Mac as a client, that is, my x3270 connects to let's say localhost:53270 plain text, stunnel connects to vmd33672.contaboserver.net:53270 with 2-way TLS and the server stunnel proxies the data to hercules, in this case VM/370 with hercules listening on 3271 (3270 taken by MVS).?
I'll prep something with instructions on easy RSA how to create client, server and ca and intermediate certs and how to setup the stunnel for both client and server. This can be replicated to other TCP/IP comms as well (thinking of HNET for example).?

kind regards
Michael

?

Hi Dave,

simply, I don't want uninvited visitors in any of my systems, be them actual or vintage. In my own network at home, behind router and firewall, unencrypted comms or terminal sessions is not much of an issue. As soon as your server is in the internet (cloud offering, virtual server) or accessible through the internet, that's a different story. We also cannot rule out that the vintage OS together with hercules can be a vector to attack the underlying host. So yes, speaking of data protection, the system(s) I run is only a big playground. No personal or business data.?
No need to update hercules, that's where ssh tunnel (Gregg) or stunnel4 (my proposal) comes in, based on the following assumption

a) the host system is guarded with a proper IPTABLES setup, only allowing for the desired TLS and/or SSH destination ports (and source ports, if establishing a link to another computer)
b) binding to the local interface (127.0.0.1) is safe. No packets can travel from the loopback interface to a network interface connected to the external world. An attacker would already have to be inside the system and be able to trace such comms.?
c) stunnel or ssh offer a bridge / TLS termination. Encrypted comms is coming in from the outside, passes through the firewall and is accepted and decrypted by the ssh or stunnel and relayed to the destination port (opened by hercules) on the loopback interface.?
d) 2-Way SSL is used to prevent from unauthorized and unwanted connection by arbitrary clients. If the client cert is invalid or unknown, the SSL handshake fails.?

If you want to allow external users to the system, you would have to establish either certificate issueing or signing. A user who wants to access your VM or MVS would have to submit a certificate signing request, you sign it with your CA and return the signed certificate to the user (which is only useful together with the private key the user must keep for himself).?

I think I should prep some slides that visualise the setup in mind (and which I, more or less, run on my own). It's all free stuff, so no cost attached. In the meantime, my setup is as follows:

Macintosh (the machine where x3270 4.x fails to establish a ssl connection for some odd reason, instead, x3270 talks to a stunnel acting as a client to the server)

/opt/homebrew/etc/stunnel/stunnel.conf

output = /opt/homebrew/var/log/stunnel.log

[x3270]

cert = /opt/homebrew/etc/stunneL/kontor2.crt

key? = /opt/homebrew/etc/stunnel/kontor.key

CAfile = /opt/homebrew/etc/stunnel/chain.pem

client = yes

accept = 127.0.0.1:43270

connect = vmd33672.contaboserver.net:43270

[x3271]

cert = /opt/homebrew/etc/stunneL/kontor2.crt

key? = /opt/homebrew/etc/stunnel/kontor.key

CAfile = /opt/homebrew/etc/stunnel/chain.pem

client = yes

accept = 127.0.0.1:53270

?

connect = vmd33672.contaboserver.net:53270


My Linux server (a cloud offering)

?

output = /var/log/stunnel4/stunnel.log
# the VM System listening at port 3271

[x3271]

accept = 53270

connect= 3271

verifyChain=yes

verifyPeer = no

cert = /etc/stunnel/vmd33672-server.pem

CAfile = /etc/stunnel/chain2.pem

# the MVS system, listening at port 3270

[x3270]

accept = 43270

connect= 3270

verifyChain = yes

verifyPeer = no

cert = /etc/stunnel/vmd33672-server.pem

?

CAfile = /etc/stunnel/chain2.pem

# the http interfaces of the two hercules instances to make it operable from the outside. Also with 2-Way TLS as we have no user management here.

[herchttp]

accept = 4888

connect= 8088

verifyChain = yes

verifyPeer = no

cert = /etc/stunnel/vmd33672-server.pem

CAfile = /etc/stunnel/chain2.pem

?

[herchttp-2]

accept = 5888

connect= 8082

verifyChain = yes

verifyPeer = no

cert = /etc/stunnel/vmd33672-server.pem

CAfile = /etc/stunnel/chain2.pem

When I connect to my vmd33672 from one of my linux boxes, I do not need to use stunnel on the client side, the x3270 call is

?

#!/bin/bash

?

x3270 -model 3279-2 -accepthostname vmd33672.contaboserver.net -cafile ~/chain.pem? -certfile ~/kontor2.crt -keyfile ~/kontor.key? L:vmd33672.contaboserver.net:43270

Tracing failed SSL handshakes can be a daunting task, so don't give up. If one detail goes wrong, the entire handshake fails. Can be anything from chain, algorithm, key size, certificate validity, common name not matching name resolution etcpp.?


Relevant IPTABLES

ACCEPT ? ? tcp? --? anywhere ? ? ? ? ? ? anywhere ? ? ? ? ? ? tcp dpt:43270

ACCEPT ? ? tcp? --? anywhere ? ? ? ? ? ? anywhere ? ? ? ? ? ? tcp dpt:53270

ACCEPT ? ? tcp? --? anywhere ? ? ? ? ? ? anywhere ? ? ? ? ? ? tcp dpt:4888

?

ACCEPT ? ? tcp? --? anywhere ? ? ? ? ? ? anywhere ? ? ? ? ? ? tcp dpt:5888

kind regards
Michael

?