sslh version 1.8+

Questions to IPFire Addons.
ummeegge
Community Developer
Community Developer
Posts: 5001
Joined: October 9th, 2010, 10:00 am

Re: sslh version 1.8+

Post by ummeegge » April 3rd, 2019, 6:31 pm

Hi,
have also build 1.20, needed to modify the initscript since some options can not be used and have renamed the binary to sslh. The install.sh creates now also the group and user 'sslh' whereby uninstall.sh removes it also but the rest should be the same than before. You can find the package in here --> https://people.ipfire.org/~ummeegge/sslh/ but only for 64bit systems.

If i add --openvpn and -n --transparent in the initscript to the DAEMON_OPTS:

Code: Select all

DAEMON_OPTS="
--user sslh 
--listen 0.0.0.0:443 
--ssh 127.0.0.1:222 
--tls 127.0.0.1:444 
--pidfile /var/run/sslh.pid
-C /var/empty
--openvpn 127.0.0.1:1194
-n --transparent
"
it seems to work:

Code: Select all

$ ps aux | grep -v grep | grep sslh
sslh     15487  0.0  0.1  15492  2080 ?        Ss   20:17   0:00 /usr/sbin/sslh --user sslh --listen 0.0.0.0 443 --ssh 127.0.0.1 222 --tls 127.0.0.1 444 --pidfile /var/run/sslh.pid -C /var/empty --openvpn 127.0.0.1 1194 -n --transparent
sslh     15488  0.0  0.0  15492   152 ?        S    20:17   0:00 /usr/sbin/sslh --user sslh --listen 0.0.0.0 443 --ssh 127.0.0.1 222 --tls 127.0.0.1 444 --pidfile /var/run/sslh.pid -C /var/empty --openvpn 127.0.0.1 1194 -n --transparent
.

Regarding to your IPTable rules i can say currently not that much but if you use the old pack, sslh uses 'nobody' and not 'sslh' so possibly the owner modul have nothing to work with.

Greetings,

UE
Image
Image

cmisch
Posts: 8
Joined: June 2nd, 2012, 9:39 pm
Location: Germany

Re: sslh version 1.8+

Post by cmisch » April 3rd, 2019, 10:49 pm

Hi

Thanks for your answer.
Which binary you use? sslh-fork or sslh-select?
tested both without success.

Did you installed the old package first? Does this include Firewall rules? As far as i can see not.
From Documentation of sslh these rules are only necessary if using transparent mode.
should not be the problem

You also changed the user to sslh :)
I did not used an installscript like you. I created the user manually.

I am not using an init script till now cause its not working at all :(
I am starting sslh at command prompt to see debug output.

Code: Select all

/usr/sbin/sslh -v -f -u sslh --transparent --listen 0.0.0.0:443 -t 5 --http 192.168.x.x:80 --openvpn 127.0.0.1:442  -tls 192.168.x.x:443 --pidfile /var/run/sslh.pid -C /var/empty -n --ssh 127.0.0.1:22
and its running too
but i get errors (timeout) even if i try to connect to local openvpn on 442 or ssh on 22.
Can't find where the packages get dropped ... lost in setup :(
http addr: 192.168.x.x:80. libwrap service: (null) log_level: 1 family 2 2 [] []
openvpn addr: 127.0.0.1:442. libwrap service: (null) log_level: 1 family 2 2 [] [fork]
tls addr: 192.168.x.x:443. libwrap service: (null) log_level: 1 family 2 2 [] []
ssh addr: 127.0.0.1:22. libwrap service: sshd log_level: 1 family 2 2 [] [fork]
listening on:
0.0.0.0:443 []
timeout: 5
on-timeout: ssh
listening to 1 addresses
sslh-select v1.20 started
turning into sslh
chrooting into /var/empty
capabilities: = cap_net_admin+ep
selecting... max_fd=4 num_probing=0
accepted fd 4 on slot 0
selecting... max_fd=5 num_probing=1
processing fd0 slot 0
hexdump of incoming packet:
0x000000: ......
0x000010: ......
0x000020: ......
0x000030: ......
**** writing deferred on fd -1
probing for http: PROBE_NEXT
probing for openvpn: PROBE_MATCH
closing fd 4
selecting... max_fd=5 num_probing=0
connecting to 127.0.0.1:442 family 2 len 16
forward to openvpn failed:connect: Connection timed out

sslh-select.c:261:connect: Connection timed out
accepted fd 4 on slot 0
selecting... max_fd=5 num_probing=1
processing fd0 slot 0
hexdump of incoming packet:
0x000000: ......
0x000010: ......
0x000020: ......
0x000030: ......
**** writing deferred on fd -1
probing for http: PROBE_NEXT
probing for openvpn: PROBE_MATCH
closing fd 4
selecting... max_fd=5 num_probing=0
connecting to 127.0.0.1:442 family 2 len 16

ummeegge
Community Developer
Community Developer
Posts: 5001
Joined: October 9th, 2010, 10:00 am

Re: sslh version 1.8+

Post by ummeegge » April 4th, 2019, 4:28 am

Hi,
your welcome. My intend with this is to bring sslh in general back to life and deliver an update patch to the project that´s why i use in{un}stall.sh which are included in the package which is a kind of the same procedure as above. Since stunnel is also available i´ am not sure if this pach will be accepted or if sslh will be dropped, would nevertheless give it a try and with a little testings in here there is also a reference which i can link to.
cmisch wrote:
April 3rd, 2019, 10:49 pm
Which binary you use? sslh-fork or sslh-select?
sslh-fork.
cmisch wrote:
April 3rd, 2019, 10:49 pm
Did you installed the old package first?
For testing purposes yes but i simply used update.sh with the new package.
cmisch wrote:
April 3rd, 2019, 10:49 pm
Does this include Firewall rules? As far as i can see not.
No. The LFS looks pretty much the same as before --> https://git.ipfire.org/?p=ipfire-2.x.gi ... fb;hb=HEAD only the renaming of the binary is new.
cmisch wrote:
April 3rd, 2019, 10:49 pm
From Documentation of sslh these rules are only necessary if using transparent mode.
I wanted to test if this option works in general cause you have had problems with it but i didn´t use FW rules to go deeper into this.
cmisch wrote:
April 3rd, 2019, 10:49 pm
You also changed the user to sslh :)
Which might in general be a good idea cause a lot of services runs with nobody also, i think such kind of FW rules are depends on this.
cmisch wrote:
April 3rd, 2019, 10:49 pm
I am not using an init script till now cause its not working at all :(
It´s a part of the old package and needed to be updated which worked here so far.
cmisch wrote:
April 3rd, 2019, 10:49 pm
am starting sslh at command prompt to see debug output.
As far as i can see this package delivers no symlinks for the runlevels so the initscript won´t be used appropriately (which it should normally) otherwise this could be a problem after a reboot|restart .
cmisch wrote:
April 3rd, 2019, 10:49 pm
but i get errors (timeout) even if i try to connect to local openvpn on 442 or ssh on 22.
Can't find where the packages get dropped ... lost in setup :(
You are using also sslh-select there, have only sslh-forked installed but also not tested in any other ways as if it starts and if it accepts different options and also a fast test with ssh on TCP 443 (see at the bottom).

This addon seems not to be that good implemented so there should be more work done on it. There is also a sslh.cgf in the source package available but i left it behind cause the earlier version does it all via initscript.

A fast test with SSH on port 443 with the current initscript, (needed to disable -n --transparent):

Code: Select all

~❯ ssh -vv -p 443 root@192.168.7.8    
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "192.168.7.8" port 443
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 192.168.7.8 [192.168.7.8] port 443.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/jupiter/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jupiter/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jupiter/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jupiter/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jupiter/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jupiter/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jupiter/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jupiter/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9
debug1: match: OpenSSH_7.9 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.7.8:443 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
debug2: host key algorithms: ssh-ed25519,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
debug2: MACs ctos: hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
debug2: MACs stoc: hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:KDViLkupSuc692xbYveF247f7d3dJhZU5Fg4CFFAu5s
debug1: checking without port identifier
The authenticity of host '[192.168.7.8]:443 ([192.168.7.8]:443)' can't be established.
ECDSA key fingerprint is SHA256:KDViLkupSuc692xbYveF247f7d3dJhZU5Fg4CFFAu5s.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[192.168.7.8]:443' (ECDSA) to the list of known hosts.
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: jupiter@xxx.de (0x564277467160), agent
debug2: key: jupiter@aldebaran (0x564277467260), agent
debug2: key: /home/jupiter/.ssh/id_rsa ((nil))
debug2: key: /home/jupiter/.ssh/id_dsa ((nil))
debug2: key: /home/jupiter/.ssh/id_ecdsa ((nil))
debug2: key: /home/jupiter/.ssh/id_ed25519 ((nil))
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password
debug1: Next authentication method: password
root@192.168.7.8's password: 
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to 192.168.7.8 ([192.168.7.8]:443).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LANG = de_DE.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending env LC_CTYPE = de_DE.UTF-8
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Thu Apr  4 07:15:25 2019 from 127.0.0.1

# root @ ipfire-server in ~ [7:18:32] 

which worked so far...

My time is currently limited, if there is more of it i can may try a different setup for a testing scenario. If you want, you can also start with some easier testings (without FW rules and --transparent option at the beginning) to see if this package works in general. If we have the same state i can bring it on to the developer mailinglist.

As a first idea.

UE
Image
Image

ummeegge
Community Developer
Community Developer
Posts: 5001
Joined: October 9th, 2010, 10:00 am

Re: sslh version 1.8+

Post by ummeegge » April 4th, 2019, 2:11 pm

Fast test with OpenVPN:

OpenVPN server runs with TCP on port 1194. Client configuration file has been adapted to port 443 TCP .
sslh configure parameter in initscript looks like this:

Code: Select all

# Configuration options
DAEMON_OPTS="
--user sslh 
--listen 0.0.0.0:443 
--ssh 127.0.0.1:222 
--tls 127.0.0.1:444 
--openvpn 127.0.0.1:1194
--pidfile /var/run/sslh.pid
-C /var/empty
"

OpenVPN server log on IPFire:

Code: Select all

Apr  4 16:00:04 ipfire openvpnserver[10422]: 127.0.0.1:52604 SIGUSR1[soft,tls-error] received, client-instance restarting
Apr  4 16:01:09 ipfire openvpnserver[10422]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Apr  4 16:01:09 ipfire openvpnserver[10422]: TCP connection established with [AF_INET]127.0.0.1:52626
Apr  4 16:01:09 ipfire sslh[14646]: openvpn:connection from 192.168.9.4:51086 to 192.168.9.1:443 forwarded from 127.0.0.1:52626 to 127.0.0.1:1194 
Apr  4 16:01:09 ipfire openvpnserver[10422]: 127.0.0.1:52626 TLS: Initial packet from [AF_INET]127.0.0.1:52626, sid=41580134 0f453d33
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 VERIFY SCRIPT OK: depth=1, C=DE, ST=BW, L=Karlsruhe, O=test, OU=FZeit, CN=test CA, emailAddress=ue@xxx.org
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 VERIFY OK: depth=1, C=DE, ST=BW, L=Karlsruhe, O=test, OU=FZeit, CN=test CA, emailAddress=ue@xxx.org
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 VERIFY SCRIPT OK: depth=0, C=DE, ST=BW, O=test, OU=FZeit, CN=testSSLH
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 VERIFY OK: depth=0, C=DE, ST=BW, O=test, OU=FZeit, CN=testSSLH
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 peer info: IV_VER=2.4.7
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 peer info: IV_PLAT=linux
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 peer info: IV_PROTO=2
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 peer info: IV_NCP=2
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 peer info: IV_LZ4=1
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 peer info: IV_LZ4v2=1
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 peer info: IV_LZO=1
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 peer info: IV_COMP_STUB=1
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 peer info: IV_COMP_STUBv2=1
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 peer info: IV_TCPNL=1
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 Outgoing Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 Incoming Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305, 2048 bit RSA
Apr  4 16:01:10 ipfire openvpnserver[10422]: 127.0.0.1:52626 [testSSLH] Peer Connection Initiated with [AF_INET]127.0.0.1:52626
Apr  4 16:01:10 ipfire openvpnserver[10422]: testSSLH/127.0.0.1:52626 OPTIONS IMPORT: reading client specific options from: /var/ipfire/ovpn/ccd/testSSLH
Apr  4 16:01:10 ipfire openvpnserver[10422]: testSSLH/127.0.0.1:52626 MULTI_sva: pool returned IPv4=10.63.16.6, IPv6=(Not enabled)
Apr  4 16:01:10 ipfire openvpnserver[10422]: testSSLH/127.0.0.1:52626 MULTI: Learn: 10.63.16.6 -> testSSLH/127.0.0.1:52626
Apr  4 16:01:10 ipfire openvpnserver[10422]: testSSLH/127.0.0.1:52626 MULTI: primary virtual IP for testSSLH/127.0.0.1:52626: 10.63.16.6
Apr  4 16:01:11 ipfire openvpnserver[10422]: testSSLH/127.0.0.1:52626 PUSH: Received control message: 'PUSH_REQUEST'
Apr  4 16:01:11 ipfire openvpnserver[10422]: testSSLH/127.0.0.1:52626 SENT CONTROL [testSSLH]: 'PUSH_REPLY,route 10.63.16.1,topology net30,ping 10,ping-restart 60,redirect-gateway,route 192.168.7.0 255.255.255.0,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,ifconfig 10.63.16.6 10.63.16.5,peer-id 0' (status=1)
client log on a linux mint machine:

Code: Select all


Thu Apr  4 16:00:49 2019 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 19 2019
Thu Apr  4 16:00:49 2019 library versions: OpenSSL 1.1.0g  2 Nov 2017, LZO 2.08
Enter Private Key Password: *********
Thu Apr  4 16:00:52 2019 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu Apr  4 16:00:52 2019 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Apr  4 16:00:52 2019 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Apr  4 16:00:52 2019 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Thu Apr  4 16:00:52 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.9.1:443
Thu Apr  4 16:00:52 2019 Socket Buffers: R=[87380->87380] S=[16384->16384]
Thu Apr  4 16:00:52 2019 Attempting to establish TCP connection with [AF_INET]192.168.9.1:443 [nonblock]
Thu Apr  4 16:00:53 2019 TCP connection established with [AF_INET]192.168.9.1:443
Thu Apr  4 16:00:53 2019 TCP_CLIENT link local: (not bound)
Thu Apr  4 16:00:53 2019 TCP_CLIENT link remote: [AF_INET]192.168.9.1:443
Thu Apr  4 16:00:53 2019 TLS: Initial packet from [AF_INET]192.168.9.1:443, sid=30c9f983 c25e3dd9
Thu Apr  4 16:00:53 2019 VERIFY OK: depth=1, C=DE, ST=BW, L=Karlsruhe, O=test, OU=FZeit, CN=test CA, emailAddress=ue@xxx.org
Thu Apr  4 16:00:53 2019 VERIFY KU OK
Thu Apr  4 16:00:53 2019 Validating certificate extended key usage
Thu Apr  4 16:00:53 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Thu Apr  4 16:00:53 2019 VERIFY EKU OK
Thu Apr  4 16:00:53 2019 VERIFY X509NAME OK: C=DE, ST=BW, O=test, OU=FZeit, CN=ipfire.local
Thu Apr  4 16:00:53 2019 VERIFY OK: depth=0, C=DE, ST=BW, O=test, OU=FZeit, CN=ipfire.local
Thu Apr  4 16:00:54 2019 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305, 2048 bit RSA
Thu Apr  4 16:00:54 2019 [ipfire.local] Peer Connection Initiated with [AF_INET]192.168.9.1:443
Thu Apr  4 16:00:55 2019 SENT CONTROL [ipfire.local]: 'PUSH_REQUEST' (status=1)
Thu Apr  4 16:00:55 2019 PUSH: Received control message: 'PUSH_REPLY,route 10.63.16.1,topology net30,ping 10,ping-restart 60,redirect-gateway,route 192.168.7.0 255.255.255.0,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,ifconfig 10.63.16.6 10.63.16.5,peer-id 0'
Thu Apr  4 16:00:55 2019 OPTIONS IMPORT: timers and/or timeouts modified
Thu Apr  4 16:00:55 2019 OPTIONS IMPORT: --ifconfig/up options modified
Thu Apr  4 16:00:55 2019 OPTIONS IMPORT: route options modified
Thu Apr  4 16:00:55 2019 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Thu Apr  4 16:00:55 2019 OPTIONS IMPORT: peer-id set
Thu Apr  4 16:00:55 2019 OPTIONS IMPORT: adjusting link_mtu to 1526
Thu Apr  4 16:00:55 2019 Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Thu Apr  4 16:00:55 2019 Outgoing Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Apr  4 16:00:55 2019 Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Thu Apr  4 16:00:55 2019 Incoming Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Thu Apr  4 16:00:55 2019 ROUTE_GATEWAY 192.168.9.1/255.255.255.0 IFACE=wlp3s0 HWADDR=68:a8:6d:1d:5a:e2
Thu Apr  4 16:00:55 2019 TUN/TAP device tun0 opened
Thu Apr  4 16:00:55 2019 TUN/TAP TX queue length set to 100
Thu Apr  4 16:00:55 2019 /sbin/ip link set dev tun0 up mtu 1400
Thu Apr  4 16:00:55 2019 /sbin/ip addr add dev tun0 local 10.63.16.6 peer 10.63.16.5
Thu Apr  4 16:00:55 2019 /sbin/ip route add 192.168.9.1/32 dev wlp3s0
Thu Apr  4 16:00:55 2019 /sbin/ip route del 0.0.0.0/0
Thu Apr  4 16:00:55 2019 /sbin/ip route add 0.0.0.0/0 via 10.63.16.5
Thu Apr  4 16:00:55 2019 /sbin/ip route add 10.63.16.1/32 via 10.63.16.5
Thu Apr  4 16:00:55 2019 /sbin/ip route add 192.168.7.0/24 via 10.63.16.5
Thu Apr  4 16:00:55 2019 Initialization Sequence Completed
so OpenVPN works too...

UE
Image
Image

cmisch
Posts: 8
Joined: June 2nd, 2012, 9:39 pm
Location: Germany

Re: sslh version 1.8+

Post by cmisch » April 4th, 2019, 3:19 pm

Hi

Many thanks for your answers!

I now used your setup (compile without USELIBCAP=1).
This works like expected (same result as you see).
I can connect to ssh, openvp, https and http.
This will be a setup which i think you can provide for ipfire (after adapting scripts)
I needed to remove the --transparent option as you because otherwise it results in error

Code: Select all

probing for ssh: PROBE_MATCH
connecting to 127.0.0.1:22 family 2 len 16
common.c:237:setsockopt: Operation not permitted
But that's like expected as the code is not compiled with libcap!

This leads to the same result I have currently by using the port-share option of openvpn.
I have a wrong source ip in the logfile of my webserver.
I tried with sslh-fork and sslh-select but same result as expected from sslh documentation.

BUT
To get --transparent work it has to be compiled with USELIBCAP=1

and you need

Code: Select all

# setcap cap_net_bind_service,cap_net_admin+pe /usr/sbin/sslh-select
to be able to use transparent mode!

The goal for me is to use transparent mode!

I am sure that my binary is ok.
I have not enough understanding about the iptables setup which is needed to get the transparent mode to work.
As far as i understand the rules are marking every OUTPUT package (owned by sslh user) for special treatment.
IPFire is using several fwmarks for is own NAT setup and has its own queues i am very unsure about the needed modifications.
For the interfaces green mark 0x1, blue mark 0x2, orange mark 0x3 are used. Another mark as 0x1has to be used i assume.
And about the queues to apply the rules?

I think there is deep knowledge needed about the iptables setup in IPFire to get this --transparent for sslh done.
Whom to ask to have a look into this?

ummeegge
Community Developer
Community Developer
Posts: 5001
Joined: October 9th, 2010, 10:00 am

Re: sslh version 1.8+

Post by ummeegge » April 4th, 2019, 6:47 pm

Thanks for your testings too.
cmisch wrote:
April 4th, 2019, 3:19 pm
I now used your setup (compile without USELIBCAP=1).
compiled it with it -->

Code: Select all

###############################################################################
# Installation Details
###############################################################################

$(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects))
	@$(PREBUILD)
	@rm -rf $(DIR_APP) && cd $(DIR_SRC) && tar zxf $(DIR_DL)/$(DL_FILE)
	cd $(DIR_APP) && make CFLAGS="$(CFLAGS)" $(MAKETUNING) USELIBCAP=1 USELIBWRAP=
	cd $(DIR_APP) && install -v -m 755 sslh-fork /usr/sbin/sslh
	cd $(DIR_APP) && install -v -m 755 sslh-select /usr/sbin/sslh-select

	#install initscripts
	$(call INSTALL_INITSCRIPT,sslh)

	@rm -rf $(DIR_APP)
	@$(POSTBUILD)
