New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compatibility with OpenSSL 1.1 #1395

Open
rhertzog opened this Issue Nov 3, 2016 · 17 comments

Comments

Projects
None yet
8 participants
@rhertzog
Copy link

rhertzog commented Nov 3, 2016

Debian wants to switch to OpenSSL 1.1 and uwsgi is currently failing to build with that version as reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828590

It would be nice if uwsgi could be made to work with OpenSSL 1.1 too.

@xrmx

This comment has been minimized.

Copy link
Collaborator

xrmx commented Nov 3, 2016

Thanks for forwarding the issue here, will take a look.

xrmx added a commit to xrmx/uwsgi that referenced this issue Nov 6, 2016

@xrmx

This comment has been minimized.

Copy link
Collaborator

xrmx commented Nov 6, 2016

@unbit i think we have a problem, you poked with struct internals which have now made opaque and thus we no more access to. With the untested patch above these two hunks needs a rework:

core/ssl.c: In function ‘uwsgi_ssl_info_cb’:
core/ssl.c:28:24: error: dereferencing pointer to incomplete type ‘SSL {aka const struct ssl_st}’
                 if (ssl->s3) {
                        ^~
core/ssl.c: In function ‘uwsgi_ssl_session_new_cb’:
core/ssl.c:64:69: error: dereferencing pointer to incomplete type ‘SSL_SESSION {aka struct ssl_session_st}’
         if (uwsgi_cache_set2(uwsgi.ssl_sessions_cache, (char *) sess->session_id, sess->session_id_length, session_blob, len, uwsgi.ssl_sessions_timeout, 0)) {
                                                                     ^~
@unbit

This comment has been minimized.

Copy link
Owner

unbit commented Nov 12, 2016

@xrmx is see no other solution than removing the ssl cache sync feature (well i do not think anyone is using it...)

xrmx added a commit to xrmx/uwsgi that referenced this issue Nov 12, 2016

Cope with openssl 1.1 API changes
Since OpenSSL 1.1.0 made some structs opaque and this we cannot
poke with the internals anymore. Because of that we have to
disable the ssl session cache.

Ref unbit#1395
@xrmx

This comment has been minimized.

Copy link
Collaborator

xrmx commented Nov 12, 2016

@unbit i've updated the branch above, any chance you can give it a run? It compiles fine on my machine with openssl 1.1.0 but I haven't tested it.

My only concern is that in both core/ssl.c and http/spdy3.c we have to ifdef this kind of code. Is it a security issue? Like now we can downgrade to a weaker crypto?

+#if OPENSSL_VERSION_NUMBER < 0x10100000L
                 if (ssl->s3) {
                         ssl->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS;
                 }
+#endif
@unbit

This comment has been minimized.

Copy link
Owner

unbit commented Nov 12, 2016

Looks good to me. It is sad we need to disable a feature, but i suppose no-one will cry for this :)

xrmx added a commit that referenced this issue Nov 15, 2016

Cope with openssl 1.1 API changes
Since OpenSSL 1.1.0 made some structs opaque and this we cannot
poke with the internals anymore. Because of that we have to
disable the ssl session cache.

Ref #1395

xrmx added a commit that referenced this issue Nov 15, 2016

Cope with openssl 1.1 API changes
Since OpenSSL 1.1.0 made some structs opaque and this we cannot
poke with the internals anymore. Because of that we have to
disable the ssl session cache.

Ref #1395
@xrmx

This comment has been minimized.

Copy link
Collaborator

xrmx commented Nov 15, 2016

@jonassmedegaard You can cherry-pick 2b3fb73 for building against openssl 1.1.0

@jonassmedegaard

This comment has been minimized.

Copy link
Contributor

jonassmedegaard commented Nov 15, 2016

Thanks!

@melvyn-sopacua

This comment has been minimized.

Copy link
Contributor

melvyn-sopacua commented Dec 2, 2016

This still gives linker errors (after fixes done in 5537b69) on FreeBSD. I assume tests done here use an openssl version built with OPENSSL_API_COMPAT, as the linker errors all reference functions guarded by that flag:

core/subscription.o: In function `uwsgi_remove_subscribe_node':
core/subscription.c:(.text+0x7ad): undefined reference to `EVP_MD_CTX_destroy'
core/subscription.c:(.text+0x7d9): undefined reference to `EVP_MD_CTX_destroy'
core/subscription.o: In function `subscription_new_sign_ctx':
core/subscription.c:(.text+0x15bb): undefined reference to `EVP_MD_CTX_create'
core/subscription.c:(.text+0x15f4): undefined reference to `EVP_MD_CTX_destroy'
core/ssl.o: In function `uwsgi_ssl_init':
core/ssl.c:(.text+0xc): undefined reference to `SSL_library_init'
core/ssl.c:(.text+0x11): undefined reference to `SSL_load_error_strings'
core/ssl.c:(.text+0x16): undefined reference to `OPENSSL_add_all_algorithms_noconf'
core/ssl.o: In function `uwsgi_ssl_new_server_context':
core/ssl.c:(.text+0x473): undefined reference to `SSLv23_server_method'
core/ssl.o: In function `uwsgi_rsa_sign':
core/ssl.c:(.text+0xd4e): undefined reference to `SSL_library_init'
core/ssl.c:(.text+0xd53): undefined reference to `SSL_load_error_strings'
core/ssl.c:(.text+0xd58): undefined reference to `OPENSSL_add_all_algorithms_noconf'
core/ssl.c:(.text+0xde5): undefined reference to `EVP_MD_CTX_create'
core/ssl.c:(.text+0xf2d): undefined reference to `EVP_MD_CTX_destroy'
core/ssl.o: In function `uwsgi_opt_sni':
core/ssl.c:(.text+0x1243): undefined reference to `SSL_library_init'
core/ssl.c:(.text+0x1248): undefined reference to `SSL_load_error_strings'
core/ssl.c:(.text+0x124d): undefined reference to `OPENSSL_add_all_algorithms_noconf'
core/ssl.o: In function `uwsgi_ssl_add_sni_item':
core/ssl.c:(.text+0x130e): undefined reference to `SSL_library_init'
core/ssl.c:(.text+0x1313): undefined reference to `SSL_load_error_strings'
core/ssl.c:(.text+0x1318): undefined reference to `OPENSSL_add_all_algorithms_noconf'
core/legion.o: In function `uwsgi_legion_register':
core/legion.c:(.text+0x2a23): undefined reference to `EVP_CIPHER_CTX_init'
core/legion.c:(.text+0x2b30): undefined reference to `EVP_CIPHER_CTX_init'
plugins/http/https.o: In function `uwsgi_opt_https2':
plugins/http/https.c:(.text+0x2bc): undefined reference to `SSL_CTX_get_ex_new_index'
cc: error: linker command failed with exit code 1 (use -v to see invocation)

Defining OPENSSL_API_COMPAT (CFLAGS+=-DOPENSSL_API_COMPAT=0x10000000) during uWSGI build doesn't help. It isn't a lot to fix and the best approach (also with respect to commit 2b3fb73) is probably to follow the OpenSSL wiki and implement the new functions.

@melvyn-sopacua

This comment has been minimized.

Copy link
Contributor

melvyn-sopacua commented Dec 4, 2016

The above is because the www/uwsgi FreeBSD port doesn't correctly link with OpenSSL if installed from ports. You get a mix of 1.0 headers from base system in /usr/include and link OpenSSL from ports in /usr/local/lib.
Patch to the port's Makefile in order to use 2b3fb73 would be:

diff --git a/www/uwsgi/Makefile b/www/uwsgi/Makefile
index 73c783e..a0eeddd 100644
--- a/www/uwsgi/Makefile
+++ b/www/uwsgi/Makefile
@@ -12,7 +12,7 @@ COMMENT= Developer-friendly WSGI server which uses uwsgi proto
 LICENSE=   GPLv2
 LICENSE_FILE= ${WRKSRC}/LICENSE

-USES=      python
+USES=      python ssl
 USE_PYTHON=   distutils
 USE_RC_SUBR=  uwsgi

@@ -43,6 +43,8 @@ O_XML=      libxml2
 O_XML=     false
 .endif

+CFLAGS+=   -I${OPENSSLINC}
+LDFLAGS+=  ${OPENSSL_LDFLAGS}
 MAKE_ENV+= CPUCOUNT=${MAKE_JOBS_NUMBER} UWSGI_EMBED_PLUGINS=cgi

 PYSETUP=         uwsgiconfig.py
@xrmx

This comment has been minimized.

Copy link
Collaborator

xrmx commented Dec 5, 2016

@melvyn-sopacua nice, thanks for digging the issue. I have no clue on how to forward the issue to freebsd though.

@melvyn-sopacua

This comment has been minimized.

Copy link
Contributor

melvyn-sopacua commented Dec 5, 2016

@xrmx Already done. It wasn't until I put in forward compatible code, that I realized I was hitting that code, while I shouldn't be. Then the proverbial light bulb came on.

@xrmx xrmx added the resolved label Jan 4, 2017

ashleygeorge pushed a commit to znanja/uwsgi that referenced this issue Feb 13, 2017

Cope with openssl 1.1 API changes
Since OpenSSL 1.1.0 made some structs opaque and this we cannot
poke with the internals anymore. Because of that we have to
disable the ssl session cache.

Ref unbit#1395
@jleclanche

This comment has been minimized.

Copy link

jleclanche commented Mar 21, 2017

@xrmx @unbit Is there a release planned with these changes? Right now, pip install uwsgi on debian stretch fails.

Edit: Mixed up version numbers

@xrmx

This comment has been minimized.

Copy link
Collaborator

xrmx commented Mar 22, 2017

@jleclanche a 2.0.15 release is planned, personally i don't have much free time to spend on uwsgi lately

@unbit

This comment has been minimized.

Copy link
Owner

unbit commented Mar 22, 2017

@jleclanche the #1490 is blocking the release, as soon as it is fixed i will upload the 2.0.15

@nooperpudd

This comment has been minimized.

Copy link

nooperpudd commented Mar 28, 2017

Very much look forward to 2.0.15 release.

@unbit

This comment has been minimized.

Copy link
Owner

unbit commented Mar 28, 2017

@numbsafari

This comment has been minimized.

Copy link

numbsafari commented Jul 6, 2017

2.0.15 is up on pypi, so this can be closed, no?

timabbott added a commit to timabbott/zulip that referenced this issue Mar 6, 2018

requirements: Update uwsgi to the latest version.
Apparently, older uwsgi doesn't install properly on systems with newer
versions of OpenSSL; see unbit/uwsgi#1395
for details.

This fixes zulip#7609.

amoralej pushed a commit to amoralej/uwsgi-distgit that referenced this issue Jun 7, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment