The MASK_HOST {host.here} is not TLS 1.3 host, this is not recommended

[MasterGroosha]

What does it mean? I see MASK_HOST is taken as TLS_DOMAIN, do I really need it?

Also a quick example how to set proxy behind nginx along with real website is highly appreciated!

[alexbers]

The proxy will be work with any MASK_HOST, but it will be detectable. The more detailed description is on https://github.com/alexbers/mtprotoproxy/issues/130.

Here are some examples how to set the proxy behind nginx: https://github.com/alexbers/mtprotoproxy/pull/119

Something like this:

stream {
        map $ssl_preread_server_name $name {
                google.com mtproxy;
                default https;
        }
        upstream mtproxy {
                server 127.0.0.1:3256;
        }
        upstream https {
                server 127.0.0.1:8443;
        }
        upstream e1 {
                server e1.ru:443;
        }
        server {
                listen 443 reuseport;
                listen [::]:443 reuseport;
                proxy_pass $name;
                proxy_protocol on;
                ssl_preread on;
        }

        server {
                listen 8443 reuseport proxy_protocol;
                proxy_pass e1;
        }
}

With HAProxy it looks a bit simpler.

[MasterGroosha]

@alexbers Pardon my dumbness, but I still don't understand what I should change to fix this "problem". The best thing which comes to my mind is putting an nginx with a real website with TLS v1.3 support and somehow making mtproxy accessible on the same port [how?]

Is disabling MASK at all a good solution? If yes, why MASK_HOST defaults to TLS_DOMAIN?

[alexbers]

You should change the TLS_DOMAIN, for random site with tls 1.3 support, for example alexbers.com.

The proxy-server will be proxying "bad" clients to this host. This is needed to protect the proxy against active attacks, for example if scanner will try to distinguish a real TLS server from the fake TLS server by sending sophisticated TLS packets and look on the answers.

If the MASK is disabled, the proxy will be more detectable, but it will work though.

[MasterGroosha]

But if I set a "random" site, it will be more detectable, won't it? Imagine my proxy is located on 100.100.100.100 IP. When scanner tries to establish connection to that server and gets "example.com" as MASK_HOST, a simple DNS query will reveal that there is no "example.com" on 100.100.100.100.

[alexbers]

The active scanner doesn't know the server name to put in SNI field in the TLS client hello packet to make a server provide a proper certificate. To get the server name, the active scanner should be integrated with the passive one to get a set of server names.

In general this is possible to block with the method you describe but many things will break:

1. The DNS servers can resolve single host name to different IP addresses, for example, depending on client location like CDNs or for load balancing/fallback purposes
2. The companies often have private DNS servers which doesn't accessible from the outside. They can resolve some hostnames to public ips also (e.g. in DMZ)
3. The hosts can have more than one IP addresses with a webserver listening on all interfaces

Also you can set the TLS_DOMAIN to some name (e.g. google.com) and MASK_HOST to some different server (e.g. ya.ru). It will be very impractical to block those hosts because in this case it became possible to block any host in the internet just by sending requests to it with wrong hostnames.

[MasterGroosha]

So I don't have to put my real domain (whics resolves to the IP of myproxy), but use any domain with proper TLS v1.3 instead?

[alexbers]

Yes, you can put any domain in TLS_DOMAIN and any valid tls 1.3 host in the MASK_HOST. By default the MASK_HOST is equal to TLS_DOMAIN

[Allineer]

Sorry, but...

1. I put some (non-existed) domain in TLS_DOMAIN
2. I use correct (another) TLS 1.3 domain in MASK_HOST
3. mtprotoproxy still prints warning for me: The MASK_HOST ... is not TLS 1.3 host, this is not recommended

At the same time, https://www.ssllabs.com/ssltest/analyze.html?d=MASK_HOST says that everything is fine:

What am I doing wrong?

RU: реально, ковыряюсь уже половину рабочего дня - виртуалку до Debian 10 обновил ради nginx 1.14.2 с поддержкой stream_ssl_preread_module - возможно, упускаю что-то совсем очевидное...

[alexbers]

May be the server sees the non-existing domain and fails to give a proper certificate.

If you tell your TLS_DOMAIN and MASK_HOST I can try to debug an issue. I am @bay3255 in tg

[uv-strich]

@Allineer As far as I understand, nginx itself might be the culprit, quoth this article:

NGINX is capable of forwarding PROXY protocol via stream module. <...> However, nginx SSL stream + Varnish listening on PROXY protocol won’t support HTTP/2 because nginx SSL stream does not know how to negotiate ALPN proto.

Using ip-address instead of domain in MASK_HOST, though, does allow to get the certificate from the nginx server at that address. Some additional investigation in the similar vein (in regards to haproxy, though) - over there #119