Make traffic unblockable

[kim0]

Governments are currently able to detect and block stubby traffic. My stubby configuration was working one day, and the next it totally stopped. AFAICT, it is being blocked now.

This is all I get from the log file

[22:52:20.214071] STUBBY: 185.49.141.37                            : Conn closed: TLS - Resps=     0, Timeouts  =     1, Curr_auth =   None, Keepalive(ms)=     0
[22:52:20.214135] STUBBY: 185.49.141.37                            : Upstream   : TLS - Resps=     0, Timeouts  =   140, Best_auth =   None
[22:52:20.214210] STUBBY: 185.49.141.37                            : Upstream   : TLS - Conns=     0, Conn_fails=     0, Conn_shuts=      0, Backoffs     =     0
[22:52:20.214600] STUBBY: 149.112.112.112                          : Conn opened: TLS - Strict Profile
[22:52:20.214642] STUBBY: 9.9.9.9                                  : Conn closed: TLS - Resps=     0, Timeouts  =     1, Curr_auth =   None, Keepalive(ms)=     0
[22:52:20.214700] STUBBY: 9.9.9.9                                  : Upstream   : TLS - Resps=     0, Timeouts  =   140, Best_auth =   None
[22:52:20.214781] STUBBY: 9.9.9.9                                  : Upstream   : TLS - Conns=     0, Conn_fails=     0, Conn_shuts=      0, Backoffs     =     0
[22:52:20.214996] STUBBY: 145.100.185.15                           : Conn opened: TLS - Strict Profile
[22:52:20.215686] STUBBY: 149.112.112.112                          : Conn closed: TLS - Resps=     0, Timeouts  =     1, Curr_auth =   None, Keepalive(ms)=     0
[22:52:20.215741] STUBBY: 149.112.112.112                          : Upstream   : TLS - Resps=     0, Timeouts  =   140, Best_auth =   None
[22:52:20.215885] STUBBY: 149.112.112.112                          : Upstream   : TLS - Conns=     0, Conn_fails=     0, Conn_shuts=      0, Backoffs     =     0
[22:52:20.216512] STUBBY: 145.100.185.15                           : Conn closed: TLS - Resps=     0, Timeouts  =     1, Curr_auth =   None, Keepalive(ms)=     0
[22:52:20.216723] STUBBY: 145.100.185.15                           : Upstream   : TLS - Resps=     0, Timeouts  =   141, Best_auth =   None
[22:52:20.216762] STUBBY: 145.100.185.15                           : Upstream   : TLS - Conns=     0, Conn_fails=     0, Conn_shuts=      0, Backoffs     =     0

and a tcpdump trace show those lovely reset packets

00:49:07.824386 IP 192.168.0.151.64617 > 185.49.141.37.853: Flags [S], seq 3556613362, win 65535, options [mss 1452,nop,wscale 5,nop,nop,TS val 1620577452 ecr 0,sackOK,tfo  cookiereq], length 0
00:49:07.930117 IP 185.49.141.37.853 > 192.168.0.151.64617: Flags [S.], seq 28933522, ack 3556613363, win 65535, options [mss 1432,nop,wscale 6,sackOK,TS val 3772144803 ecr 1620577452], length 0
00:49:07.930281 IP 192.168.0.151.64617 > 185.49.141.37.853: Flags [R], seq 3556613363, win 0, length 0
00:49:08.647125 IP 192.168.0.151.64623 > 185.49.141.37.853: Flags [S], seq 2416128189, win 65535, options [mss 1452,nop,wscale 5,nop,nop,TS val 1620578266 ecr 0,sackOK,tfo  cookiereq], length 0
00:49:08.778047 IP 185.49.141.37.853 > 192.168.0.151.64623: Flags [S.], seq 3750967884, ack 2416128190, win 65535, options [mss 1432,nop,wscale 6,sackOK,TS val 867156840 ecr 1620578266], length 0
00:49:08.778129 IP 192.168.0.151.64623 > 185.49.141.37.853: Flags [R], seq 2416128190, win 0, length 0

although strangely I am able to telnet to port 853 successfully! Please consider adopting techniques to avoid blocking of stubby traffic.

[wtoorop]

Thank you for reporting this Ahmed,

On the Test server list, there are a few servers that offer DNS-over-TLS on port 443 (https). Have you tried those? I.e.:

upstream_recursive_servers:
# dns.cmrg.net server using Knot resolver. Warning - has issue when used for
# DNSSEC. (This also listens on port 443)
  - address_data: 199.58.81.218
    tls_port: 443
    tls_auth_name: "dns.cmrg.net"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 3IOHSS48KOc/zlkKGtI46a9TY9PPKDVGhE3W2ZS4JZo=
      - digest: "sha256"
        value: 5zFN3smRPuHIlM/8L+hANt99LW26T97RFHqHv90awjo=
# Lorraine Data Network  (self-signed cert). Also listens on port 443.
  - address_data: 80.67.188.188
    tls_port: 443
    tls_pubkey_pinset:
      - digest: "sha256"
        value: WaG0kHUS5N/ny0labz85HZg+v+f0b/UQ73IZjFep0nM=

Do you have suggestions on how to work around this kind of hampering?

[kim0]

