[CDRIVER-2846] OpenSSL 1.1.1 compatibility Created: 07/Oct/18 Updated: 28/Oct/23 Resolved: 16/Nov/18 |
|
| Status: | Closed |
| Project: | C Driver |
| Component/s: | tls |
| Affects Version/s: | None |
| Fix Version/s: | 1.14.0 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | A. Jesse Jiryu Davis | Assignee: | A. Jesse Jiryu Davis |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Epic Link: | FY2019Q4 Quick Wins (C and CXX) | ||||||||
| Description |
|
Our Evergreen Archlinux images just upgraded to OpenSSL 1.1.1, revealing at least 3 issues:
Update: The test certs are ok for now, the original report that OpenSSL 1.1.1 bans SHA1 signatures was wrong, it's actually a Debian policy that bans them. I've opened Some clues about the mock server test failures. OpenSSL 1.1.1 supports TLS 1.3: "TLSv1.3 sends more non-application data records after the handshake is finished. At least the session ticket and possibly a key update is send after the finished message. With TLSv1.2 it happened in case of renegotiation. SSL_read() has always documented that it can return SSL_ERROR_WANT_READ after processing non-application data, even when there is still data that can be read. When SSL_MODE_AUTO_RETRY is set using SSL_CTX_set_mode() OpenSSL will try to process the next record, and so not return SSL_ERROR_WANT_READ while it still has data available. Because many applications did not handle this properly, SSL_MODE_AUTO_RETRY has been made the default. If the application is using blocking sockets and SSL_MODE_AUTO_RETRY is enabled, and select() is used to check if a socket is readable this results in SSL_read() processing the non-application data records, but then try to read an application data record which might not be available and hang." The C Driver isn't hanging with blocking sockets, it's getting an error with non-blocking sockets. Still, the problem must be in this vicinity, because disabling TLS 1.3 in _mongoc_openssl_ctx_new with "SSL_CTX_set_max_proto_version (ctx, TLS1_2_VERSION)" makes the bug disappear.
|
| Comments |
| Comment by Githook User [ 16/Nov/18 ] | |||||
|
Author: {'name': 'A. Jesse Jiryu Davis', 'email': 'jesse@mongodb.com', 'username': 'ajdavis'}Message: OpenSSL 1.1.1 supports TLSv1.3, and the docs say "TLSv1.3 sends more Also fix the CMake config check for ASN1_STRING_get0_data, and avoid Finally, if we test build an old OpenSSL locally on a system where 1.1.1 is the | |||||
| Comment by A. Jesse Jiryu Davis [ 14/Nov/18 ] | |||||
|
... on repeated testing these discrepancies are noise. There's a 100-millisecond timeout within the mock server "accept()" loop, I bet that causes a race that can sometimes add 100 ms to the test duration - but I observe that both with and without my OpenSSL 1.1.1 fix in place. The tests run within the same range of durations with and without this fix. | |||||
| Comment by A. Jesse Jiryu Davis [ 13/Nov/18 ] | |||||
|
So far, the Ubuntu 14.04 "/Client*" tests are the same speed as the Archlinux TLS v1.3 tests except for:
| |||||
| Comment by A. Jesse Jiryu Davis [ 12/Nov/18 ] | |||||
|
Done - with a server built against OpenSSL 1.1.1 the old driver fails to connect, as expected, and the new one succeeds. I want to compare the runtimes of the "/Client*" tests with and without TLS v1.3 and the patch: this change risks trying too hard to read from a closed or failed connection, and comparing test durations seems like a good place to find new bugs in that area. | |||||
| Comment by A. Jesse Jiryu Davis [ 07/Nov/18 ] | |||||
|
The code review is rough, but it seems to have approximately the right solution for OpenSSL 1.1.1. So far I think LibreSSL, SChannel, and Secure Transport don't support TLS v1.3 and don't need the analogous fix yet. We don't have a server with TLS v1.3 support available in Evergreen yet, so before I close this ticket I should build one on Arch Linux and test the old and new driver code against it. |