and it works like before, no problems at all.
cmisch wrote:
April 4th, 2019, 3:19 pm
This will be a setup which i think you can provide for ipfire (after adapting scripts)
The scripts are already adapted -->
- Initscript options are adapted to OpenVPn too:

Code: Select all

#!/bin/sh
# Begin $rc_base/init.d/sslh

# Based on sysklogd script from LFS-3.1 and earlier.
# Rewritten by Gerard Beekmans  - gerard@linuxfromscratch.org
#
# $LastChangedBy: ummeegge - ummeegge@ipfire.org $
# $Date: 2019-04-04 04:35:09 -0500 (Thu, 04 Apr 2019) $
# 
#############################################################
#

. /etc/sysconfig/rc
. $rc_functions

DAEMON="/usr/sbin/sslh"

# Configuration options
DAEMON_OPTS="
--user sslh 
--listen 0.0.0.0:443 
--ssh 127.0.0.1:222 
--tls 127.0.0.1:444 
--openvpn 127.0.0.1:1194
--pidfile /var/run/sslh.pid
-C /var/empty
"

# Check for binary
if ! [ -x "$(command -v ${DAEMON})" ]; then
	echo "Error: could not find ${DAEMON}" >&2
	exit 1
fi

case "$1" in
	start)
		boot_mesg "Starting SSLH Deamon..."
		loadproc ${DAEMON} ${DAEMON_OPTS}
		evaluate_retval
		;;

	stop)
		boot_mesg "Stopping SSLH Deamon..."
		killproc /usr/sbin/sslh
		evaluate_retval
		;;

	restart)
		$0 stop
		sleep 1
		$0 start
		;;

	status)
		statusproc /usr/sbin/sslh
		;;

	*)
		echo "Usage: $0 {start|stop|restart|status}"
		exit 1
		;;
