How does Syncthing handle its end-to-end security? (issues with MITM Forti SSL corporate firewall)

General
1

Dear all,

I know a little how Syncthing does its crypto-magic. It uses a custom BEP (Block Exchange Protocol) which is similair to Bittorrent. The nodes handshake with SSL/TLS in a strict mode on a custom non 443 port. When I use the non default port my two nodes don’t connect with a corporate firewall of Forti(gate) which basicly cuts an SSL/TLS connection for deep packet inspection (DPI) which is in practice an SSL/TLS MITM proxy. I never got it working to punch a hole in the firewall at work. So probably it seems als to inspect even on non 443 ports it is SSL/TLS traffic on those standard ports.

Does Syncthing something related to “SSL Pinning” for maximum security?

When I SSH to a machine from inside the corporate network and tunnel over SOCKS proxy with HTTP(s) with a browser everything works fine. Of course this works because SSH MITM firewall proxy server bullshit will choke the SSH connection because they do al kind of weird time based key rotation for sessions.

Sorry for my crying at this setup. But I would like to know how to punch a hole in the firewall to use Syncthing without much effort and a vanilla build. Worst case I can shoot an SSH tunnel and tunnel TCP over it and connect syncthing on both ends but that is boring.

Cheers all, and thanks for reading.

  • Xor-gate
2

Syncthing device IDs are essentially certificate pinning. It won’t work to have a MITM proxy (by design).

This will work, and may be your only an option if there’s no other way to get a TCP (or QUIC) connection through the firewall.

Edit: Actually, another option may be to use a relay. There’s some device ID authentication there as well of the relay, but it doesn’t really have to match anything apart from what Syncthing on the inside sees. It doesn’t matter if it’s MITM:ed, because we negotiate another TLS channel inside which the proxy should hopefully leave alone.

So, you might be able to set up a relay yourself, have your firewall-inside device connect to it, it will complain about the device ID mismatch, you change the expected device ID to suit, and then be good to go.

3

So basicly the relay makes an SSL connection to the MITM firewall proxy and on top of that the client connecting to the relay will “shoot another TLS channel through the relay via the firewall which is probably not intercepted because it is dual layer crypto” ?

I would prefer the last solution because it is semi-transparent for the client. And I don’t need to fight with keeping SSH tunnels alive under windows.

4

Something like that.

1 Like
5

Thanks @calmh !

6

However, this approach requires the certificate’s fingerprint of the MITM firewall to remain constant - otherwise you would have to keep adjusting your configs all the time. I don’t have enough experience with Fortigate to know whether it generates new certs all the time or keeps reusing them for a significantly long period.

It also won’t work if the MITM firewall sends more than one certificate (which isn’t unlikely, if it uses intermediates). Syncthing is hardcoded to expect only a single cert. syncthing/lib/relay/client/static.go at 1fc4c9d9c5eca92665d4b75ace8828140a9fcbe6 · syncthing/syncthing · GitHub

Aaaaand it looks like it also requires TLS ALPN negotation to succeed, with proto bep-relay. This will most likely not be the case with a MITM device:

1 Like
7

And to deal the final blow to this idea:

The relay authenticates its connected devices based on the sent client certificate:

A “Split TLS” proxy such as the Fortigate firewall will usually be unable to provide any client certificate. It cannot use the real client’s certificate (TLS security design prevents this), so the only thing it could do is to make up its own fake cert on the fly. This on the other hand means that the relay will compute a wrong device ID, which then means that session invitation/session joining won’t work since the IDs are all wrong.

Syncthing (and TLS in general) is really well designed to resist any kind of MITM :slight_smile:. Trying to do MITM for TLS inspection is a mistake in the first place IMHO. I know it’s not your fault though.

1 Like
8

Devil’s in the details! :smiley: Scrap that idea, then.

2 Likes
9

Thanks guys, I will try to punch a hole in the firewall with a persistent SSH tunnel for TCP and let Syncthing talk through it.

10

The certificates will be rotated because of expiry times. I’m not sure which expiry time it has set as I have not analyzed it. But then things break once in a time and I need to monitor that by hand which is a pain. The firewall ssl proxy certificate is pushed to the desktop system probably by Microsoft domain controller to the Windows certificate store. Yeah lets talk about the joy of PKI :frowning:

11

I’m in a corporate fight to let them know SSL MITM firewall “security” is a bad thing. I now also reference to this recommendation:

https://www.cisa.gov/news-events/alerts/2017/03/16/https-interception-weakens-tls-security

3 Likes
12

So the story did continue. The corporate SSL deep packet inspection (DPI) will still be enable for our VLAN. So its still possible to shoot a SSH SOCKS proxy to home and connect Syncthing through this as it is immune to SSL introspection.

The documentation is in sublime conditions for using proxies.

Basicly this means:

ssh -D 1337 -q -C -N jerry@<my home domain>.org # SSH Tunnel on windows with SSH on WSL (windows subsystem for linux) 


# And synctrayzor environment variables

export all_proxy=socks5://127.0.0.1:1337
export ALL_PROXY_NO_FALLBACK=1

https://docs.syncthing.net/users/proxying.html

Works like a charm. But the network is “super secure” with SSL DPI enabled! There is of course no hole to transfer data to the internet…

2 Likes