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 <lmc...@apache.org> 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 <micha...@apache.org> > 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 > > > > >
