M
Mikey At Work
Does anyone know of any HTTPS servers available that are totally written in
Python? Thanks.
Python? Thanks.
Mikey At Work said: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 said:Have you seen: http://trevp.net/tlslite/ ?
Paul Rubin said: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.
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...
Paul Rubin said: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.
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.
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.
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.
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..
Paul Rubin said:Where do you get the fingerprint?
Yes, but each of the N people needs to authenticate N-1 of those
fingerprints somehow, so that's O(N**2) authentication operations.
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.
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.
Here's some good writings about this approach:
http://trevp.net/cryptoID/cryptoID.html
But you need to do O(N**2) address exchanges in any case, so you can
just piggyback key distribution on those.
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.
Paul Rubin said: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.
Yes, but if the address is bogus and the public key is good, then
someone intercepting the encrypted traffic can't read it.
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.
I'm presuming these are along similar lines as the first.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.