Thanks! I just tried the 2 servers with the configuration you gave me, and they still seem blocked.

[11:34:51.518403] STUBBY: 80.67.188.188                            : Conn opened: TLS - Strict Profile
[11:34:51.521711] STUBBY: 80.67.188.188                            : Conn closed: TLS - Resps=     0, Timeouts  =     1, Curr_auth =   None, Keepalive(ms)=     0
[11:34:51.522218] STUBBY: 80.67.188.188                            : Upstream   : TLS - Resps=     0, Timeouts  =    33, Best_auth =   None
[11:34:51.522443] STUBBY: 80.67.188.188                            : Upstream   : TLS - Conns=     0, Conn_fails=     0, Conn_shuts=      0, Backoffs     =     0
[11:35:08.006493] STUBBY: 199.58.81.218                            : Conn opened: TLS - Strict Profile
[11:35:08.007608] STUBBY: 199.58.81.218                            : Conn closed: TLS - Resps=     0, Timeouts  =     1, Curr_auth =   None, Keepalive(ms)=     0
[11:35:08.007672] STUBBY: 199.58.81.218                            : Upstream   : TLS - Resps=     0, Timeouts  =    34, Best_auth =   None
[11:35:08.007738] STUBBY: 199.58.81.218                            : Upstream   : TLS - Conns=     0, Conn_fails=     0, Conn_shuts=      0, Backoffs     =     0

I suppose the whole point of this project is to help users achieve better privacy from ISP/Gov snooping. And when those guys can't snoop, they detect and block the traffic (at least in some unfortunate countries). Thus I am suggesting to make the goal of being "unblockable" one of the main goals of this project.

How to achieve this, is a hard question, one that I'm hardly qualified to answer. I am sure hundreds of security/privacy experts will contribute code/ideas to further improve the situation. For starters, it would help if the protocol level handshake is not recognizable from HTTPS (browser) traffic. Perhaps integrating a "pluggable transport" like Tor does would be a good idea. The evasion techniques is an arms race, which will keep evolving.

Thanks for a great product .. Wish I could use it more.

[ArchangeGabriel]

Well indeed apart from using the 443 port (which I also do because 53/853 are blocked in numerous places), there is not a lot you can do (assuming this is already undistinguishable from HTTPS requests, but maybe I’m wrong on this).

Ironically, maybe IP-over-DNS could save you, so in the end that would be DNS-over-IP-over-DNS. Let me explain this: you have two upstream DNS server, the normal one and the “VPN” one. Whenever you need to reach outside while dodging censorship, you send “false” DNS requests to the local network resolver, which then forward them to the corresponding DNS authority, that happen to be your “VPN” DNS server. This server decodes the network packets hidden in the DNS query, and send them to the global network for you. Then it forwards the replies back to you as the answer to your initial DNS query.

As you guessed, latencies are quite high and bandwith quite low, but I would use it just to tunnel the real DNS traffic. So schematically:

Your computer → False DNS queries encapsulating the real ones, encrypted → Local Resolver → Your authoritative server → Decrypt and resolves the actual query, send it back encrypted to → Local Resolver → Your computer.

Note that in this context DNS-over-TLS is useless (at least at your computer level), you’re already encrypting your traffic toward an upstream you control (which can then use DNS-over-TLS to reach outside, but not necessarily).

[hanvinke]

What about the ipv6 servers, also being blocked?

[kim0]

ipv6 is not available for almost any connection type. Only ipv4 works here. But if ISPs were to offer ipv6 soon, it's not hard to imagine the same DPI equipment would detect and block the same streams over ipv6. It's almost trivial for them to do so.

[hanvinke]

A pity there is no other solution for the moment. Maybe of some help to you:

If you are by any chance using the newest OpenSSL version 1.1.1 (since you can telnet to port 853) you can only use Stubby in strict mode in conjunction with the GetDNS-1.3.0 release. With OpenSSL version 1.1.1 and older than version 1.3.0 GetDNS releases Stubby only works in opportunistic mode, strict mode will fail completely.

The best solution currently is therefore to use OpenSSL version 1.1.1 with GetDNS-1.3.0 release. Both strict mode and opportunistic mode then work flawlessly with the highest available security.

A good site to test the SSL/TLS Capabilities of your Browser : https://www.ssllabs.com/ssltest/viewMyClient.html

On https://en.internet.nl you can test your connection.

[saradickinson]

Thanks for this report - sorry to hear you are hitting problems. I'm slightly confused by the logs because if the connections were being RESET as shown then I would expect to see stubby reporting connection failures, not timeouts. In fact it looks like the TCP handshake is being blocked in your tcpdump - do you see the same thing when trying on port 443? If so I think that means any blocking is at the IP address level :-( (Note that the server at 199.58.81.218 is currently offline and has been for a while, but the other one serving port 443 is up). You can check the status of the servers here: https://dnsprivacy.org/jenkins/job/dnsprivacy-monitoring/

Mentions for other possible solutions are given here: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+-+The+Solutions The ones available today are DNSCrypt and proxying traffic over HTTP using the BII implementation. Would be interesting to see if those work for you.

[wtoorop]

Is suppose currently DoH on an IP hosting many other popular websites would deal with this effectively too. Closing ticket.