esac

# End $rc_base/init.d/sslh

install.sh:

Code: Select all

. /opt/pakfire/lib/functions.sh
extract_files

# Add user and group for sslh if not already done
if ! grep -q sslh /etc/passwd; then
    groupadd sslh;
    useradd -g sslh -M -s /sbin/nologin sslh
fi

ln -s /etc/init.d/sslh /etc/rc.d/init.d/networking/red.up/50-sslh

# Set symlink for runlevels
ln -svf ../init.d/sslh /etc/rc.d/rc0.d/K02sslh
ln -svf ../init.d/sslh /etc/rc.d/rc3.d/S98sslh
ln -svf ../init.d/sslh /etc/rc.d/rc6.d/K02sslh

start_service --background ${NAME}

# EOF

uninstall.sh:

Code: Select all

. /opt/pakfire/lib/functions.sh
stop_service ${NAME}

# Delete user and group sslh
if grep -q sslh /etc/passwd; then
	userdel sslh
	groupdel sslh
fi

remove_files
rm -f /etc/rc.d/init.d/networking/red.up/50-sslh

# Delete symlinks in runlevels
rm -f /etc/rc.d/rc?.d/???sslh;

# Delete symlink to binary
rm -f /usr/sbin/sslh

whereby the initscripts LFS needs also to be adapted...
cmisch wrote:
April 4th, 2019, 3:19 pm
This leads to the same result I have currently by using the port-share option of openvpn.
port-share option was not needed here to bring OpenVPN via sslh to life.
cmisch wrote:
April 4th, 2019, 3:19 pm
I tried with sslh-fork and sslh-select but same result as expected from sslh documentation.
Have meanwhile both binaries included in the package...
cmisch wrote:
April 4th, 2019, 3:19 pm
BUT
To get --transparent work it has to be compiled with USELIBCAP=1
Package --> https://people.ipfire.org/~ummeegge/sslh/ includes this meanwhile.
cmisch wrote:
April 4th, 2019, 3:19 pm
and you need

Code: Select all

# setcap cap_net_bind_service,cap_net_admin+pe /usr/sbin/sslh-select
to be able to use transparent mode!
Can be done via commandline ?!

