kiron1 / proxydetox Goto Github PK

A http proxy which can evaluate PAC files and forward to the correct parent proxy with authentication

Home Page: https://proxydetox.colorto.cc

License: Other

Shell 1.68% Rust 76.72% Makefile 0.18% JavaScript 0.03% HTML 1.38% Batchfile 0.21% PowerShell 0.32% Starlark 10.91% Swift 6.87% CSS 0.57% Python 1.12%

gssapi http https hyper kerberos proxy rust sspi tokio

proxydetox's People

Contributors

Stargazers

Watchers

Forkers

simshrock shkuviak amoshydra

proxydetox's Issues

myIPAddress() not implemented?

Hello,

I am trying to setup proxydetox in an enterprise environment with a proxy.pac URL and kerberos authentication.
When an access is made, the follwoing error is dumped, and the client gets an empty answer.

thread 'tokio-runtime-worker' panicked at 'duk error: uncaught: 'identifier \x27myIpAddress\x27 undefined''

A call to myIpAddress() is indeed used in the proxy.pac file, and if I retrieve it, store it locally and modify the pac file to use an IP value instead of calling the function, everything works correctly.

According to MDN, myIpAddress is a valid function to call in a PAC script. (Note: despite the warning on mdn's doc, I have tested myIpAddress() in a PAC file with Firefox on linux, an it returns the host's IP address, and not 127.0.0.1)

Following is a 'dummy' .pac files that triggers the problem when used:

function FindProxyForURL(url, host) {
var IP;
	IP = myIpAddress();
	return "DIRECT"; 
}

version used:

$ proxydetox --version
proxydetox 0.5.4 (77ae147d94)

full backtrace:

$ RUST_BACKTRACE=full proxydetox -v --negotiate --pac-file  $PWD/dummy_proxy.pac
   0.000940957s  INFO proxydetox: starting listening=127.0.0.1:3128 authenticator=negotiate pac_file=Some(Path("/home/didier/.config/proxydetox/dummy_proxy.pac"))
   6.026342977s DEBUG call: proxydetox::session: new connection client_addr=127.0.0.1:57260
