Re: Pure Python HTTPS Server

Discussion in 'Python' started by Trevor Perrin, Feb 26, 2004.

  1. At 04:56 PM 2/26/2004 -0500, Mikey At Work wrote:

    >Does anyone know of any HTTPS servers available that are totally written in
    >Python? Thanks.



    tlslite lets you run Python's BaseHTTPServer or SimpleHTTPServer with HTTPS.
    http://trevp.net/tlslite/

    It's pure-python, but you have to generate your server certificate
    externally (like with OpenSSL).

    Also, it doesn't know how to load OpenSSL's PEM-encoded private keys unless
    you have M2Crypto. I'll add that next week.


    Trevor
    Trevor Perrin, Feb 26, 2004
    #1
    1. Advertising

  2. On Thu, 26 Feb 2004 14:45:56 -0800,
    Trevor Perrin <> wrote:
    > tlslite lets you run Python's BaseHTTPServer or SimpleHTTPServer with HTTPS.
    > http://trevp.net/tlslite/


    Neat!

    Would tlslite be able to handle TLS asynchronously? I've been wanting to
    add SSL/TLS support to Medusa, but didn't want to require external packages
    such as PyOpenSSL.

    --amk
    A.M. Kuchling, Feb 27, 2004
    #2
    1. Advertising

  3. At 07:11 AM 2/27/2004 -0600, A.M. Kuchling wrote:

    >On Thu, 26 Feb 2004 14:45:56 -0800,
    > Trevor Perrin <> wrote:
    > > tlslite lets you run Python's BaseHTTPServer or SimpleHTTPServer with

    > HTTPS.
    > > http://trevp.net/tlslite/

    >
    >Neat!
    >
    >Would tlslite be able to handle TLS asynchronously?


    Not at the moment, I don't think. Right now it assumes it has a blocking
    socket, and when you call TLSConnection.read() it blocks until one (or
    more) TLS records has been fully received.

    I'm a little fuzzy about asynch stuff. I don't think I can emulate a
    file-descriptor to make it work with select(). What about an interface
    where you can say "get any available bytes", with no blocking? Is that on
    the right track?


    > I've been wanting to
    >add SSL/TLS support to Medusa, but didn't want to require external packages
    >such as PyOpenSSL.



    It'll be slow, of course, with pure-Python ciphers:
    - ~25 KB/sec AES, on a P4 1.7 Ghz
    - ~250 KB/sec RC4, " "


    Are you and Paul still looking at adding ciphers to stdlib? That would
    make me really, really happy :)....

    Trevor
    Trevor Perrin, Feb 27, 2004
    #3
  4. Trevor Perrin

    Paul Rubin Guest

    Trevor Perrin <> writes:
    > I'm a little fuzzy about asynch stuff. I don't think I can emulate a
    > file-descriptor to make it work with select(). What about an
    > interface where you can say "get any available bytes", with no
    > blocking? Is that on the right track?


    I guess you could use that in combination with pause/sigalarm to
    emulate select, but it's probably better to find some way to use
    select directly deep down.

    > Are you and Paul still looking at adding ciphers to stdlib? That
    > would make me really, really happy :)....


    Do you mean me? I proposed a standard block cipher API and wrote a
    sample implementation last year, but had to set it aside temporarily
    because of other commitments at the time. Between then and now I
    heard that the distro maintainers decided they weren't willing to put
    ciphers into the stdlib because they were concerned it would create
    legal obstacles importing Python into certain places. They didn't
    seem to mind that the existing rotor module already creates those same
    issues, or that just about every web browser these days contains an
    SSL stack, so they only need to be concerned about places where it's
    illegal to use web browsers. I haven't pursued the issue since then,
    but I guess I can do some more work on the code now.
    Paul Rubin, Feb 27, 2004
    #4
  5. On Fri, 27 Feb 2004 11:01:08 -0800,
    Trevor Perrin <> wrote:
    > I'm a little fuzzy about asynch stuff. I don't think I can emulate a
    > file-descriptor to make it work with select(). What about an interface
    > where you can say "get any available bytes", with no blocking? Is that on
    > the right track?


    The hard part is really the initial negotiation, which has to be
    interruptible in order to avoid making the entire server hang if a client
    disappears during the initial exchange of packets.

    > Are you and Paul still looking at adding ciphers to stdlib? That would
    > make me really, really happy :)....


    No, unfortunately; the python-dev consensus was that encryption raised
    export control issues, and the existing rotor module is now on its way to
    being removed.

    --amk
    A.M. Kuchling, Feb 28, 2004
    #5
  6. At 08:23 PM 2/27/2004 -0600, A.M. Kuchling wrote:

    >On Fri, 27 Feb 2004 11:01:08 -0800,
    > Trevor Perrin <> wrote:
    > > I'm a little fuzzy about asynch stuff. I don't think I can emulate a
    > > file-descriptor to make it work with select(). What about an interface
    > > where you can say "get any available bytes", with no blocking? Is that on
    > > the right track?

    >
    >The hard part is really the initial negotiation, which has to be
    >interruptible in order to avoid making the entire server hang if a client
    >disappears during the initial exchange of packets.


    Yeah, I see. I'll try to redo the handshake to support that, and let you
    know how it goes (I'll probably send some questions your way too, if that's
    okay... I'm sorta out of my element here).



    > > Are you and Paul still looking at adding ciphers to stdlib? That would
    > > make me really, really happy :)....

    >
    >No, unfortunately; the python-dev consensus was that encryption raised
    >export control issues, and the existing rotor module is now on its way to
    >being removed.


    That's too bad. Thanks for letting me know.

    Trevor
    Trevor Perrin, Feb 28, 2004
    #6
  7. Paul Rubin <http://> wrote in message news:<>...
    > Trevor Perrin <> writes:
    > > Are you and Paul still looking at adding ciphers to stdlib? That
    > > would make me really, really happy :)....

    >
    > Do you mean me?


    Yes! Sorry, I was typing quickly.


    > I proposed a standard block cipher API and wrote a
    > sample implementation last year,


    I like that API. I wonder if there's any performance issues in
    separating the codebook from the mode-of-operation, but I haven't
    thought about that much.


    > but had to set it aside temporarily
    > because of other commitments at the time. Between then and now I
    > heard that the distro maintainers decided they weren't willing to put
    > ciphers into the stdlib because they were concerned it would create
    > legal obstacles importing Python into certain places. They didn't
    > seem to mind that the existing rotor module already creates those same
    > issues, or that just about every web browser these days contains an
    > SSL stack, so they only need to be concerned about places where it's
    > illegal to use web browsers.


    Yeah, I thought things were pretty liberalized these days. US Export
    isn't a problem. I guess a few countries still have import issues,
    but providing a no-crypto distribution that omits a few modules seems
    like it would take care of that.

    > I haven't pursued the issue since then,
    > but I guess I can do some more work on the code now.


    I'd be happy to help, or cheerlead, or anything. Is this something
    that belongs on the python-crypto list?


    Trevor
    Trevor Perrin, Feb 28, 2004
    #7
  8. Trevor Perrin

    Paul Rubin Guest

    (Trevor Perrin) writes:
    > > I proposed a standard block cipher API and wrote a
    > > sample implementation last year,

    >
    > I like that API. I wonder if there's any performance issues in
    > separating the codebook from the mode-of-operation, but I haven't
    > thought about that much.


    If needed, the C-level API can be expanded so codebook modules have a
    way to communicate directly with the modes-of-operation module,
    without needing to do Python attribute lookups all the time. But even
    without that optimization, I don't think the performance issues should
    be so bad. The attribute lookup shouldn't be any slower than a
    codebook call, so if you do it just once when you invoke a chaining
    mode, the overhead for large buffers should be minimal.

    > Yeah, I thought things were pretty liberalized these days. US Export
    > isn't a problem. I guess a few countries still have import issues,
    > but providing a no-crypto distribution that omits a few modules seems
    > like it would take care of that.


    I think that got debated at some length, but I wasn't around for it.

    > > I haven't pursued the issue since then, but I guess I can do some
    > > more work on the code now.

    >
    > I'd be happy to help, or cheerlead, or anything. Is this something
    > that belongs on the python-crypto list?


    I dunno, discussions on that list tend to go around in circles. There
    were a couple of unresolved questions about the API that I've now
    forgotten. I guess I should dig up that code and look at it again.

    Do you happen to have a pure-Python DES implementation around? I
    started writing one once, but it had some bug (i.e. it didn't pass
    FIPS test vectors) that I never got around chasing down.

    Did you ever look at the key management scheme I circulated a while
    back? Is it the kind of thing anyone cares about?
    Paul Rubin, Feb 28, 2004
    #8
  9. Paul Rubin <http://> wrote in message news:<>...
    > (Trevor Perrin) writes:
    > > > I proposed a standard block cipher API and wrote a
    > > > sample implementation last year,

    > >
    > > I like that API. I wonder if there's any performance issues in
    > > separating the codebook from the mode-of-operation, but I haven't
    > > thought about that much.

    >
    > If needed, the C-level API can be expanded so codebook modules have a
    > way to communicate directly with the modes-of-operation module,
    > without needing to do Python attribute lookups all the time. But even
    > without that optimization, I don't think the performance issues should
    > be so bad. The attribute lookup shouldn't be any slower than a
    > codebook call, so if you do it just once when you invoke a chaining
    > mode, the overhead for large buffers should be minimal.


    Sounds good, as long as you don't have to do anything expensive
    per-block.


    > Do you happen to have a pure-Python DES implementation around? I
    > started writing one once, but it had some bug (i.e. it didn't pass
    > FIPS test vectors) that I never got around chasing down.


    I found one here:
    http://home.pacific.net.au/~twhitema/des.html

    It's too slow to do anything useful (that's DES's fault, I think, not
    the progammer's).


    >
    > Did you ever look at the key management scheme I circulated a while
    > back? Is it the kind of thing anyone cares about?


    I didn't see that. I did see that you've talked about a stdlib
    interface to OS-level Random Number Generators, like /dev/urandom and
    CryptGenRandom. I think that's an excellent idea.

    (aside from ciphers and RNGs, the other thing on my wish-list is
    faster modular exponentiation.. Python use a simple right-to-left
    square-and-multiply. I'm no expert here, but I think it would be
    pretty easy to make that a few times faster for crypto sized numbers.
    tlslite's handshaking, in python code, is ~5x slower than OpenSSL
    right now..)


    Trevor
    Trevor Perrin, Feb 28, 2004
    #9
  10. Trevor Perrin

    Paul Rubin Guest

    (Trevor Perrin) writes:
    > > Did you ever look at the key management scheme I circulated a while
    > > back? Is it the kind of thing anyone cares about?

    >
    > I didn't see that. I did see that you've talked about a stdlib
    > interface to OS-level Random Number Generators, like /dev/urandom and
    > CryptGenRandom. I think that's an excellent idea.


    http://www.nightsong.com/phr/crypto/crypto.txt

    But I want to change it some, to use standard ciphers.

    > (aside from ciphers and RNGs, the other thing on my wish-list is
    > faster modular exponentiation.. Python use a simple right-to-left
    > square-and-multiply. I'm no expert here, but I think it would be
    > pretty easy to make that a few times faster for crypto sized numbers.
    > tlslite's handshaking, in python code, is ~5x slower than OpenSSL
    > right now..)


    Use gmpy, http://gmpy.sf.net
    Paul Rubin, Feb 28, 2004
    #10
  11. Paul Rubin <http://> wrote in message news:<>...
    > (Trevor Perrin) writes:
    > > > Did you ever look at the key management scheme I circulated a while
    > > > back? Is it the kind of thing anyone cares about?

    > [...]
    > http://www.nightsong.com/phr/crypto/crypto.txt


    I like the ideas about key protection. It's a higher-level API then I
    have a need for, though. I'd just like to see a few fast primitives
    in stdlib.


    > > (aside from ciphers and RNGs, the other thing on my wish-list is
    > > faster modular exponentiation.. Python use a simple right-to-left
    > > square-and-multiply. I'm no expert here, but I think it would be
    > > pretty easy to make that a few times faster for crypto sized numbers.
    > > tlslite's handshaking, in python code, is ~5x slower than OpenSSL
    > > right now..)

    >
    > Use gmpy, http://gmpy.sf.net


    That's another couple modules users have to install though (GMPY and
    GMP). I was thinking the current pow() implementation could be
    optimized a bit.

    Trevor
    Trevor Perrin, Feb 29, 2004
    #11
  12. Trevor Perrin

    Paul Rubin Guest

    (Trevor Perrin) writes:
    > > Use gmpy, http://gmpy.sf.net

    >
    > That's another couple modules users have to install though (GMPY and
    > GMP). I was thinking the current pow() implementation could be
    > optimized a bit.


    My lib is written to use gmpy when it's available and the default
    stuff if "import gmpy" fails. The default stuff is fast enough on
    current desktop cpu's for most client side applications that I can
    think of. For a server app, you always want more speed, but asking
    someone to install GMP (if it's not already present) is less onerous.
    GMP is included by default in a lot of GNU/Linux distros.
    Paul Rubin, Mar 1, 2004
    #12
  13. Paul Rubin <http://> wrote in message news:<>...
    > (Trevor Perrin) writes:
    > > > Use gmpy, http://gmpy.sf.net

    > >
    > > That's another couple modules users have to install though (GMPY and
    > > GMP). I was thinking the current pow() implementation could be
    > > optimized a bit.

    >
    > My lib is written to use gmpy when it's available and the default
    > stuff if "import gmpy" fails. The default stuff is fast enough on
    > current desktop cpu's for most client side applications that I can
    > think of. For a server app, you always want more speed, but asking
    > someone to install GMP (if it's not already present) is less onerous.


    Good points and good advice, thanks. Depending on key size, this
    gives me a 3-6x speedup in handshaking.

    Trevor
    Trevor Perrin, Mar 2, 2004
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Todd Aspeotis
    Replies:
    3
    Views:
    451
    Kanenas
    May 30, 2005
  2. Mikey At Work

    Pure Python HTTPS Server

    Mikey At Work, Feb 26, 2004, in forum: Python
    Replies:
    10
    Views:
    926
    Trevor Perrin
    Feb 29, 2004
  3. DrChaos

    https pure java

    DrChaos, Oct 14, 2006, in forum: Java
    Replies:
    2
    Views:
    380
    Tom Forsmo
    Oct 15, 2006
  4. Replies:
    4
    Views:
    774
    Ben C
    Mar 29, 2008
  5. Axel
    Replies:
    8
    Views:
    1,067
    Adrienne Boswell
    Apr 27, 2009
Loading...

Share This Page