Https/NAT support

[elazarl]

Https/NAT support

Here is trivial external wrapper for goproxy: http://ix.io/9he

[elazarl]

Hi,

Thanks for the interesting idea. Sorry it took me some time to get back to you.

I'm hesitate whether or not to include that in core goproxy library, since it's not directly related to the proxy module. It's a good idea to include that in a different module.

What you're asking is unsolvable in the general case, since, plain SSL/TLS communicatiom does not tell you which host is it directed to without SNI extension. For example Windows XP clients will simply not work.

That said, it could be useful in some situations, and I see no reason not to include it.

If that's OK with you, I'll take your wrapper and try to integrate it into the [goproxy] framework.

That will be very good to have that functionality in the upstream as an option. But if so, wrapper could be probably integrated in better way. For example, that CONNECT emulation should go away, i think

[elazarl]

Thanks for the input.

I disagree.

CONNECT must remain, since CONNECT is the standard way to achieve HTTPS
connection via a proxy.

You're interested with a different nonstandard functionality, you want to
capture an https connection on it's way out, intercept it, and decipher it
using the so called "man in the middle attack".

To do that in the general case, you must save the original destination IP
of the HTTPS stream, it will not always be sent by the client.

I can see why it could be useful, so I think I should add that, but you
should note those are two different *and *orthogonal features.

Am I clear? Are we on the same page?

Do we have a shared understanding what does the CONNECT method do?

On Sun, Dec 8, 2013 at 1:30 PM, alxchk [email protected] wrote:

That will be very good to have that functionality in the upstream as an
option. But if so, wrapper could be probably integrated in better way. For
example, that CONNECT emulation should go away, i think

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-30079745
.

Am I clear? Are we on the same page?

Probably yes. I just thought about adding additional API to pass/inject stream to proxy. But if there is no simple way to integrate something like that, then it's ok to have wrapper as-is

[mzimmerman]

I've got a working prototype of this but as @elazarl eluded to, it's not part of the core proxy functionality but it still needs to re-use much of the code. I'll work on refactoring it so it's not so ugly; I've got a lot of copy/paste code from the core goproxy.

One key that helped make it much easier is @inconshreveable 's (go-vhost) [https://github.com/inconshreveable/go-vhost] It has an SNI parsing function.

[mzimmerman]

The example that enables this was submitted in pull request #69

[mzimmerman]

I've further flushed this out in https://github.com/mzimmerman/whitelistproxy -- it's fully functioning at this point (at least for my requirements). It's not pretty; could use some better documentation and prettier HTML but it's got a nice core of features so far.