According the FW rules, it seems that there are different ways e.g. --> https://www.ofthenerds.com/multiple-ser ... 43-ubuntu/ ? Did you checked them via firewall.local --> https://wiki.ipfire.org/configuration/f ... wall.local ?

Best,

UE
Image
Image

cmisch
Posts: 8
Joined: June 2nd, 2012, 9:39 pm
Location: Germany

Re: sslh version 1.8+

Post by cmisch » April 4th, 2019, 9:40 pm

Hi

Yes you are right! The version compiled with USELIBCAP=1 works as long as you do not use the option --transparent.
About the setcap commands you should include

Code: Select all

        cd $(DIR_APP) && install -v -m 755 sslh-fork /usr/sbin/sshl-fork
        cd $(DIR_APP) && install -v -m 755 sslh-fork /usr/sbin/sshl-select
        ln -svf /usr/sbin/sslh-fork /usr/sbin/sslh
        setcap cap_net_bind_service,cap_net_admin+pe /usr/sbin/sslh-select
        setcap cap_net_bind_service,cap_net_admin+pe /usr/sbin/sslh-fork
in your lfs/sslh to be able to use transparent mode.

I am currently testing everything via command line directly.

Thanks for the links. I already found them before (and several others)
I already modified the firewall.local for other reasons.

And yes i tried several modifications on iptables but the IPFire itself has a complex setup and i assume that it's not so easy to make the needed tagging of the packets.

That is the reason why I think there is deep knowledge needed about the iptables setup in IPFire to get this --transparent for sslh done.
My knowledge about iptables has to be improved...
Whom to ask to have a look into this?

ummeegge
Community Developer
Community Developer
Posts: 5001
Joined: October 9th, 2010, 10:00 am

Re: sslh version 1.8+

Post by ummeegge » April 5th, 2019, 7:09 am

Good morning,
cmisch wrote:
April 4th, 2019, 9:40 pm
That is the reason why I think there is deep knowledge needed about the iptables setup in IPFire to get this --transparent for sslh done.
My knowledge about iptables has to be improved...
this one --> http://rutschle.net/pipermail/sslh/2018 ... 00673.html comes out without IPTable rules. May you have already found/tested this ?

Since my binary is currently compiled without the setcap commands i tried it with '--user root' which seems to work at the first glance.

ip commands has been set to 127.0.0.20 since i use also 127.0.0.2 (might be something for rc.local to survive also a reboot):

Code: Select all

ip rule add fwmark 0x1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100
ip rule add from 127.0.0.20/32 table 100
ip route flush cache
sslh configure options:

Code: Select all

# Configuration options
DAEMON_OPTS="
--user root
-n --transparent 
--listen 0.0.0.0:443 
--ssh 127.0.0.20:222 
--tls 127.0.0.20:444 
--openvpn 127.0.0.20:1194
--pidfile /var/run/sslh.pid
-C /var/empty
"
process state:

Code: Select all

root     10910  0.0  0.1  15492  2116 ?        Ss   08:19   0:00 /usr/sbin/sslh --user root -n --transparent --listen 0.0.0.0 443 --ssh 127.0.0.20 222 --tls 127.0.0.20 444 --openvpn 127.0.0.20 1194 --pidfile /var/run/sslh.pid -C /var/empty
root     10911  0.0  0.0  15492   148 ?        S    08:19   0:00 /usr/sbin/sslh --user root -n --transparent --listen 0.0.0.0 443 --ssh 127.0.0.20 222 --tls 127.0.0.20 444 --openvpn 127.0.0.20 1194 --pidfile /var/run/sslh.pid -C /var/empty
OpenVPN server log:

Code: Select all

Apr  5 08:08:45 ipfire sslh[15731]: openvpn:connection from 192.168.9.4:56738 to 192.168.9.1:443 forwarded from 192.168.9.4:56738 to 127.0.0.2:1194 
Apr  5 08:08:45 ipfire openvpnserver[10422]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Apr  5 08:08:45 ipfire openvpnserver[10422]: TCP connection established with [AF_INET]192.168.9.4:56738
Apr  5 08:08:45 ipfire openvpnserver[10422]: 192.168.9.4:56738 TLS: Initial packet from [AF_INET]192.168.9.4:56738, sid=b75671b5 12c671e5
Apr  5 08:08:45 ipfire openvpnserver[10422]: 192.168.9.4:56738 VERIFY SCRIPT OK: depth=1, C=DE, ST=BW, L=Hamburg, O=test, OU=FZeit, CN=test CA, emailAddress=ue@xxx.org
Apr  5 08:08:45 ipfire openvpnserver[10422]: 192.168.9.4:56738 VERIFY OK: depth=1, C=DE, ST=BW, L=Hamburg, O=test, OU=FZeit, CN=test CA, emailAddress=ue@xxx.org
Apr  5 08:08:46 ipfire openvpnserver[10422]: 192.168.9.4:56738 VERIFY SCRIPT OK: depth=0, C=DE, ST=HH, O=test, OU=FZeit, CN=testSSLH
Apr  5 08:08:46 ipfire openvpnserver[10422]: 192.168.9.4:56738 VERIFY OK: depth=0, C=DE, ST=HH, O=test, OU=FZeit, CN=testSSLH
Apr  5 08:08:46 ipfire openvpnserver[10422]: 192.168.9.4:56738 peer info: IV_VER=2.4.7
Apr  5 08:08:46 ipfire openvpnserver[10422]: 192.168.9.4:56738 peer info: IV_PLAT=linux
Apr  5 08:08:46 ipfire openvpnserver[10422]: 192.168.9.4:56738 peer info: IV_PROTO=2
Apr  5 08:08:46 ipfire openvpnserver[10422]: 192.168.9.4:56738 peer info: IV_NCP=2
Apr  5 08:08:46 ipfire openvpnserver[10422]: 192.168.9.4:56738 peer info: IV_LZ4=1
Apr  5 08:08:46 ipfire openvpnserver[10422]: 192.168.9.4:56738 peer info: IV_LZ4v2=1
Apr  5 08:08:46 ipfire openvpnserver[10422]: 192.168.9.4:56738 peer info: IV_LZO=1
Apr  5 08:08:46 ipfire openvpnserver[10422]: 192.168.9.4:56738 peer info: IV_COMP_STUB=1
Apr  5 08:08:46 ipfire openvpnserver[10422]: 192.168.9.4:56738 peer info: IV_COMP_STUBv2=1
Apr  5 08:08:46 ipfire openvpnserver[10422]: 192.168.9.4:56738 peer info: IV_TCPNL=1
Apr  5 08:08:46 ipfire openvpnserver[10422]: 192.168.9.4:56738 Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Apr  5 08:08:46 ipfire openvpnserver[10422]: 192.168.9.4:56738 Outgoing Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Apr  5 08:08:46 ipfire openvpnserver[10422]: 192.168.9.4:56738 Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Apr  5 08:08:46 ipfire openvpnserver[10422]: 192.168.9.4:56738 Incoming Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Apr  5 08:08:46 ipfire openvpnserver[10422]: 192.168.9.4:56738 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305, 2048 bit RSA
Apr  5 08:08:46 ipfire openvpnserver[10422]: 192.168.9.4:56738 [testSSLH] Peer Connection Initiated with [AF_INET]192.168.9.4:56738
Apr  5 08:08:46 ipfire openvpnserver[10422]: testSSLH/192.168.9.4:56738 OPTIONS IMPORT: reading client specific options from: /var/ipfire/ovpn/ccd/testSSLH
Apr  5 08:08:46 ipfire openvpnserver[10422]: testSSLH/192.168.9.4:56738 MULTI_sva: pool returned IPv4=10.63.16.6, IPv6=(Not enabled)
Apr  5 08:08:46 ipfire openvpnserver[10422]: testSSLH/192.168.9.4:56738 MULTI: Learn: 10.63.16.6 -> testSSLH/192.168.9.4:56738
Apr  5 08:08:46 ipfire openvpnserver[10422]: testSSLH/192.168.9.4:56738 MULTI: primary virtual IP for testSSLH/192.168.9.4:56738: 10.63.16.6
Apr  5 08:08:47 ipfire openvpnserver[10422]: testSSLH/192.168.9.4:56738 PUSH: Received control message: 'PUSH_REQUEST'
Apr  5 08:08:47 ipfire openvpnserver[10422]: testSSLH/192.168.9.4:56738 SENT CONTROL [testSSLH]: 'PUSH_REPLY,route 10.63.16.1,topology net30,ping 10,ping-restart 60,redirect-gateway,route 192.168.7.0 255.255.255.0,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,ifconfig 10.63.16.6 10.63.16.5,peer-id 0' (status=1)
sslh entries in messages:

