support customized Proxy-Authorization header

[ghost]

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

[klzgrad]

Which commercial HTTP proxy providers?

[ghost]

https://fpn.firefox.com/

[klzgrad]

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]

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?

naiveproxy/src/net/http/proxy_client_socket.cc

Line 45 in f51cbff

request_headers->MergeFrom(extra_headers);

[klzgrad]

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

[ghost]

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]

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

[ghost]

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

naiveproxy/src/net/http/proxy_client_socket.cc

Line 47 in f51cbff

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

[klzgrad]

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]

Fair enough. Close for now. :)

[klzgrad]

--extra-headers is supported now.