This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Python SSL stack doesn't support Elliptic Curve ciphers
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: jcea, meador.inge, naif, pitrou, python-dev, vinay.sajip
Priority: normal Keywords: patch

Created on 2011-12-18 13:37 by naif, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
ecdh.patch pitrou, 2011-12-19 10:09 review
ssl-ecdh.diff vinay.sajip, 2012-02-19 20:17 Changes to ECDH logic for Mac OS X 10.5.8 / OpenSSL 0.9.7 review
Messages (35)
msg149755 - (view) Author: naif (naif) Date: 2011-12-18 13:37
Python SSL doesn't support Elliptic Curve ciphers in in all version tested.

This is a serious performance issue because it's not possible to use as a server or as client the performance improvement provided by ECC based ciphers.
Nowdays ECC are supported by all latests browsers.

ECC provide a strong performance improvements (even x3) also when used with Perfect Forward Secrecy enabled ciphers like described on:
http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html

In order to enable ECC ciphers (and eventually ECC keys) the SSL implementation the in the file Modules/_ssl.c must be modified.

For example apache had several modifications to support ECC on their SSL (openssl based) stack:
https://issues.apache.org/bugzilla/show_bug.cgi?id=40132
https://build.opensuse.org/package/view_file?file=httpd-ssl-ecc-ecdh.patch&package=apache2&project=home%3Aelvigia%3Atls1.2&rev=2

So Python SSL module should introduce similar modifications to fully support Elliptic Curve ciphers for SSL in order to:

- Provide performance improvements
- Provide cryptography security improvements
- Allow writing of applications compliant with NSA Suite-B standard
msg149758 - (view) Author: naif (naif) Date: 2011-12-18 14:24
Other example for DH and ECC from:
https://github.com/bumptech/stud/blob/master/stud.c

#ifndef OPENSSL_NO_DH
static int init_dh(SSL_CTX *ctx, const char *cert) {
    DH *dh;
    BIO *bio;

    assert(cert);

    bio = BIO_new_file(cert, "r");
    if (!bio) {
      ERR_print_errors_fp(stderr);
      return -1;
    }

    dh = PEM_read_bio_DHparams(bio, NULL, NULL, NULL);
    BIO_free(bio);
    if (!dh) {
        ERR("{core} Note: no DH parameters found in %s\n", cert);
        return -1;
    }

    LOG("{core} Using DH parameters from %s\n", cert);
    SSL_CTX_set_tmp_dh(ctx, dh);
    LOG("{core} DH initialized with %d bit key\n", 8*DH_size(dh));
    DH_free(dh);

#ifdef NID_X9_62_prime256v1
    EC_KEY *ecdh = NULL;
    ecdh = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
    SSL_CTX_set_tmp_ecdh(ctx,ecdh);
    EC_KEY_free(ecdh);
    LOG("{core} ECDH Initialized with NIST P-256\n");
#endif

    return 0;
}
#endif /* OPENSSL_NO_DH */



#ifndef OPENSSL_NO_DH
    init_dh(ctx, OPTIONS.CERT_FILE);
#endif /* OPENSSL_NO_DH */
msg149760 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-12-18 14:30
It's not obvious to me which APIs should be used to provide such support. Python mostly uses high-level OpenSSL APIs, and lets OpenSSL load certificates.

Do you want to try writing a patch? General instructions on how to contribute can be found at http://docs.python.org/devguide/
msg149761 - (view) Author: naif (naif) Date: 2011-12-18 14:51
Have a look also at DH related ticket: http://bugs.python.org/issue13626

There is a code example on how PHP manage the DH parameter setup with high level OpenSSL.

The code must check if the ciphers is EC or DH and in that case setup appropriate parameters by generating random data for DH operations.
msg149779 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-12-18 16:31
Ok, so you are talking specifically about ECDH? Or is there something to be done for generic EC support?

