[
https://issues.apache.org/jira/browse/HTTPCLIENT-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated HTTPCLIENT-2302:
---------------------------------------
Description:
The examples
[ClientCustomSSL|https://github.com/apache/httpcomponents-client/blob/rel/v5.2.1/httpclient5/src/test/java/org/apache/hc/client5/http/examples/ClientCustomSSL.java]
and
[AsyncClientCustomSSL|https://github.com/apache/httpcomponents-client/blob/rel/v5.2.1/httpclient5/src/test/java/org/apache/hc/client5/http/examples/AsyncClientCustomSSL.java]
both have a Javadoc comment which says:
{quote}This example demonstrates how to create secure connections with a custom
SSL context.
{quote}
However, this is misleading or even incorrect because the code below does the
following:
{code:java}
.loadTrustMaterial((chain, authType) -> {
final X509Certificate cert = chain[0];
return "CN=httpbin.org".equalsIgnoreCase(cert.getSubjectDN().getName());
})
{code}
This accepts the certificate as long as the subject matches, without properly
validating it at all, allowing man-in-the-middle attacks.
This can for example be seen with the various [https://badssl.com/] subdomains.
For example changing in the example the URL to
[https://self-signed.badssl.com/] and changing the expected subject to
{{"CN=*.badssl.com, O=BadSSL, L=San Francisco, ST=California, C=US"}} still
successfully creates the connection, even though the certificate is self-signed
and could have been issued by a malicious actor performing a MITM attack.
Ideally this section with the custom {{TrustStrategy}} should be removed
because it is not even necessary for this example to work.
Or if you want to keep this, then there should be a big "WARNING: ..." comment
in this line. Otherwise users might erroneously think a custom
{{TrustStrategy}} is needed for TLS to work, or they might just keep this
example code because their code "works", without understanding the consequences
of this.
was:
{+}{+}The examples
[ClientCustomSSL|https://github.com/apache/httpcomponents-client/blob/rel/v5.2.1/httpclient5/src/test/java/org/apache/hc/client5/http/examples/ClientCustomSSL.java]
and
[AsyncClientCustomSSL|https://github.com/apache/httpcomponents-client/blob/rel/v5.2.1/httpclient5/src/test/java/org/apache/hc/client5/http/examples/AsyncClientCustomSSL.java]
both have a Javadoc comment which says:
{quote}This example demonstrates how to create secure connections with a custom
SSL context.
{quote}
However, this is misleading or even incorrect because the code below does the
following:
{code:java}
.loadTrustMaterial((chain, authType) -> {
final X509Certificate cert = chain[0];
return "CN=httpbin.org".equalsIgnoreCase(cert.getSubjectDN().getName());
})
{code}
This accepts the certificate as long as the subject matches, without properly
validating it at all, allowing man-in-the-middle attacks.
This can for example be seen with the various [https://badssl.com/] subdomains.
For example changing in the example the URL to
[https://self-signed.badssl.com/] and changing the expected subject to
{{"CN=*.badssl.com, O=BadSSL, L=San Francisco, ST=California, C=US"}} still
successfully creates the connection, even though the certificate is self-signed
and could have been issued by a malicious actor performing a MITM attack.
Ideally this section with the custom {{TrustStrategy}} should be removed
because it is not even necessary for this example to work.
Or if you want to keep this, then there should be a big "WARNING: ..." comment
in this line. Otherwise users might erroneously think a custom
{{TrustStrategy}} is needed for TLS to work, or they might just keep this
example code because their code "works", without understanding the consequences
of this.
> Examples ClientCustomSSL and AsyncClientCustomSSL are misleading and insecure
> -----------------------------------------------------------------------------
>
> Key: HTTPCLIENT-2302
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2302
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Reporter: Marcono1234
> Priority: Major
>
> The examples
> [ClientCustomSSL|https://github.com/apache/httpcomponents-client/blob/rel/v5.2.1/httpclient5/src/test/java/org/apache/hc/client5/http/examples/ClientCustomSSL.java]
> and
> [AsyncClientCustomSSL|https://github.com/apache/httpcomponents-client/blob/rel/v5.2.1/httpclient5/src/test/java/org/apache/hc/client5/http/examples/AsyncClientCustomSSL.java]
> both have a Javadoc comment which says:
> {quote}This example demonstrates how to create secure connections with a
> custom SSL context.
> {quote}
> However, this is misleading or even incorrect because the code below does the
> following:
> {code:java}
> .loadTrustMaterial((chain, authType) -> {
> final X509Certificate cert = chain[0];
> return "CN=httpbin.org".equalsIgnoreCase(cert.getSubjectDN().getName());
> })
> {code}
> This accepts the certificate as long as the subject matches, without properly
> validating it at all, allowing man-in-the-middle attacks.
> This can for example be seen with the various [https://badssl.com/]
> subdomains. For example changing in the example the URL to
> [https://self-signed.badssl.com/] and changing the expected subject to
> {{"CN=*.badssl.com, O=BadSSL, L=San Francisco, ST=California, C=US"}} still
> successfully creates the connection, even though the certificate is
> self-signed and could have been issued by a malicious actor performing a MITM
> attack.
> Ideally this section with the custom {{TrustStrategy}} should be removed
> because it is not even necessary for this example to work.
> Or if you want to keep this, then there should be a big "WARNING: ..."
> comment in this line. Otherwise users might erroneously think a custom
> {{TrustStrategy}} is needed for TLS to work, or they might just keep this
> example code because their code "works", without understanding the
> consequences of this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
