Pure Python HTTPS Server

[Mikey At Work]

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

[Paul Rubin]

"Mikey At Work" <it**********@yahooNOSPAM.com> 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.

[Bob Ippolito]

On 2004-02-26 17:24:01 -0500, Paul Rubin <http://ph****@NOSPAM.invalid> said:

"Mikey At Work" <it**********@yahooNOSPAM.com> 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/ ?

[Paul Rubin]

Bob Ippolito <bo*@redivi.com> 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.

[Trevor Perrin]

Paul Rubin <http://ph****@NOSPAM.invalid> wrote in message news:<7x************@ruckus.brouhaha.com>...

Bob Ippolito <bo*@redivi.com> 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

[Paul Rubin]

tr***@trevp.net (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.

[Trevor Perrin]

Paul Rubin <http://ph****@NOSPAM.invalid> wrote in message news:<7x************@ruckus.brouhaha.com>...

tr***@trevp.net (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/...redkeys-02.txt

[Paul Rubin]

tr***@trevp.net (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.

[Trevor Perrin]

Paul Rubin <http://ph****@NOSPAM.invalid> wrote in message news:<7x************@ruckus.brouhaha.com>...

tr***@trevp.net (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

[Paul Rubin]

tr***@trevp.net (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.

[Trevor Perrin]

Paul Rubin <http://ph****@NOSPAM.invalid> wrote in message news:<7x************@ruckus.brouhaha.com>...

tr***@trevp.net (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