Problem with firewall/proxy configurations

[jbuberel]

Here at work (Motorola), all outbound connections must go through an authenticated HTTP proxy server. This is not a Socks5 proxy, but an HTTP proxy. I know that earlier versions of SecureCRT did not support HTTP proxies, so I tried to use the 'USER user@host login' Firewall type.

When I tried to open an SSH2 connection using that configuration, I saw the following error dialog:

Invalid Firewall Type[USER user@host port (with login)]: Connecting 
without firewall. Valid types are: Generic proxy, SocksV4 and SocksV5.

Is this the intended behavior?

Also - are there any plans to support HTTP proxies?

[jdev]

SecureCRT has supported HTTP proxies for some time, but it does not currently have native support for HTTP proxies that require authentication.

Support for authenticated HTTP proxies is being considered for inclusion in SecureCRT. If you send me a private note with your contact information, I can make sure that you are notified when authenticated proxies are supported in SecureCRT.

Meanwhile, there is a workaround that you might consider using. Most authenticated HTTP proxies use the "Basic" authentication mechanism, so if you set the firewall Type in SecureCRT's Global configuration to Generic proxy, fill in the hostname/ip and port, leave the Proxy prompt empty, and specify the Proxy command as:

CONNECT %h:%p HTTP/1.0\r\nProxy-Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQK\r\n\r\n

Where dXNlcm5hbWU6cGFzc3dvcmQK is username:password base64-encoded.

If you have access to a Unix system that has the uuencode utility installed, you can use the following command to base64 encode your username:password component:

echo username:password | uuencode -m /dev/stdout

Output from using uuencode as indicated above would look similar to:

begin-base64 644 /dev/stdout
dXNlcm5hbWU6cGFzc3dvcmQK
====

(The actual base64 encoded information you need will be sandwiched between two lines of insignificant information as in the example above).

Alternatively, you can use one of several online base64 encoder/decoders to base64 encode your "username:password" text. Here are two such sites:

http://www.motobit.com/util/base64-decoder-encoder.asp
http://makcoder.sourceforge.net/demo/base64.php

Does this information help you configure SecureCRT to connect through your authenticated HTTP proxy?

[dkratter]

I also have to go through a corporate HTTP proxy. I tried doing what you suggested in SCRT5b4, but I am never able to authenticate. I can't really tell what the problem is other than it keeps trying to connect to the host and never does.

It would be really good if you added proper support for HTTP proxies.

[jbuberel]

Just wanted to let you know that using the Generic Proxy work-around described above, I was able to get this working using a NetScreen Authenticating HTTP proxy here on my employer's network.

I used the web-based uuencoder:

http://makcoder.sourceforge.net/demo/base64.php

Thanks for the tip!

[jdev]

Originally Posted by dkratter

I also have to go through a corporate HTTP proxy. I tried doing what you suggested in SCRT5b4, but I am never able to authenticate. I can't really tell what the problem is other than it keeps trying to connect to the host and never does.

It would be really good if you added proper support for HTTP proxies.

Sorry to hear that the jump-through-hoops workaround didn't work for you. I agree that we need to add support for authenticated HTTP proxies. I've added another entry for this functionality in our database for SecureCRT. If you would like to be notified via e-mail when this feature is available, please send me a private message with your e-mail address.

Thanks.

[jbuberel]

For those interested, I can confirm that support for authenticating HTTP Proxies is part of the SecureCRT v5.2 alpha releases. I have tested a version of this and found that it did indeed work on my current network.

So it is probably safe to assume this will appear in the final release of SecureCRT 5.2.