{"push_id":3008603816,"size":2,"distinct_size":2,"ref":"refs/heads/master","head":"1d0a8943d8be24a6f3dd3e4d2c8bfaad1fb75c87","before":"4de2aeccb045269526d6f24772b6d8dec043e713","commits":[{"sha":"44931460201d15fe573bea3cf7e16ceaf620f803","author":{"name":"Narayanan Iyer","email":"a0773260a60602a6cb900dc800820fe2e0f35cab@yottadb.com"},"message":"[#376] Add support for TLS 1.3 in the reference TLS implementation that ships with the encryption plugin; [#375] Remove support for SSL2.0, SSL3.0 and TLS1.0 even for encrypted SOCKET devices using TLS plugin\n\nFixes for #376\n---------------\nThe primary fix is to sr_unix/gtm_tls_impl.c to allow TLS 1.3 (which is the default ssl version in the\nlibssl.so library on Ubuntu 18.10) as a recognized version in the plugin.\n\nWhile at this, removed openssl-1.0 code in the makefile (sr_unix/Makefile.mk) that was introduced a while\nback. This was an Arch-Linux-only workaround introduced around a year back to force openssl1.0 to be linked\nby the TLS plugin and is no longer needed now that we support openssl1.1.\n\nWith these changes, testing in-house revealed a non-trivial issue. TLS 1.3 does not support renegotiation\nwhereas that is a user-visible aspect of the TLS plugin. So SSL_renegotiate() calls were done only for\nTLS 1.2 and below whereas in TLS 1.3 a SSL_key_update() call is now done to update the connection keys\nwhich is the primary purpose (in my understanding) why the SSL_renegotiate() call is currently being\nused in the plugin. This keeps the user-level view of a key renegotiation still in place even if TLS 1.3\nis being used inside the plugin.\n\nIt was also noticed that assert() macro was enabled even in PRO builds of the TLS plugin (gtm_tls_impl.c)\nwhereas in the YottaDB code it is enabled only in DEBUG builds. This can have even user-visible impact\nin cases where the assert() call invokes other functions. This macro is now fixed to be enabled only in\nDEBUG builds.\n\nSSL_get_verify_result() was being invoked unnecessarily (in my opinion) in gtm_tls_connect(),\ngtm_tls_accept(), gtm_tls_send() and gtm_tls_recv(). Those calls are now removed and just SSL_get_error()\nis invoked in case of an error.\n\nFixes for #375\n---------------\nThe place where list of supported TLS versions was checked is not correct. It was in\ngtm_tls_get_conn_info() in the TLS plugin which is called by the replication servers in TLS mode,\nbut not necessarily by encrypted SOCKET devices (in M) which acts as a server or client with TLS\nenabled (and uses the TLS plugin). This check is now done in a new function ydb_tls_is_supported()\nwhich is invoked from gtm_tls_connect() and gtm_tls_accept() (the client and server side\ninvocations) which are called both by the replication servers and encrypted SOCKET devices which\nuses TLS functionality. This new function returns -1 in case of an unsupported TLS version (of the\nnegotiated connection). Additionally, it sets the error string to indicate the current TLS version\n(e.g. \"TLSv1.1\") thus giving the user a more friendly error message in case the connection is not\nsupported by the TLS plugin.","distinct":true,"url":"https://api.github.com/repos/YottaDB/YDB/commits/44931460201d15fe573bea3cf7e16ceaf620f803"},{"sha":"1d0a8943d8be24a6f3dd3e4d2c8bfaad1fb75c87","author":{"name":"Narayanan Iyer","email":"a0773260a60602a6cb900dc800820fe2e0f35cab@yottadb.com"},"message":"[#376] Disable SSL_MODE_AUTO_RETRY due to SSL_read() hangs since TLS 1.3 sends more non-application data records after handshake\n\nThe online_rollback/gtm8421 subtest (and online_rollback/basic subtest) failed on systems where TLS 1.3 was\nin use in the system installed openssl library (OpenSSL 1.1.1).\n\nThe real issue seems to be a hang in the source server. An strace showed the below C-stack at the time\nof the read() system call hang. The read() call eventually got interrupted by a timer (after 15 seconds)\nand so returned back from SSL_read() to the caller gtm_tls_recv() but it is effectively a hang.\n\n/usr/lib/libc-2.28.so(__read+0x15) [0xec775]\n/usr/lib/libcrypto.so.1.1(BIO_sock_should_retry+0x60) [0xb0100]\n/usr/lib/libcrypto.so.1.1(BIO_number_written+0xba) [0xab33a]\n/usr/lib/libcrypto.so.1.1(ERR_load_BIO_strings+0x1b3) [0xaa1c3]\n/usr/lib/libcrypto.so.1.1(BIO_read+0x23) [0xaa793]\n/usr/lib/libssl.so.1.1(SSL_rstate_string+0x270) [0x22500]\n/usr/lib/libssl.so.1.1(SSL_rstate_string+0x448b) [0x2671b]\n/usr/lib/libssl.so.1.1(SSL_rstate_string+0x1e1f) [0x240af]\n/usr/lib/libssl.so.1.1(SSL_rstate_string+0x92c6) [0x2b556]\n/usr/lib/libssl.so.1.1(SSL_get_default_timeout+0x8c) [0x361ac]\n/usr/lib/libssl.so.1.1(SSL_read+0x24) [0x362b4]\nplugin/libgtmtls.so(gtm_tls_recv+0xaf) [0xb613]\nlibyottadb.so(intrsafe_gtm_tls_recv+0x62) [0x4eca31]\nlibyottadb.so(repl_recv+0x184) [0x3b9fba]\nlibyottadb.so(gtmsource_recv_ctl+0x2e7) [0xc0b70]\nlibyottadb.so(gtmsource_process+0x35ec) [0xc5345]\nlibyottadb.so(gtmsource+0x275e) [0xbb27c]\nlibyottadb.so(mupip_main+0x229) [0x2e1a3]\nmupip(dlopen_libyottadb+0x6bd) [0x1917]\nmupip(main+0x3b) [0x1244]\n/usr/lib/libc-2.28.so(__libc_start_main+0xf3) [0x24223]\nmupip(_start+0x2e) [0x113e]\n\n-------------\nhttps://wiki.openssl.org/index.php/TLS1.3 says the following about TLS 1.3.\n\nTLSv1.3 sends more non-application data records after the handshake is finished. At least the session\nticket and possibly a key update is send after the finished message. With TLSv1.2 it happened in\ncase of renegotiation. SSL_read() has always documented that it can return SSL_ERROR_WANT_READ\nafter processing non-application data, even when there is still data that can be read. When\nSSL_MODE_AUTO_RETRY is set using SSL_CTX_set_mode() OpenSSL will try to process the next record,\nand so not return SSL_ERROR_WANT_READ while it still has data available. Because many applications\ndid not handle this properly, SSL_MODE_AUTO_RETRY has been made the default. If the application\nis using blocking sockets and SSL_MODE_AUTO_RETRY is enabled, and select() is used to check if a\nsocket is readable this results in SSL_read() processing the non-application data records, but then\ntry to read an application data record which might not be available and hang.\n-------------\n\nThe YottaDB TLS plugin had previously enabled SSL_MODE_AUTO_RETRY. While going through the code, I\ndo not see any reason why this is necessary as the caller code of gtm_tls_recv() (e.g. repl_recv())\nseems to be coded to handle the GTMTLS_WANT_READ and GTMTLS_WANT_WRITE return codes (which are TLS\nplugin names for the underlying SSL error codes SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE).\n\nYottaDB uses blocking sockets for the replication servers as well as for the SOCKET device. Now that\nwe know TLS 1.3 can cause hangs in SSL_read(), SSL_MODE_AUTO_RETRY is disabled. Note that it is not\nenough to remove the SSL_CTX_set_mode() call that previously enabled SSL_MODE_AUTO_RETRY as this is\nthe default in TLS 1.3. Hence the SSL_CTX_set_mode() call replacement with SSL_CTX_clear_mode().","distinct":true,"url":"https://api.github.com/repos/YottaDB/YDB/commits/1d0a8943d8be24a6f3dd3e4d2c8bfaad1fb75c87"}]}
{"actor":{"display_login":"chathaway-codes"}}