OpenSSL has a SSL_CTX_set_tmp_dh() function (macro, actually), but it's undocumented. Best bet is probably to follow ssl/ssltest.c (OpenSSL source tree), lines 825 and following, under "#ifndef OPENSSL_NO_ECDH".
msg149782 - (view) Author: naif (naif) Date: 2011-12-18 16:58
This is how the Stud software enable also the use of ECC in OpenSSL TLS
https://github.com/bumptech/stud/pull/61
msg149826 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-12-19 10:09
Here is a patch adding a set_ecdh_curve() method on SSL contexts, and a ssl.OP_SINGLE_ECDH_USE option flag. This is enough to enable ECDH with compatible clients (I've tested with Firefox and openssl s_client).
msg149828 - (view) Author: naif (naif) Date: 2011-12-19 10:32
So, with this patch it should be possible to strictly enable ciphers such as:
ECDHE-RSA-AES256-SHA   SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256) Mac=SHA1
ECDH-RSA-AES256-SHA    SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1
ECDH-ECDSA-AES256-SHA  SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1

Which ciphers did you negotiated succesfully?


While with the implementation of http://bugs.python.org/issue13627 (DH/DHE ciphers) we should be able to negotiate:
 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA       EDH-RSA-DES-CBC3-SHA (SSLv3)
 TLS_DHE_DSS_WITH_DES_CBC_SHA            EDH-DSS-CBC-SHA (TLSv1)
 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA       EDH-DSS-DES-CBC3-SHA (TLSv1)
 TLS_DHE_RSA_WITH_DES_CBC_SHA            EDH-RSA-DES-CBC-SHA (TLSv1)
 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       EDH-RSA-DES-CBC3-SHA (TLSv1)
 TLS_DHE_DSS_WITH_AES_128_CBC_SHA        DHE-DSS-AES128-SHA
 TLS_DHE_DSS_WITH_AES_256_CBC_SHA        DHE-DSS-AES256-SHA
 TLS_DHE_RSA_WITH_AES_128_CBC_SHA        DHE-RSA-AES128-SHA
 TLS_DHE_RSA_WITH_AES_256_CBC_SHA        DHE-RSA-AES256-SHA

Do you expect it would be a difficult step to handle also the DH/DHE (non ECC) negotiation?

Additionally it would be imho very important if the Python language would provide a "default ciphers setup" that look at maximum compatibility, performance and security.

If it sounds fine for you, i would open another ticket to create a default cipherlist.
msg149832 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-12-19 10:44
> So, with this patch it should be possible to strictly enable ciphers such as:
> ECDHE-RSA-AES256-SHA   SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256) Mac=SHA1
> ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256) Mac=SHA1
> ECDH-RSA-AES256-SHA    SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1
> ECDH-ECDSA-AES256-SHA  SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1
> 
> Which ciphers did you negotiated succesfully?

I didn't try to negotiate a specific cipher, I just saw that the
selected cipher was ECDHE-RSA-AES256-SHA (using a standard self-signed
certificate). I suppose other ciphers are accessible as well.

> While with the implementation of http://bugs.python.org/issue13627
> (DH/DHE ciphers) we should be able to negotiate:

You mean issue13626.

> Do you expect it would be a difficult step to handle also the DH/DHE
> (non ECC) negotiation?

No, but that's issue13626 :)

> Additionally it would be imho very important if the Python language
> would provide a "default ciphers setup" that look at maximum
> compatibility, performance and security.

You have the set_ciphers() method which allows you to set a "cipher
string":
http://docs.python.org/dev/library/ssl.html#ssl.SSLContext.set_ciphers
OpenSSL itself has several generic cipher settings available:
http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT

For example the following setting gives you only ECDH ciphers with
strong encryption and authentication:

$ openssl ciphers -v 'kEECDH:!NULL:!aNULL'
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=3DES(168) Mac=SHA1
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
ECDHE-ECDSA-RC4-SHA     SSLv3 Kx=ECDH     Au=ECDSA Enc=RC4(128)  Mac=SHA1

We are not cryptography experts and I don't think it would be a good
idea to maintain our own list of ciphers.

