Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support customized Proxy-Authorization header #66

Closed
ghost opened this issue May 9, 2020 · 11 comments
Closed

support customized Proxy-Authorization header #66

ghost opened this issue May 9, 2020 · 11 comments

Comments

@ghost
Copy link

ghost commented May 9, 2020

Some commercial HTTPS proxy providers uses Proxy-Authorization: Bearer <token> instead of basic auth for proxy authorization. With this supported and padding off, naiveproxy can be used as a socks2https tool.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Proxy-Authorization
https://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml

@ghost ghost changed the title support customzied Proxy-Authorization header like Bearer <token> support customized Proxy-Authorization header May 9, 2020
@klzgrad
Copy link
Owner

klzgrad commented May 9, 2020

Which commercial HTTP proxy providers?

@ghost
Copy link
Author

ghost commented May 9, 2020

https://fpn.firefox.com/

@klzgrad
Copy link
Owner

klzgrad commented May 10, 2020

How do you go about getting the OAuth code? As I see in https://github.com/mozilla/secure-proxy/blob/master/docs/authentication.md it's not trivial. Usually OAuth codes need periodic rotation, then how do you plan to rotate it with naiveproxy? I just don't see how this is enabled by simply adding this proxy-authorization header.

@ghost
Copy link
Author

ghost commented May 10, 2020

I think it would be too much for naiveproxy to perform OAuth rotations. The header should be generated by a third party program.

Is it possible to expose the extra_headers of BuildTunnelRequest in the command line, like in curl?

request_headers->MergeFrom(extra_headers);

@klzgrad
Copy link
Owner

klzgrad commented May 12, 2020

Can be supported after Chrome v83 https://bugs.chromium.org/p/chromium/issues/detail?id=926427

@ghost
Copy link
Author

ghost commented May 13, 2020

Great news! Maybe the padding header can also be fed in from an external program/ plugin so that higher level of obfuscation can be achieved

@klzgrad
Copy link
Owner

klzgrad commented May 14, 2020

No, putting garbage in this extra header won't do better than the padding header already there.

@ghost
Copy link
Author

ghost commented May 16, 2020

Not fully convinced. Having a hard-coded random function which has a distribution which is not customizable can also be considered as vulnerable, if you are pursuing a full obfuscation

std::string(base::RandInt(16, 32), '.'));

@klzgrad
Copy link
Owner

klzgrad commented May 16, 2020

How is it vulnerable? What can you deduce out of it? This distribution is so small there isn't even enough entropy to decide if a random number generator is at work from observing packet lengths.

This padding header will only effect a single packet per user connection, the HTTP/2 CONNECT header. The more important padding is about the subsequent user payloads, which include their own handshake sizes.

[16, 32] is an informed guess, see #1 (comment). 55 to 31 bytes are CONNECT HEADERS with authority of various sizes. ~68 bytes are some usual GET HEADERS of specific sites in real traffic. So [31, 55] + [16, 32] -> a distribution in [47, 87] which is neither uniform or gaussian.

So there isn't anything to deduce there. I could make it more complex but this part doesn't matter yet.

@ghost
Copy link
Author

ghost commented May 17, 2020

Fair enough. Close for now. :)

@ghost ghost closed this as completed May 17, 2020
@klzgrad
Copy link
Owner

klzgrad commented May 20, 2020

--extra-headers is supported now.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant