Proxy Support

[jesperalmstrom]

Describe the bug When trying to install and run behind a corporate proxy solution (MITM) the extension will time-out after some while with the following message

Unable to load Lambda Functions, click here to retry

To Reproduce

1. Sit behind a proxy/firewall with working HTTP_PROXY and HTTPS_PROXY config.
2. Install according to README.md
3. Run Connect to AWS:

Select your profile in Visual Studio Code

1. Launch Visual Studio Code.
2. Select View > Command Palette... and search for AWS.
3. Select AWS: Connect to AWS

Expected behavior Something should load ...

Desktop (please complete the following information):

• OS: Linux
• Visual Studio Code Version: 1.30.1
• AWS Toolkit for Visual Studio Code Version: 0.0.1

Additional context There is a experimental setting in VS Code "http.proxySupport": "on" This does not work.

[jesperalmstrom]

https://github.com/Microsoft/vscode/issues/12588 This could be interesting.

[jesperalmstrom]

Tested with latest VSCode and latest aws-toolkit-vscode build but it did not help.

2019-03-12 21:48:54 [INFO]: > Downloading latest toolkits endpoint data
2019-03-12 21:48:54 [ERROR]: Error getting resource from https://aws-toolkit-endpoints.s3.amazonaws.com/endpoints.json :  Error: tunneling socket could not be established, statusCode=403
	at ClientRequest.onConnect (/home/jesper/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-0.0.1/node_modules/tunnel-agent/index.js:166:19)
	at Object.onceWrapper (events.js:273:13)
	at ClientRequest.emit (events.js:182:13)
	at ClientRequest.EventEmitter.emit (domain.js:442:20)
	at Socket.socketOnData (_http_client.js:465:11)
	at Socket.emit (events.js:182:13)
	at Socket.EventEmitter.emit (domain.js:442:20)
	at ClientRequest.onsocket (/usr/share/code/resources/app/node_modules.asar/https-proxy-agent/index.js:182:14)
	at Object.onceWrapper (events.js:273:13)
	at ClientRequest.emit (events.js:187:15)
	at ClientRequest.EventEmitter.emit (domain.js:442:20)
	at tickOnSocket (_http_client.js:651:7)
	at onSocketNT (_http_client.js:667:5)
	at process._tickCallback (internal/process/next_tick.js:63:19)
2019-03-12 21:57:58 [ERROR]: Error: connect ETIMEDOUT 52.94.241.129:443
	at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1161:14)

[bryceitoc9]

I'm assuming all VS Code-written networking features work fine? If so, the proxy is probably only affecting the AWS JS SDK and CLI (both of which we leverage).

For our future reference, here's how to implement a proxy with the JS SDK (we'll have to implement this) https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/node-configuring-proxies.html . If you're getting blocked on SAM-related calls (such as deploying functions), this should work if you export these for all new sessions (we'll look to add a configuration for this through VS Code directly): https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-proxy.html

[mpiroc]

We currently lack an explicit strategy for dealing with proxies. As part of the solution for this issue, we need to define and document a complete story for proxy support, and validation for that story. This includes (at mimimum):

• A documented model/instructions for using the toolkit from behind a proxy.
• A formal set of manual and/or automated tests to validate proxy support.

[justinmk3]

Status

2024

From https://github.com/microsoft/vscode/issues/12588#issuecomment-2111861237 :

Work is under way to make Chromium's implementation of fetch available to extensions. This issue is unlikely to be closed soon though, as many extensions are using Node's https module for which we have only partial support for proxies. Only proxies without auth and with Kerberos auth are supported at the moment.

If you think your setup should already work with the https module, but doesn't, please install the Network Proxy Test extension (https://marketplace.visualstudio.com/items?itemName=chrmarti.network-proxy-test) and check the output of F1 > Network Proxy Test: Test Connection in VS Code.

This configuration was observed to work (on macOS):

• There is a new vscode setting Http > Experimental: System Certificates V2 which helps "if your self signed cert is trusted by your OS".
• This extension may also be useful: https://marketplace.visualstudio.com/items?itemName=linhmtran168.mac-ca-vscode
  • Windows: https://marketplace.visualstudio.com/items?itemName=ukoloff.win-ca
• settings:

  {
      "http.proxyStrictSSL": false,
      "http.proxySupport": "on",
      "http.experimental.systemCertificatesV2": true,
      "http.proxy": "http://0.0.0.0:1080",
  }
  

2020

From https://github.com/microsoft/vscode/issues/12588#issuecomment-297341617 :

For downloading extensions and updates, VS Code uses Chromium's cross-platform support for proxies. That looks up the proxy configuration in the OS.