(furthermore, I don't think "maximum compatibility, performance and
security" are generally compatible with each other)
msg149836 - (view) Author: naif (naif) Date: 2011-12-19 10:53
The Tor Project is composed of Cryptography experts, thus i am opening that ticket cause with our group we're implementing Tor2web based on Python that require *strict* security requirements for crypto.

The Tor Project heavily use Python for most of tools.

If you want we can open a discussion within Tor Project to have a "rationale method" to define a set of "default ciphers" considering the ration of security/performance/compatibility.

That way anyone using Python SSL/TLS will be sure in using a "Secure system" without the risk of legacy protocol such as SSLv2 or insecure ciphers like Export 40bit DES that are nowdays enabled by default.

Today a Python coder approaching SSL/TLS will have an insecurely configured TLS connection that can be hijacked via SSLv2 protocol or cracked via 40bit DES. 

Even Firefox, Chrome, IE, Opera disable by default certain protocols and certain ciphers, so imho it would be valuable to have a "Secure default", obviously considering and maintaining compatibility.

What do you think?
msg149840 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-12-19 11:14
> If you want we can open a discussion within Tor Project to have a
> "rationale method" to define a set of "default ciphers" considering
> the ration of security/performance/compatibility.

Why don't you simple define your own default ciphers and call the
set_ciphers() method?

That said, we could perhaps call set_ciphers("HIGH") by default. This
excludes legacy ciphers (such as RC4, DES) without having us maintain an
explicit list.
msg149841 - (view) Author: naif (naif) Date: 2011-12-19 11:16
Created a ticket there for a default-setting:

Python SSL Stack doesn't have a Secure Default set of ciphers
http://bugs.python.org/issue13636
msg149874 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2011-12-19 16:18
New changeset 8b729d65cfd2 by Antoine Pitrou in branch 'default':
Issue #13627: Add support for SSL Elliptic Curve-based Diffie-Hellman
http://hg.python.org/cpython/rev/8b729d65cfd2
msg149875 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-12-19 16:19
Patch now committed in 3.3.
msg149955 - (view) Author: Meador Inge (meador.inge) * (Python committer) Date: 2011-12-21 05:18
ECC is *not* available in the OpenSSL package provided on RedHat systems.  RedHat intentionally strips it due to patent concerns (http://en.wikipedia.org/wiki/ECC_patents).  Therefore committing this work made it much more difficult to build the ssl module on RedHat systems.

I couldn't find a clear statement of this in any RedHat documentation, but I did find a few references to the stripping in these places:

   * https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=623483
   * https://www.martineve.com/2011/07/22/using-elliptical-curve-cryptography-in-openssh/
   * https://bugzilla.redhat.com/show_bug.cgi?id=615372

Perhaps we should make these algorithms build conditional?  Are these patent issues of concern to us?
msg149961 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-12-21 07:22
> Perhaps we should make these algorithms build conditional?  Are these
> patent issues of concern to us?

Well, if RedHat used the "standard" OPENSSL_NO_ECDH flag, it's easy
enough to fix compilation of the ssl module.
msg149962 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-12-21 08:18
Can you post the exact compiler errors you encountered?
msg149963 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-12-21 08:19
Nevermind, I've found them on the Fedora buildbot.
msg149964 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2011-12-21 08:28
New changeset ec44f2e82707 by Antoine Pitrou in branch 'default':
Fix ssl module compilation if ECDH support was disabled in the OpenSSL build.
http://hg.python.org/cpython/rev/ec44f2e82707
msg149965 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-12-21 08:33
Since we're at it, do you know if Redhat also disables regular Diffie-Hellman? See issue13626.
msg149966 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-12-21 08:34
ec44f2e82707 fixed compilation on Fedora and test_ssl passed fine.
msg149999 - (view) Author: Meador Inge (meador.inge) * (Python committer) Date: 2011-12-21 15:45
> ec44f2e82707 fixed compilation on Fedora and test_ssl passed fine.

Awesome, thanks Antoine.  I will checkout the DH patch from issue13626 on Fedora today.
msg153536 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2012-02-17 10:52
I'm getting a failure building on Mac OS X Leopard (10.5.8) relating to ECDH:

/Users/vinay/projects/pythonv/Modules/_ssl.c: In function ""PyInit__ssl":
/Users/vinay/projects/pythonv/Modules/_ssl.c:2545: error: "SSL_OP_SINGLE_ECDH_USE" undeclared (first use in this function)

The relevant line

    PyModule_AddIntConstant(m, "OP_SINGLE_ECDH_USE", SSL_OP_SINGLE_ECDH_USE);

isn't bracketed with #ifndef OPENSSL_NO_ECDH/#endif - shouldn't it be?
msg153538 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-02-17 10:57
> I'm getting a failure building on Mac OS X Leopard (10.5.8) relating to ECDH:

Thanks for reporting. It should be fixed in c1a07c8092f7. Can you try?
msg153541 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2012-02-17 12:48
> Can you try?

That error goes away, but there are others. Sorry, I missed them in amongst the warnings, or I would have posted all of them. Here's the complete console output for the _ssl extension:

building '_ssl' extension
gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -IInclude -I. -I./Include -I/Users/vinay/projects/pythonv -c /Users/vinay/projects/pythonv/Modules/_ssl.c -o build/temp.macosx-10.5-i386-3.3/Users/vinay/projects/pythonv/Modules/_ssl.o
/Users/vinay/projects/pythonv/Modules/_ssl.c: In function ‘_get_peer_alt_names’:
/Users/vinay/projects/pythonv/Modules/_ssl.c:634: warning: passing argument 2 of ‘ASN1_item_d2i’ from incompatible pointer type
/Users/vinay/projects/pythonv/Modules/_ssl.c:639: warning: passing argument 2 of ‘method->d2i’ from incompatible pointer type
/Users/vinay/projects/pythonv/Modules/_ssl.c: In function ‘PySSL_compression’:
/Users/vinay/projects/pythonv/Modules/_ssl.c:1011: warning: implicit declaration of function ‘SSL_get_current_compression’
/Users/vinay/projects/pythonv/Modules/_ssl.c:1011: warning: assignment makes pointer from integer without a cast
/Users/vinay/projects/pythonv/Modules/_ssl.c: In function ‘set_ecdh_curve’:
/Users/vinay/projects/pythonv/Modules/_ssl.c:2048: error: ‘EC_KEY’ undeclared (first use in this function)
/Users/vinay/projects/pythonv/Modules/_ssl.c:2048: error: (Each undeclared identifier is reported only once
/Users/vinay/projects/pythonv/Modules/_ssl.c:2048: error: for each function it appears in.)
/Users/vinay/projects/pythonv/Modules/_ssl.c:2048: error: ‘key’ undeclared (first use in this function)
/Users/vinay/projects/pythonv/Modules/_ssl.c:2060: warning: implicit declaration of function ‘EC_KEY_new_by_curve_name’
/Users/vinay/projects/pythonv/Modules/_ssl.c:2065: warning: implicit declaration of function ‘SSL_CTX_set_tmp_ecdh’
/Users/vinay/projects/pythonv/Modules/_ssl.c:2066: warning: implicit declaration of function ‘EC_KEY_free’

Failed to build these modules:
_ssl
msg153542 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-02-17 12:56
> That error goes away, but there are others. Sorry, I missed them in
> amongst the warnings, or I would have posted all of them. Here's the
> complete console output for the _ssl extension:

Uh, what is the OpenSSL version there?
Can you try to find out if OPENSSL_NO_ECDH is defined?
msg153555 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2012-02-17 15:52
It looks like it's OpenSSL 0.9.7. It's an old machine which I can't change things on - it's got MacPorts OpenSSL which is 1.0.0g, and I thought it was using that. On closer investigation, the version in /usr/include (0.9.7l) is actually being included.

Presumably, even if only an old version of OpenSSL is available, Python should still build cleanly, even if it's without Elliptic Curve cipher support? If you'd like me to try anything else, just ask.
msg153556 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2012-02-17 15:53
Oh - and, ECDH is not matched by any file in that OpenSSL include directory/hierarchy.
msg153571 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2012-02-17 17:05
Also, if it's OK for the Elliptic Curve code to be optional in builds, the failure to import OP_SINGLE_ECDH_USE into ssl.py from _ssl should not cause "import ssl" to fail.
msg153586 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-02-17 17:51
Ok, can you try again? 06ed9b3f02af
msg153614 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2012-02-18 00:45
Almost there. The file now compiles, but a failure occurs in a later step due to compression functionality being unavailable:

building '_ssl' extension
gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -IInclude -I. -I./Include -I/Users/vinay/projects/pythonv -c /Users/vinay/projects/pythonv/Modules/_ssl.c -o build/temp.macosx-10.5-i386-3.3/Users/vinay/projects/pythonv/Modules/_ssl.o
/Users/vinay/projects/pythonv/Modules/_ssl.c: In function ‘_get_peer_alt_names’:
/Users/vinay/projects/pythonv/Modules/_ssl.c:645: warning: passing argument 2 of ‘ASN1_item_d2i’ from incompatible pointer type
/Users/vinay/projects/pythonv/Modules/_ssl.c:650: warning: passing argument 2 of ‘method->d2i’ from incompatible pointer type
/Users/vinay/projects/pythonv/Modules/_ssl.c: In function ‘PySSL_compression’:
/Users/vinay/projects/pythonv/Modules/_ssl.c:1022: warning: implicit declaration of function ‘SSL_get_current_compression’
/Users/vinay/projects/pythonv/Modules/_ssl.c:1022: warning: assignment makes pointer from integer without a cast
gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.5-i386-3.3/Users/vinay/projects/pythonv/Modules/_ssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.macosx-10.5-i386-3.3/_ssl.so
*** WARNING: renaming "_ssl" since importing it failed: dlopen(build/lib.macosx-10.5-i386-3.3/_ssl.so, 2): Symbol not found: _SSL_get_current_compression
  Referenced from: /Users/vinay/projects/pythonv/build/lib.macosx-10.5-i386-3.3/_ssl.so
  Expected in: dynamic lookup

Failed to build these modules:
_ssl                                                  

It looks as if OPENSSL_NO_COMP needs to be defined in _ssl.c if the OpenSSL version is too old and not already defined. With this change:

#if OPENSSL_VERSION_NUMBER < 0x0090800fL && !defined(OPENSSL_NO_COMP)
# define OPENSSL_NO_COMP
#endif

the ssl library builds without errors. However, test_ssl fails because it still expects OP_SINGLE_ECDH_USE to be defined. With this change in test_constants:

        if ssl.HAS_ECDH:
            ssl.OP_SINGLE_ECDH_USE

all tests pass.

I notice that the test there for OP_NO_COMPRESSION is version-based rather than capability-based, and it might be a good idea to change this too.
msg153722 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-02-19 19:44
Could you provide a patch with those proposed changes?

Le samedi 18 février 2012 à 00:45 +0000, Vinay Sajip a écrit :
> Vinay Sajip <vinay_sajip@yahoo.co.uk> added the comment:

> 
> Almost there. The file now compiles, but a failure occurs in a later step due to compression functionality being unavailable:
> 
> building '_ssl' extension
> gcc -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -IInclude -I. -I./Include -I/Users/vinay/projects/pythonv -c /Users/vinay/projects/pythonv/Modules/_ssl.c -o build/temp.macosx-10.5-i386-3.3/Users/vinay/projects/pythonv/Modules/_ssl.o
> /Users/vinay/projects/pythonv/Modules/_ssl.c: In function ‘_get_peer_alt_names’:
> /Users/vinay/projects/pythonv/Modules/_ssl.c:645: warning: passing argument 2 of ‘ASN1_item_d2i’ from incompatible pointer type
> /Users/vinay/projects/pythonv/Modules/_ssl.c:650: warning: passing argument 2 of ‘method->d2i’ from incompatible pointer type
> /Users/vinay/projects/pythonv/Modules/_ssl.c: In function ‘PySSL_compression’:
> /Users/vinay/projects/pythonv/Modules/_ssl.c:1022: warning: implicit declaration of function ‘SSL_get_current_compression’
> /Users/vinay/projects/pythonv/Modules/_ssl.c:1022: warning: assignment makes pointer from integer without a cast
> gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.5-i386-3.3/Users/vinay/projects/pythonv/Modules/_ssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.macosx-10.5-i386-3.3/_ssl.so
> *** WARNING: renaming "_ssl" since importing it failed: dlopen(build/lib.macosx-10.5-i386-3.3/_ssl.so, 2): Symbol not found: _SSL_get_current_compression
>   Referenced from: /Users/vinay/projects/pythonv/build/lib.macosx-10.5-i386-3.3/_ssl.so
>   Expected in: dynamic lookup
> 
> Failed to build these modules:
> _ssl                                                  
> 
> It looks as if OPENSSL_NO_COMP needs to be defined in _ssl.c if the OpenSSL version is too old and not already defined. With this change:
> 
> #if OPENSSL_VERSION_NUMBER < 0x0090800fL && !defined(OPENSSL_NO_COMP)
> # define OPENSSL_NO_COMP
> #endif
> 
> the ssl library builds without errors. However, test_ssl fails because it still expects OP_SINGLE_ECDH_USE to be defined. With this change in test_constants:
> 
>         if ssl.HAS_ECDH:
>             ssl.OP_SINGLE_ECDH_USE
> 
> all tests pass.
> 
> I notice that the test there for OP_NO_COMPRESSION is version-based rather than capability-based, and it might be a good idea to change this too.
> 
> ----------
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue13627>
> _______________________________________
msg153724 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2012-02-19 20:17
Attached.
msg153725 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-02-19 20:26
> Attached.

Thanks. Should be fixed in 1a06f0a8120f. Can you check? :)
msg153740 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2012-02-20 00:39
Good news: the _ssl module builds OK, the ssl module can be imported, and test_ssl now has no failures on Mac OS X 10.5.8 / OpenSSL 0.9.7 :-)
History
Date User Action Args
2022-04-11 14:57:24adminsetgithub: 57836
2012-02-20 00:39:42vinay.sajipsetmessages: + msg153740
2012-02-19 20:26:26pitrousetmessages: + msg153725
2012-02-19 20:17:38vinay.sajipsetfiles: + ssl-ecdh.diff

