Option to manually specify username/password

[piejanssens]

No description provided.

[genotrance]

The whole point of Px was to avoid providing username/password, but I understand that means it only works on Windows and when part of the domain. I felt cntlm or NTLMaps filled that space already so didn't feel the need to explore it in Px.

I'm curious to hear your thoughts on this feature though.

[piejanssens]

Many users that require NTLM to access the internet use cntlm not only because it gives access to applications that don't support NTLM, but also because cntlm allows you to specify another account. Px works only if you are using the account on the network with a computer that is logged on to that domain. I often receive an AD account, but use my own laptop (local login) and then use cntlm to access the internet. Cntlm has difficulties on Win10 and it would be nice to switch over to something more modern.

[schniggie]

Same for me here. cntlm often dies or stops working. So itwould be really great if pxould receive an option to supply own credentials.

[genotrance]

I've looked into this for a couple days and it should be relatively easy to add this functionality. However, it brings some secondary questions to think about:-

• Password storage - right now Px doesn't have to store any sensitive information. If we add this feature, we need to ensure the password is stored safely.

• Right now Px is not interactive at all - you can either specify configuration with the config file or the command line parameters. Given it is built as a GUI application, you cannot read the password from stdin. This either means adding GUI support, a separate password binary or two separate CLI vs. GUI mode apps. Perhaps some other options as well but something to figure out in order to do this right to meet the password safety issue.

• Once this feature is in, Linux support becomes possible and immediately it means this should be implemented as cross-platform a way as possible. I'm curious if there is much interest for this to seriously consider it in the future.

Sharing to update on where we are with this and if there are any good ideas to deal with these design questions.

[schniggie]

@genotrance Sounds great. Indeed the password handling topic is not very straightforward. You first thoughts would be to use still Kerberos and therefore px needs the Domain credentials of a user right? So you cannot use any NetNTLMv2 hash for authentication?

[genotrance]

Yes, I need the raw password for something like ntlm-auth to generate the hashes for authentication.

My current plan for Windows is to use Credentials Manager - if you want to provide credentials to Px, you would go to Credentials Manager and add a generic entry using its GUI. Then Px would get the credentials from CM and use it. This way, Px is neither responsible for the UI, storage or security of the credentials. There is still the concern of having the password in memory but that comes with the territory and will be documented.

No idea on Linux yet but will cross that bridge when we get to it.

Now, Px uses both pywin32 and winkerberos for NTLM and Kerberos respectively. Both support password based authentication as well as SSPI but are Windows specific, so I plan on using ntlm-auth for NTLM and kerberos for Kerberos since those are cross-platform and could eventually work on Linux as well. These will only be used for password based auth and SSPI will still stay as it is. I do not have a Kerberos setup to test against so will have to depend on the community to verify that it works as expected.

Open to feedback on this approach - let me know what you think. Github issues work fine but also feel free to join https://gitter.im/genotrance/px to chat about Px.

[schniggie]

Give me a ping, as soon as it could be tested :)

[vincentkoc]

I second this, CNTLM project has died. Leaving a huge gap for a maintained CLI driven cross-platform NTLM proxy solution

[genotrance]

I've just implemented this feature in the latest commit / vHEAD release. Please try it out and let me know your feedback. You need to setup your password as a generic credential using Credential Manager. I have updated the README with details.

I've tested NTLM auth on my laptop but it is part of the domain and logged in with a domain account (SSPI ready) so it will help to test with a non-SSPI configuration.

Second, I have implemented this for Kerberos as well but do not have a server to test against so that's another use case that requires careful testing.

Thanks in advance for your support!

[piejanssens]

It seems to be working good.

[genotrance]

Is this NTLM or Kerberos?

[piejanssens]

NTLM (but it's not visible in the logs, is it?)

[genotrance]

Yes it shows up in the logs.

do_proxy_type: Selected: {('proxy01.example.com', 8080): 'NTLM'}

You should also see the following in place of pywin32 SSPI to confirm.

get_response_ntlm: ntlm-auth

[piejanssens]

Process-1: Thread_0: 1536661156: do_proxy_type: Selected: ('xxxx', 80): None

[genotrance]

Can you please share the full log?

[piejanssens]

I was getting "An established connection was aborted by the software in your host machine". Turned Symantec firewall off and now I can see:

MainProcess: Thread_0: 1536670357: do_proxy_type: Auth mechanisms: NEGOTIATE NTLM BASIC realm="onbox" 
MainProcess: Thread_0: 1536670357: do_proxy_type: Selected: ('xxxx', 80): NTLM

However it's not working, getting 407's for every request.
In my px.ini I've put my NTLM username and in the credentials store I've created a 'Px' Windows credential with the same username and the proxy password.
How can I unsanitize my logs to see what it's sending to the proxy server?

--
Edit: username pw issue is resolved, I should use domain\username in both the px.ini and credential manager
Issue with proxy type 'None' remains (seemingly random) even with Symantec firewall off. So it must be another program interfering or something else.

[genotrance]

Yes - if it doesn't find an equivalent password in credentials manager, it will fall back to pywin32 SSPI. You can see get_response_ntlm: ntlm-auth in the logs compared to get_response_sspi: pywin32 SSPI.

Have you whitelisted the px or Python binary in the firewall?