Am 2021-11-27 um 19:55 schrieb larry mccay:
It is still unclear to me whether there is a security issue with using the
existing Kerberos/SPNEGO implementation.
Sorry if I am missing a clear message here.
If you plan to use GSS-API, you code must comply with RFC 7546 to
complete and trust the security context. If you don't I see a
trust/security issue here.
Same approach is for TLS, if you never verify the peer's cert against a
trusted CA how can you know whether this channel is authentic and secure?
On Sat, Nov 27, 2021 at 5:02 AM Oleg Kalnichevski <ol...@apache.org> wrote:
On Fri, 2021-11-26 at 18:39 +0100, Michael Osipov wrote:
Am 2021-11-23 um 20:14 schrieb Oleg Kalnichevski:
Folks
Here's my proposal
HttpClient 5.2:
* Announce the plan to deprecate and eventually remove NTLM support
and experimental SPNEGO / Kerberos support
* Ask downstream projects to get in touch with us. Invite
interested
parties to participate in Kerberos support improvements
OK for me.
HttpClient 5.3:
* Make NTLM / SPNEGO / Kerberos disabled by default requiring an
explicit opt-in from the user. Mark respective implementations
deprecated.
Also OK for me also. I have explicitly disabled SPNEGO for Wagon
some
time ago. It simply did not make any sense.
* Remove stateful connection support
^^^^^^^^^^^^^^^^^^^^^^
This contradicts the option still to explicitly enable to
providers.
Did you mistype?
Hi Michael
What I propose is that the support for connection state tracking be
removed in 5.3. It is an extra security mechanism presently used by
NTLM only. It adds a lot of otherwise unnecessary complexity to the
connection pooling logic and the APIs. I would like to get rid of it
sooner.
* Invite interested parties to participate in Kerberos support
improvements
HttpClient 6.0:
* Remove NTLM support
* Remove SPNEGO / Kerberos support if still broken
Can you answer my previous request?
What is important to know for you when you want to remove code: The
security context loop is always client initiated and required to be
completed by a token sent from the server with the response unless
it
is 401/407. So the HttpClient needs to store the context somewhere
until it receives the response, completes security context and
frees
the security context. This is on a per-request basis. If the
context
is not completed with the response then the authentication should
not
be trusted, either an exception should be through or a
warning/error
must be logged.
Will this still be possible for SPNEGO to be implemented properly
after
the remove of stateful connection support?
Of course. There will be no changes to the Auth APIs. It will always be
possible to add NTLM and Kerberos as extra authentication schemes if
desired.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
