SSL padding bug with suwsgi

[jyundt]

First reported by Norbert Wasilewski on the mailing list.

Using suwsgi between nginx <-> uwsgi causes timeouts or connection resets. Reverting to uwsgi protocol (e.g. no encryption) resolves this problem. Reproducible on CentOS 7, Ubuntu 16.04 and Ubuntu 14.04.

As per Roberto De Ioris, this may be an OpenSSL padding bug:

Hi, just to inform you that the task is becoming more challenging than expected, there is something wrong with openssl padding, i am still heavily working on it.

I'll back to you as soon as i have updates

For more information, refer to previous mailing list posts:

• http://lists.unbit.it/pipermail/uwsgi/2016-November/008596.html
• http://lists.unbit.it/pipermail/uwsgi/2016-November/008610.html
• http://lists.unbit.it/pipermail/uwsgi/2017-February/008650.html

[unbit]

I am still bashing my head over this, currently the only way i found to reproduce the problem is when nginx is in place. Can you confirm that with https-socket you have no issues ?

[jyundt]

@unbit
Flipping to https-socket gives me a similar error compared to suwsgi but there doesn't seem to be as pronounced of a performance hit during these connection resets.

Mar 22 14:43:33 centos uwsgi[19912]: uwsgi_proto_ssl_write()/SSL_write(): Connection reset by peer [proto/base.c line 291]
Mar 22 14:43:33 centos uwsgi[19912]: Wed Mar 22 14:43:33 2017 - uwsgi_response_sendfile_do(): Connection reset by peer [core/writer.c line 645] during GET /static/image.jpg (127.0.0.1)
Mar 22 14:43:33 centos uwsgi[19912]: IOError: write error

However, I started noticing these new nginx errors with https-socket:

2017/03/22 14:46:32 [warn] 16069#16069: *9 upstream sent more data than specified in "Content-Length" header while reading upstream, client: 96.235.##.##, server: ip-172-31-##-##.ec2.internal, request: "GET /static/image.jpg HTTP/1.1", upstream: "https://172.31.##.##:5000/static/image.jpg", host: "######", referrer: "######"

Most of my testing has been pretty subjective so far. Let me know if you'd like me to collect any strace/tcpdump/whatever data.

[unbit]

@jyundt Those are completely different errors, it looks like the sendfile api over ssl is broken. Damn another bug :) By the way, in my tests https-socket requests are alla managed fine, while uwsgi not. I fear it is something wrong in nginx, i will investigate on it too.

[jyundt]

@unbit

Those are completely different errors, it looks like the sendfile api over ssl is broken. Damn another bug :)

Yikes, sorry about the false positive.

Do you want me to open a separate GH bug for this sendfile + ssl problem? If so, do you need any additional data?

[unbit]

@jyundt the https+sendfile bug has been solved in 2.0.15. Unfortunately still no suwsgi fix :(