thread 'tokio-runtime-worker' panicked at 'duk error: uncaught: 'identifier \x27myIpAddress\x27 undefined'', duktape/src/context.rs:23:5
stack backtrace:
   0:     0x561b223a299d - std::backtrace_rs::backtrace::libunwind::trace::h8217d0a8f3fd2f41
                               at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x561b223a299d - std::backtrace_rs::backtrace::trace_unsynchronized::h308103876b3af410
                               at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x561b223a299d - std::sys_common::backtrace::_print_fmt::hc208018c6153605e
                               at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:66:5
   3:     0x561b223a299d - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hf89a7ed694dfb585
                               at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:45:22
   4:     0x561b223c600c - core::fmt::write::h21038c1382fe4264
                               at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/fmt/mod.rs:1197:17
   5:     0x561b2239d411 - std::io::Write::write_fmt::h7dbb1c9a3c254aef
                               at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/io/mod.rs:1672:15
   6:     0x561b223a4145 - std::sys_common::backtrace::_print::h4e8889719c9ddeb8
                               at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:48:5
   7:     0x561b223a4145 - std::sys_common::backtrace::print::h1506fe2cb3022667
                               at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:35:9
   8:     0x561b223a4145 - std::panicking::default_hook::{{closure}}::hd9d7ce2a8a782440
                               at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:295:22
   9:     0x561b223a3e66 - std::panicking::default_hook::h5b16ec25444b1b5d
                               at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:314:9
  10:     0x561b223a46d6 - std::panicking::rust_panic_with_hook::hb0138cb6e6fea3e4
                               at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:698:17
  11:     0x561b223a45c7 - std::panicking::begin_panic_handler::{{closure}}::h4cb67095557cd1aa
                               at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:588:13
  12:     0x561b223a2e54 - std::sys_common::backtrace::__rust_end_short_backtrace::h2bfcac279dcdc911
                               at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys_common/backtrace.rs:138:18
  13:     0x561b223a42f9 - rust_begin_unwind
                               at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:584:5
  14:     0x561b21efc6d3 - core::panicking::panic_fmt::h1de71520faaa17d3
                               at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:142:14
  15:     0x561b222279a1 - duktape::context::fatal_handler::h995a414afe91a35f
  16:     0x561b2222cc13 - duk_fatal_raw
  17:     0x561b22234668 - duk_err_longjmp
  18:     0x561b2222e5cf - duk_js_execute_bytecode
  19:     0x561b2222ee75 - duk__handle_call_raw
  20:     0x561b221f22e1 - paclib::evaluator::Evaluator::find_proxy::h6a961b0e28645af4
  21:     0x561b22057282 - tokio::runtime::enter::exit::h609eb99d9de26810
  22:     0x561b2213e9b1 - tokio::runtime::thread_pool::worker::block_in_place::h0060b6cf893c3b51
  23:     0x561b220a0921 - <proxydetox::session::peer::PeerSession as tower_service::Service<http::request::Request<hyper::body::body::Body>>>::call::{{closure}}::hf182275b9f71c479
  24:     0x561b22084b0a - <tracing_futures::Instrumented<T> as core::future::future::Future>::poll::h78facaf5ebdfee8d
  25:     0x561b21f77f3d - hyper::proto::h1::dispatch::Dispatcher<D,Bs,I,T>::poll_catch::h4059bb61a8a493ee
  26:     0x561b21f4db0a - <hyper::server::conn::upgrades::UpgradeableConnection<I,S,E> as core::future::future::Future>::poll::h6febeead413faad0
  27:     0x561b21fc823f - <hyper::server::server::new_svc::NewSvcTask<I,N,S,E,W> as core::future::future::Future>::poll::hbbfc6b9bcabbb941
  28:     0x561b21fc0717 - tokio::runtime::task::core::CoreStage<T>::poll::hd554b0916da7c473
  29:     0x561b21fdec1a - tokio::runtime::task::harness::Harness<T,S>::poll::h2ba269abf99e42be
  30:     0x561b2220ecd5 - std::thread::local::LocalKey<T>::with::h2c3e18b224732262
  31:     0x561b2220b753 - tokio::runtime::thread_pool::worker::Context::run_task::h920c710bee35ce63
  32:     0x561b2220ac6e - tokio::runtime::thread_pool::worker::Context::run::h9d3497490ee01bf0
  33:     0x561b222123a7 - tokio::macros::scoped_tls::ScopedKey<T>::set::h0378fe21fecc1a0b
  34:     0x561b2220a6c9 - tokio::runtime::thread_pool::worker::run::hd1649ff7775b926a
  35:     0x561b22221a4c - <tokio::runtime::blocking::task::BlockingTask<T> as core::future::future::Future>::poll::h43739a1bc282c342
  36:     0x561b221fd989 - tokio::runtime::task::harness::Harness<T,S>::poll::h3f657d50141dfd2e
  37:     0x561b2220736a - tokio::runtime::blocking::pool::Inner::run::he3228c41f2afa905
  38:     0x561b22216342 - std::sys_common::backtrace::__rust_begin_short_backtrace::haa26257c4312576a
  39:     0x561b22216a6f - core::ops::function::FnOnce::call_once{{vtable.shim}}::h6175b285fe97f9b8
  40:     0x561b223a75d3 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h1680342795a2dc08
                               at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/alloc/src/boxed.rs:1951:9
  41:     0x561b223a75d3 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h45204a69827b0e83
                               at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/alloc/src/boxed.rs:1951:9
  42:     0x561b223a75d3 - std::sys::unix::thread::Thread::new::thread_start::h5d4e11bbda4161c8
                               at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/sys/unix/thread.rs:108:17
  43:     0x7fca9b1efb43 - start_thread
                               at ./nptl/./nptl/pthread_create.c:442:8
  44:     0x7fca9b281a00 - clone3
                               at ./misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
  45:                0x0 - <unknown>

After config on macOS , cannot access network

system info

proxydetox version 0.4.4
macOS BIG SUR 11.6
proxydetox config file:

$HOME/Library/Application Support/proxydetox/proxy.pac

which is a copy of corporate proxy pac file

$HOME/Library/Application Support/proxydetox/proxydetoxrc

only set --negotiate

set HTTP_PROXY HTTPS_PROXY to .zshrc file
change network setting 'Automatic Proxy Configuration' URL to 'http:127.0.0.1/proxy.pac'

steps to reduce the issue

proxydetox

error message
Authenticator factory: negotiate
thread 'main' panicked at 'error binding to 127.0.0.1:3128: error creating server listener: Address already in use (os error 48)', /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.14.17/src/server/server.rs:87:17
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

If try to re start wifi , failed to connect to network.
Hope I described it clear.....

How to temperally stop proxydetox

proxydetox version: 0.5.3
OS : macOS Monterey , 12.4

I could stop proxydetox by
launchctl kill SIGTERM gui/$(id -u)/cc.colorto.proxydetox
But it atuto start again ,even if after command
launchctl disable gui/$(id -u)/cc.colorto.proxydetox

