Am 2018-11-15 um 10:22 schrieb Oleg Kalnichevski:
On Wed, 2018-11-14 at 21:38 +0100, Michael Osipov wrote:
Am 2018-11-13 um 15:50 schrieb Oleg Kalnichevski:
On Mon, 2018-11-12 at 19:31 -0500, Karl Wright wrote:
Hi Michael,
I did not contribute this work; I merely obliquely helped
integrating
it.
If I recall correctly, there was a reasonable case made for it,
but I
don't
remember what it wasy.
Karl
Hi Michael
For full background:
https://github.com/apache/httpcomponents-client/pull/66
CredSSP is marked experimental. We can still remove it.
I just pinged the author on GitHub after reading the discussion. I
didn't not find any benefit mentioned in the discussion.
What bugs me is that people push two distinct changes (NTLM
improvement
and CredSSP) in one change making harder to review, rollback, track.
Proprietary stuff like this is hard to maintain because it is most a
one
time contribution. Microsoft has released new revisions of the spec.
Curl suffers from the same issue. A lot of people contribute one
time,
is mentioned in 'curl --version', but no one really knows whether
the
stuff works actually.
This is something we should avoid. If there is a feature none of the
committers can really test somehow, how are we supposed to support
that?
CredSSP is no different that many other contributions that people drop
on us, then lose interest and walk away.
I intend to remove OSGi stuff in the next 5.0 releases. I will not
hesitate to remove CredSSP as well.
I absolutely second that. Lets create a remove ticket in JIRA.
Michael
On Mon, Nov 12, 2018 at 5:50 PM Michael Osipov <
[email protected]>
wrote:
Guys,
I just have discovered that CredSSP has been added with (NTLM,
yuck)
some time ago. Can someone point me to a valid use case for
this
over
HTTP? Karl? As far as I understand CredSSP [1] it is simply not
compatible with/designed for HTTP and duplicates the transport
encryption. The main purpose is to securely transport the
Kerberos
UPN
and password of the user to the target server, e.g., for RDP to
obtain a
TGT on the remote machine as if someone is physically in front
of
the
remote machine.
This makes sense if you work on raw sockets, but on HTTP?
The CredSspScheme also says that it should work with GSS, but I
believe
that this is impossible because as soon as yo have the
GSSCredential,
you don't have access to the UPN and password, you have the TGT
only.
Neither with JGSS, Heimdal, nor MIT Kerberos unless you acquire
them
again, like the RDP login dialog does.
So again, what does it better than HTTPS + SPNEGO with
credential
delegation or contraint delegation also given that this works
on
the
Windows backend only?!
Michael
[1] https://msdn.microsoft.com/en-us/library/cc226794.aspx
-------------------------------------------------------------
----
----
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
-----------------------------------------------------------------
----
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
