neon mixes up proxy and target host when using SSPI on Windows

1983-01-06 at 1983-01-06 at
Thu Aug 25 05:47:29 EDT 2011

Hi folks,

I am chasing a subtile bug in Subversion and posted this already on the svn users ml [1]. We came to the conclusion that this might be neon and SSPI related.

I use SVN 1.6.17 and neon 0.29.6 and Windows and FreeBSD.

I have a company proxy with Negotiate/Kerberos authentication. When neon constructs the auth for the proxy server.

This my setting in Subversion:
http-proxy-host =
http-proxy-port = 85
neon-debug-mask = 24

This is what neon spits out when I run
svn ls

ah_create, for WWW-Authenticate
ah_create, for Proxy-Authenticate
ah_post_send (#0), code is 407 (want 407), Proxy-Authenticate is Negotiate, Kerberos, NTLM, Basic realm=""
auth: Got challenge (code 407).
auth: Got 'Negotiate' challenge.
auth: Got 'NTLM' challenge.
auth: Ignored parameter: realm = "
auth: Trying Negotiate challenge...
auth: SSPI challenge.
sspi: Created context with SPN 'HTTP/'
auth: Accepted Negotiate challenge.
auth: Sending 'Negotiate' response.

It canonicalizes the hostname of the target server instead of the proxy server. The SPN is incorrect and it falls back to SPNEGO with NTLM.

Now when I do the same in FreeBSD, it works like a charm with GSSAPI. So I presume that the SSPI code is buggy somehow.



Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro!

More information about the neon mailing list