<div dir="ltr"><br><br><div class="gmail_quote">On Sat, May 14, 2011 at 2:55 PM, Erik de Castro Lopo <span dir="ltr"><<a href="mailto:mle%2Bhs@mega-nerd.com">mle+hs@mega-nerd.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Michael Snoyman wrote:<br>
<br>
> > I've implemented four functions; proxyHttp, proxyHttpLbs,<br>
> > proxyHttpRedirect and proxyHttpLbsRedirect but it occurs<br>
> > to me that if we added a field of type 'Maybe Proxy' to the<br>
> > 'Request m' data type, the fucntionality of the four functions<br>
> > I have hacked up could be merged with the original versions<br>
> > of these.<br>
> ><br>
> > Does that sound like a sane approach?<br>
><br>
> Yes, I think that sounds good. Just let me know when I should look at the<br>
> code; I'm impressed how quickly you're getting this done!<br>
<br>
</div>Ok, I've submitted a github pull request that modifies the<br>
existing http function to proxy HTTP requests. This was a<br>
relatively simple matter of modifying hosts, ports, and<br>
headers.<br>
<br>
I'm now looking at doing HTTPS and I'm a little lost on how<br>
to proceed. Basically proxying of HTTPS works as follows:<br>
<br>
a) Wants to connect to <a href="https://encrypted.google.com/" target="_blank">https://encrypted.google.com/</a><br>
via HTTP proxy called squid listening on port 3128.<br>
<br>
b) Client opens an un-encrypted connection to squid:3128<br>
and sends a request:<br>
<br>
CONNECT <a href="http://encrypted.google.com:443" target="_blank">encrypted.google.com:443</a> HTTP/1.1<br>
<br>
c) Squid proxy connects to <a href="http://encrypted.google.com" target="_blank">encrypted.google.com</a> port 443<br>
and gets back a response of:<br>
<br>
HTTP/1.1 200 Connection established<br>
<br>
which it sends the client.<br>
<br>
d) The squid proxy then blindly transfers bytes from the client<br>
to <a href="http://encrypted.google.com" target="_blank">encrypted.google.com</a> and bytes from <a href="http://encrypted.google.com" target="_blank">encrypted.google.com</a><br>
to the client.<br>
<br>
e) The client does TLS negotiation over the bi-directional pipe<br>
established and maintained by the proxy.<br>
<br>
I can send the CONNECT and get back the HTTP 200 OK, but I'm<br>
not sure how to proceed.<br>
<br>
Clues?<br>
<div><div></div><div class="h5"><br><br></div></div></blockquote><div>Hmm... this *does* seem problematic. If I understand correctly, we need to first accept unencrypted data over the socket, and then encrypted. The first thing (and probably least important) that jumps out to me is that we probably need to reconsider how we use the manager for proxied connections. The more serious concern is that the TLS package uses Handles under the surface, while http-enumerator uses Sockets for non-SSL connections.</div>
<div><br></div><div>If I were to take a stab at the best approach, it would be to modify withSslConn to (optionally) read in the HTTP response line from the proxy before handing control off to TLS. I'm not sure I entirely understand the issue, but does that seem like a plausible approach?</div>
<div><br></div><div>Michael</div></div></div>