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?


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]

Reply via email to