[
https://issues.apache.org/jira/browse/HTTPCLIENT-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17770922#comment-17770922
]
Marcono1234 commented on HTTPCLIENT-2302:
-----------------------------------------
{quote}
do _NOT_ disable the hostname verification, so the purported MITM would not
succeed anyway
{quote}
But hostname verification only makes sure the hostname specified in the
certificate matches the hostname of the target server, it doesn't validate the
certificate chain. Does it?
With the httpbin.org example above; what prevents an attacker from performing a
man-in-the-middle attack and providing their own certificate which has
httpbin.org as {{subjectAltName}}? I don't think anything is preventing this,
which can be seen with the https://self-signed.badssl.com/ example above, where
only checking {{getSubjectDN()}} allows the connection despite the self-signed
certificate. So anyone could have created that certificate, even an attacker.
> 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
