[jira] [Commented] (HTTPCLIENT-2151) Optionally use JSSE inbuilt endpoint identification
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814287#comment-17814287
]
ASF subversion and git services commented on HTTPCLIENT-2151:
-
Commit 2e46b62ffd8c0e00ac7438c6c81b9ac6ec445149 in httpcomponents-client's
branch refs/heads/master from Oleg Kalnichevski
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=2e46b62ff ]
HTTPCLIENT-2151: Support for JSSE in-built endpoint identification
> Optionally use JSSE inbuilt endpoint identification
> ---
>
> Key: HTTPCLIENT-2151
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2151
> Project: HttpComponents HttpClient
> Issue Type: Wish
> Components: HttpClient (classic)
>Reporter: Peter Dettman
>Priority: Minor
> Fix For: 5.4-alpha2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This issue brings to the fore that part of HTTPCLIENT-2134 which is actually
> within the scope of HttpClient: the possibility of using JSSE inbuilt
> endpoint identification ("HTTPS") instead of performing those checks
> externally (typically in
> _org.apache.hc.client5.http.ssl.DefaultHostnameVerifier_).
> Java 1.7 added the method
> SSLParameters.setEndpointIdentificationAlgorithm(String). Calling this method
> with the argument "HTTPS" (case-insensitive) will result in the endpoint
> identification checks from RFC 2818 being automatically done by JSSE during
> the handshake (specifically when the X509TrustManager validates the server
> certificate). Note that the setting can also be interrogated via
> SSLParameters.getEndpointIdentificationAlgorithm.
> This has some minor advantages relative to performing the checks externally:
> * The check is done earlier in the handshake, reducing the cost of failed
> connections. (Technically this might still be achieved anyway by wrapping the
> X509TrustManager and applying a HostnameVerifier at that stage).
> * Per my comments in HTTPCLIENT-2134, in some nuanced situations SunJSSE will
> be willing to resume a session only if it knows for sure that endpoint
> identification is being used (which it can't know for an arbitrary
> HostnameVerifier).
> * SunJSSE's HTTPS endpoint identification has special (less-restrictive)
> rules for wildcard characters when the trust anchor is a certificate from the
> 'cacerts' file (what it calls a "public root CA").
> There may be other implications that I am unaware of, but I think this
> establishes that some users may prefer (or even need) to delegate endpoint
> identification to JSSE in this way. They presumably will not then want a
> duplicate check in DefaultHostnameVerifier.
> I am not yet that familiar with HttpClient, but I assume a user could already
> provide a custom SSLSocketFactory which enables JSSE endpoint identification
> on sockets before returning them, and then separately configure a no-op
> HostnameVerifier. I consider that to be rather fragile and it's easy to see
> mistakes leading to no endpoint identification being performed.
> I am proposing that HttpClient support this via a simpler configuration
> mechanism. To loosely outline some basic options:
> IGNORE: don't even check whether JSSE endpoint identification was enabled
> (i.e. assume it wasn't).
> AWARE: check at runtime whether JSSE endpoint identification was "HTTPS" for
> a given socket connection.
> DISABLE: remove any existing setting for JSSE endpoint identification (set it
> to "").
> FORCE: overwrite any existing setting for JSSE endpoint identification (set
> it to "HTTPS").
> So we would consider some value that came to us via the SSLSocketFactory's
> default socket setup, and whether to ignore it, respect it, or force it
> on/off. DefaultHostnameVerifier can then be set to possibly skip its own
> endpoint checks when appropriate.
--
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
[jira] [Commented] (HTTPCLIENT-2151) Optionally use JSSE inbuilt endpoint identification
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813105#comment-17813105
]
Oleg Kalnichevski commented on HTTPCLIENT-2151:
---
[~peter.dettman] Feel free to review the PR with the proposed changes:
[https://github.com/apache/httpcomponents-client/pull/545]
Oleg
> Optionally use JSSE inbuilt endpoint identification
> ---
>
> Key: HTTPCLIENT-2151
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2151
> Project: HttpComponents HttpClient
> Issue Type: Wish
> Components: HttpClient (classic)
>Reporter: Peter Dettman
>Priority: Minor
> Fix For: 5.4-alpha2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This issue brings to the fore that part of HTTPCLIENT-2134 which is actually
> within the scope of HttpClient: the possibility of using JSSE inbuilt
> endpoint identification ("HTTPS") instead of performing those checks
> externally (typically in
> _org.apache.hc.client5.http.ssl.DefaultHostnameVerifier_).
> Java 1.7 added the method
> SSLParameters.setEndpointIdentificationAlgorithm(String). Calling this method
> with the argument "HTTPS" (case-insensitive) will result in the endpoint
> identification checks from RFC 2818 being automatically done by JSSE during
> the handshake (specifically when the X509TrustManager validates the server
> certificate). Note that the setting can also be interrogated via
> SSLParameters.getEndpointIdentificationAlgorithm.
> This has some minor advantages relative to performing the checks externally:
> * The check is done earlier in the handshake, reducing the cost of failed
> connections. (Technically this might still be achieved anyway by wrapping the
> X509TrustManager and applying a HostnameVerifier at that stage).
> * Per my comments in HTTPCLIENT-2134, in some nuanced situations SunJSSE will
> be willing to resume a session only if it knows for sure that endpoint
> identification is being used (which it can't know for an arbitrary
> HostnameVerifier).
> * SunJSSE's HTTPS endpoint identification has special (less-restrictive)
> rules for wildcard characters when the trust anchor is a certificate from the
> 'cacerts' file (what it calls a "public root CA").
> There may be other implications that I am unaware of, but I think this
> establishes that some users may prefer (or even need) to delegate endpoint
> identification to JSSE in this way. They presumably will not then want a
> duplicate check in DefaultHostnameVerifier.
> I am not yet that familiar with HttpClient, but I assume a user could already
> provide a custom SSLSocketFactory which enables JSSE endpoint identification
> on sockets before returning them, and then separately configure a no-op
> HostnameVerifier. I consider that to be rather fragile and it's easy to see
> mistakes leading to no endpoint identification being performed.
> I am proposing that HttpClient support this via a simpler configuration
> mechanism. To loosely outline some basic options:
> IGNORE: don't even check whether JSSE endpoint identification was enabled
> (i.e. assume it wasn't).
> AWARE: check at runtime whether JSSE endpoint identification was "HTTPS" for
> a given socket connection.
> DISABLE: remove any existing setting for JSSE endpoint identification (set it
> to "").
> FORCE: overwrite any existing setting for JSSE endpoint identification (set
> it to "HTTPS").
> So we would consider some value that came to us via the SSLSocketFactory's
> default socket setup, and whether to ignore it, respect it, or force it
> on/off. DefaultHostnameVerifier can then be set to possibly skip its own
> endpoint checks when appropriate.
--
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
[jira] [Commented] (HTTPCLIENT-2151) Optionally use JSSE inbuilt endpoint identification
[
https://issues.apache.org/jira/browse/HTTPCLIENT-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17810436#comment-17810436
]
Oleg Kalnichevski commented on HTTPCLIENT-2151:
---
[~peter.dettman] I need to find (or put together) a reasonable test to proceed.
I had no luck with HTTPCLIENT-2134
Oleg
> Optionally use JSSE inbuilt endpoint identification
> ---
>
> Key: HTTPCLIENT-2151
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2151
> Project: HttpComponents HttpClient
> Issue Type: Wish
> Components: HttpClient (classic)
>Reporter: Peter Dettman
>Priority: Minor
> Fix For: 5.4-alpha2
>
>
> This issue brings to the fore that part of HTTPCLIENT-2134 which is actually
> within the scope of HttpClient: the possibility of using JSSE inbuilt
> endpoint identification ("HTTPS") instead of performing those checks
> externally (typically in
> _org.apache.hc.client5.http.ssl.DefaultHostnameVerifier_).
> Java 1.7 added the method
> SSLParameters.setEndpointIdentificationAlgorithm(String). Calling this method
> with the argument "HTTPS" (case-insensitive) will result in the endpoint
> identification checks from RFC 2818 being automatically done by JSSE during
> the handshake (specifically when the X509TrustManager validates the server
> certificate). Note that the setting can also be interrogated via
> SSLParameters.getEndpointIdentificationAlgorithm.
> This has some minor advantages relative to performing the checks externally:
> * The check is done earlier in the handshake, reducing the cost of failed
> connections. (Technically this might still be achieved anyway by wrapping the
> X509TrustManager and applying a HostnameVerifier at that stage).
> * Per my comments in HTTPCLIENT-2134, in some nuanced situations SunJSSE will
> be willing to resume a session only if it knows for sure that endpoint
> identification is being used (which it can't know for an arbitrary
> HostnameVerifier).
> * SunJSSE's HTTPS endpoint identification has special (less-restrictive)
> rules for wildcard characters when the trust anchor is a certificate from the
> 'cacerts' file (what it calls a "public root CA").
> There may be other implications that I am unaware of, but I think this
> establishes that some users may prefer (or even need) to delegate endpoint
> identification to JSSE in this way. They presumably will not then want a
> duplicate check in DefaultHostnameVerifier.
> I am not yet that familiar with HttpClient, but I assume a user could already
> provide a custom SSLSocketFactory which enables JSSE endpoint identification
> on sockets before returning them, and then separately configure a no-op
> HostnameVerifier. I consider that to be rather fragile and it's easy to see
> mistakes leading to no endpoint identification being performed.
> I am proposing that HttpClient support this via a simpler configuration
> mechanism. To loosely outline some basic options:
> IGNORE: don't even check whether JSSE endpoint identification was enabled
> (i.e. assume it wasn't).
> AWARE: check at runtime whether JSSE endpoint identification was "HTTPS" for
> a given socket connection.
> DISABLE: remove any existing setting for JSSE endpoint identification (set it
> to "").
> FORCE: overwrite any existing setting for JSSE endpoint identification (set
> it to "HTTPS").
> So we would consider some value that came to us via the SSLSocketFactory's
> default socket setup, and whether to ignore it, respect it, or force it
> on/off. DefaultHostnameVerifier can then be set to possibly skip its own
> endpoint checks when appropriate.
--
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
