You might want to take a look at m2crypto[0]. While I have not
personally run it on Windows (runs great on OS X and Linux) they do
provide pre-compiled Windows binaries.
[0] http://chandlerproject.org/bin/view/Projects/MeTooCrypto
--
Michael E. Crute
http://mike.crute.org
It is a mistake to think you can solve any major problem just with
potatoes. --Douglas Adams
Evpy[1] is designed to be a very easy-to-use interface to OpenSSL,
although it is by design limited to doing things the right way, so it
may not meet your needs.
Full disclosure, I'm its author.
Geremy Condra
which one is for windows, for Python version 2.5.4 ? And how to uninstall
when required?
I don't use windows so I can't help you with Windows specific
questions. The windows downloads are clearly marked for python 2.4,
2.5 and 2.6. Go back and read the entire page.
You can try http://www.egenix.com/products/python/pyOpenSSL/ -- its
fairly low-level OpenSSL, but its pretty comprehensive.
And you uninstall it in Add & Remove Programs.
--
Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/
How about contributing to the standard hashlib and ssl modules? Is
there anything there that goes in the way, e.g. design-wise?
Regards
Antoine.
Evpy currently uses ctypes for its bindings, so my understanding is
that it isn't eligible for inclusion, but a rewrite as a C extension is
under way and I'd be happy to contribute that.
The hard thing would be finding someone to champion it on the
political side, since I have little interest in fighting the interminable
political battles that go with the push for inclusion.
Geremy Condra
That was not my question. My question was whether there was a reason to
rewrite a separate OpenSSL-accessing library rather than contributing to
improve the "hashlib" and "ssl" modules which are already part of the
Python stdlib.
Regards
Antoine.
M2Crypto for Python 2.5 works well. I've used it both on Windows
and Linux. If you have to build it, though; that's a huge pain.
It uses SWIG, and the build process seems to have problems that
require workarounds.
The new SSL module in Python 2.6 is convenient, but insecure.
It doesn't check whether the remote domain matches the
cert being presented. So it's vulnerable to man-in-the-middle
attacks, or sites with "borrowed" SSL certs. See
"http://mail.python.org/pipermail/python-list/2010-April/1242166.html".
John Nagle
Yes. Hashlib is designed to provide cryptographic hashes, and the ssl
module to provide TLS support. Evpy provides encryption and signing.
Am I answering your question?
Geremy Condra
> The new SSL module in Python 2.6
There isn't an SSL module in Python 2.6. There is a module named "ssl"
which pretends to implement SSL, but in fact doesn't.
> is convenient, but insecure.
In which case, it isn't actually convenient, in any meaningful sense of
the word.
As one of my friends is fond of saying, it lets you talk encrypted to
your attacker ;)
Geremy Condra
Hmm, indeed, thank you. For some strange reason I had forgotten that
hashlib is limited to hashing (I'm not even being ironical :-S).
Regards
Antoine.
That's a good way to put it.
John Nagle
What do you mean by "doesn't"?
Can you point to an open bug report describing the issue?
He's describing the lack of hostname checking, discussed here[0],
here[1], and in my pycon lightning talk last year, wherever those
are kept. My understanding is that it has led to vulnerabilities in
code deployed by Red Hat and several other vendors; if you need
to speak with them I can probably get the people involved in that
effort to come forward privately.
Both the lead for M2Crypto and the authors of zc.ssl have publicly
stated that this needs to be fixed.
Geremy Condra
[0] http://mail.python.org/pipermail/python-list/2010-April/1242166.html
[1] http://bugs.python.org/issue1589
> He's describing the lack of hostname checking, discussed here[0],
> here[1], and in my pycon lightning talk last year, wherever those
> are kept.
Ok, thank you.
I have tried to put some effort into the py3k ssl docs, so that security
issues get mentioned:
http://docs.python.org/dev/py3k/library/ssl.html#security-considerations
Any improvement or correction is welcome.
Also, following issue1589 (certificate hostname checking), I think it
would be useful at least to provide the necessary helper functions in
order to check certificate conformity, even if they aren't called
implicitly. I would encourage interested people to provide a patch for
the py3k ssl module, and will gladly review it.
Regards
Antoine.
Could similar notifications be added to urllib, etc? That's where
people really get bitten badly by this.
> Also, following issue1589 (certificate hostname checking), I think it
> would be useful at least to provide the necessary helper functions in
> order to check certificate conformity, even if they aren't called
> implicitly. I would encourage interested people to provide a patch for
> the py3k ssl module, and will gladly review it.
I'm not sure what this fixes if it doesn't get used in the higher-level
modules, but I can ask if anybody is interested.
Geremy Condra
I suppose so, although I'm not responsible for these modules.
> > Also, following issue1589 (certificate hostname checking), I think it
> > would be useful at least to provide the necessary helper functions in
> > order to check certificate conformity, even if they aren't called
> > implicitly. I would encourage interested people to provide a patch for
> > the py3k ssl module, and will gladly review it.
>
> I'm not sure what this fixes if it doesn't get used in the higher-level
> modules, but I can ask if anybody is interested.
Actually it could be used, at least optionally, by the higher-level
modules (I'm not sure it can always be enabled by default, although
security-wise it would certainly be preferrable).
Regards
Antoine.
> Also, following issue1589 (certificate hostname checking), I think it
> would be useful at least to provide the necessary helper functions in
> order to check certificate conformity, even if they aren't called
> implicitly. I would encourage interested people to provide a patch for
> the py3k ssl module, and will gladly review it.
The main issue is with the use of SSL for HTTPS: you *must* check the
hostname against the certificate *before* sending the request. Allowing
the caller to discover afterwards that (potentially confidential) data
has been sent to an unknown destination is not an acceptable alternative.
This check shouldn't require any additional steps on the part of the
caller. Simply creating an HTTPS connection or opening a connection using
an "https:" URL should be sufficient. If you want to provide support for
"fake SSL" (e.g. to allow connecting to hosts with self-signed
certificates), *that* should require additional steps.
The biggest problem with crypto is that it's very hard to tell the
difference between working crypto and broken crypto. If you make it easy
for developers to get it wrong, some of them *will* get it wrong, and it
may take a long time before anyone discovers this.
>> I have tried to put some effort into the py3k ssl docs, so that security
>> issues get mentioned:
>> http://docs.python.org/dev/py3k/library/ssl.html#security-considerations
>> Any improvement or correction is welcome.
>
> Could similar notifications be added to urllib, etc? That's where
> people really get bitten badly by this.
If you have specific ideas, propose them on the tracker.
------
I think the following section
"
<blah>
"
should be added to <specific place>
---------
There are people who will add .rst markup to ascii text once it is
agreed on.
If you want cross-references to the above added to docs for other
modules, just say that.
Terry Jan Reedy
urllib is basically a web client and as such it should act like a
browser, with a default certificate store. It should refuse to connect
to an https host that doesn't have a valid certificate, unless you
override the default (supply your own CA store or validation routine).
There could be some pre-written override options, such as accept expired
certificate, accept certificate named "www.xyz.com" when the actual host
is "abc.xyz.com", or that sort of thing. These are code changes, not
doc updates.
I've opened the requested bug report:
http://bugs.python.org/issue9003
Just for the record, I'd rather see this fixed than note the need for a
workaround.
Geremy Condra
http://bugs.python.org/issue1589
Just reopened by Antoine Pitrou.
Realistically, there are obscure situations where you might want to
open an SSL connection without hostname validation. Those
situations are unusual. (I actually do that to read the SSL
certificate, without sending data, in a system which collects data
from SSL certs. This is not the normal case.)
The typical Python user will expect SSL checking for URL opening
to behave like a browser does. They won't be up to speed on the
internal mechanics of X.509 certificates. The default case should
be to require a hostname match (considering certificate wildcards,
multiple common names, multiple alt names, etc.).
Expecting the caller to do this check is unreasonable. It's
about 70 lines of python code to cover all the cases. And
that's without proper support for error reporting for internationalized
host names.
Without a hostname check, the SSL module insures only, as someone
else points out, that "you have an encrypted connection to your
attacker".
John Nagle
If you are interested in this, I would encourage you to post a patch or
a proposal on the aforementioned bug entry so as to add a hostname
checking function to the SSL module.
(m2crypto has its own implementation that can serve as a source of
inspiration, and test cases)
If/when that is done, the second step would be to integrate it by
default with the urllib module, and perhaps other ones.
Thanks
Antoine.
John, I'll do this if you don't want to. Let me know.
Geremy Condra