For extensions (which run in a separate process that does not have Chromium's network library available) we are using an Electron API to look up the proxy configuration from the OS. That is cross-platform, but it does not support authentication.

• vscode extensions don't have access to chromium network API, so we need to handle this separately.

For our future reference, here's how to implement a proxy with the JS SDK (we'll have to implement: sdk v2 sdk v3)

Patch for trying that in our codebase (sdk v2):

diff --git a/src/shared/awsClientBuilder.ts b/src/shared/awsClientBuilder.ts
index 12bfde9bfe86..9622a5d0267e 100644
--- a/src/shared/awsClientBuilder.ts
+++ b/src/shared/awsClientBuilder.ts
@@ -7,6 +7,7 @@ import { ServiceConfigurationOptions } from 'aws-sdk/lib/service'
 import { env, version } from 'vscode'
 import { AwsContext } from './awsContext'
 import { pluginVersion } from './constants'
+import * as proxyagent from 'proxy-agent'
-
 export interface AWSClientBuilder {
     createAndConfigureServiceClient<T>(                      
@@ -34,6 +35,9 @@ export class DefaultAWSClientBuilder implements AWSClientBuilder {
             awsServiceOpts = {}
         }                       
-                                
+        // awsServiceOpts.httpOptions = { agent: new proxyagent('http://example.com') }
+        awsServiceOpts.httpOptions = { proxy: 'http://example.com' }
+                                  
         if (!awsServiceOpts.credentials) {                                 
             awsServiceOpts.credentials = await this._awsContext.getCredentials()
         }

And/or we may need to provide the ability to specify paths to certificates. In the node.js API typically this is the ca field on calls to https.Agent(), tls.connect(), etc.

ca: [ fs.readFileSync('path/intermed-ca.cert.pem'), fs.readFileSync('path/root-ca.cert.pem') ]

Workarounds

ref https://github.com/microsoft/vscode/issues/189133 https://github.com/microsoft/vscode-test-cli/issues/7

• Try the experimental vscode setting: "http.experimental.systemCertificatesV2": true
• Set log level to trace using the vscode command Developer: Set Log Level....
• Reload vscode.
• Check that the Extension Host output channel does not contain any ProxyResolver#tls.connect entries.

Related

• sdk v3 proxy middleware: https://github.com/awslabs/aws-sdk-v3-js-proxy
• https://github.com/microsoft/vscode/issues/12588
• https://code.visualstudio.com/updates/v1_51#_remember-proxy-credentials
• https://github.com/microsoft/vscode/issues/94148
• https://github.com/aws/aws-toolkit-jetbrains/pull/735
• https://github.com/aws/aws-toolkit-jetbrains/pull/874
• https://github.com/aws/aws-sdk-js-v3/discussions/3652

[boyersnet]

@justinmk3 has there been any more updates on the ability to specify paths on the CA certificates? I'm having this exact issue and the SAM team sent me over to the toolkit team. See (https://github.com/awslabs/aws-sam-cli/issues/1981) for details. A member of my team also mentioned it here (https://github.com/aws/aws-toolkit-vscode/issues/917#issuecomment-583658923).

[justinmk3]

@boyersnet no update since https://github.com/aws/aws-toolkit-vscode/issues/185#issuecomment-589500254 .

ability to specify paths on the CA certificates?

Do you do this in other software? Examples would be helpful.

[boyersnet]

@justinmk3 - In order to get the docker container to work with SAM CLI, I had to pass the path to my cert bundle as an env variable (AWS_CA_BUNDLE - per AWS CLI documentation). Once that was done, the call to SSM worked as expected from the container. The problem I face now is how to debug in VS Code with the toolkit. The toolkit should follow the same pattern as the AWS CLI and respect order specified here: https://docs.aws.amazon.com/cli/latest/topic/config-vars.html

[justinmk3]

Thanks for mentioning that. AWS_CA_BUNDLE is another mechanism that has not been mentioned yet. Related SDK issue: https://github.com/aws/aws-sdk-js/issues/2970

[justinmk3]

Related: VSCode 1.51 release notes mention

• proxy dialog https://code.visualstudio.com/updates/v1_51#_remember-proxy-credentials
• window.enableExperimentalProxyLoginDialog: true setting

[AbhilashPurohith]

Go to Visual Studio -> Settings icon -> Settings -> search for Proxy -> Remove http proxy if any -> uncheck Http: Proxy Strict SSL -> restart Visual studio code

This solved my problem.

If at all you are not able to do it. Try removing proxy from settings.. Go out of VPN and then try it again.

Or else check if u are setting any http proxy in your environmental variables. Remove it and try