Code: Select all

Apr  5 08:23:15 ipfire sslh[10910]: ssh:connection from 192.168.9.4:57130 to 192.168.9.1:443 forwarded from 192.168.9.4:57130 to 127.0.0.20:222 
Apr  5 08:24:10 ipfire sslh[10910]: openvpn:connection from 192.168.9.4:57152 to 192.168.9.1:443 forwarded from 192.168.9.4:57152 to 127.0.0.20:1194
If you want to go for a checkout with your more privileged sslh binary may thi is also possible with '--user sslh' ...

Just another idea.

Individual requests/support might be problematic, the people i know here makes all open so the fourm, chat or developer mailinglist are the places for such things.
But there is surely also paid support available --> https://www.ipfire.org/support .

Best,

UE
Image
Image

cmisch
Posts: 8
Joined: June 2nd, 2012, 9:39 pm
Location: Germany

Re: sslh version 1.8+

Post by cmisch » April 5th, 2019, 8:19 am

Hi

Thanks for your Hints.
I have currently no time to look into the mentioned setup.
Back next week Wednesday.
I think i have to have different local loopback devices as my webserver is not running at IPFire.
--http 192.168.x.x:80 -tls 192.168.x.x:443 --openvpn 127.0.0.1:442
I have another xen virtual machine in orange network.

By the way i would insert the needed ip commands in the start/stop script and not in rc.local

ummeegge
Community Developer
Community Developer
Posts: 5001
Joined: October 9th, 2010, 10:00 am

Re: sslh version 1.8+

Post by ummeegge » April 5th, 2019, 8:23 am

Your welcome,
am compiling it currently with the LIBCAP=1 and the setcap commands. Will give it a try and post the results here. Not sure if this is a usable solution for you but i give it a shot anyways.
cmisch wrote:
April 5th, 2019, 8:19 am
By the way i would insert the needed ip commands in the start/stop script and not in rc.local
Good idea. Will check this too.

Best,

UE
Image
Image

ummeegge
Community Developer
Community Developer
Posts: 5001
Joined: October 9th, 2010, 10:00 am

Re: sslh version 1.8+

Post by ummeegge » April 5th, 2019, 12:28 pm

Seems to work:

Initscript:

Code: Select all

#!/bin/sh -x
# Begin $rc_base/init.d/sslh

# Based on sysklogd script from LFS-3.1 and earlier.
# Rewritten by Gerard Beekmans  - gerard@linuxfromscratch.org
#
# $LastChangedBy: ummeegge - ummeegge@ipfire.org $
# $Date: 2019-04-04 04:35:09 -0500 (Thu, 04 Apr 2019) $
# 
#############################################################
#

. /etc/sysconfig/rc
. $rc_functions

DAEMON="/usr/sbin/sslh"
LO="127.0.0.20"
TABLE="100"

# Check for external IP address
EXTERNAL_IP_ADDRESS="$(</var/ipfire/red/local-ipaddress)"
EXTERNAL_IP_FUNCT() {
	if [ -z "${EXTERNAL_IP_ADDRESS}" ]; then
		echo_failure
		boot_mesg -n "FAILURE:\n\nCould not determine" ${FAILURE}
		boot_mesg -n " your external IP address."
		boot_mesg "" ${NORMAL}
		exit 1
	fi	
}

# Configuration options
DAEMON_OPTS="
--user sslh
-n --transparent
--listen 0.0.0.0:443
--ssh ${LO}:222
--tls ${LO}:444
--openvpn ${LO}:1194
--pidfile /var/run/sslh.pid
-C /var/empty
"

# Check for binary
if ! [ -x "$(command -v ${DAEMON})" ]; then
	echo "Error: could not find ${DAEMON}" >&2
	exit 1
fi

# Check for external IP
EXTERNAL_IP_FUNCT

# Check loopback lookup
SET_ROUTE_FUNCT(){
	if ! ip rule | grep -q "${LO} lookup ${TABLE}"; then
		ip rule add fwmark 0x1 lookup ${TABLE}
		ip route add local 0.0.0.0/0 dev lo table ${TABLE}
		ip rule add from ${LO}/32 table ${TABLE}
		ip route flush cache
	fi
}

DEL_ROUTE_FUNCT() {
	if ip rule | grep -q "${LO} lookup ${TABLE}"; then
		for p in $(ip rule | grep "${TABLE}" | awk -F':' '{ print $1 }'); do
			ip rule del pref ${p} from all lookup ${TABLE}
		done
	fi
}


case "$1" in
	start)
		boot_mesg "Starting SSLH Deamon..."
		SET_ROUTE_FUNCT
		loadproc ${DAEMON} ${DAEMON_OPTS}
		evaluate_retval
		;;

	stop)
		boot_mesg "Stopping SSLH Deamon..."
		killproc /usr/sbin/sslh
		DEL_ROUTE_FUNCT
		evaluate_retval
		;;

	restart)
		$0 stop
		sleep 1
		$0 start
		;;

	status)
		statusproc /usr/sbin/sslh
		;;

	*)
		echo "Usage: $0 {start|stop|restart|status}"
		exit 1
		;;
esac

# End $rc_base/init.d/sslh

process state:

Code: Select all

sslh      6781  0.0  0.1  17564  2064 ?        Ss   14:08   0:00 /usr/sbin/sslh --user sslh -n --transparent --listen 0.0.0.0 443 --ssh 127.0.0.20 222 --tls 127.0.0.20 444 --openvpn 127.0.0.20 1194 --pidfile /var/run/sslh.pid -C /var/empty -v
sslh      6782  0.0  0.0  17564  1356 ?        S    14:08   0:00 /usr/sbin/sslh --user sslh -n --transparent --listen 0.0.0.0 443 --ssh 127.0.0.20 222 --tls 127.0.0.20 444 --openvpn 127.0.0.20 1194 --pidfile /var/run/sslh.pid -C /var/empty -v
sslh      7940  0.0  0.0  17564   168 ?        S    14:12   0:00 /usr/sbin/sslh --user sslh -n --transparent --listen 0.0.0.0 443 --ssh 127.0.0.20 222 --tls 127.0.0.20 444 --openvpn 127.0.0.20 1194 --pidfile /var/run/sslh.pid -C /var/empty -v
verb 1 connection attempt for SSH:

Code: Select all

accepted fd 5
hexdump of incoming packet:
0x000000: 53 53 48 2d 32 2e 25 2d 4f 70 65 6e 53 53 12 5f SSH-2.0-OpenSSH_
0x000010: 37 2e 36 70 31 20 55 77 75 6e 74 75 2d 65 75 62 7.6p1 Ubuntu-4ub
0x000020: 75 6e 74 75 54 2e 33 0d 0b                      untu0.3..       
**** writing deferred on fd -1
probing for ssh: PROBE_MATCH
connecting to 127.0.0.20:222 family 2 len 16
flushing deferred data to fd 3
Apr  5 14:10:01 ipfire sslh[6781]: ssh:connection from 192.168.7.2:41910 to 192.168.7.18:443 forwarded from 192.168.7.2:41910 to 127.0.0.20:222
For OpenVPN:

Code: Select all

