[
https://issues.apache.org/jira/browse/HTTPCLIENT-2302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771248#comment-17771248
]
Marcono1234 commented on HTTPCLIENT-2302:
-----------------------------------------
{quote}
Marcono1234 And then what? They would also need to hijack httpbin.org and
replace the original key and the certificate on the target server or at the
very least hijack the DNS resolution on the client side, would not they? You
might as well get green men from Mars involved in that attack.
{quote}
No you don't, you would have to perform a man-in-the-middle attack; unless I am
overlooking something here, in that case please point that out. That does not
involve hijacking any servers; in the easiest case the user connects to an open
unprotected network and you can intercept their traffic. I am not going to
start a general discussion here about how likely / easy or not it is to perform
a man-in-the-middle attack; my point is that this would allow a
man-in-the-middle attack.
{quote}
Again, these examples of HttpClient APi usage and not a tutorial how to do
certificate validation correctly.
{quote}
My points are:
# The usage of {{TrustStrategy}} is not needed for the example to work; it
might just confuse the user because and make them erroneously believe it is
necessary to use a {{TrustStrategy}}
# The {{TrustStrategy}} is used without any comment and without explaining the
security implications
It is not really clear to me why you are so repulsing; if any of my previous
messages sounded rude, then that was not my intention.
If you want I can provide a PR for adjusting the examples; I would prefer to
remove the {{TrustStrategy}} usage, but if you really want to keep it then I
would at least like to add a comment there.
> 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
