Issue13627
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.
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) * ![]() |
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) * ![]() |
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) * ![]() |
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) * ![]() |
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) * ![]() |
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) ![]() |
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) * ![]() |
Date: 2011-12-19 16:19 | |
Patch now committed in 3.3. |
|||
msg149955 - (view) | Author: Meador Inge (meador.inge) * ![]() |
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) * ![]() |
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) * ![]() |
Date: 2011-12-21 08:18 | |
Can you post the exact compiler errors you encountered? |
|||
msg149963 - (view) | Author: Antoine Pitrou (pitrou) * ![]() |
Date: 2011-12-21 08:19 | |
Nevermind, I've found them on the Fedora buildbot. |
|||
msg149964 - (view) | Author: Roundup Robot (python-dev) ![]() |
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) * ![]() |
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) * ![]() |
Date: 2011-12-21 08:34 | |
ec44f2e82707 fixed compilation on Fedora and test_ssl passed fine. |
|||
msg149999 - (view) | Author: Meador Inge (meador.inge) * ![]() |
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) * ![]() |
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) * ![]() |
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) * ![]() |
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) * ![]() |
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) * ![]() |
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) * ![]() |
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) * ![]() |
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) * ![]() |
Date: 2012-02-17 17:51 | |
Ok, can you try again? 06ed9b3f02af |
|||
msg153614 - (view) | Author: Vinay Sajip (vinay.sajip) * ![]() |
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) * ![]() |
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) * ![]() |
Date: 2012-02-19 20:17 | |
Attached. |
|||
msg153725 - (view) | Author: Antoine Pitrou (pitrou) * ![]() |
Date: 2012-02-19 20:26 | |
> Attached. Thanks. Should be fixed in 1a06f0a8120f. Can you check? :) |
|||
msg153740 - (view) | Author: Vinay Sajip (vinay.sajip) * ![]() |
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:24 | admin | set | github: 57836 |
2012-02-20 00:39:42 | vinay.sajip | set | messages: + msg153740 |
2012-02-19 20:26:26 | pitrou | set | messages: + msg153725 |
2012-02-19 20:17:38 | vinay.sajip | set | files:
+ ssl-ecdh.diff messages: + msg153724 |
2012-02-19 19:44:57 | pitrou | set | messages: + msg153722 |
2012-02-18 00:45:29 | vinay.sajip | set | messages: + msg153614 |
2012-02-17 17:51:48 | pitrou | set | messages: + msg153586 |
2012-02-17 17:05:58 | vinay.sajip | set | messages: + msg153571 |
2012-02-17 15:53:54 | vinay.sajip | set | messages: + msg153556 |
2012-02-17 15:52:18 | vinay.sajip | set | messages: + msg153555 |
2012-02-17 12:56:03 | pitrou | set | messages: + msg153542 |
2012-02-17 12:48:16 | vinay.sajip | set | messages: + msg153541 |
2012-02-17 10:57:13 | pitrou | set | messages: + msg153538 |
2012-02-17 10:52:32 | vinay.sajip | set | nosy:
+ vinay.sajip messages: + msg153536 |
2011-12-21 15:45:08 | meador.inge | set | messages: + msg149999 |
2011-12-21 08:34:52 | pitrou | set | status: open -> closed messages: + msg149966 |
2011-12-21 08:33:37 | pitrou | set | messages: + msg149965 |
2011-12-21 08:28:25 | python-dev | set | messages: + msg149964 |
2011-12-21 08:19:42 | pitrou | set | messages: + msg149963 |
2011-12-21 08:18:59 | pitrou | set | messages: + msg149962 |
2011-12-21 07:27:53 | pitrou | set | status: closed -> open |
2011-12-21 07:22:55 | pitrou | set | messages: + msg149961 |
2011-12-21 05:18:25 | meador.inge | set | nosy:
+ meador.inge messages: + msg149955 |
2011-12-19 16:19:05 | pitrou | set | status: open -> closed resolution: fixed messages: + msg149875 stage: patch review -> resolved |
2011-12-19 16:18:23 | python-dev | set | nosy:
+ python-dev messages: + msg149874 |
2011-12-19 11:16:14 | naif | set | messages: + msg149841 |
2011-12-19 11:14:23 | pitrou | set | messages: + msg149840 |
2011-12-19 10:53:36 | naif | set | messages: + msg149836 |
2011-12-19 10:44:54 | pitrou | set | messages:
+ 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:33 | naif | set | messages: + msg149828 |
2011-12-19 10:09:26 | pitrou | set | files:
+ ecdh.patch keywords: + patch messages: + msg149826 stage: needs patch -> patch review |
2011-12-19 01:56:38 | jcea | set | nosy:
+ jcea |
2011-12-18 16:58:46 | naif | set | messages: + msg149782 |
2011-12-18 16:31:11 | pitrou | set | messages: + msg149779 |
2011-12-18 14:51:31 | naif | set | messages: + msg149761 |
2011-12-18 14:30:54 | pitrou | set | versions:
- 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:59 | naif | set | messages: + msg149758 |
2011-12-18 13:37:58 | naif | create |