Outbound Connection

Our outbound connection uses an outbound/forward proxy.

Proxy Definition

The most succinct definition we’ve found on what a proxy does is from Postman

The proxy can reside on your local machine, somewhere in your network, or at any point between your client and the destination server on the internet.

Similar to the way parents might speak to each other through a child, the child is a proxy relaying all communications between the 2 parents.

Parent 1: Ask your father if he can pick you up after school.

Timmy: Can you pick me up after school.

Parent 2: Yeah.

Timmy: Dad says yeah.

In this analogy, the child forwards the information on behalf of each parent. Besides just relaying information, proxies can do much more.

  • Record all traffic between your machine and the internet
  • Reveal the contents of all requests, responses, cookies, and headers
  • Route traffic to specified internet locations
  • Debugging
  • Security from direct attacks.

The difference between our outbound proxy and our inbound is that the outbound is dynamic and can communicate to many different endpoints while the inbound proxy sits between your client side and your server side.

What does it allow you to do?

  • Like the inbound connection, the outbound/forward proxy allows you to rewrite requests and responses on the fly.
  • Lets you operate on data outside of the scope of your backend systems.
  • Set/Change/Strip Headers - perform any operation on the payload.
  • Modify the payload, even if it’s not a strict redaction/replacement.
  • Perform Edge Computing, as needed for computing outside of the scope of your system (enterprise plans)
  • Adds an additional layer of security requiring proxy-authorization credentials and a root certificate to be set.
  • Is used to integrate into third party services and allows for configurations that are processor specific as mentioned in the integrations page.
  • Our forward/outbound proxy also allows for IP Anonymization as an additional upgrade.

How does it work?

You set your server to send traffic through our outbound/forward proxy and create routes, filters and operations for your different API endpoints.

Example:

  • BEFORE: server.foo.com → api.worldpay.com
  • AFTER: server.foo.com → tenantid.SANDBOX.verygoodproxy.com → api.worldpay.com

The forward/outbound proxy directs traffic between your server (outbound) traffic, the VGS vault (where sensitive data is stored), and your third party integrations as illustrated by the below image. reverse-proxy-client-server

How do I implement it?

For many languages, setting the proxy as an environmental variable enables the forward proxy to be used at a framework or library level.

We have several examples of API Call specific forward implementations here.

python
import os

USERNAME = os.environ.get('USERNAME')
PASSWORD = os.environ.get('PASSWORD')
TENANT_ID = os.environ.get('TENANT_ID')

HTTPS_PROXY = "%s:%s@%s.SANDBOX.verygoodproxy.com:8080".format(USERNAME, PASSWORD, TENANT_ID)

SSL Certificates

The forward proxy requires an SSL certificate. We have a different server certificate for each environment, SANDBOX and LIVE (as you can see from the Python example above). You can find these certificates within the dashboard.

HTTP Basic Authentication

The VGS forward proxy supports HTTP Basic Authentication. This enables a password of your VGS vault, so that only your application can reveal and access sensitive data. You must provide the username and password via the following URL format. https://username:password@tenant-id.SANDBOX.verygoodproxy.com:8080

Note: Some backend languages require you to access this url by passing auth in a different manner.

VGS forward proxy reveal operations require http basic authentication using the username and password provided in the VGS dashboard. It is up to you to protect these credentials, treat them like an API key. For more information on Basic Authentication.

Storing HTTP Basic Authentication Secrets Securely

  • Do not embed secrets directly in code.
  • Do not store secrets in files inside your application, including the application’s source tree
  • If you do accidentally commit secrets to version control, revoke it immediately and generate a new one.
  • Ensure secrets not appear in URLs or anywhere they can be captured in web server logs.
  • Review your code carefully and ensure it doesn’t contain secrets or any other private information before publicly releasing it.
  • Put the configuration file containing the secrets in the revision control ignore. This prevents committing them by mistake in the future.
  • Limit the usage of secrets
  • Restrict your secrets to be used by only the IP addresses, referrer URLs, and mobile apps that need them. Don’t share your secrets with different applications. If more than one application uses the same API, register each application so you get a new set of secrets and update the secrets.
  • Delete unneeded secrets.
  • Update (Regenerate) your secrets periodically.

References:

Best practices for securely using Secrets

REST Security Cheat Sheet - OWASP

Encrypted Communication

VGS supports encryption to protect communications between VGS and your web application. VGS supports the TLS cryptographic protocol. Support for anything less than TLS1.2 is officially deprecated.

For more information regarding TLS:

If you need any help setting up the forward proxy please contact us on site chat or at support@verygoodsecurity.com.