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

1983-01-06 at gmx.net 1983-01-06 at gmx.net
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:
[global]
http-proxy-host = proxy.company.net
http-proxy-port = 85
neon-debug-mask = 24

This is what neon spits out when I run
svn ls https://svn.apache.org/repos/asf/

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="proxy.company.net"
auth: Got challenge (code 407).
auth: Got 'Negotiate' challenge.
auth: Got 'NTLM' challenge.
auth: Ignored parameter: realm = "proxy.company.net
auth: Trying Negotiate challenge...
auth: SSPI challenge.
sspi: Created context with SPN 'HTTP/harmonia.apache.org'
auth: SSPI challenge [TlRMTVNTUAABAAAAt4II4gAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==]
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.

Thanks,

Mike

[1] http://svn.haxx.se/users/archive-2011-08/0464.shtml
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de



More information about the neon mailing list