扭曲的反向代理SSL后端

Question

I'm fairly new to twisted, and trying to utilize twisted.web.proxy.ReverseProxyResource to create a reverse proxy. Ultimately I want clients to connect to it using SSL, then I'll validate the request, and pass it only to an SSL backend server. I'm starting out with the below (very) basic code, but struggling to get it to connect to an SSL backend, and am finding the documentation lacking. Would anyone be able to give me some good pointers, or ideally some example code?

In the code below it obviously won't work because its expecting to hit a plain HTTP server, how would I 'ssl' this?

As always any help is very, very, much appreciated all.

Thanks

Alex

from twisted.internet import reactor
from twisted.web import proxy, server
from twisted.web.resource import Resource

class Simple(Resource):
    isLeaf = False
    def getChild(self, name, request):
        print "getChild called with name:'%s'" % name
        #host = request.getAllHeaders()['host']
        host = "127.0.0.1"  #yes there is an SSL host listening here
        return proxy.ReverseProxyResource(host, 443, "/"+name)

simple = Simple()
site = server.Site(simple)
reactor.listenTCP(8000, site)
reactor.run()

Answer 1

ReverseProxyResource does not support TLS. When you write ReverseProxyResource(host, 443, "/"+name) you're creating a resource which will establish a normal TCP connection to host on port 443. The TCP connection attempt will succeed but the TLS handshake will definitely fail - because the client won't even attempt one.

This is a limitation of the current ReverseProxyResource : it doesn't support the feature you want. It's somewhat likely that this feature could be implemented fairly easily. Since ReverseProxyResource was implemented, Twisted has introduced the concept of "endpoints" which make it much easier to write code that is transport-agnostic.

ReverseProxyResource could be updated to work in terms of "endpoints" (preserving backwards compatibility with the current API, though, required by Twisted). This doesn't complicate the implementation much (it may actually simplify it) and would allow you to proxy over any kind of transport for which an endpoint implementation exists (there is one for TLS, there are also many more kinds).