Pure Python HTTPS Server

Discussion in 'Python' started by Mikey At Work, Feb 26, 2004.

  1. Does anyone know of any HTTPS servers available that are totally written in
    Python? Thanks.
     
    Mikey At Work, Feb 26, 2004
    #1
    1. Advertising

  2. Mikey At Work

    Paul Rubin Guest

    "Mikey At Work" <> writes:
    > Does anyone know of any HTTPS servers available that are totally
    > written in Python? Thanks.


    That depends on what you mean by "pure". You can do it with the various
    OpenSSL Python bindings that have been written. I don't think anyone
    has ever written a complete SSL stack in Python. I've toyed with the
    idea but it would be a lot of work.
     
    Paul Rubin, Feb 26, 2004
    #2
    1. Advertising

  3. Mikey At Work

    Bob Ippolito Guest

    On 2004-02-26 17:24:01 -0500, Paul Rubin <http://> said:

    > "Mikey At Work" <> writes:
    >> Does anyone know of any HTTPS servers available that are totally
    >> written in Python? Thanks.

    >
    > That depends on what you mean by "pure". You can do it with the various
    > OpenSSL Python bindings that have been written. I don't think anyone
    > has ever written a complete SSL stack in Python. I've toyed with the
    > idea but it would be a lot of work.


    Have you seen: http://trevp.net/tlslite/ ?
     
    Bob Ippolito, Feb 26, 2004
    #3
  4. Mikey At Work

    Paul Rubin Guest

    Bob Ippolito <> writes:
    > Have you seen: http://trevp.net/tlslite/ ?


    No, hadn't seen it. Interesting, thanks. It looks like it's not a
    full blown implementation right now (no real attempt to handle
    certificates) but that it's moving in that direction.
     
    Paul Rubin, Feb 26, 2004
    #4
  5. Paul Rubin <http://> wrote in message news:<>...
    > Bob Ippolito <> writes:
    > > Have you seen: http://trevp.net/tlslite/ ?

    >
    > No, hadn't seen it. Interesting, thanks. It looks like it's not a
    > full blown implementation right now (no real attempt to handle
    > certificates) but that it's moving in that direction.


    Hi Paul,

    If you have an X.509 cert you can use it; and you can authenticate the
    other guy based on his X.509 fingerprint.

    There's no path validation or cert creation. My view is that certs
    are a disaster, and I'm doing users a *favor* by keeping them at arm's
    length :). Fingerprints are easier to use, so that's what the
    library encourages.

    Anyways, I don't plan to add more X.509 support. If someone else
    wants to, it is open-source...

    Trevor
     
    Trevor Perrin, Feb 27, 2004
    #5
  6. Mikey At Work

    Paul Rubin Guest

    (Trevor Perrin) writes:
    > There's no path validation or cert creation. My view is that certs
    > are a disaster, and I'm doing users a *favor* by keeping them at arm's
    > length :). Fingerprints are easier to use, so that's what the
    > library encourages.


    But it means you need a separate fingerprint for each person you talk
    to. If you're going to do that, you may as well just use shared
    symmetric keys and not mess with TLS.

    > Anyways, I don't plan to add more X.509 support. If someone else
    > wants to, it is open-source...


    Yeah, that's what I mean about it being a lot of work to do the full
    stack. It's great that you've provided this starting point though.
     
    Paul Rubin, Feb 27, 2004
    #6
  7. Paul Rubin <http://> wrote in message news:<>...
    > (Trevor Perrin) writes:
    > > There's no path validation or cert creation. My view is that certs
    > > are a disaster, and I'm doing users a *favor* by keeping them at arm's
    > > length :). Fingerprints are easier to use, so that's what the
    > > library encourages.

    >
    > But it means you need a separate fingerprint for each person you talk
    > to.


    You need to *get* the fingerprint of each person you talk to. But if
    you're calling people you need to get their phone number, if you're
    emailing them you need to get their email address, etc.. acquiring
    fingerprints isn't much different from acquiring those things, and
    it's a hundred times easier than doing anything with certificates,
    IMHO.


    > If you're going to do that, you may as well just use shared
    > symmetric keys and not mess with TLS.


    Well, fingerprints are public, not secret data. So they're much
    easier to distribute, and N people only need N fingerprints, whereas
    they'd need N-squared shared keys.

    (of course you know that; I just can't resist a chance to sing the
    virtues of fingerprints... I'm sort of a fingerprint zealot :).

    (And even if you *are* using symmetric keys, you still might want to
    use TLS just for its record layer; that's what the shared-keys
    Internet-Draft [1] is about, which tlslite implements).

    >
    > > Anyways, I don't plan to add more X.509 support. If someone else
    > > wants to, it is open-source...

    >
    > Yeah, that's what I mean about it being a lot of work to do the full
    > stack. It's great that you've provided this starting point though.


    Thanks. I don't agree that the "full stack" of PKIX protocols is
    worth implementing or using, but we can agree to disagree on that..

    Trevor

    [1] http://www.ietf.org/internet-drafts/draft-ietf-tls-sharedkeys-02.txt
     
    Trevor Perrin, Feb 28, 2004
    #7
  8. Mikey At Work

    Paul Rubin Guest

    (Trevor Perrin) writes:
    > > But it means you need a separate fingerprint for each person you talk
    > > to.

    >
    > You need to *get* the fingerprint of each person you talk to. But if
    > you're calling people you need to get their phone number, if you're
    > emailing them you need to get their email address, etc.. acquiring
    > fingerprints isn't much different from acquiring those things, and
    > it's a hundred times easier than doing anything with certificates, IMHO.


    Where do you get the fingerprint? By email from the person you want
    to connect to? How do you know that the email is really coming from them?
    >
    > > If you're going to do that, you may as well just use shared
    > > symmetric keys and not mess with TLS.

    >
    > Well, fingerprints are public, not secret data. So they're much
    > easier to distribute, and N people only need N fingerprints, whereas
    > they'd need N-squared shared keys.


    Yes, but each of the N people needs to authenticate N-1 of those
    fingerprints somehow, so that's O(N**2) authentication operations.

    > > Yeah, that's what I mean about it being a lot of work to do the full
    > > stack. It's great that you've provided this starting point though.

    >
    > Thanks. I don't agree that the "full stack" of PKIX protocols is
    > worth implementing or using, but we can agree to disagree on that..


    I don't know about going berserk writing ASN1 parsers and that whole
    bit, but there really should be some way to do basic cert checking.
     
    Paul Rubin, Feb 28, 2004
    #8
  9. Paul Rubin <http://> wrote in message news:<>...
    > (Trevor Perrin) writes:
    > > > But it means you need a separate fingerprint for each person you talk
    > > > to.

    > >
    > > You need to *get* the fingerprint of each person you talk to. But if
    > > you're calling people you need to get their phone number, if you're
    > > emailing them you need to get their email address, etc.. acquiring
    > > fingerprints isn't much different from acquiring those things, and
    > > it's a hundred times easier than doing anything with certificates, IMHO.

    >
    > Where do you get the fingerprint?


    Through the same channel that you used to acquire the email address.

    Put it this way: If you acquire someone's address through a secure
    channel, then you can use that same channel for fingerprint
    distribution. If you acquired their address through an *insecure*
    channel, then there's no point in using a PKI-provided (address,
    public key) binding, since the address could be bogus.

    So PKI (address, key) bindings are strictly less secure than simply
    distributing fingerprints through the same channels used to distribute
    addresses (DNS, LDAP, and paper directories, URLs, business cards,
    pen-and-paper, etc.).

    Here's some good writings about this approach:

    http://trevp.net/cryptoID/cryptoID.html
    http://www.waterken.com/dev/YURL/
    http://zooko.com/distnames.html


    > > Well, fingerprints are public, not secret data. So they're much
    > > easier to distribute, and N people only need N fingerprints, whereas
    > > they'd need N-squared shared keys.

    >
    > Yes, but each of the N people needs to authenticate N-1 of those
    > fingerprints somehow, so that's O(N**2) authentication operations.


    But you need to do O(N**2) address exchanges in any case, so you can
    just piggyback key distribution on those.


    >
    > > > Yeah, that's what I mean about it being a lot of work to do the full
    > > > stack. It's great that you've provided this starting point though.

    > >
    > > Thanks. I don't agree that the "full stack" of PKIX protocols is
    > > worth implementing or using, but we can agree to disagree on that..

    >
    > I don't know about going berserk writing ASN1 parsers and that whole
    > bit, but there really should be some way to do basic cert checking.


    I'll try to provide an interface for cryptlib and openssl's cert
    checking. So if you have those libraries you can use it, but it won't
    be in pure python.


    Trevor
     
    Trevor Perrin, Feb 28, 2004
    #9
  10. Mikey At Work

    Paul Rubin Guest

    (Trevor Perrin) writes:
    > > Where do you get the fingerprint?

    >
    > Through the same channel that you used to acquire the email address.


    Well, no. That channel doesn't have to be secure. If you think it's
    secure, you may as well use it for secret keys. Aha you say, it only
    has to be secure against tampering, not mere eavesdropping. But if
    you've got a definite way to secure it against tampering, you may as
    well also secure it against eavesdropping.

    > Put it this way: If you acquire someone's address through a secure
    > channel, then you can use that same channel for fingerprint
    > distribution. If you acquired their address through an *insecure*
    > channel, then there's no point in using a PKI-provided (address,
    > public key) binding, since the address could be bogus.


    Yes, but if the address is bogus and the public key is good, then
    someone intercepting the encrypted traffic can't read it. That's the
    whole point of encryption. Also, routing to the address is done by
    mechanisms outside the recipient's control. You could get the address
    through a secure channel, only to have someone hijack the address the
    next day.

    > Here's some good writings about this approach:
    > http://trevp.net/cryptoID/cryptoID.html


    This paper begins

    Abstract: In this paper, we argue that person-to-person key
    distribution is best accomplished with a key-centric approach,

    However the idea of certificates is to do away with the need for
    person-to-person key distribution.

    > http://www.waterken.com/dev/YURL/
    > http://zooko.com/distnames.html


    I'm presuming these are along similar lines as the first.

    > > Yes, but each of the N people needs to authenticate N-1 of those
    > > fingerprints somehow, so that's O(N**2) authentication operations.

    >
    > But you need to do O(N**2) address exchanges in any case, so you can
    > just piggyback key distribution on those.


    The addresses can be unauthenticated and are much easier to accomplish.

    > > I don't know about going berserk writing ASN1 parsers and that whole
    > > bit, but there really should be some way to do basic cert checking.

    >
    > I'll try to provide an interface for cryptlib and openssl's cert
    > checking. So if you have those libraries you can use it, but it won't
    > be in pure python.


    Cool, thanks.
     
    Paul Rubin, Feb 28, 2004
    #10
  11. Paul Rubin <http://> wrote in message news:<>...
    > (Trevor Perrin) writes:
    > > > Where do you get the fingerprint?

    > >
    > > Through the same channel that you used to acquire the email address.

    >
    > Well, no. That channel doesn't have to be secure. If you think it's
    > secure, you may as well use it for secret keys. Aha you say, it only
    > has to be secure against tampering, not mere eavesdropping.


    Exactly!

    > But if
    > you've got a definite way to secure it against tampering, you may as
    > well also secure it against eavesdropping.


    Exchanging an "authentic" piece of data is much easier than exchanging
    a secret one.

    For one thing, authenticity is additive: Say I list my fingerprint at
    the bottom of every email, print it on my webpage and business cards,
    and list it in directories. You can check my fingerprint through
    multiple channels to attain more confidence in it than any single
    channel provides.

    By contrast, secrecy is destroyed by broadcasting, so you and I would
    need a single, highly-secure channel for a shared-secret.


    >
    > > Put it this way: If you acquire someone's address through a secure
    > > channel, then you can use that same channel for fingerprint
    > > distribution. If you acquired their address through an *insecure*
    > > channel, then there's no point in using a PKI-provided (address,
    > > public key) binding, since the address could be bogus.

    >
    > Yes, but if the address is bogus and the public key is good, then
    > someone intercepting the encrypted traffic can't read it.


    I wasn't clear. PKIs often map an address to a public key. If you
    input a bogus address to the PKI (i.e. an address chosen by an
    attacker), you'll get back a bogus key.

    So this sort of PKI *assumes* a tamper-proof channel for distributing
    addresses. Otherwise, garbage in; garbage out. But in the presence
    of such a channel, the PKI is superfluous. Worse than superfluous: it
    *reduces* security by adding an unnecessary point of failure.


    > > Here's some good writings about this approach:
    > > http://trevp.net/cryptoID/cryptoID.html

    >
    > This paper begins
    >
    > Abstract: In this paper, we argue that person-to-person key
    > distribution is best accomplished with a key-centric approach,
    >
    > However the idea of certificates is to do away with the need for
    > person-to-person key distribution.


    It's poorly phrased, by "person-to-person key distribution" I meant
    "key distribution in support of person-to-person communications" (like
    email, VoIP, etc.).

    However, you're right: certificates *do* try to automate key
    distribution so it doesn't require human involvement.

    That forces people to explain all their trust relationships and
    requirements to the computer, so that it can process certificate
    graphs on their behalf and calculate which public keys are acceptable
    to them.

    The problem is that people's trust relationships and requirements are
    complex and context-dependent, and thus difficult to express in a
    machine-usable form (look at PGP's web of trust, which is both too
    crude to model real-world trust relationships, and too complicated for
    most people to use).

    Furthermore, people have access to channels which could potentially be
    used for key distribution which software has no knowledge of
    (face-to-face contact, business cards, paper directories, etc.).

    So instead of trying to automate key distribution, we should try to
    make it easy for people to perform it themselves. Fingerprints are
    the best way to do that, in my opinion.

    Anyways, that sums up that paper, you can skip it now :)...


    >
    > > http://www.waterken.com/dev/YURL/
    > > http://zooko.com/distnames.html

    >
    > I'm presuming these are along similar lines as the first.


    I think they share a theme, at least, which is the power of cutting
    out the middleman and using cryptographic identifiers directly.


    Trevor
     
    Trevor Perrin, Feb 29, 2004
    #11
    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:
    499
    Kanenas
    May 30, 2005
  2. Trevor Perrin

    Re: Pure Python HTTPS Server

    Trevor Perrin, Feb 26, 2004, in forum: Python
    Replies:
    12
    Views:
    1,153
    Trevor Perrin
    Mar 2, 2004
  3. DrChaos

    https pure java

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

Share This Page