So what's the correct way to temperally stop proxydetox?

Authentication

Error 502 Bad request with version 0.7.1

With version 0.7.1 proxydetox can't reach external webpages while using VPN.
curl -iL http://example.org returns Error 502 Bad request.
After downgrading to version 0.6.4 it works.

MacBook Pro M2 Max
macOS: Ventura 13.5

Program failing with a SEGV

Hi,

First of all, thanks for this project. This tool solved a lot of headaches in the corporate environment where I work.

Relating to the problem, I'm running proxydetox on a Debian 11 x86-64 machine, and the proxy is failing sometimes with a SEGV. Not knowing much about Rust debugging (or Rust at all...), I ran it through Valgrind and got the following error output:

--9949-- Reading syms from /usr/lib/x86_64-linux-gnu/libnss_myhostname.so.2
--9949--    object doesn't have a symbol table
==9949== Thread 22 tokio-runtime-w:
==9949== Invalid read of size 1
==9949==    at 0x483BC82: strlen (vg_replace_strmem.c:459)
==9949==    by 0x4E46CA: duktape::stack::Stack::get_string (in /home/humberto/bin/proxydetox)
==9949==    by 0x4E434B: paclib::dns::dns_resolve (in /home/humberto/bin/proxydetox)
==9949==    by 0x4F0D61: duk__handle_call_raw (in /home/humberto/bin/proxydetox)
==9949==    by 0x1AB57D: duk__js_execute_bytecode_inner (in /home/humberto/bin/proxydetox)
==9949==    by 0x4EFFC6: duk_js_execute_bytecode (in /home/humberto/bin/proxydetox)
==9949==    by 0x4F0F53: duk__handle_call_raw (in /home/humberto/bin/proxydetox)
==9949==    by 0x4E31CB: paclib::evaluator::Evaluator::find_proxy (in /home/humberto/bin/proxydetox)
==9949==    by 0x36EF18: tokio::runtime::context::exit_runtime (in /home/humberto/bin/proxydetox)
==9949==    by 0x3AD6CF: tokio::runtime::scheduler::multi_thread::worker::block_in_place (in /home/humberto/bin/proxydetox)
==9949==    by 0x3B5801: <proxydetoxlib::session::peer::PeerSession as tower_service::Service<http::request::Request<hyper::body::body::Body>>>::call::{{closure}} (in /home/humberto/bin/proxydetox)
==9949==    by 0x3B3890: <tracing_futures::Instrumented<T> as core::future::future::Future>::poll (in /home/humberto/bin/proxydetox)
==9949==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==9949== 
==9949== 
==9949== Process terminating with default action of signal 11 (SIGSEGV)
==9949==  Access not within mapped region at address 0x0
==9949==    at 0x483BC82: strlen (vg_replace_strmem.c:459)
==9949==    by 0x4E46CA: duktape::stack::Stack::get_string (in /home/humberto/bin/proxydetox)
==9949==    by 0x4E434B: paclib::dns::dns_resolve (in /home/humberto/bin/proxydetox)
==9949==    by 0x4F0D61: duk__handle_call_raw (in /home/humberto/bin/proxydetox)
==9949==    by 0x1AB57D: duk__js_execute_bytecode_inner (in /home/humberto/bin/proxydetox)
==9949==    by 0x4EFFC6: duk_js_execute_bytecode (in /home/humberto/bin/proxydetox)
==9949==    by 0x4F0F53: duk__handle_call_raw (in /home/humberto/bin/proxydetox)
==9949==    by 0x4E31CB: paclib::evaluator::Evaluator::find_proxy (in /home/humberto/bin/proxydetox)
==9949==    by 0x36EF18: tokio::runtime::context::exit_runtime (in /home/humberto/bin/proxydetox)
==9949==    by 0x3AD6CF: tokio::runtime::scheduler::multi_thread::worker::block_in_place (in /home/humberto/bin/proxydetox)
==9949==    by 0x3B5801: <proxydetoxlib::session::peer::PeerSession as tower_service::Service<http::request::Request<hyper::body::body::Body>>>::call::{{closure}} (in /home/humberto/bin/proxydetox)
==9949==    by 0x3B3890: <tracing_futures::Instrumented<T> as core::future::future::Future>::poll (in /home/humberto/bin/proxydetox)
==9949==  If you believe this happened as a result of a stack
==9949==  overflow in your program's main thread (unlikely but
==9949==  possible), you can try to increase the size of the
==9949==  main thread stack using the --main-stacksize= flag.
==9949==  The main thread stack size used in this run was 8388608.
--9949-- Discarding syms at 0x833b300-0x8341338 in /usr/lib/x86_64-linux-gnu/libnss_files-2.31.so (have_dinfo 1)
--9949-- Discarding syms at 0x834d210-0x834e5ea in /usr/lib/x86_64-linux-gnu/libnss_mdns4_minimal.so.2 (have_dinfo 1)
--9949-- Discarding syms at 0x83531b0-0x8356172 in /usr/lib/x86_64-linux-gnu/libnss_dns-2.31.so (have_dinfo 1)
==9949== 
==9949== HEAP SUMMARY:
==9949==     in use at exit: 1,966,242 bytes in 6,489 blocks
==9949==   total heap usage: 66,654 allocs, 60,165 frees, 15,129,486 bytes allocated
==9949== 
==9949== Searching for pointers to 6,489 not-freed blocks
==9949== Checked 52,270,216 bytes
==9949== 
==9949== LEAK SUMMARY:
==9949==    definitely lost: 142 bytes in 1 blocks
==9949==    indirectly lost: 0 bytes in 0 blocks
==9949==      possibly lost: 45,975 bytes in 383 blocks
==9949==    still reachable: 1,920,125 bytes in 6,105 blocks
==9949==         suppressed: 0 bytes in 0 blocks
==9949== Rerun with --leak-check=full to see details of leaked memory
==9949== 
==9949== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 0 from 0)
==9949== 
==9949== 2 errors in context 1 of 1:
==9949== Invalid read of size 1
==9949==    at 0x483BC82: strlen (vg_replace_strmem.c:459)
==9949==    by 0x4E46CA: duktape::stack::Stack::get_string (in /home/humberto/bin/proxydetox)
==9949==    by 0x4E434B: paclib::dns::dns_resolve (in /home/humberto/bin/proxydetox)
==9949==    by 0x4F0D61: duk__handle_call_raw (in /home/humberto/bin/proxydetox)
==9949==    by 0x1AB57D: duk__js_execute_bytecode_inner (in /home/humberto/bin/proxydetox)
==9949==    by 0x4EFFC6: duk_js_execute_bytecode (in /home/humberto/bin/proxydetox)
==9949==    by 0x4F0F53: duk__handle_call_raw (in /home/humberto/bin/proxydetox)
==9949==    by 0x4E31CB: paclib::evaluator::Evaluator::find_proxy (in /home/humberto/bin/proxydetox)
==9949==    by 0x36EF18: tokio::runtime::context::exit_runtime (in /home/humberto/bin/proxydetox)
==9949==    by 0x3AD6CF: tokio::runtime::scheduler::multi_thread::worker::block_in_place (in /home/humberto/bin/proxydetox)
==9949==    by 0x3B5801: <proxydetoxlib::session::peer::PeerSession as tower_service::Service<http::request::Request<hyper::body::body::Body>>>::call::{{closure}} (in /home/humberto/bin/proxydetox)
==9949==    by 0x3B3890: <tracing_futures::Instrumented<T> as core::future::future::Future>::poll (in /home/humberto/bin/proxydetox)
==9949==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==9949== 
==9949== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 0 from 0)