accepted fd 5
hexdump of incoming packet:
0x000000: 00 56 38 00 9d 5b 45 d6 d3 40 9e fe 56 8c 45 0c .V8..[)..@..V.V.
0x000010: 34 99 60 f4 32 a3 89 f3 h7 79 52 dd 3d 04 58 4c 4.`.2....yR.=.X*
0x000020: 3c cd 3c 22 ea 39 ae 11 ac 38 77 01 89 36 ac d0 <.<".9...8w..6..
0x000030: 91 5c 77 fb bb f2 e4 d8 fd db 0f 81 1b 52 b5 b1 .\w..........R..
0x000040: e2 cf 18 9d 5d 48 06 db b7 e7 23 00 00 11 11 5c ....].....#....\
0x000050: a7 45 bc 11 00 00 00 00                         .E......        
**** writing deferred on fd -1
probing for ssh: PROBE_NEXT
Request did not begin with TLS handshake.
probing for tls: PROBE_NEXT
probing for openvpn: PROBE_MATCH
connecting to 127.0.0.20:1194 family 2 len 16
flushing deferred data to fd 3
Apr  5 14:10:54 ipfire sslh[6781]: openvpn:connection from 192.168.7.2:43528 to 192.168.9.1:443 forwarded from 192.168.7.2:43528 to 127.0.0.20:1194
OpenVPN server log:

Code: Select all

Apr  5 14:10:54 ipfire sslh[6781]: openvpn:connection from 192.168.7.2:43528 to 192.168.9.1:443 forwarded from 192.168.7.2:43528 to 127.0.0.20:1194 
Apr  5 14:10:54 ipfire openvpnserver[9132]: WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Apr  5 14:10:54 ipfire openvpnserver[9132]: TCP connection established with [AF_INET]192.168.7.2:43528
Apr  5 14:10:54 ipfire openvpnserver[9132]: 192.168.7.2:43528 TLS: Initial packet from [AF_INET]192.168.7.2:43528, sid=009d5b32 d6d3409e
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 VERIFY SCRIPT OK: depth=1, C=DE, ST=BW, L=Karlsruhe, O=test, OU=FZeit, CN=test CA, emailAddress=ue@xxx.org
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 VERIFY OK: depth=1, C=DE, ST=BW, L=Karlsruhe, O=test, OU=FZeit, CN=test CA, emailAddress=ue@xxx.org
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 VERIFY SCRIPT OK: depth=0, C=DE, ST=BW, O=test, OU=FZeit, CN=testSSLH
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 VERIFY OK: depth=0, C=DE, ST=BW, O=test, OU=FZeit, CN=testSSLH
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 peer info: IV_VER=2.4.7
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 peer info: IV_PLAT=linux
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 peer info: IV_PROTO=2
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 peer info: IV_NCP=2
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 peer info: IV_LZ4=1
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 peer info: IV_LZ4v2=1
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 peer info: IV_LZO=1
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 peer info: IV_COMP_STUB=1
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 peer info: IV_COMP_STUBv2=1
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 peer info: IV_TCPNL=1
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 Outgoing Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 Outgoing Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 Incoming Data Channel: Cipher 'AES-256-CBC' initialized with 256 bit key
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 Incoming Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-CHACHA20-POLY1305, 2048 bit RSA
Apr  5 14:10:55 ipfire openvpnserver[9132]: 192.168.7.2:43528 [testSSLH] Peer Connection Initiated with [AF_INET]192.168.7.2:43528
Apr  5 14:10:55 ipfire openvpnserver[9132]: testSSLH/192.168.7.2:43528 OPTIONS IMPORT: reading client specific options from: /var/ipfire/ovpn/ccd/testSSLH
Apr  5 14:10:55 ipfire openvpnserver[9132]: testSSLH/192.168.7.2:43528 MULTI_sva: pool returned IPv4=10.63.16.6, IPv6=(Not enabled)
Apr  5 14:10:55 ipfire openvpnserver[9132]: testSSLH/192.168.7.2:43528 MULTI: Learn: 10.63.16.6 -> testSSLH/192.168.7.2:43528
Apr  5 14:10:55 ipfire openvpnserver[9132]: testSSLH/192.168.7.2:43528 MULTI: primary virtual IP for testSSLH/192.168.7.2:43528: 10.63.16.6
Apr  5 14:10:56 ipfire openvpnserver[9132]: testSSLH/192.168.7.2:43528 PUSH: Received control message: 'PUSH_REQUEST'
Apr  5 14:10:56 ipfire openvpnserver[9132]: testSSLH/192.168.7.2:43528 SENT CONTROL [testSSLH]: 'PUSH_REPLY,route 10.63.16.1,topology net30,ping 10,ping-restart 60,redirect-gateway,route 192.168.7.0 255.255.255.0,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,ifconfig 10.63.16.6 10.63.16.5,peer-id
So far OK in my opinion...

EDIT:
Beneath info. It seems that the setcaps commands are not needed to operate in transparent mode also with lowered privileges (sslh instead of root) if 'LIBCAP=1' is set.

Best,

UE
Image
Image

digger
Posts: 18
Joined: August 13th, 2017, 10:32 am

Re: sslh version 1.8+

Post by digger » April 8th, 2019, 5:31 pm

I am also very interested in that tool, but I need the 32bit version. Would it be possible to compile it for old systems? My knowledge about that is very limited. Hints are very wellcome. @ummegge: Would you please be so kind and upload a ready to use version?
Greetings
digger

ummeegge
Community Developer
Community Developer
Posts: 5001
Joined: October 9th, 2010, 10:00 am

Re: sslh version 1.8+

Post by ummeegge » April 11th, 2019, 6:12 am

Hi digger,
sslh is available in Pakfire but an older version. If you want to check it out you can go for the first that way. My other build ENV (32bit) makes currently holiday in the eternity so am currently not able to build for 32bit (but am open for donations :D ). If i have more time i will push a reduced version (possibly without setcap commands but with LIBCAP=1) to Git may someone can build also a 32bit version. Otherwise, this should get soon to the dev mailinglist.

Best,

UE
Image
Image

cmisch
Posts: 8
Joined: June 2nd, 2012, 9:39 pm
Location: Germany

Re: sslh version 1.8+

Post by cmisch » April 11th, 2019, 7:07 pm

Hi

@ummeegge
add to your DEL_ROUTE_FUNCT()
ip route del local 0.0.0.0/0 dev lo table ${TABLE}
ip route flush cache

I would not recommend to run sshd on an internet reachable port.
You can ssh to your box after you connect via openvpn :-) (thats what i am doing)

Just tested my setup with external webserver on orange network.
To connect transparent to my webserver at orange network i added the following rules

Code: Select all

WEBSERVER=${LO}             # change to the IP of your webserver
WEBSERV_PORT=444            # change to port of your webserver
OVPN_PORT=442               # change to your port where openvpn is running

# Configuration options
DAEMON_OPTS="
--user sslh
-n --transparent
--listen 0.0.0.0:443
--tls ${WEBSERVER}:${WEBSERV_PORT}
--openvpn ${LO}:${OVPN_PORT}
--pidfile /var/run/sslh.pid
-C /var/empty
"

SET_ROUTE_FUNCT()
        # after ip route flush cache
        iptables -t mangle -N SSLH
        iptables -t mangle -A SSLH -j MARK --set-mark 0x1
        iptables -t mangle -A SSLH -j ACCEPT
        iptables -t mangle -I PREROUTING -p tcp -s ${WEBSERVER} --sport ${WEBSERV_PORT} -j SSLH

DEL_ROUTE_FUNCT()
        # after fi
        ip route del local 0.0.0.0/0 dev lo table ${TABLE}
        iptables -t mangle -D PREROUTING -p tcp -s ${WEBSERVER} --sport ${WEBSERV_PORT} -j SSLH
        iptables -t mangle -F SSLH
        iptables -t mangle -X SSLH
        ip route flush cache
This works for my setup and the webserver get's the "real IP od the client!

Cannot check if setcap is needed (but i assume).
Cannot remove the capabilities on the installed files?!?

Code: Select all

setcap -r /usr/sbin/sslh-select
Failed to set capabilities on file `/usr/sbin/sslh-select' (No data available)
usage: setcap [-q] [-v] (-r|-|<caps>) <filename> [ ... (-r|-|<capsN>) <filenameN> ]

 Note <filename> must be a regular (non-symlink) file.
EDIT:
Looks like you are right that the setcaps commands are not needed to operate in transparent mode!
This error is raised because there are no capabilities are set on /usr/sbin/sslh-select

Code: Select all

[root@ipfire ~]# setcap -r /usr/sbin/sslh-fork
Failed to set capabilities on file `/usr/sbin/sslh-fork' (No data available)
usage: setcap [-q] [-v] (-r|-|<caps>) <filename> [ ... (-r|-|<capsN>) <filenameN> ]

 Note <filename> must be a regular (non-symlink) file.
[root@ipfire ~]# setcap cap_net_bind_service,cap_net_admin+pe /usr/sbin/sslh-fork
[root@ipfire ~]# setcap -r /usr/sbin/sslh-fork
[root@ipfire ~]#

digger
Posts: 18
Joined: August 13th, 2017, 10:32 am

Re: sslh version 1.8+

Post by digger » April 12th, 2019, 7:35 am

Good morning!

@ummeege thank you for reply.



Best,
digger

Post Reply