featured transparent tcp/udp/ssl proxy https://www.smithproxy.org
Important: This is serious. Cryptographically you are allowing smithproxy to actually terminate TLS on itself, and opening a new TLS connection to your originally intended server.
For general information go here: www.smithproxy.org <<<
You can reach us also here:
Discord server
Discord server
Before you start with testing
You will see certificate on smithproxy startup. Copy this certificate, and add it in your browser trusted root CA list. This certificate will be used to sign spoofed target server certificates. Unless set, your browser experience will be really painful.
Important: This is serious. Cryptographically you are allowing smithproxy to actually terminate TLS on itself, and opening a new TLS connection to your originally intended server.
As the user, you are now only controlling security of the connection between you and smithproxy. The rest is not in your hand (it's in hands of smithproxy).
Then, you can then point your browser to port 1080, and test. You should not see much issues. Browsing is ok, and smithproxy is in its default config, which is intended for demonstration purposes (no OCSP, hacking features disabled).
After you are done with testing
I strongly recommend to remove previously added CA certificate from trusted root certificate authorities! Of course it applies to all places you did this, not only your browser.
Where to look further
All your files should be accessible from docker host, if you used volumes, as suggested above. I am mentioning here full paths how they look inside of container.
sxy volume
/etc/smithproxy/ - all config rulessmithproxy.cfg- policies and profiles. There is a ton and half of things to play with.users.cfg- user databases and realms (disabled by default)
sxyvar volume
/var/log/smithproxy* - various logging files.smithproxy.cfg- general logging of smithproxy daemon
sxydumps volume
/var/local/smithproxy/data - content writer target directory (disabled by default)smithproxy CLI
smithproxy_cli is your friend. Once you got CLI, type enable to elevate your privileges. CLI looks like this: root@pixie:/app# smithproxy_cli
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
--==[ Smithproxy command line utility ]==--
smithproxy(pixie) > en
Password:
smithproxy(pixie) #
smithproxy(pixie) # diag proxy session list
MitmProxy: l:tcp_192.168.122.1:54942 <+> r:tcp_109.233.72.84:80 policy: 1 up/down: 0/35.35M
MitmProxy: l:ssli_192.168.122.1:47030 <+> r:ssli_181.160.161.165:443 policy: 1 up/down: 0/0
MitmProxy: l:ssli_192.168.122.1:47040 <+> r:ssli_172.240.130.251:443 policy: 1 up/down: 0/12k
... yes, it's telnet to localhost. If you don't like it, submit patches. And yes, you can see actual connection speed in the rightmost column.
Restarting smithproxy
You might need it one day.
/etc/init.d/smithproxy restart
You will see many privilege-related errors. You can ignore them in this testing image. Image is intended to be used in non-privileged mode, therefore only SOCKS4 or SOCKS5 could be used. Transparent proxying might not work properly, as you need to route traffic directly to container.