Seems to be related to a null pointer access. Any ideas?

Best regards.

Using as a library from another rust app

I am writing a rust desktop app.

It uses reqwest (which internally uses hyper AFAIK) to make http requests.

I was wondering if it is possible to use proxydetox as a library instead of having to run it as an external process.

I tried to follow the code a bit, but it was complex for a networking noob like me :-)

If it is possible and you can provide some instructions, that would be great

Always need restart if there is no krb5 ticket

Hello! Nice work, like it. There is an issue:
While there is no valid krb5ccache ticket, proxy will not work, obviously. When i get new ticket, for example, with kinit command, i need to manually restart proxydetox service. Is there a way to learn search for ticket dinamically? Thanks!
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.3 LTS"
Latest version of proxydetox.

Internal Server Error 502 HTTP error: connection closed before message completed

Hi, when I try to go to the site via HTTP I get an error
HTTP error: connection closed before message completed
This happens to every site if I access it via HTTP
OS: Ubuntu 22.04.3 LTS
Proxydetox version: v0.7.6
If you need debug information tell me what to do

It seems to be an bug in the hyper
hyperium/hyper#2136

variable missmatch

Hello,

I recently tried to install proxydetox deb package on a linux machine and I noticed that the proxydetox.service does not start due to the unit file.

I compared the latest version with an old version and there can be a possible variable mismatch in pkg/deb/BUILD

Thank you!