Re: Valid usecase of CredSSP auth scheme
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 < micha...@apache.org> 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: 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 - 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 - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Valid usecase of CredSSP auth scheme
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. Oleg > > Michael > > > > On Mon, Nov 12, 2018 at 5:50 PM Michael Osipov < > > > micha...@apache.org> > > > 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: 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 > > > > > > > - > 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: Valid usecase of CredSSP auth scheme
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 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: 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 - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Valid usecase of CredSSP auth scheme
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. Oleg > On Mon, Nov 12, 2018 at 5:50 PM Michael Osipov > 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: 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: Valid usecase of CredSSP auth scheme
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 On Mon, Nov 12, 2018 at 5:50 PM Michael Osipov 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: dev-unsubscr...@hc.apache.org > For additional commands, e-mail: dev-h...@hc.apache.org > >
Valid usecase of CredSSP auth scheme
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: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
