|
From: Philip W. <Phi...@fl...> - 2019-01-13 16:52:01
|
Hi. NTLM is a different protocol to SSL/TLS. Trying to use SSL to talk to a NTLM authenticated proxy will not work. You will get an SSL exception which might look similar to other SSL protocol errors but won’t be solved by fixing bugs in the SSL engine. No matter how well we talk SSL the NTLM proxy won’t understand. Next you say CNTLM works fine on Windows. Good. You then say it’s not available on RedHat. But it is, it’s right here - there’s an RPM and everything - you don’t even need to build from source: https://sourceforge.net/projects/cntlm/files/cntlm/cntlm%200.92.3/ I mean it’s on SourceForge which is not ideal these days but it does exist! I suspect Python / PIP are mis understanding your problem. If you don’t use cntlm, then yes your requests will fail. This is not PIPs fault - they just don’t speak the proxy protocol - that’s why cNTLM exists - to tunnel through NTLM. Expecting every app developers to implement closed source protocols is just onerous. Hence a proxy. You will need to use CNTLM for everything that needs to go through this Windows monstrosity. Best regards, Philip Whitehouse Technical Lead FIXHub Team On 13 Jan 2019, at 16:20, Colin DuPlantis <co...@ma...<mailto:co...@ma...>> wrote: QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J Support: http://www.quickfixj.org/support/ It seems you gave a long list of software that doesn't work in this configuration unless there's a Microsoft helper in the loop. I am not sure how you come to the conclusion that QFJ must be the problem despite all the other packages that don't work in a similar configuration. I know that's not helpful, and that's not the reason I'm writing. Have you tried stunnel? I have had very good luck getting stunnel configured to just about anything On Sun, Jan 13, 2019, 7:18 AM Andrew Marlow <mar...@gm...<mailto:mar...@gm...> wrote: QuickFIX/J Documentation: http://www.quickfixj.org/documentation/ QuickFIX/J<http://www.quickfixj.org/documentation/QuickFIX/J> Support: http://www.quickfixj.org/support/ Hello everyone, I am using quickfixj to talk to a remote service that uses SSL encryption. I can get to the web landing page using curl but I get an SSLException with quickfixj during the handshake. I think this must be an issue with the quickfixj code. Let me explain some more: The remote service cannot be accessed directly because of a corporate firewall. The corporation is a heavy user of Microsoft software/environments so the corporate proxy uses NTLM for authentication. This works fine for web users from their windows workstations. However, it causes problems for some other software. An example is the python pip command. That fails with a proxy authentication error even when the correct credentials are supplied. This was reported as a problem to the python/pip developers. They refused to fix the issue. They said it was because the corporate proxy had been misconfigured and they were not going to change their code to cope with corporate misconfiguration. So the problem remains. To get around this problem I use a windows service called CNTLM. It is basically a proxy for a proxy. I enter my credentials into that and it sorts out the traffic forwarding to the pypi website. So when I hit a similar problem with quickfixj I eventually hit on the idea of using CNTLM. I did and the quickfixj communication now works. This is how I can get things to work on windows but unfortunately the software has to be run in a RHEL environment where CNTLM is not available. I do not know what I am going to be able to do about that. I've heard that other software gets hit by the same issue. There was a problem in chrome some years ago apparently. There is a recently logged issue with talend, as can be seen at https://community.talend.com/t5/Design-and-Development/tRest-with-NTLM-Proxy-Authorization/td-p/95066. There was also (and still might be) a problem with postman, as you can see here: https://github.com/postmanlabs/postman-app-support/issues/3692. Other examples include ArcEarth, https://community.esri.com/thread/189903-web-proxy-ntlm-authentication-error, and gradle, see https://stackoverflow.com/questions/14434101/gradle-not-working-behind-proxy-with-ntlm-on-windows. But there is one bit of software that I am able to connect with ok and that's curl. I am using a very recent version, 2.57. I cannot help thinking that curl has put in a workaround of the kind requested by python pip users. I hope to do some investigation to see if earlier versions of curl have the issue. That might shed some light on where the fix (if any) was supplied. It might be in the curl code or it might be in openssl. I am really not sure. But I am fairly convinced that apps that experience the issue must employ some sort of workaround. I note that a bug report was raised against quickfixj that might be the same issue, see https://www.quickfixj.org/jira/browse/QFJ-949 . It was closed with the statement ". I doubt that this is a bug since many people are using SSL with Java 8.". I am using JDK8 and I see the issue unless I use CNTLM. So perhaps this bug report should be re-opened. I admit it might be a bug in mina, since that is the component that quickfixj uses for the SSL handling. Could a version be built with the most recent version of mina please? -- Regards, Andrew Marlow http://www.andrewpetermarlow.co.uk _______________________________________________ Quickfixj-users mailing list Qui...@li...<mailto:Qui...@li...> https://lists.sourceforge.net/lists/listinfo/quickfixj-users _______________________________________________ Quickfixj-users mailing list Qui...@li...<mailto:Qui...@li...> https://lists.sourceforge.net/lists/listinfo/quickfixj-users |