Re: Gradual deprecation and removal of NTLM and SPNEGO support
On Sun, 2021-11-28 at 16:46 +0100, Michael Osipov wrote: > Am 2021-11-27 um 11:01 schrieb Oleg Kalnichevski: > > 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. > > I see, I am completely unaware of this code, frankly. But when this > is > removed, how is the NTLM scheme going to work at all? This is about pooling of authenticated (stateful) connections, not about authentication. NTLM handshake will work as before but the connection manager will no longer take NTLM state into account. The users will have to decide whether or not they want different users to share the same pool of NTLM connections. HttpClient will no longer do that for them. > It requires > connection tracking for sure. Sorry for playing stupid, but you code > knodledge is magnitudes apart from me. > I hope that the curent NTLM module is explicitly excluded from > HTTP/2 > because it is not compatible with concurrent streams on one TCP > connection. See > https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10/http2-on-iis#when-is-http2-not-supported > Presently we do not. One more reason to disable NTLM by default. > Will you prepare a PR for this somehwere next year? > I surely will. Oleg - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Gradual deprecation and removal of NTLM and SPNEGO support
Am 2021-11-27 um 11:01 schrieb Oleg Kalnichevski: 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. I see, I am completely unaware of this code, frankly. But when this is removed, how is the NTLM scheme going to work at all? It requires connection tracking for sure. Sorry for playing stupid, but you code knodledge is magnitudes apart from me. I hope that the curent NTLM module is explicitly excluded from HTTP/2 because it is not compatible with concurrent streams on one TCP connection. See https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10/http2-on-iis#when-is-http2-not-supported Will you prepare a PR for this somehwere next year? * 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. Great, that is what I wanted to know whether we are still able to make things right in the future. Michael - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Gradual deprecation and removal of NTLM and SPNEGO support
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 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
Re: Gradual deprecation and removal of NTLM and SPNEGO support
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. On Sat, Nov 27, 2021 at 5:02 AM Oleg Kalnichevski 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 > >
Re: Gradual deprecation and removal of NTLM and SPNEGO support
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
Re: Gradual deprecation and removal of NTLM and SPNEGO support
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? * 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? HttpClient 6.0 is not going to happen sooner than 2025. There should plenty of time for downstream projects to re-act and adjust. - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Gradual deprecation and removal of NTLM and SPNEGO support
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 HttpClient 5.3: * Make NTLM / SPNEGO / Kerberos disabled by default requiring an explicit opt-in from the user. Mark respective implementations deprecated. * Remove stateful connection support * Invite interested parties to participate in Kerberos support improvements HttpClient 6.0: * Remove NTLM support * Remove SPNEGO / Kerberos support if still broken HttpClient 6.0 is not going to happen sooner than 2025. There should plenty of time for downstream projects to re-act and adjust. Oleg On Sat, 2021-11-20 at 19:52 +0100, Michael Osipov wrote: > Am 2021-11-20 um 17:41 schrieb Oleg Kalnichevski: > > Folks > > > > Presently NTLM & SPNEGO are stated as supported authentication > > schemes, > > by the project which is, quite frankly, not the case. There are > > partial > > implementations in various state of decay contributed some while > > ago by > > contributors long gone with no one on the project both capable and > > willing to maintain that code and deal with user reported issues. > > > > I think we should drop the pretense and start dealing with the > > problem. > > If we cannot adequately support those features we should consider > > deprecating and eventually removing them entirely. > > > > As the first step I would like to propose NTLM & SPNEGO be made an > > opt- > > in feature as of version 5.3. Users would have to explicitly enable > > NTLM & SPNEGO support to make HttpClient engage in an NTLM or > > SPNEGO > > handshake. > > > > This may encourage people vested in NTLM and SPNEGO come forth and > > help > > support those features. > > > > Also, the deprecation or removal of NTLM would unable us to drop > > connection state tracking support and greatly simplify the > > connection > > management APIs. > > Let me both comment since I have experience with them and on > contributions in general. > Contributions: I generally, for all ASF projects I maintain, reject > contributions I cannot test or do not have access to the technology > to > do so (it must be freely, namely OSS). I have recently deleted 130 > 000 > LoC in Maven SCM for commercial SCMs because none of us is able to > test > them. > > Now let's get into those two: > NTLM: Although the client part is fully documented these days, this > mechanism is very problematic in many ways. It is connection-bound > and > generally not suited for HTTP which is stateless, in fact IIS > disabled > it on HTTP/2 for obvious reasons. There is no OSS implementation (at > least I am not aware of) on the server-side (if you put apart innards > of > Samba) which gives me the ability to hook into Apache HTTPd or > Tomcat, > ideally as an opaque GSS-API or jGSS mechanism and test properly. > You > always need a domain controller, ideally Active Directory and a > Windows > server with IIS to test this. The server needs to talk to the DC > likely > through MS-RPC (DCE-RPC) (part of the protocol). There is no way I > am > going to do this. Only SSPI supports this out of the box. Moreover, > the > mechanism is deprecated for many years by Microsoft and replaced > with > standard Kerberos. > If your company hasn't moved to Kerberos or client certs then > something > is seriously wrong with your company. > My verdict: There is no way we can make this right/reliable/correct. > If > you check MS-NLMP [1] there are constant updates putting a burden on > us. > I support its removal in 6.0. > > SPNEGO: This is a pseudo-mechanism negotiating sub-mechanisms (NTLM > or > Kerberos). Although a Microsoft invention also, this has an RFC and > is > completely open. When I talk about SPNEGO I always mean Kerberos > negotiated, nothing else. Pure Kerberos does *not* exist over HTTP, > thus > no need to support it. Kerberos is freely available (for all OSes) > and a > KDC can be set up with MIT Kerberos, Heimdal or Samba or GNU/Linux > or > FreeBSD to test. I have a test network in VirtualBox which just > works. > It is just effort for the implementor to do so, but easier than > brain > surgery. > SPNEGO/Kerberos does *not* require any connection binding, I have > been > using it for more than 10 years and I have *never* seen more than > one > roundtrip, see also [2]. Neither with MIT Kerberos, Microsoft > Kerberos > or Java Kerberos. > One of the biggest problems with many OSS approaches I have seen on > the > client side: they are crap and logically broken. Namely, they > violate > RFC 7546 [3] and don't make things right. Even curl is broken [3]. > The > only OSS library I know to be correct is libserf. Many just don't > read > the RFCs to make things right, compared to you! Ping Identity is > also > broken. I told this to our service support at
Re: Gradual deprecation and removal of NTLM and SPNEGO support
Karl, the dicsussion isn't about NTLM, but SPNEGO/Kerberos only. Am 2021-11-21 um 01:22 schrieb Karl Wright: This is not a security issue. The implementation of NTLM is just as secure as the Microsoft implementation. That's not terribly secure but that's inherent in their design. Karl On Sat, Nov 20, 2021 at 7:02 PM larry mccay wrote: This is a concerning statement and I need some additional information to determine what sort of risk is inherent in the current implementation. Perhaps we should take those details off list if this is a security issue. I'll need to determine whether there are any workarounds or usage patterns that we can use to ensure that we are safe. Currently we do not preemptively send tokens and we use our own delegation tokens after the first authentication. On Sat, Nov 20, 2021 at 2:58 PM Michael Osipov wrote: Am 2021-11-20 um 20:46 schrieb larry mccay: Hi - I am the Apache Knox PMC chair and a committer on Hadoop and other ecosystem projects. FYI, Apache Knox is indeed dependent on SPNEGO in httpclient. Knox is a Hadoop ecosystem gateway and as part of the trusted proxy or proxyuser pattern within Hadoop it requires all proxies that dispatch requests on behalf of other users to authenticate via Kerberos/SPNEGO. Knox is not the only proxyuser in the ecosystem and likely not the only one that is leveraging HttpClient this way. It is used within a huge number of Hadoop deployments both on-prem and in the cloud and SPNEGO is critical to the security of these deployments. If this would be critical for security then you would not rely on it. It does not complete the security context for you. As sad as it sounds. I am currently in a project at work where I try to get rid of the Ping Identity/OAuth/OIDC hype and move to to SPNEGO/Kerberos and HttpClient is used, in Spring and JMeter. Maybe this well an opportunity to make it right, but this will only land in 5.2.x, maybe 5.1.x if the API allows it. M - 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
Re: Gradual deprecation and removal of NTLM and SPNEGO support
This is not a security issue. The implementation of NTLM is just as secure as the Microsoft implementation. That's not terribly secure but that's inherent in their design. Karl On Sat, Nov 20, 2021 at 7:02 PM larry mccay wrote: > This is a concerning statement and I need some additional information to > determine what sort of risk is inherent in the current implementation. > Perhaps we should take those details off list if this is a security issue. > > I'll need to determine whether there are any workarounds or usage patterns > that we can use to ensure that we are safe. > Currently we do not preemptively send tokens and we use our own delegation > tokens after the first authentication. > > > On Sat, Nov 20, 2021 at 2:58 PM Michael Osipov > wrote: > > > Am 2021-11-20 um 20:46 schrieb larry mccay: > > > Hi - > > > > > > I am the Apache Knox PMC chair and a committer on Hadoop and other > > > ecosystem projects. > > > > > > FYI, Apache Knox is indeed dependent on SPNEGO in httpclient. > > > Knox is a Hadoop ecosystem gateway and as part of the trusted proxy or > > > proxyuser pattern within Hadoop it requires all proxies that dispatch > > > requests on behalf of other users to authenticate via Kerberos/SPNEGO. > > > Knox is not the only proxyuser in the ecosystem and likely not the only > > one > > > that is leveraging HttpClient this way. > > > It is used within a huge number of Hadoop deployments both on-prem and > in > > > the cloud and SPNEGO is critical to the security of these deployments. > > > > If this would be critical for security then you would not rely on it. It > > does not complete the security context for you. As sad as it sounds. > > > > I am currently in a project at work where I try to get rid of the Ping > > Identity/OAuth/OIDC hype and move to to SPNEGO/Kerberos and HttpClient > > is used, in Spring and JMeter. Maybe this well an opportunity to make it > > right, but this will only land in 5.2.x, maybe 5.1.x if the API allows > it. > > > > M > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > > For additional commands, e-mail: dev-h...@hc.apache.org > > > > >
Re: Gradual deprecation and removal of NTLM and SPNEGO support
This is a concerning statement and I need some additional information to determine what sort of risk is inherent in the current implementation. Perhaps we should take those details off list if this is a security issue. I'll need to determine whether there are any workarounds or usage patterns that we can use to ensure that we are safe. Currently we do not preemptively send tokens and we use our own delegation tokens after the first authentication. On Sat, Nov 20, 2021 at 2:58 PM Michael Osipov wrote: > Am 2021-11-20 um 20:46 schrieb larry mccay: > > Hi - > > > > I am the Apache Knox PMC chair and a committer on Hadoop and other > > ecosystem projects. > > > > FYI, Apache Knox is indeed dependent on SPNEGO in httpclient. > > Knox is a Hadoop ecosystem gateway and as part of the trusted proxy or > > proxyuser pattern within Hadoop it requires all proxies that dispatch > > requests on behalf of other users to authenticate via Kerberos/SPNEGO. > > Knox is not the only proxyuser in the ecosystem and likely not the only > one > > that is leveraging HttpClient this way. > > It is used within a huge number of Hadoop deployments both on-prem and in > > the cloud and SPNEGO is critical to the security of these deployments. > > If this would be critical for security then you would not rely on it. It > does not complete the security context for you. As sad as it sounds. > > I am currently in a project at work where I try to get rid of the Ping > Identity/OAuth/OIDC hype and move to to SPNEGO/Kerberos and HttpClient > is used, in Spring and JMeter. Maybe this well an opportunity to make it > right, but this will only land in 5.2.x, maybe 5.1.x if the API allows it. > > M > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
Re: Gradual deprecation and removal of NTLM and SPNEGO support
Am 2021-11-20 um 20:46 schrieb larry mccay: Hi - I am the Apache Knox PMC chair and a committer on Hadoop and other ecosystem projects. FYI, Apache Knox is indeed dependent on SPNEGO in httpclient. Knox is a Hadoop ecosystem gateway and as part of the trusted proxy or proxyuser pattern within Hadoop it requires all proxies that dispatch requests on behalf of other users to authenticate via Kerberos/SPNEGO. Knox is not the only proxyuser in the ecosystem and likely not the only one that is leveraging HttpClient this way. It is used within a huge number of Hadoop deployments both on-prem and in the cloud and SPNEGO is critical to the security of these deployments. If this would be critical for security then you would not rely on it. It does not complete the security context for you. As sad as it sounds. I am currently in a project at work where I try to get rid of the Ping Identity/OAuth/OIDC hype and move to to SPNEGO/Kerberos and HttpClient is used, in Spring and JMeter. Maybe this well an opportunity to make it right, but this will only land in 5.2.x, maybe 5.1.x if the API allows it. M - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Gradual deprecation and removal of NTLM and SPNEGO support
Hi - I am the Apache Knox PMC chair and a committer on Hadoop and other ecosystem projects. FYI, Apache Knox is indeed dependent on SPNEGO in httpclient. Knox is a Hadoop ecosystem gateway and as part of the trusted proxy or proxyuser pattern within Hadoop it requires all proxies that dispatch requests on behalf of other users to authenticate via Kerberos/SPNEGO. Knox is not the only proxyuser in the ecosystem and likely not the only one that is leveraging HttpClient this way. It is used within a huge number of Hadoop deployments both on-prem and in the cloud and SPNEGO is critical to the security of these deployments. We are currently on 4.5.13 for HttpClient. A backward compatible path forward here is going to be needed and I'd be happy to help out however I can. thanks, --larry On Sat, Nov 20, 2021 at 2:08 PM Michael Osipov wrote: > Am 2021-11-20 um 19:35 schrieb Oleg Kalnichevski: > > On Sat, 2021-11-20 at 12:25 -0500, Karl Wright wrote: > >> These protocols are, unfortunately, still used. > >> > >> However, the projects I know that use them have not yet moved to 5.x > >> of > >> httpcomponents. Other projects I know of that used to use > >> httpcomponents > >> have since upgraded to different http libraries that supported http > >> 2.0 > >> early on. > >> > >> The hint that all it takes is a shove from below to convince other > >> projects > >> to drop NTLM support is, perhaps, not accurate. Projects that > >> maintain > >> NTLM support do so because they are tied to legacy systems that use > >> it. > >> Later improvements, e.g. Kerberos, have also only lightly been > >> supported by > >> HttpComponents, and only with external configuration, which really > >> limits > >> its utility. ManifoldCF, which does much integration with windows > >> systems, supports Kerberos but only in the most hacky way, because > >> there > >> wasn't anything more seamless available. > >> > >> I would therefore counter-propose that Kerberos become a first-class > >> replacement to NTLM before NTLM is discontinued. By first-class, I > >> mean > >> that it is possible to programmatically set up a kerberos connection > >> without an external config file. Maybe this is now possible; if so > >> please > >> correct me. > >> > >> I would love to be able to contribute to this effort, but I fear my > >> day > >> job's responsibilities are so vast and growing that this will be > >> impossible. At best I can maintain the projects I have; new > >> development is > >> out of the question at the moment. > >> > >> Karl > >> > > > > Hi Karl > > > > I am so happy that you are still keeping an eye on the mailing list and > > reacting on NTLM related matters. > > > > I do understand your position. The problem is there are no volunteers > > eager to do work on Kerberos support either. We cannot keep on > > pretending everything is all right. We need to make downstream projects > > aware of the situation and making NTLM, SPNEGO and Kerberos an opt-in > > features by default would be the right thing to do in my opinion. > > FWIW, I have explicitly configured auth schemes in Wagon to those known > to work (except NTLM): https://issues.apache.org/jira/browse/WAGON-539 > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
Re: Gradual deprecation and removal of NTLM and SPNEGO support
Am 2021-11-20 um 19:35 schrieb Oleg Kalnichevski: On Sat, 2021-11-20 at 12:25 -0500, Karl Wright wrote: These protocols are, unfortunately, still used. However, the projects I know that use them have not yet moved to 5.x of httpcomponents. Other projects I know of that used to use httpcomponents have since upgraded to different http libraries that supported http 2.0 early on. The hint that all it takes is a shove from below to convince other projects to drop NTLM support is, perhaps, not accurate. Projects that maintain NTLM support do so because they are tied to legacy systems that use it. Later improvements, e.g. Kerberos, have also only lightly been supported by HttpComponents, and only with external configuration, which really limits its utility. ManifoldCF, which does much integration with windows systems, supports Kerberos but only in the most hacky way, because there wasn't anything more seamless available. I would therefore counter-propose that Kerberos become a first-class replacement to NTLM before NTLM is discontinued. By first-class, I mean that it is possible to programmatically set up a kerberos connection without an external config file. Maybe this is now possible; if so please correct me. I would love to be able to contribute to this effort, but I fear my day job's responsibilities are so vast and growing that this will be impossible. At best I can maintain the projects I have; new development is out of the question at the moment. Karl Hi Karl I am so happy that you are still keeping an eye on the mailing list and reacting on NTLM related matters. I do understand your position. The problem is there are no volunteers eager to do work on Kerberos support either. We cannot keep on pretending everything is all right. We need to make downstream projects aware of the situation and making NTLM, SPNEGO and Kerberos an opt-in features by default would be the right thing to do in my opinion. FWIW, I have explicitly configured auth schemes in Wagon to those known to work (except NTLM): https://issues.apache.org/jira/browse/WAGON-539 - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Gradual deprecation and removal of NTLM and SPNEGO support
Am 2021-11-20 um 18:25 schrieb Karl Wright: These protocols are, unfortunately, still used. ManifoldCF, which does much integration with windows systems, supports Kerberos but only in the most hacky way, because there wasn't anything more seamless available. I would therefore counter-propose that Kerberos become a first-class replacement to NTLM before NTLM is discontinued. By first-class, I mean that it is possible to programmatically set up a kerberos connection without an external config file. Maybe this is now possible; if so please correct me. Yes, this is impossible. Even impossible with MIT Kerberos. You must have at least a krb5.conf and a JAAS login file. Read further. I would love to be able to contribute to this effort, but I fear my day job's responsibilities are so vast and growing that this will be impossible. At best I can maintain the projects I have; new development is out of the question at the moment. This is purely a Java problem, not a Kerberos problem. The configuration is inevitable because Java is portable otherwise you need to resort to native APIs, e.g., JNA/JNA to SSPI or MIT Kerberos, but that would require custom authenticators. There is now a SSPI binding/implementation for JGSS, but it is not good. I told this Weijun Wang already, but he's the only one at Oracle who is working on this, read busy (read my mails on security-dev). Another huge issue is that stupid JAAS/LoginModule/Subjec thing in Java. It does not have the credential acquision API [1], [2] which MIT Kerberos introduced many years ago, plus in does not even interact to store tickets on the local FILE cache. I'd love to solve all of these issues, but it cannot just be me in the Java world to solve a problem for miliions of devs. Nico Williams of Six Sigma had bright ideas, but very little time. Michael [1] https://pythongssapi.github.io/python-gssapi/stable/gssapi.raw.html#module-gssapi.raw.ext_cred_store [2] https://pythongssapi.github.io/python-gssapi/stable/gssapi.raw.html#module-gssapi.raw.ext_password - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Gradual deprecation and removal of NTLM and SPNEGO support
Am 2021-11-20 um 17:41 schrieb Oleg Kalnichevski: Folks Presently NTLM & SPNEGO are stated as supported authentication schemes, by the project which is, quite frankly, not the case. There are partial implementations in various state of decay contributed some while ago by contributors long gone with no one on the project both capable and willing to maintain that code and deal with user reported issues. I think we should drop the pretense and start dealing with the problem. If we cannot adequately support those features we should consider deprecating and eventually removing them entirely. As the first step I would like to propose NTLM & SPNEGO be made an opt- in feature as of version 5.3. Users would have to explicitly enable NTLM & SPNEGO support to make HttpClient engage in an NTLM or SPNEGO handshake. This may encourage people vested in NTLM and SPNEGO come forth and help support those features. Also, the deprecation or removal of NTLM would unable us to drop connection state tracking support and greatly simplify the connection management APIs. Let me both comment since I have experience with them and on contributions in general. Contributions: I generally, for all ASF projects I maintain, reject contributions I cannot test or do not have access to the technology to do so (it must be freely, namely OSS). I have recently deleted 130 000 LoC in Maven SCM for commercial SCMs because none of us is able to test them. Now let's get into those two: NTLM: Although the client part is fully documented these days, this mechanism is very problematic in many ways. It is connection-bound and generally not suited for HTTP which is stateless, in fact IIS disabled it on HTTP/2 for obvious reasons. There is no OSS implementation (at least I am not aware of) on the server-side (if you put apart innards of Samba) which gives me the ability to hook into Apache HTTPd or Tomcat, ideally as an opaque GSS-API or jGSS mechanism and test properly. You always need a domain controller, ideally Active Directory and a Windows server with IIS to test this. The server needs to talk to the DC likely through MS-RPC (DCE-RPC) (part of the protocol). There is no way I am going to do this. Only SSPI supports this out of the box. Moreover, the mechanism is deprecated for many years by Microsoft and replaced with standard Kerberos. If your company hasn't moved to Kerberos or client certs then something is seriously wrong with your company. My verdict: There is no way we can make this right/reliable/correct. If you check MS-NLMP [1] there are constant updates putting a burden on us. I support its removal in 6.0. SPNEGO: This is a pseudo-mechanism negotiating sub-mechanisms (NTLM or Kerberos). Although a Microsoft invention also, this has an RFC and is completely open. When I talk about SPNEGO I always mean Kerberos negotiated, nothing else. Pure Kerberos does *not* exist over HTTP, thus no need to support it. Kerberos is freely available (for all OSes) and a KDC can be set up with MIT Kerberos, Heimdal or Samba or GNU/Linux or FreeBSD to test. I have a test network in VirtualBox which just works. It is just effort for the implementor to do so, but easier than brain surgery. SPNEGO/Kerberos does *not* require any connection binding, I have been using it for more than 10 years and I have *never* seen more than one roundtrip, see also [2]. Neither with MIT Kerberos, Microsoft Kerberos or Java Kerberos. One of the biggest problems with many OSS approaches I have seen on the client side: they are crap and logically broken. Namely, they violate RFC 7546 [3] and don't make things right. Even curl is broken [3]. The only OSS library I know to be correct is libserf. Many just don't read the RFCs to make things right, compared to you! Ping Identity is also broken. I told this to our service support at work, he was pissed off. 6,5 years I ago I have created HTTPCLIENT-1625 to make things right, 4.x flow was not suitable, in 5.x this was reworked and I believe it will work, but don't know for sure. Shamely, I haven't had enough free time to tackle this issue, I am requirements-driven from work after all and didn't have this one for Java in all those years, clients were in C or C#. Both the JGSS code and the JNA-based code for SSPI aren't really good. As soon as a business need arises here at work, I will start working on it. 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. My verdict:
Re: Gradual deprecation and removal of NTLM and SPNEGO support
On Sat, 2021-11-20 at 12:25 -0500, Karl Wright wrote: > These protocols are, unfortunately, still used. > > However, the projects I know that use them have not yet moved to 5.x > of > httpcomponents. Other projects I know of that used to use > httpcomponents > have since upgraded to different http libraries that supported http > 2.0 > early on. > > The hint that all it takes is a shove from below to convince other > projects > to drop NTLM support is, perhaps, not accurate. Projects that > maintain > NTLM support do so because they are tied to legacy systems that use > it. > Later improvements, e.g. Kerberos, have also only lightly been > supported by > HttpComponents, and only with external configuration, which really > limits > its utility. ManifoldCF, which does much integration with windows > systems, supports Kerberos but only in the most hacky way, because > there > wasn't anything more seamless available. > > I would therefore counter-propose that Kerberos become a first-class > replacement to NTLM before NTLM is discontinued. By first-class, I > mean > that it is possible to programmatically set up a kerberos connection > without an external config file. Maybe this is now possible; if so > please > correct me. > > I would love to be able to contribute to this effort, but I fear my > day > job's responsibilities are so vast and growing that this will be > impossible. At best I can maintain the projects I have; new > development is > out of the question at the moment. > > Karl > Hi Karl I am so happy that you are still keeping an eye on the mailing list and reacting on NTLM related matters. I do understand your position. The problem is there are no volunteers eager to do work on Kerberos support either. We cannot keep on pretending everything is all right. We need to make downstream projects aware of the situation and making NTLM, SPNEGO and Kerberos an opt-in features by default would be the right thing to do in my opinion. Oleg - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Gradual deprecation and removal of NTLM and SPNEGO support
These protocols are, unfortunately, still used. However, the projects I know that use them have not yet moved to 5.x of httpcomponents. Other projects I know of that used to use httpcomponents have since upgraded to different http libraries that supported http 2.0 early on. The hint that all it takes is a shove from below to convince other projects to drop NTLM support is, perhaps, not accurate. Projects that maintain NTLM support do so because they are tied to legacy systems that use it. Later improvements, e.g. Kerberos, have also only lightly been supported by HttpComponents, and only with external configuration, which really limits its utility. ManifoldCF, which does much integration with windows systems, supports Kerberos but only in the most hacky way, because there wasn't anything more seamless available. I would therefore counter-propose that Kerberos become a first-class replacement to NTLM before NTLM is discontinued. By first-class, I mean that it is possible to programmatically set up a kerberos connection without an external config file. Maybe this is now possible; if so please correct me. I would love to be able to contribute to this effort, but I fear my day job's responsibilities are so vast and growing that this will be impossible. At best I can maintain the projects I have; new development is out of the question at the moment. Karl On Sat, Nov 20, 2021 at 11:42 AM Oleg Kalnichevski wrote: > Folks > > Presently NTLM & SPNEGO are stated as supported authentication schemes, > by the project which is, quite frankly, not the case. There are partial > implementations in various state of decay contributed some while ago by > contributors long gone with no one on the project both capable and > willing to maintain that code and deal with user reported issues. > > I think we should drop the pretense and start dealing with the problem. > If we cannot adequately support those features we should consider > deprecating and eventually removing them entirely. > > As the first step I would like to propose NTLM & SPNEGO be made an opt- > in feature as of version 5.3. Users would have to explicitly enable > NTLM & SPNEGO support to make HttpClient engage in an NTLM or SPNEGO > handshake. > > This may encourage people vested in NTLM and SPNEGO come forth and help > support those features. > > Also, the deprecation or removal of NTLM would unable us to drop > connection state tracking support and greatly simplify the connection > management APIs. > > Oleg > > > - > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
