Where my hatred of Microsoft knows no limit. I'm seeing code in my sleep, and seeing the Truth behind the Code. The Neanderthal Technology Lan Manager will be defeated. Jakarta commons HttpClient has support for NTLM, and has support for SSL. Trying to use them together, fails. Simple HTTP worked fine with the proxy server, once I got all the JCE stuff sorted out (stupid, stupid requirements dating back to export requirements on munitions-grade crypto). I listened to the socket, and could FEEL what was wrong. Now I just need to find the snippet of apache code where they close that socket when they shouldn't ... naughty apache, I trusted you to get this right. There's an NTLM SSL proxy authentication implementation in Mozilla, which seems to work right; I tore that apart to see how it is supposed to work. Can't cut-and-paste or even link to that code, since it's in the wrong language. Unless I threw a JNI wrapper around it ... but that could put us into wacky redistribution issues with AOL. Unforgivably, versions of Microsoft Proxy Server older than HTTP Digest authentication don't support proxy authentication via HTTP Digest, and people are afraid to upgrade when they are locked into vendors like Microsoft that molest you every time you ask them for help. NTLM actually seems to be a fairly straightforward encrypted challenge-response, it's just undocumented and using funky encryption and impossible to test without access to expensive, proprietary, wacky servers with license agreements written by donkey-raping minions of malevolence. And I don't see anything in the RFCs explaining WHY it should throw a hissy fit at using a new socket for the auth-response, but it doesn't even really surprise me any more. Now I just have to dive into the HTTPClient code and fix it for them.