You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Bert Huijben <be...@qqmail.nl> on 2011/08/24 11:52:45 UTC
RE: Proxy authentication with Negotiate uses wrong host
> -----Original Message-----
> From: 1983-01-06@gmx.net [mailto:1983-01-06@gmx.net]
> Sent: woensdag 24 augustus 2011 10:47
> To: users@subversion.apache.org
> Subject: Re: Proxy authentication with Negotiate uses wrong host
>
> > On Wed, Aug 24, 2011 at 09:25:49AM +0200, 1983-01-06@gmx.net wrote:
> > > I'll do but why is Negotiate auth activated in session.c if the target
> > host is ssy only? This should be on the user to decide not subversion.
> >
> > I don't know who made this decision and why.
> > Maybe svn blame on that file leads to more info?
>
> I checked blame already. There was a rather long explanation but still no
> argument to me.
The Subversion parts of this code were written when neon only supported NTLM via Negotiate. NTLM is known to be insecure when not used over https.
Then somebody added Kerberos support to neon, but the api wasn't updated to allow different behavior for the specific implementations.
As Stefan already noted: this discussion belongs on the neon mailinglist. Once neon supports the necessary hooks/apis to enable Negotiate for the secure protocols we can enable them in Subversion.
(Or maybe neon can just enable the safe protocols all the time?)
@serf developers: This should probably be handled in serf too.
Bert
Re: RE: Proxy authentication with Negotiate uses wrong host
Posted by 19...@gmx.net.
> On Wed, 2011-08-24 at 07:42 -0400, 1983-01-06@gmx.net wrote:
> > Are you refering to sole Kerberos or are you just concerned about
> > transport encryption? Your statement somewhat irritates me.
> > Given that the HTTP traffic cannot be securely wrapped into the GSS
> > content and nor the SASL QOP can be set (like for LDAP), I would
> > neglect that and still say TLS is not of your concern but of mine or
> > the users in general.
>
> Any authentication-only mechanism used over an insecure channel is
> vulnerable to MITM attacks which preserve the authentication and change
> the data. Of course, this applies to HTTP basic and digest over raw
> HTTP just as much as it does to negotiate, so perhaps it doesn't make
> sense to restrict negotiate auth to HTTPS only on this basis alone.
>
> A further concern with HTTP negotiate is that it is scoped to the TCP
> connection and not to a single HTTP request. Ignorant proxies may
> combine TCP connections for multiple users' requests and inadvertently
> authenticate one users' requests with anothers' credentials. I may be
> wrong, but I believe this is the concern which leads implementations to
> restrict NTLM to HTTPS. Switching from NTLM to Kerberos does not
> mitigate this concern at all. If there are other vulnerabilities in
> NTLM which don't presuppose an MITM attack, perhaps I'm wrong.
Greg,
thanks for the insight. I will file a bug that the sole negotiate/kerberos and SSL restriction should be removed because it is not enforced on basic and digest either.
Mike
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
Re: RE: Proxy authentication with Negotiate uses wrong host
Posted by 19...@gmx.net.
> On Wed, 2011-08-24 at 07:42 -0400, 1983-01-06@gmx.net wrote:
> > Are you refering to sole Kerberos or are you just concerned about
> > transport encryption? Your statement somewhat irritates me.
> > Given that the HTTP traffic cannot be securely wrapped into the GSS
> > content and nor the SASL QOP can be set (like for LDAP), I would
> > neglect that and still say TLS is not of your concern but of mine or
> > the users in general.
>
> Any authentication-only mechanism used over an insecure channel is
> vulnerable to MITM attacks which preserve the authentication and change
> the data. Of course, this applies to HTTP basic and digest over raw
> HTTP just as much as it does to negotiate, so perhaps it doesn't make
> sense to restrict negotiate auth to HTTPS only on this basis alone.
>
> A further concern with HTTP negotiate is that it is scoped to the TCP
> connection and not to a single HTTP request. Ignorant proxies may
> combine TCP connections for multiple users' requests and inadvertently
> authenticate one users' requests with anothers' credentials. I may be
> wrong, but I believe this is the concern which leads implementations to
> restrict NTLM to HTTPS. Switching from NTLM to Kerberos does not
> mitigate this concern at all. If there are other vulnerabilities in
> NTLM which don't presuppose an MITM attack, perhaps I'm wrong.
Greg,
thanks for the insight. I will file a bug that the sole negotiate/kerberos and SSL restriction should be removed because it is not enforced on basic and digest either.
Mike
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
Re: RE: Proxy authentication with Negotiate uses wrong host
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2011-08-24 at 07:42 -0400, 1983-01-06@gmx.net wrote:
> Are you refering to sole Kerberos or are you just concerned about
> transport encryption? Your statement somewhat irritates me.
> Given that the HTTP traffic cannot be securely wrapped into the GSS
> content and nor the SASL QOP can be set (like for LDAP), I would
> neglect that and still say TLS is not of your concern but of mine or
> the users in general.
Any authentication-only mechanism used over an insecure channel is
vulnerable to MITM attacks which preserve the authentication and change
the data. Of course, this applies to HTTP basic and digest over raw
HTTP just as much as it does to negotiate, so perhaps it doesn't make
sense to restrict negotiate auth to HTTPS only on this basis alone.
A further concern with HTTP negotiate is that it is scoped to the TCP
connection and not to a single HTTP request. Ignorant proxies may
combine TCP connections for multiple users' requests and inadvertently
authenticate one users' requests with anothers' credentials. I may be
wrong, but I believe this is the concern which leads implementations to
restrict NTLM to HTTPS. Switching from NTLM to Kerberos does not
mitigate this concern at all. If there are other vulnerabilities in
NTLM which don't presuppose an MITM attack, perhaps I'm wrong.
Re: RE: Proxy authentication with Negotiate uses wrong host
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2011-08-24 at 07:42 -0400, 1983-01-06@gmx.net wrote:
> Are you refering to sole Kerberos or are you just concerned about
> transport encryption? Your statement somewhat irritates me.
> Given that the HTTP traffic cannot be securely wrapped into the GSS
> content and nor the SASL QOP can be set (like for LDAP), I would
> neglect that and still say TLS is not of your concern but of mine or
> the users in general.
Any authentication-only mechanism used over an insecure channel is
vulnerable to MITM attacks which preserve the authentication and change
the data. Of course, this applies to HTTP basic and digest over raw
HTTP just as much as it does to negotiate, so perhaps it doesn't make
sense to restrict negotiate auth to HTTPS only on this basis alone.
A further concern with HTTP negotiate is that it is scoped to the TCP
connection and not to a single HTTP request. Ignorant proxies may
combine TCP connections for multiple users' requests and inadvertently
authenticate one users' requests with anothers' credentials. I may be
wrong, but I believe this is the concern which leads implementations to
restrict NTLM to HTTPS. Switching from NTLM to Kerberos does not
mitigate this concern at all. If there are other vulnerabilities in
NTLM which don't presuppose an MITM attack, perhaps I'm wrong.
Re: RE: Proxy authentication with Negotiate uses wrong host
Posted by 19...@gmx.net.
> Betreff: RE: Proxy authentication with Negotiate uses wrong host
> On Wed, 2011-08-24 at 05:52 -0400, Bert Huijben wrote:
> > Then somebody added Kerberos support to neon, but the api wasn't
> > updated to allow different behavior for the specific implementations.
>
> Kerberos via HTTP negotiate is also insecure when not used over HTTPS.
> In HTTP negotiate, the GSSAPI mechanism (Kerberos) isn't used to protect
> the data stream, only to authenticate. So you still need a secure
> channel.
>
> (Also, negotiate auth does no channel binding, which means Kerberos
> provides no additional protection against MITM attacks on the TLS
> channel. That just means it's still important for the client to verify
> the server cert. I've heard that Microsoft has some extensions to RFC
> 4559 to do channel binding, but I don't know any details and Neon almost
> certainly doesn't have any support for it.)
Greg,
Are you refering to sole Kerberos or are you just concerned about transport encryption? Your statement somewhat irritates me.
Given that the HTTP traffic cannot be securely wrapped into the GSS content and nor the SASL QOP can be set (like for LDAP), I would neglect that and still say TLS is not of your concern but of mine or the users in general.
Correct me if I am wrong.
Mike
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
Re: RE: Proxy authentication with Negotiate uses wrong host
Posted by 19...@gmx.net.
> Betreff: RE: Proxy authentication with Negotiate uses wrong host
> On Wed, 2011-08-24 at 05:52 -0400, Bert Huijben wrote:
> > Then somebody added Kerberos support to neon, but the api wasn't
> > updated to allow different behavior for the specific implementations.
>
> Kerberos via HTTP negotiate is also insecure when not used over HTTPS.
> In HTTP negotiate, the GSSAPI mechanism (Kerberos) isn't used to protect
> the data stream, only to authenticate. So you still need a secure
> channel.
>
> (Also, negotiate auth does no channel binding, which means Kerberos
> provides no additional protection against MITM attacks on the TLS
> channel. That just means it's still important for the client to verify
> the server cert. I've heard that Microsoft has some extensions to RFC
> 4559 to do channel binding, but I don't know any details and Neon almost
> certainly doesn't have any support for it.)
Greg,
Are you refering to sole Kerberos or are you just concerned about transport encryption? Your statement somewhat irritates me.
Given that the HTTP traffic cannot be securely wrapped into the GSS content and nor the SASL QOP can be set (like for LDAP), I would neglect that and still say TLS is not of your concern but of mine or the users in general.
Correct me if I am wrong.
Mike
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
RE: Proxy authentication with Negotiate uses wrong host
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2011-08-24 at 05:52 -0400, Bert Huijben wrote:
> Then somebody added Kerberos support to neon, but the api wasn't
> updated to allow different behavior for the specific implementations.
Kerberos via HTTP negotiate is also insecure when not used over HTTPS.
In HTTP negotiate, the GSSAPI mechanism (Kerberos) isn't used to protect
the data stream, only to authenticate. So you still need a secure
channel.
(Also, negotiate auth does no channel binding, which means Kerberos
provides no additional protection against MITM attacks on the TLS
channel. That just means it's still important for the client to verify
the server cert. I've heard that Microsoft has some extensions to RFC
4559 to do channel binding, but I don't know any details and Neon almost
certainly doesn't have any support for it.)
RE: Proxy authentication with Negotiate uses wrong host
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2011-08-24 at 05:52 -0400, Bert Huijben wrote:
> Then somebody added Kerberos support to neon, but the api wasn't
> updated to allow different behavior for the specific implementations.
Kerberos via HTTP negotiate is also insecure when not used over HTTPS.
In HTTP negotiate, the GSSAPI mechanism (Kerberos) isn't used to protect
the data stream, only to authenticate. So you still need a secure
channel.
(Also, negotiate auth does no channel binding, which means Kerberos
provides no additional protection against MITM attacks on the TLS
channel. That just means it's still important for the client to verify
the server cert. I've heard that Microsoft has some extensions to RFC
4559 to do channel binding, but I don't know any details and Neon almost
certainly doesn't have any support for it.)
Re: RE: Proxy authentication with Negotiate uses wrong host
Posted by 19...@gmx.net.
Bert,
> > -----Original Message-----
> > From: 1983-01-06@gmx.net [mailto:1983-01-06@gmx.net]
> > Sent: woensdag 24 augustus 2011 10:47
> > To: users@subversion.apache.org
> > Subject: Re: Proxy authentication with Negotiate uses wrong host
> >
> > > On Wed, Aug 24, 2011 at 09:25:49AM +0200, 1983-01-06@gmx.net wrote:
> > > > I'll do but why is Negotiate auth activated in session.c if the
> target
> > > host is ssy only? This should be on the user to decide not subversion.
> > >
> > > I don't know who made this decision and why.
> > > Maybe svn blame on that file leads to more info?
> >
> > I checked blame already. There was a rather long explanation but still
> no
> > argument to me.
>
> The Subversion parts of this code were written when neon only supported
> NTLM via Negotiate. NTLM is known to be insecure when not used over https.
I am aware of that. That's why I want to use Kerberos in the first place.
> Then somebody added Kerberos support to neon, but the api wasn't updated
> to allow different behavior for the specific implementations.
>
> As Stefan already noted: this discussion belongs on the neon mailinglist.
> Once neon supports the necessary hooks/apis to enable Negotiate for the
> secure protocols we can enable them in Subversion.
> (Or maybe neon can just enable the safe protocols all the time?)
Are you suggesting to file another ticket for that?
I would file two:
1. Subversion passes wrong hostname to build the SPN. (Have neon debug output).
2. Allow user to use any auth on any http scheme. Transport security should be user's concern, not subversion's one.
Mike
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
Re: RE: Proxy authentication with Negotiate uses wrong host
Posted by 19...@gmx.net.
Bert,
> > -----Original Message-----
> > From: 1983-01-06@gmx.net [mailto:1983-01-06@gmx.net]
> > Sent: woensdag 24 augustus 2011 10:47
> > To: users@subversion.apache.org
> > Subject: Re: Proxy authentication with Negotiate uses wrong host
> >
> > > On Wed, Aug 24, 2011 at 09:25:49AM +0200, 1983-01-06@gmx.net wrote:
> > > > I'll do but why is Negotiate auth activated in session.c if the
> target
> > > host is ssy only? This should be on the user to decide not subversion.
> > >
> > > I don't know who made this decision and why.
> > > Maybe svn blame on that file leads to more info?
> >
> > I checked blame already. There was a rather long explanation but still
> no
> > argument to me.
>
> The Subversion parts of this code were written when neon only supported
> NTLM via Negotiate. NTLM is known to be insecure when not used over https.
I am aware of that. That's why I want to use Kerberos in the first place.
> Then somebody added Kerberos support to neon, but the api wasn't updated
> to allow different behavior for the specific implementations.
>
> As Stefan already noted: this discussion belongs on the neon mailinglist.
> Once neon supports the necessary hooks/apis to enable Negotiate for the
> secure protocols we can enable them in Subversion.
> (Or maybe neon can just enable the safe protocols all the time?)
Are you suggesting to file another ticket for that?
I would file two:
1. Subversion passes wrong hostname to build the SPN. (Have neon debug output).
2. Allow user to use any auth on any http scheme. Transport security should be user's concern, not subversion's one.
Mike
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone