?

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

?