New Target Extension OBSF
PATCH 1/1 New Target Extension OBSF
This modules does two things:
1) it encrypts UDP traffic.
2) it adds false bytes(padding).
Its purpose is to escape smarter DPIs which blocks certain kinds of packets by several heuristic methods.
Its purpose is not providing security or prevent man in a middle attack.
Still to do:
1) Add AES support.
2) False bytes addition or removal.
3) Write userspace plugin.
extensions/Kbuild +1 -0
@@ -35,6 +35,7 @@ obj-${build_pknock} += pknock/ obj-${build_psd} += xt_psd.o obj-${build_quota2} += xt_quota2.o +obj-${build_OBSF} += xt_OBSF.o -include ${M}/*.Kbuild -include ${M}/Kbuild.*
extensions/xt_OBSF.c new file +148 -0
148 lines not on this page · raw message
extensions/xt_OBSF.h new file +32 -0
@@ -0,0 +1,32 @@ +#ifndef _LINUX_NETFILTER_XT_OBSF_H +#define _LINUX_NETFILTER_XT_OBSF_H 1 + +#define XT_OBSF_MAX_KEY_LEN 32 +enum { +XT_OBSF_ENC_ARC4 =1 <<0 , +XT_OBSF_ENC_AES =1 <<1 , +XT_OBSF_PAD_STATIC =1 <<2 , +XT_OBSF_PAD_RANDOM =1 <<3 , +XT_OBSF_ENC_ENC =1 <<4 , +XT_OBSF_ENC_DEC =1 <<5 , +XT_OBSF_PAD_ADD =1 <<6 , +XT_OBSF_PAD_REM =1 <<7 +}; + +struct xt_OBSF_tginfo { +__u8 flags; +__u8 key[XT_OBSF_MAX_KEY_LEN ]; +__u8 key_len; +struct xt_obsf_priv *priv; +}; + +struct xt_OBSF_tginfo_v1 { +__u8 flags; +__u8 key[XT_OBSF_MAX_KEY_LEN ]; +__u8 key_len; +__u8 start; +__u8 end; +struct xt_obsf_priv *priv; +}; + +#endif /* _LINUX_NETFILTER_XT_OBSF_H */
mconfig +1 -0
@@ -26,3 +26,4 @@ build_pknock=m build_psd=m build_quota2=m +build_OBSF=m
Quoted 6 lines · aft
1) it encrypts UDP traffic.
2) it adds false bytes(padding).Its purpose is to escape smarter DPIs which blocks certain kinds of packets by several heuristic methods.
But then why not use IPsec (udpencap), OpenVPN, or something? After all, you do already need a cooperating peer to decrypt your traffic, and hence might as well pick a _standardized_ solution.
If all you want is evading some DPI gateways, I guess even the lowly XOR non-encryption scheme will sufficiently work.
Quoted 9 lines
extensions/xt_OBSF.c new file +9
-0+static struct xt_target obsf_tg_reg[]__read_mostly = { + { + .name ="OBSF" , + .family =NFPROTO_UNSPEC , + .target = obsf_tg, + .checkentry = obsf_tg_check, + .targetsize =sizeof (struct xt_OBSF_tginfo ), + .me =THIS_MODULE , + },
extensions/xt_OBSF.c line 134
Quoted 10 lines
extensions/xt_OBSF.c new file +10
-0+ { + .name = "OBSF", + .revision = 1, + .family = NFPROTO_UNSPEC, + .target = obsf_tg_v1, + .targetsize = sizeof(struct xt_OBSF_tginfo_v1), + .checkentry = obsf_tg_check_v1, + .me = THIS_MODULE, + }, +};
There is no need to use two revisions.
Quoted 6 lines · Jan Engelhardt
Quoted 4 lines · aft
1) it encrypts UDP traffic.
2) it adds false bytes(padding).
Quoted 7 lines
Quoted 2 lines
Its purpose is to escape smarter DPIs which blocks certain kinds of packets by several heuristic methods.
But then why not use IPsec (udpencap), OpenVPN, or something? After all, you do already need a cooperating peer to decrypt your traffic, and hence might as well pick a _standardized_ solution.
The client does not support IPsec.
Quoted 3 lines
If all you want is evading some DPI gateways, I guess even the lowly XOR non-encryption scheme will sufficiently work.
XOR used to work, but DPIs recently started detecting XORed packets.
Quoted 13 lines
Quoted 13 lines
extensions/xt_OBSF.c new file +13
-0+static struct xt_target obsf_tg_reg[]__read_mostly = { + { + .name ="OBSF" , + .family =NFPROTO_UNSPEC , + .target = obsf_tg, + .checkentry = obsf_tg_check, + .targetsize =sizeof (struct xt_OBSF_tginfo ), + .me =THIS_MODULE , + }, + { + .name ="OBSF" , + .revision =1 , + .family =NFPROTO_UNSPEC ,
Quoted 9 lines
extensions/xt_OBSF.c line 134
Quoted 6 lines
extensions/xt_OBSF.c new file +6
-0+ .target = obsf_tg_v1, + .targetsize = sizeof(struct xt_OBSF_tginfo_v1), + .checkentry = obsf_tg_check_v1, + .me = THIS_MODULE, + }, +};There is no need to use two revisions.
Well, i thought there are times when you will not inject false bytes, just encryption will suffices. That's why i've made
Two versions. When to make two versions is not really clear to me.
My idea was, a feature will always available, and another feature will be available on demand, So better divide it in two versions.
I will change it and post the patch.
cheers.
Signature · 1 line
-aft
Quoted 8 lines · Aft nix
Quoted 6 lines · Jan Engelhardt
Quoted 4 lines · aft
1) it encrypts UDP traffic.
2) it adds false bytes(padding).
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Its purpose is to escape smarter DPIs which blocks certain kinds of packets by several heuristic methods.
But then why not use IPsec (udpencap), OpenVPN, or something? After all, you do already need a cooperating peer to decrypt your traffic, and hence might as well pick a _standardized_ solution.
The client does not support IPsec.
Why would it not? If you can make kernel changes, you can as well run a simple userspace program. (Example for a userspace program that does IPsec using tun interface: vpnc.)
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
extensions/xt_OBSF.c new file +11
-0+ }, + { + .name = "OBSF", + .revision = 1, + .family = NFPROTO_UNSPEC, + .target = obsf_tg_v1, + .targetsize = sizeof(struct xt_OBSF_tginfo_v1), + .checkentry = obsf_tg_check_v1, + .me = THIS_MODULE, + }, +};
Quoted 5 lines
Quoted 1 line
There is no need to use two revisions.
Well, i thought there are times when you will not inject false bytes, just encryption will suffices. That's why i've made
Two versions. When to make two versions is not really clear to me.
A new ABI is needed when the struct you are using to pass options such as "pad or not" does not suffice to hold your option data any more.
Quoted 17 lines · Jan Engelhardt
Quoted 15 lines · Aft nix
Quoted 12 lines · Jan Engelhardt
Quoted 6 lines · aft
1) it encrypts UDP traffic.
2) it adds false bytes(padding).Its purpose is to escape smarter DPIs which blocks certain kinds of packets by several heuristic methods.
But then why not use IPsec (udpencap), OpenVPN, or something? After all, you do already need a cooperating peer to decrypt your traffic, and hence might as well pick a _standardized_ solution.
Quoted 5 lines
Quoted 1 line
The client does not support IPsec.
Why would it not? If you can make kernel changes, you can as well run a simple userspace program. (Example for a userspace program that does IPsec using tun interface: vpnc.)
I'm doing these in Server's kernel. The client is a mobile device. AES/ARC4 are implemented in the client application directly.
Quoted 15 lines
Quoted 15 lines
Quoted 14 lines
extensions/xt_OBSF.c line 134
Quoted 12 lines
extensions/xt_OBSF.c new file +11
-0+ }, + { + .name = "OBSF", + .revision = 1, + .family = NFPROTO_UNSPEC, + .target = obsf_tg_v1, + .targetsize = sizeof(struct xt_OBSF_tginfo_v1), + .checkentry = obsf_tg_check_v1, + .me = THIS_MODULE, + }, +};There is no need to use two revisions.
Quoted 7 lines
Quoted 3 lines
Well, i thought there are times when you will not inject false bytes, just encryption will suffices. That's why i've made
Two versions. When to make two versions is not really clear to me.A new ABI is needed when the struct you are using to pass options such as "pad or not" does not suffice to hold your option data any more.
I've changed it in my recent version, see newer pathces, where i changed it to reflect your suggestion.
Thanks for clearing that out. I had a confused conception about when to use more than one DS.
Signature · 1 line
-aft