<!-- 
RSS generated by JIRA (9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66) at Wed Feb 07 21:16:31 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>MongoDB Jira</title>
    <link>https://jira.mongodb.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>9.7.1</version>
        <build-number>970001</build-number>
        <build-date>13-04-2023</build-date>
    </build-info>


<item>
            <title>[CDRIVER-2846] OpenSSL 1.1.1 compatibility</title>
                <link>https://jira.mongodb.org/browse/CDRIVER-2846</link>
                <project id="10030" key="CDRIVER">C Driver</project>
                    <description>&lt;p&gt;Our Evergreen Archlinux images just upgraded to OpenSSL 1.1.1, revealing at least 3 issues:&lt;/p&gt;
&lt;ul&gt;
	&lt;li&gt;Our&#160;ASN1_STRING_get0_data config check in CMake is broken and doesn&apos;t detect that the new function is available.&lt;/li&gt;
	&lt;li&gt;Our test certs are signed with SHA1. I&apos;ve &lt;a href=&quot;https://github.com/mongodb/motor/pull/43&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;heard this is now prohibited&#160;&lt;/a&gt;but can&apos;t find OpenSSL docs that say so; anyway we must regenerate them with SHA256.&lt;/li&gt;
	&lt;li&gt;The mock server tests fail instantly now, even with new certs. TLS handshake succeeds and the client can send isMaster to the mock server, but it gets some error reading the mock server&apos;s reply.&lt;/li&gt;
&lt;/ul&gt;


&lt;p&gt;Update:&#160;The test certs are ok for now, the original report that OpenSSL 1.1.1 bans SHA1 signatures was wrong, it&apos;s actually a Debian policy that bans them. I&apos;ve opened &lt;a href=&quot;https://jira.mongodb.org/browse/DRIVERS-575&quot; title=&quot;Regenerate test certificates with SHA256 signatures&quot; class=&quot;issue-link&quot; data-issue-key=&quot;DRIVERS-575&quot;&gt;&lt;del&gt;DRIVERS-575&lt;/del&gt;&lt;/a&gt; to regenerate them, but that&apos;s not the bug here.&lt;/p&gt;

&lt;p&gt;Some clues about the mock server test failures. &lt;a href=&quot;https://wiki.openssl.org/index.php/TLS1.3&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;OpenSSL 1.1.1 supports TLS 1.3&lt;/a&gt;:&lt;/p&gt;

&lt;p&gt;&quot;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.&#160;&lt;a href=&quot;https://www.openssl.org/docs/manmaster/man3/SSL_read.html&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;SSL_read()&lt;/a&gt;&#160;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&#160;&lt;a href=&quot;https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_mode.html&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;SSL_CTX_set_mode()&lt;/a&gt;&#160;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.&quot;&lt;/p&gt;

&lt;p&gt;The C Driver isn&apos;t hanging with blocking sockets, it&apos;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 &quot;SSL_CTX_set_max_proto_version (ctx, TLS1_2_VERSION)&quot; makes the bug disappear.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;</description>
                <environment></environment>
        <key id="615159">CDRIVER-2846</key>
            <summary>OpenSSL 1.1.1 compatibility</summary>
                <type id="2" iconUrl="https://jira.mongodb.org/secure/viewavatar?size=xsmall&amp;avatarId=14711&amp;avatarType=issuetype">New Feature</type>
                                            <priority id="3" iconUrl="https://jira.mongodb.org/images/icons/priorities/major.svg">Major - P3</priority>
                        <status id="6" iconUrl="https://jira.mongodb.org/images/icons/statuses/closed.png" description="The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.">Closed</status>
                    <statusCategory id="3" key="done" colorName="success"/>
                                    <resolution id="13201">Fixed</resolution>
                                        <assignee username="jesse@mongodb.com">A. Jesse Jiryu Davis</assignee>
                                    <reporter username="jesse@mongodb.com">A. Jesse Jiryu Davis</reporter>
                        <labels>
                    </labels>
                <created>Sun, 7 Oct 2018 15:17:42 +0000</created>
                <updated>Sat, 28 Oct 2023 11:29:33 +0000</updated>
                            <resolved>Fri, 16 Nov 2018 23:20:14 +0000</resolved>
                                                    <fixVersion>1.14.0</fixVersion>
                                    <component>tls</component>
                                        <votes>0</votes>
                                    <watches>2</watches>
                                                                                                                <comments>
                            <comment id="2065433" author="xgen-internal-githook" created="Fri, 16 Nov 2018 23:16:54 +0000"  >&lt;p&gt;Author:&lt;/p&gt;
{&apos;name&apos;: &apos;A. Jesse Jiryu Davis&apos;, &apos;email&apos;: &apos;jesse@mongodb.com&apos;, &apos;username&apos;: &apos;ajdavis&apos;}
&lt;p&gt;Message: &lt;a href=&quot;https://jira.mongodb.org/browse/CDRIVER-2846&quot; title=&quot;OpenSSL 1.1.1 compatibility&quot; class=&quot;issue-link&quot; data-issue-key=&quot;CDRIVER-2846&quot;&gt;&lt;del&gt;CDRIVER-2846&lt;/del&gt;&lt;/a&gt; OpenSSL 1.1.1 compatibility&lt;/p&gt;

