[Twisted-Python] HTTPS and subjectAltName

Roland Hedberg roland.hedberg at adm.umu.se
Sat Apr 12 09:41:40 EDT 2008


Jean-Paul Calderone wrote:
> On Fri, 11 Apr 2008 07:54:47 +0200, Roland Hedberg 
> <roland.hedberg at adm.umu.se> wrote:
>> Jean-Paul Calderone wrote:
>>> On Thu, 10 Apr 2008 19:37:33 +0200, Roland Hedberg 
>>> <roland.hedberg at adm.umu.se> wrote:
>>>>
>>>> [snip]
>>>>
>>>> The error I get is:
>>>>
>>>>  File 
>>>> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- 
>>>> packages/twisted/internet/ssl.py", line 169, in createInternetSocket
>>>>  return SSL.Connection(self.ctxFactory.getContext(), sock)
>>>>  TypeError: Connection() argument 1 must be Context, not instance
>>>>
>>>> So, if it possible to use M2Crypto together with Twisted ?
>>>> If so, can someone tell me what I might have missed ?
>>>
>>> M2Crypto includes support for Twisted.  So, if you want to use M2Crypto
>>> instead of pyOpenSSL, you should use the APIs M2Crypto provides.
>>
>> So, I've studied the wrapper that the Chandler project provides.
>> Unfortunately they don't provide a wrapper for SSLServer which is what 
>> I need. Which made me look at the Twisted code.
>> So what's the correct way to 'wrap' SSLServer, should I wrap 
>> _AbstractServer or is that a no-no ?
> 
> SSLServer implements a very simple set of functionality.  It will be very
> easy to replicate it using the M2Crypto API.  You just need a startService
> (and maybe a privilegedStartService) that calls the M2Crypto server setup
> API and a stopService that calls the M2Crypto server shutdown API (which I
> hope is just IListeningPort.stopListening).
> 
> _AbstractServer is private, so you shouldn't touch it.  You can look at its
> implementation (barely a page) to get some hints about what to write, 
> though.

OK, this wasn't hard to do.

But then I stumble on the next block and that's making a client use 
M2Crypto.
This turned out to be a bit tougher since the choice of SSL 
implementation is buried deep down in internet/tcp.py .
Someone must have thought about allowing for a choice of implementation 
by specifying an abstract definition of functionality (base 
class/interface), right ?
If I would make an attempt at doing this, would that be ok ? And is 
there something I should build on ?

-- Roland




More information about the Twisted-Python mailing list