[sslh] Better --transparent way on Linux

[Jan Moesen]

> To confirm I understood this right, I can supress all the
> instructions in doc/config.md from line 124 to 185, and
> replace them with just:
> 
>>      ip -6 rule add from ::1 lookup 100
>>      ip -6 route add local ::/0 dev lo table 100
> 
>> ip rule add from 127.0.0.1 lookup 100
>> ip route add local 0.0.0.0/0 dev lo table 100
> 
> Is that correct?

I tried this approach on my server for jan.moesen.nu, and while it seems 
to work fine for external connections, I cannot reach the multiplexed 
SSH and SSL servers from the host itself. I.e., I can reach 
jan.moesen.nu just fine from outside, but not when I SSH into the server 
(called purplepixelhost in the log snippets below) and try to reach it 
from there. Neither via localhost/127.0.0.1 or jan.moesen.nu/37.187.45.81.

E.g.

@home-computer $ curl --head https://jan.moesen.nu/
HTTP/1.1 200 OK

@purplepixelhost $ curl --head https://jan.moesen.nu/
curl: (35) gnutls_handshake() failed: The TLS connection was 
non-properly terminated.

@purplepixelhost $ curl --head https://localhost/
curl: (35) gnutls_handshake() failed: The TLS connection was 
non-properly terminated.

(Similar results when using the server as a SOCKS proxy with `ssh -D` 
and surfing through that proxy.)


This is what the successful attempt when coming from external IP, like 
my home computer, looks like in syslog and the access.log:

Dec 13 22:55:11 purplepixelhost sslh[5406]: connection from 
12-34-56-78.access.telenet.be:39746 to purplepixelhost.moesen.nu:https 
forwarded from 12-34-56-78.access.telenet.be:39746 to 
localhost.localdomain:snpp

12.34.56.78 jan.moesen.nu - [13/Dec/2019:22:54:20 +0100] "HEAD / 
HTTP/1.1" 200 0 "-" "curl/7.64.1"


And here are those unsuccesful attempts when coming from the localhost:

Dec 13 22:56:52 purplepixelhost sslh[5406]: bind:98:Address already in use
Dec 13 22:56:52 purplepixelhost sslh[5406]: bind_peer:98:Address already 
in use
Dec 13 22:56:52 purplepixelhost sslh[5406]: connect: Address already in use
Dec 13 22:57:26 purplepixelhost sslh[5406]: bind:98:Address already in use
Dec 13 22:57:26 purplepixelhost sslh[5406]: bind_peer:98:Address already 
in use
Dec 13 22:57:26 purplepixelhost sslh[5406]: connect: Address already in use


I do not understand what address is already in use. (Might be useful to 
add that to the log message.) When I check netstat for what is occupying 
the relevant ports, it says:

# netstat -lnp | egrep ':(22|222|443|444)\b' | column -t
tcp   0  0  0.0.0.0:22     0.0.0.0:*  LISTEN  5347/sshd
tcp   0  0  0.0.0.0:443    0.0.0.0:*  LISTEN  5406/sslh
tcp   0  0  127.0.0.1:444  0.0.0.0:*  LISTEN  5447/lighttpd
tcp   0  0  0.0.0.0:222    0.0.0.0:*  LISTEN  5347/sshd
tcp6  0  0  :::22          :::*       LISTEN  5347/sshd
tcp6  0  0  :::222         :::*       LISTEN  5347/sshd

So that is sshd listening on port 22 and 222 on all addresses, lighttpd 
on port 444 only on 127.0.0.1, and sslh on port 443.


sslh is started with the following parameters:

DAEMON_OPTS="--user sslh --transparent --on-timeout ssl --listen 0:443 
--ssh 127.0.0.1:22 --ssl 127.0.0.1:444 --pidfile /var/run/sslh/sslh.pid"


I executed those `ip rule` and `ip route` commands that are the subject 
of this thread:

# ip rule add from 127.0.0.1 lookup 100; ip route add local 0.0.0.0/0 
dev lo table 100; ip -6 rule add from ::1 lookup 100; ip -6 route add 
local ::/0 dev lo table 100


Lighttpd is listening on port 80 (irrelevant) and on port 444 using this 
configuration directive:

$SERVER["socket"] == "127.0.0.1:444" {



When I try to access Lighttpd on port 444 from the localhost, it *does* 
work:

$ curl --head --insecure -H 'Host: jan.moesen.nu' https://localhost:444/
HTTP/1.1 200 OK



TL;DR: SSLH to multiplex SSH and SSL/TLS works fine. Transparent 
proxying works fine, too, but only for external connections. From 
localhost (even using the external IP), SSLH tries to bind to an address 
that is already in use. (No idea which. Its own address again?)

Anyone have an idea of what is going wrong/what I am doing wrong?

Cheers, and thanks for all the work so far,

Jan