ProxHTTPSProxy, a Proxomitron SSL Helper Program

[Graycode]

(May. 28, 2010 04:49 AM)JJoe Wrote:  ... Graycode (not a User of the Proxomitron) ... How about some feedback?

I'm still thinking about this, but didn't want distract whenever with 'opinion' too much. But since you asked, here's a few things:

1. SSL Closure
I've reviewed my (very old) coding for OpenSSL, and the closure issue was raised a lot. Scan through the HTTPS RFC 2818 and you'll see premature SSL closure avoidance mentioned many times.

Within the Python there is commented out:

Code:

# shutdown cause a hard-to-hanle Exception on ssl_sock.read() (closed?)
# socket.SHUT_WR == 1
#ssl_sock.shutdown(1)

I think that shudown() should be used, assuming it means the same in Python as it does in C sockets. Shutting down for writing tells the local socket layer to send a FIN after any pending outbound data has been sent. At that point the client's socket layer should end the connection, which will be known by the receipt of 0 bytes. I looked a bit for an OpenSSL "flush" method, but couldn't spot it and wouldn't know if Python incorporates that anyway.


2. Non-SSL on port 443
TCP port 443 is supposed to be used only for SSL. You've already encountered Polipo refusing non-SSL through that port, and you may encounter that with other proxies or applications. Currently the code is using port 443 for both SSL and for non-SSL. One of my very early strategies was to use a different port to "key in" on what wasn't really encrypted data.

Consider having an option to substitute a different port, for example port 30443. The 307 redirection could send the user to http: on that port instead of :443.

From Proxo you would forward any requests for SSL or for port :30443 to ProxHTTPSproxy. I'm not so well versed in Proxomitron, hopefully it can do that.

The option could have additional benefit in debugging. For example http://some-ssl-server:30443/stuff.htm should become visible as plain text through ProxHTTPSproxy even without consideration of 'proxcert.pem' or 307 redirection.

Sorry about my lack of Python knowledge, but here is what I'm trying to suggest:

Code:

## alternate port option for processing 307-redirected SSL
alt_port = ':30443'

Code:

def do_METHOD(self):
    method = self.command
    https_url = 'https://%s' % self.path.split('http://')[1]
    if (alt_port != ''):        ## substitution port option
        https_url = https_url.replace(alt_port,':443',1)

Normally I'd say to modify the Host: header as well but I see you're dropping that header. I assume that's a Python UrlLib reason.

Code:

def do_CONNECT(self):
    host_port = self.path
    if (alt_port != ''):        ## substitution port option
        host_port = host_port.replace(':443',alt_port,1)

3. Do you really need the 307 Redirect?
This is the biggest thing because here I might suggest that whenever goes on a wild goose chase.

Consider the original objective:

(May. 19, 2010 06:56 AM)whenever Wrote:  One of the purposes I decided to learn Python Programming Language is to write a proxy which can do https interception to solve Proxomitron's SSL issue, so here comes the ProxHTTPSProxy, a Proxomitron SSL Helper Program.

If you want to expand into a full-blown proxy that's one thing. You did get around Proxo's SSL issue. But then maybe it goes astray and introduces unforseen issues.

(I think) Proxo's SSL problem went away with your use of 'proxcert.pem'. That certificate would have been generated simply and does not contain the many extensions that have been added to (Open)SSL. With that certificate, Proxo and its SSLEAY libraries should stay happy because the newer SSL extensions aren't in there.

The problem (I think) arises when servers present newer more complicated certificates with extensions that the old SSLEAY versions didn't know about.

Maybe you should look into abandoning the 307 completely. In its place, collect those decrypted request headers (and any data) very similar to what's now done within do_METHOD. Don't issue a 307, but instead implement a data tunnel whereby you're handling all the (newer) SSL for the target server side and pumping back SSL to Proxo using the (old) proxcert.pem. You could probably implement a single-use tunnel by forcing a 'Connection: Close' on the server's response headers being given back to Proxo.

Let Proxomitron use its SSLEAY. Let it manage the in/out HTTP headers and filter the data. But defend it from newer incompatible SSL methods.

Proxo(using SSLEAY) --- (proxcert.pem) ProxHTTPS (any SSL method) --- secure servers.

So, I'm talking about an SSL-only solution. One that only has the do_CONNECT() and does not need (or does not have) the do_METHOD().

Maybe that's not realistic or technically possible. Or maybe it wouldn't really resolve anything.