messages: + msg153724
2012-02-19 19:44:57pitrousetmessages: + msg153722
2012-02-18 00:45:29vinay.sajipsetmessages: + msg153614
2012-02-17 17:51:48pitrousetmessages: + msg153586
2012-02-17 17:05:58vinay.sajipsetmessages: + msg153571
2012-02-17 15:53:54vinay.sajipsetmessages: + msg153556
2012-02-17 15:52:18vinay.sajipsetmessages: + msg153555
2012-02-17 12:56:03pitrousetmessages: + msg153542
2012-02-17 12:48:16vinay.sajipsetmessages: + msg153541
2012-02-17 10:57:13pitrousetmessages: + msg153538
2012-02-17 10:52:32vinay.sajipsetnosy: + vinay.sajip
messages: + msg153536
2011-12-21 15:45:08meador.ingesetmessages: + msg149999
2011-12-21 08:34:52pitrousetstatus: open -> closed

messages: + msg149966
2011-12-21 08:33:37pitrousetmessages: + msg149965
2011-12-21 08:28:25python-devsetmessages: + msg149964
2011-12-21 08:19:42pitrousetmessages: + msg149963
2011-12-21 08:18:59pitrousetmessages: + msg149962
2011-12-21 07:27:53pitrousetstatus: closed -> open
2011-12-21 07:22:55pitrousetmessages: + msg149961
2011-12-21 05:18:25meador.ingesetnosy: + meador.inge
messages: + msg149955
2011-12-19 16:19:05pitrousetstatus: open -> closed
resolution: fixed
messages: + msg149875

