Syncting on Port 443 behind SSLH - configuration

I want Syncthing to listen on 443 on a machine with a preexisting HTTPS server. Here’s how I did it:

1: Install sslh. My version is 1.19c
2: modify /etc/sslh.conf (or /etc/default/sslh.conf) as follows:

protocols:
(
     { name: "regex"; host: "localhost"; port: "22000"; regex_patterns: ["syncthing"];},
     { name: "tls"; host: "localhost"; port: "443"; alpn_protocols: [ "h2", "http/1.1", "spdy/1", "spdy/2", "spdy/3" ];},
     { name: "ssh"; service: "ssh"; host: "localhost"; port: "22"; fork: true; }
#     { name: "anyprot"; host: "localhost"; port: "22000"; }
);

3: configure your HTTPS server to listen on localhost:443 (instead of 0.0.0.0:443)
4: run it with “sslh -F /etc/sslh.conf”
5: find out for yourself how to properly daemonize sslh on your machine so it runs on startup, otherwise the

A few notes:

  • Instead of the “regex” entry, it would also work to set the “anyprot” (= none-of-the-above-forwarding) to the Syncthing port. In this case, no other application can use the default case.
  • Adding the ALPN protocols to the “tls” entry is necessary to forward all HTTPS traffic to Apache. Without the protocol list, the Syncthing TLS handshake is forwarded to Apache as well. In this case the following error appeared in my log: Got peer certificate list of length 2 != 1 from peer.
  • I don’t know if Syncthing sends an ALPN protocol string. If so, one could replace the Syncthing “regex” entry with an entry like {name: "tls"; host: "localhost"; port "22000"; alpn_protocols: ["$syncthing_protocol_identifier"];}.
    Does Syncthing transmit an ALPN protocol ID?

Background: I have an IPv4-only node behind a restrictive firewall which filters most outgoing ports except for a few standard ports like 443. Relaying works fine but in my case I prefer a direct connection.

2 Likes

Yes. It’s bep/1.0 (acronym for Block Exchange Protocol v1).

Remark: Be aware that not all TLS implementations support ALPN. Syncthing implementations based on Go generally support this, but (future?) third party clients may not. Also, minor https implementations (bots etc) will often not use or support ALPN, so if you want to support these cases, have a default/fallback configured.

1 Like

Thanks, bep/1.0 works fine.

Per your remark: Good hint. I added the “regex” case as fallback.

2 Likes