SIP005 - TCP MD5SIG to counter TCP RST MitM attack about shadowsocks-org HOT 11 CLOSED

Despite the insecure MD5 problem, can TCP_MD5SIG be used on Windows? I suspect it. I've searched for a while and have found none so far. We need a cross platform solution.

In order to defend TCP against spurring attacks, we need to somehow authenticate the TCP header. I think @clowwindy has already pointed us the direction with ShadowVPN.

from shadowsocks-org.

@Mygod OKay, I just forget there are Windows users.

Although it's more-or-less the same suituation for multipath TCP, or even TCP fast open.
Multipath TCP is even not supported in mainline linux, and Windows doesn't support fast open until Windows 10.

While they are both supported by ss-libev.
Although TCP_MD5SIG, unlike MPTCP or fast open, will cause network stack to directly drop unauthenticated segments without fallback method.

Any authentication against TCP or IP header has their problem in fact.
They both exposed special flag for their header, making it quite easy to be detected and blocked.

from shadowsocks-org.

Yes and so we can use UDP to work around this problem. (ShadowVPN tunnels IP packets over UDP)

I think for now using kcptun plugin is the best choice to work around TCP reset attacks.

@madeye What do you think?

from shadowsocks-org.

TCP reset attack is already not a "popular" approach. Today, If one IP gets detected, all the traffic from it is just dropped or null routed.

But like MPTCP and TCP fast open, if we can easily add it to shadowsocks, I think it would be useful to someone.

For example, with MPTCP, OVH is able to provide a product named "Overthebox" based on shadowsocks. It's quite useful if you have multiple up-links. Here are some details: http://bitsofnetworks.org/ovhs-overthebox-internet-access-link-aggregation-using-multipath-tcp.html

from shadowsocks-org.

@Mygod Makes sense.

There are a lot of advantage using UDP, from full control of the stack to no need to wait kernel to accept some feature.

@madeye For implementation, it should be quite easy. Both client and server setup their pre-shared key(could just hash the password), call setsockopt(), ~~~and hope everything works fine~~~ that's all.
At least for linux kernel, it's more popular than TCP fast open.

I'll wait for some time before sending out the patch, to see if it's really needed.

Thanks

from shadowsocks-org.

The downside of UDP tunneling is that UDP packets are dropped and traffic-shaped heavily on many ISPs. It's barely usable during peak hours when ISPs give higher priority to TCP packets.

from shadowsocks-org.

I worked with TCP_MD5SIG (on the kernel side) at a network switch company a while ago. There is a huge limitation here to be kept in mind: TCP_MD5SIG (RFC 2385) was invented to protect protocols like BGP -- where ports of both clients and servers are known and fixed, so the implementations (Linux for example) require users to bind on both client and server sides, and provide the <key, peer sockaddr (addr+port)> mappings to kernel. And no, it does not support "default key" lookup. In the context of common C/S architectures like Shadowsocks, the client address and port are unknown in advance, rendering this protection useless at least on Linux.

Furthermore, as one might have noticed, MD5 is dated and in fact, RFC 2385 has been obsoleted by RFC 5925, TCP-AO, which unfortunately is not yet supported on consumer OSes AFAIK. Being an obsolete (and undocumented) feature, MD5SIG might be removed from Linux kernel at any time.

Here's a useful article I found talking from the userland if you are interested https://criticalindirection.com/2015/05/12/tcp_md5sig/

from shadowsocks-org.

@Hexcles So this proposal is dead end?

from shadowsocks-org.

from shadowsocks-org.

Understand. Thanks for the explanation!

I really wish it'd be easier to manipulate raw IP packets from userspace…

from shadowsocks-org.

I think it's safe to close this now.

from shadowsocks-org.