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 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: What we have now for SPNEGO/Kerberos should be removed > in > 6.0, *but not* the technical support to integrate it properly into > HttpClient. > > I used it daily on four OSes on client-side and server-side, it just > works with zero headache for the user. In modern C# applications > interactively, or headless in ancient Fortran apps via C. Even fully > automated in GitLab runners for access APIs on Tomcat. > > Michael > > [1] > https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/b38c36ed-2804-4868-a9ff-8dd3182128e4 > [2] https://github.com/gssapi/mod_auth_gssapi/issues/204 > [3] https://datatracker.ietf.org/doc/html/rfc7546 > [4] > https://curl.se/docs/knownbugs.html#curl_never_completes_Negotiate_o > > --------------------------------------------------------------------- > 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