stage: patch review -> resolved
2011-12-19 16:18:23python-devsetnosy: + python-dev
messages: + msg149874
2011-12-19 11:16:14naifsetmessages: + msg149841
2011-12-19 11:14:23pitrousetmessages: + msg149840
2011-12-19 10:53:36naifsetmessages: + msg149836
2011-12-19 10:44:54pitrousetmessages: + msg149832
title: Python SSL stack doesn't support Elliptic Curve ciphers -> Python SSL stack doesn't support Elliptic Curve ciphers
2011-12-19 10:32:33naifsetmessages: + msg149828
2011-12-19 10:09:26pitrousetfiles: + ecdh.patch
keywords: + patch
messages: + msg149826

stage: needs patch -> patch review
2011-12-19 01:56:38jceasetnosy: + jcea
2011-12-18 16:58:46naifsetmessages: + msg149782
2011-12-18 16:31:11pitrousetmessages: + msg149779
2011-12-18 14:51:31naifsetmessages: + msg149761
2011-12-18 14:30:54pitrousetversions: - Python 2.6, Python 3.1, Python 2.7, Python 3.2, Python 3.4
nosy: + pitrou

messages: + msg149760

type: enhancement
stage: needs patch
2011-12-18 14:24:59naifsetmessages: + msg149758
2011-12-18 13:37:58naifcreate