Proxy authentication with Negotiate uses wrong host
Hi folks, I am trying to make Subversion run with our ISA proxy which advertises Proxy-Authenticate: Negotiate, NTLM, Basic. My Subversion version is: 1.6.7 on Windows XP, tried with 1.7-beta3 which even did not want to accept the URL. The HTTP lib is neon because serf quit working with "svn: Error running context: Internal error". This is the UA sent by Subversion: SVN/1.6.17 (r1128011) neon/0.29.6 Now, when the proxy server challenges Subversion to authenticate, Subversion tries to retrieve a service ticket for the target host /instead of/ for the proxy host. I debugged that in a Wireshark session. Should I file a bug report? I already sent a mail to TortoiseSVN ml [1] but was redirected here because it uses Subversion libs to perform authentication. A very interesting point is that I am running the same setup on FreeBSD and the service ticket is successfully obtained for the proxy server. Mike [1] http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2825191 -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone
Proxy authentication with Negotiate uses wrong host
Hi folks, I am trying to make Subversion run with our ISA proxy which advertises Proxy-Authenticate: Negotiate, NTLM, Basic. My Subversion version is: 1.6.7 on Windows XP, tried with 1.7-beta3 which even did not want to accept the URL. The HTTP lib is neon because serf quit working with "svn: Error running context: Internal error". This is the UA sent by Subversion: SVN/1.6.17 (r1128011) neon/0.29.6 Now, when the proxy server challenges Subversion to authenticate, Subversion tries to retrieve a service ticket for the target host /instead of/ for the proxy host. I debugged that in a Wireshark session. Should I file a bug report? I already sent a mail to TortoiseSVN ml [1] but was redirected here because it uses Subversion libs to perform authentication. A very interesting point is that I am running the same setup on FreeBSD and the service ticket is successfully obtained for the proxy server. Mike [1] http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2825191 -- 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
> Betreff: Re: Proxy authentication with Negotiate uses wrong host > On Mon, Aug 22, 2011 at 12:55:58PM +0200, 1983-01...@gmx.net wrote: > > Now, when the proxy server challenges Subversion to authenticate, > Subversion tries to retrieve a service ticket for the target host /instead of/ > for the proxy host. I debugged that in a Wireshark session. > > Should I file a bug report? > > I've taken a look at neon, and it provides everything that's needed. > But the application must call ne_set_proxy_auth() for it to work. > > Subversion only calls this if the http-proxy-username option has been > configured in the file ~/.subversion/servers. Have you done that? Stefan, no, I did not set that value neither on Windows nor on FreeBSD. Using Negotiate does require setting a username. That's what the credentials cache is for. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de -- 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
> Betreff: Re: Proxy authentication with Negotiate uses wrong host > On Mon, Aug 22, 2011 at 01:41:59PM +0200, 1983-01...@gmx.net wrote: > > no, I did not set that value neither on Windows nor on FreeBSD. Using > Negotiate does require setting a username. That's what the credentials cache > is for. > > You expect svn to get the proxy username from the ~/.subversion/auth > cache? That expection is not unreasonable, but it is not what the > implementation does, as far as I undestand (see > subversion/libsvn_ra_neon/session.c). No, I don't expect svn to do that and imho there is no need to. I have double-checked on FreeBSD and there is no cache for the proxy because this is done by the GSSAPI externally. > Have you tried setting the option to see if it fixes your problem? Yes, I did with 'http-proxy-username = mumu'. No avail. > I'm trying to figure out whether we should file an issue for this, > but I cannot do any testing myself. Your help is appreciated. I will help as much as I can. 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
> Betreff: Re: Proxy authentication with Negotiate uses wrong host > > Digging deeper into that file shows that Negotiate auth for servers > > (not proxy servers) is done only when the server is servered with > > HTTPS [2]. > > Having taken a brief glance it looks as if you can override this > via the http-auth-types option in ~/.subversion/servers. > Have you tried that? Yes, I did that already. Set to negotiate;basic. No avail. For some strange reason it simply ignores the setup. Should I try any specific neon debug mask? > > I took a look back at neon_auth.h (define > > NE_AUTH_NEGOTIATE) [3] and it constantly says that Digest and > > Negotiate are unsecure and require a secure connection which is > > complete non-sense. Kerberos was designed to provide security in > > unsecure networks. This is definitively wrong documentation. > > Not sure if this documentation is generally wrong. > It can depend on what kinds of assumptions people make about security. > Please verify this question with the neon devs. 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. Mike -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone -- 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
> On Tue, Aug 23, 2011 at 10:47:35PM +0200, Michael-O wrote: > > I made some digging in the subversion and neon code and notices some > > interesting and odd stuff. > > > > If you take a look at the aforementioned session.c in line 865 [1] > > you'll see that the code is correct, Negotiate auth is added if no > > proxy_username is set. So my assumption was correct. It should work > > out-of-the box. > > Yes, you're right. It seems I misread this and didn't notice > the 'else' part which also enables Negotiate auth. Sorry. > Stefan, another note. I tried a different proxy machine (we have a farm of) and tried: H:\Projekte>svn ls http://svn.apache.org/repos/asf/ The TGS-REQ body is as follows Server Name (Service and Instance): HTTP/harmonia.apache.org + some other stuff The KDC responses with: Error: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN Server Name (Service and Instance): HTTP/harmonia.apache.org This is the output of Wirshark on FreeBSD: The TGS-REQ body is as follows Server Name (Service and Instance): HTTP/my.proxy.server And so forth. I can privately send you both wireshark dumps if you'd like. Mike -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Re: Proxy authentication with Negotiate uses wrong host
> On Wed, Aug 24, 2011 at 09:25:49AM +0200, 1983-01...@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. -- 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
Bert, > > -Original Message- > > From: 1983-01...@gmx.net [mailto:1983-01...@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...@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
> 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
> On Wed, 2011-08-24 at 07:42 -0400, 1983-01...@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