&lt;p&gt;OpenSSL 1.1.1 supports TLSv1.3, and the docs say &quot;TLSv1.3 sends more&lt;br/&gt;
non-application data records after the handshake is finished.&quot; When the async&lt;br/&gt;
loop detects a socket is readable, the available data might be non-application&lt;br/&gt;
data and BIO_read returns 0. Update the async code to keep trying to read in&lt;br/&gt;
this scenario.&lt;/p&gt;

&lt;p&gt;Also fix the CMake config check for ASN1_STRING_get0_data, and avoid&lt;br/&gt;
deprecation warnings with OpenSSL 1.1.0+ from the old ASN1_STRING_data.&lt;/p&gt;

&lt;p&gt;Finally, if we test build an old OpenSSL locally on a system where 1.1.1 is the&lt;br/&gt;
default, we must keep the old OpenSSL out of CMake&apos;s own LD path or it will&lt;br/&gt;
fail to start.&lt;br/&gt;
Branch: master&lt;br/&gt;
&lt;a href=&quot;https://github.com/mongodb/mongo-c-driver/commit/7c416045fce45cbdfc46acc9d0def98294b35549&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://github.com/mongodb/mongo-c-driver/commit/7c416045fce45cbdfc46acc9d0def98294b35549&lt;/a&gt;&lt;/p&gt;</comment>
                            <comment id="2061598" author="jesse" created="Wed, 14 Nov 2018 14:17:15 +0000"  >&lt;p&gt;... on repeated testing these discrepancies are noise. There&apos;s a 100-millisecond timeout within the mock server &quot;accept()&quot; 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.&lt;/p&gt;</comment>
                            <comment id="2059610" author="jesse" created="Tue, 13 Nov 2018 01:55:26 +0000"  >&lt;p&gt;So far, the Ubuntu 14.04 &quot;/Client*&quot; tests are the same speed as the Archlinux TLS v1.3 tests except for:&lt;/p&gt;
&lt;p/&gt;
&lt;div id=&quot;syntaxplugin&quot; class=&quot;syntaxplugin&quot; style=&quot;border: 1px dashed #bbb; border-radius: 5px !important; overflow: auto; max-height: 30em;&quot;&gt;
&lt;table cellspacing=&quot;0&quot; cellpadding=&quot;0&quot; border=&quot;0&quot; width=&quot;100%&quot; style=&quot;font-size: 1em; line-height: 1.4em !important; font-weight: normal; font-style: normal; color: black;&quot;&gt;
		&lt;tbody &gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;  margin-top: 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;Test: Ubuntu duration, Archlinux duration&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;/Client/rs_seeds_no_connect/pooled: 0.298137 0.397505&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;/Client/rs_seeds_connect/single: 0.299025 0.398155&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;/Client/mongos_seeds_no_connect/pooled: 0.29807 0.39731&lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
				&lt;tr id=&quot;syntaxplugin_code_and_gutter&quot;&gt;
						&lt;td  style=&quot; line-height: 1.4em !important; padding: 0em; vertical-align: top;&quot;&gt;
					&lt;pre style=&quot;font-size: 1em; margin: 0 10px;   margin-bottom: 10px;  width: auto; padding: 0;&quot;&gt;&lt;span style=&quot;color: black; font-family: &apos;Consolas&apos;, &apos;Bitstream Vera Sans Mono&apos;, &apos;Courier New&apos;, Courier, monospace !important;&quot;&gt;/Client/mongos_seeds_connect/pooled: 0.299938 0.398329 &lt;/span&gt;&lt;/pre&gt;
			&lt;/td&gt;
		&lt;/tr&gt;
			&lt;/tbody&gt;
&lt;/table&gt;
&lt;/div&gt;
&lt;p/&gt;</comment>
                            <comment id="2058253" author="jesse" created="Mon, 12 Nov 2018 03:43:11 +0000"  >&lt;p&gt;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 &quot;/Client*&quot; 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.&lt;/p&gt;</comment>
                            <comment id="2054981" author="jesse" created="Wed, 7 Nov 2018 20:01:58 +0000"  >&lt;p&gt;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&apos;t support TLS v1.3 and don&apos;t need the analogous fix &lt;b&gt;yet&lt;/b&gt;. We don&apos;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.&lt;/p&gt;</comment>
                    </comments>
                <issuelinks>
                            <issuelinktype id="10012">
                    <name>Related</name>
                                            <outwardlinks description="related to">
                                        <issuelink>
            <issuekey id="617162">CDRIVER-2853</issuekey>
        </issuelink>
                            </outwardlinks>
                                                        </issuelinktype>
                    </issuelinks>
                <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_15850" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                            <customfield id="customfield_10857" key="com.pyxis.greenhopper.jira:gh-epic-link">
                        <customfieldname>Epic Link</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>CXX-1675</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_12550" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>2|hu01yf:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10558" key="com.pyxis.greenhopper.jira:gh-global-rank">
                        <customfieldname>Rank (Obsolete)</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>9223372036854775807</customfieldvalue>
                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            </customfields>
    </item>
</channel>
</rss>