Application Security and Acceleration

Objective

The Volterra Application Security and Acceleration solution (also called as Volterra AppProtect) uses application security to provide enhanced security to customer applications distributed over internet or across private networks. The AppProtect also enhances end-user experience using the application acceleration.

The Volterra AppProtect takes advantage of the functionalities of the Volterra Distributed Applications platform providing security and application acceleration for the applications running on network cloud, edge cloud, or internet. The App Protect solution provides the following:

  • Best performance, e2e security, and high availability using a global AnyCast/GSLB network.
  • The Volterra Global AnyCast network absorbs highly distributed attack traffic to ensure 100% of applications availability.
  • Supports rate-limiting for granular control to block against slow and high rate attacks
  • Protects against direct attacks on the origin using a secure tunnel between Volterra RE sites
  • Detects and blocks L3, L4, and L7 attacks using network-level policy, service-level policy, Web Application Firewall, and HTTPS offload.

Note: For more information on the Volterra Distributed Applications Platform and Volterra concepts, see Concepts.


Components of AppProtect

Volterra AppProtect solution can be classified into the following types of functionalities:

  • Application Security - Provides security from threats such as API attacks, bot-based attacks, malware, DDoS attacks, and so on.
  • Application Acceleration - Delivers enhanced user experience by supporting reliable connection for global access, reduces latency, improves throughput, and load-balancing.

The following image is a topological representation of Volterra AppProtect securing and accelerating the applications.

Components of Application Security

Volterra AppProtect has the following set of functionalities providing enhanced security to the globally distributed applications:

  • VoltMesh Application Security using the Web Access Firewall (WAF)
  • VoltMesh Load Balancing and Service Mesh (Layer 7 HTTP/HTTPS proxy, Layer 4 TCP/UDP proxy)
  • VoltMesh Secure Networking (Layer 3 Routing, Network Policy, Network Firewall)
  • Observability/Monitoring

As part of the Layer 7 HTTP/HTTPS Proxy, the following functionalities are supported:

  • HTTPS TLS/SSL Offload
  • HTTP Large Header support
  • HTTP Header manipulation
  • HTTP/1.1 & HTTP/2 support
  • CORS (Cross Origin Resource Sharing)
  • HSTS (HTTP Strict Transport Security)

Components of Application Acceleration

Volterra AppProtect solution offers the following functionalities to offer enhanced user experience:

  • Global Server Load Balancing (GLSB) with Anycast IP address support
  • Service Mesh using Layer 7 HTTP/HTTPS proxy and Layer 4 TCP/UDP proxy.
  • Observability
  • OCSP Stapling

Volterra platform support the following load balancing algorithms:

  • Round Robin
  • Least Request
  • Ring Hash
  • Random

Note: In case of endpoint reachability from the Volterra Regional Edge (RE) sites and better performance, it is recommended to set the endpoint_selection to local_only.

Prerequisites

The following prerequisites apply:

  • VES account

    Note: If you do not have an account, see Create a VES Account.

  • A virtual host with a signed TLS certificate

    Note: If you do not have a virtual host, see Create a Virtual Host.

  • The vesctl tool. Download vesctl on your local machine as it is used to apply Blindfold to the TLS certificate.
  • Optionally, one or more cloud or edge locations with Volterra site

    Note: Install the Volterra node or cluster image in your cloud or edge location. See How to Create a Site for more information.


Configuration

The following image shows the configuration sequence of enabling Volterra AppProtect for your application.

appprot config seq
Figure: Configuration Sequence of Applying Volterra AppProtect

Configuration Sequence

You can use the Volterra Terraform Provider to apply a default configuration or manually configure the Volterra AppProtect to secure your application.

Manually configuring Volterra AppProtect requires performing the following sequence of actions:

Phase Description
Obtain API Credentials Generate the API credentials from the VoltConsole.
Create Endpoints Create endpoints for your applications.
Create Cluster Create a cluster associating with the created endpoints.
Create routes Create HTTP route (redirection) and HTTPS route pointing to the created cluster.
Create Advertise Policy Create one policy for redirect route and one policy for HTTPS route.
Create WAF Create a WAF object.
Create Virtual Host Create one HTTP virtual host for redirection and another HTTPS virtual host with AppProtect Services.

Apply Volterra AppProtect Using Volterra Terraform

Perform the following to apply Volterra AppProtect and secure your applications using Volterra terraform:

Step 1: Log in to the VoltConsole and download API credentials from the Sytem -> IAM -> API Credentials option. Click Create credentials, set a password, and click Download.

Note: Memorise the password you set as that is required to set the environment variable for terraform.

APICred
Generate API Credentials

Step 2: Create terraform input variables file and populate the fields. This example shows sample file entries.

{
    "api_p12_file": "/Users/qasim/Downloads/<YOUR_TENANT_API_CREDENTIALS>.p12",
    "api_url": "https://<YOUR_TENANT_NAME>.console.ves.volterra.io/api",
    "https_offload": "false",
    "name": "mediapart"
}

Step 3: Configure an environmental variable with API credentials password.

Note: Use the password set in Step 1.

export VES_P12_PASSWORD=<API_CREDENTIAL_PASSWORD>

Step 4: Initialise terraform resources and create them using the input variables created in Step 2.

terraform init
terraform apply -var-file=<PATH_TO_VARIABLES_FILE>

Step 5: Verify that the AppProtect is applied.

Verification of HTTP to HTTPS Redirect:

time curl -v --resolve www.mediapart.fr:80:<DNS_CNAME> http://www.mediapart.fr/ -I

# Example
time curl -v --resolve www.mediapart.fr:80:ves-io-a0f60493-c580-4dfa-bd8e-9e4e99d26c12.ac.vh.ves.io http://www.mediapart.fr/ -I

Response

* Resolve address 'ves-io-a0f60493-c580-4dfa-bd8e-9e4e99d26c12.ac.vh.ves.io' found illegal!
* Couldn't parse CURLOPT_RESOLVE entry 'www.mediapart.fr:80:ves-io-a0f60493-c580-4dfa-bd8e-9e4e99d26c12.ac.vh.ves.io'!
*   Trying 72.19.3.133...
* TCP_NODELAY set
* Connected to www.mediapart.fr (72.19.3.133) port 80 (#0)
> HEAD / HTTP/1.1
> Host: www.mediapart.fr
> User-Agent: curl/7.64.1
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
< location: https://www.mediapart.fr/
location: https://www.mediapart.fr/
< date: Fri, 17 Jan 2020 17:47:51 GMT
date: Fri, 17 Jan 2020 17:47:51 GMT
< server: envoy
server: envoy
< transfer-encoding: chunked
transfer-encoding: chunked

< 
* Connection #0 to host www.mediapart.fr left intact
* Closing connection 0
curl -v --resolve  http://www.mediapart.fr/ -I  0.00s user 0.01s system 8% cpu 0.123 total

Verification of HTTPS:

time curl -v --resolve www.mediapart.fr:443:<DNS_CNAME> https://www.mediapart.fr/ -I

# Example
time curl -v --resolve www.mediapart.fr:443:ves-io-a0f60493-c580-4dfa-bd8e-9e4e99d26c12.ac.vh.ves.io https://www.mediapart.fr/ -I

Response

* Resolve address 'ves-io-a0f60493-c580-4dfa-bd8e-9e4e99d26c12.ac.vh.ves.io' found illegal!
* Couldn't parse CURLOPT_RESOLVE entry 'www.mediapart.fr:443:ves-io-a0f60493-c580-4dfa-bd8e-9e4e99d26c12.ac.vh.ves.io'!
*   Trying 72.19.3.133...
* TCP_NODELAY set
* Connected to www.mediapart.fr (72.19.3.133) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: OU=Domain Control Validated; OU=Gandi Standard Wildcard SSL; CN=*.mediapart.fr
*  start date: Jun 11 00:00:00 2019 GMT
*  expire date: Jun 11 23:59:59 2021 GMT
*  subjectAltName: host "www.mediapart.fr" matched cert's "*.mediapart.fr"
*  issuer: C=FR; ST=Paris; L=Paris; O=Gandi; CN=Gandi Standard SSL CA 2
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fcbc5005000)
> HEAD / HTTP/2
> Host: www.mediapart.fr
> User-Agent: curl/7.64.1
> Accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS == 4294967295)!
< HTTP/2 200 
HTTP/2 200 
< server: envoy
server: envoy
< date: Fri, 17 Jan 2020 17:49:55 GMT
date: Fri, 17 Jan 2020 17:49:55 GMT
< content-type: text/html; charset=UTF-8
content-type: text/html; charset=UTF-8
< vary: Accept-Encoding,Accept-Encoding
vary: Accept-Encoding,Accept-Encoding
< cache-control: public, s-maxage=14400
cache-control: public, s-maxage=14400
< x-content-type-options: nosniff
x-content-type-options: nosniff
< x-frame-options: ALLOW-FROM https://moncompte.mediapart.fr
x-frame-options: ALLOW-FROM https://moncompte.mediapart.fr
< x-xss-protection: 1
x-xss-protection: 1
< age: 3375
age: 3375
< x-ua-compatible: IE=Edge
x-ua-compatible: IE=Edge
< access-control-allow-origin: *
access-control-allow-origin: *
< strict-transport-security: max-age=31536000; includeSubDomains;preload
strict-transport-security: max-age=31536000; includeSubDomains;preload
< datacenter: ny8.nyc
datacenter: ny8.nyc
< x-envoy-upstream-service-time: 93
x-envoy-upstream-service-time: 93

< 
* Connection #0 to host www.mediapart.fr left intact
* Closing connection 0
curl -v --resolve  https://www.mediapart.fr/ -I  0.02s user 0.01s system 7% cpu 0.370 total

Note: To delete the configuration, execute the terraform destroy -var-file=<PATH_TO_VARIABLES_FILE> command.

Configure Volterra AppProtect from VoltConsole

Log in to the VoltConsole with your tenant credentials and perform the following:

Create BGP ASN Set

You can create BGP Autonomous System Number (ASN) sets and apply them later in the service policies to allow or reject traffic from the BGP AS sets. Perform the following to create a BGP ASN set.

Step 1: Change to your namespace and select Security from the configuration menu and BGP ASN Sets. Click Add BGP ASN set to open BGP ASN set configuration form.

ASNSet
Figure: BGP ASN Set Creation

Step 2: Click Add as number in the AS Numbers field and enter the ASNs. Click Add BGP ASN set after adding all the intended ASNs.

Note: You can add multiple ASNs by clicking Add as number for each ASN.


Create IP Prefix Sets

You can create prefix sets for IP address ranges and apply them later in the service or network policies to allow(white listing) or reject(block listing) traffic from them. Perform the following to create IP prefix set:

Step 1: Change to your namespace and select Security from the configuration menu and IP Prefix Sets. Click Add IP prefix set to open IP prefix set configuration form.

ASNSet
Figure: IP Prefix Set Creation

Step 2: Click Add prefix in the Prefix field and enter the prefix in the network-prefix/subnetmask format. Click Add IP prefix set after adding all the intended prefixes.

Note: You can add multiple prefixes using the Add prefix option for each prefix.


Create Service Policies

You can create a service policy for your application in order to control your application traffic. The Volterra AppProtect solution requires you to configure service policies with traffic filtering based on conditions such as ASNs, user-agents, URLs, and IP addresses.

Volterra supports creating one or more service policy rules and attaching them to service policy. You can also create one or more service policies and attach them into a service policy set. For more information on service policy configuration, see Configure a Service Policy.

Create Service Policies for Incoming Requests

Perform the following to configure service policy for incoming requests from specific BGP ASNs and IP addresses:

Step 1: Change to your namespace and create service a policy rule from the Security -> Service Policies option. Enter name for the rule and set action as Allow for allowing traffic or Deny for blocking. Click AS Matcher to open the AS matcher configuration form.

PolRule
Figure: Service Policy Rule AS Matcher

Step 2: Click Select asn set and select a BGP ASN set from the displayed list. Click Select asn set and click Apply.

PolRuleASN
Figure: Service Policy Rule BGP ASN Set

Note: Use the BGP ASN set created in the Create BGP ASN Set chapter.

Step 3: Click IP Prefix Matcher to open prefix matcher configuration form. Click Select prefix set and select a prefix set from the displayed list. Click Select prefix set and click Apply.

PolRule
Figure: Service Policy Rule IP Prefix Matcher

PolRulePrefix
Figure: Service Policy Rule Prefix Set

Note: Use the IP prefix set created in the Create IP Prefix Sets chapter.

Step 4: Click Add service policy rule to create the policy rule.

Step 5: Create a service policy rule with action opposite to that of the previous rule. Apply ASN set and prefix sets accordingly.

Step 6: Create a service policy using the Add service policy option and enter the name. In the Rules field, click Select rule to apply the rules created in Step 4 and Step 5. Click Add service policy to complete creating the service policy.

Create Service Policies for Outgoing Requests

You can control the requests towards specific websites using URL filtering or using the user-agents. Perform the following to configure service policy for outgoing requests.

Step 1: Create two service policy rules with the actions as Allow and Deny respectively.

Step 2: Create a service policy rules with the actions as Allow.

Step 3: Open another service policy rule creation form, enter the name, and set the action as Deny. Click Add header in the HTTP Headers field and enter the configuration as per the following guidelines:

  • Enter user-agent for the Header name field.
  • Select Match Values for the Match Options field.
  • Click Add exact value and enter a user agent string.

Click Add header and Add service policy rule to complete creating the service policy rule.

Step 4: Create a service policy using the Add service policy option and enter the name. In the Rules field, click Select rule to apply the rule where the Allow action is configured.

Step 5: Click Server Name Matcher field to open the server name matcher form. Click Add exact value and enter the URLs of the websites to which you want to allow the access. Click Apply and Add service policy to complete creating the policy.

Step 6: Create a service policy using the Add service policy option and enter the name. In the Rules field, click Select rule to apply the rule where the Deny action is configured.

Step 7: Click Server Name Matcher field to open the server name matcher form. Click Add exact value and enter *. Click Apply and Add service policy to complete creating the policy.

Step 8: Create a service policy and first attach the rule with the Deny action created in Step 3. Then attach the rule with the Allow action created in Step 2. Click Add service policy to complete creating the service policy.

Note: Ensure that you first attach the rule with the Deny action as the service policy by default is enabled with the First Rule Match as the rule combining algorithm.

Create Service Policy Sets

You can combine one or more service policies into a service policy set. Perform the following to configure service policy set.

Step 1: Select Service Policy Sets and click Add service policy set to open policy set configuration form. Configure name and labels as per your requirement.

Step 2: Click Select policy and select the policies configured in previous chapters to combine them into the policy set. Click Select policy and Add service policy set to complete creating the service policy set.


Create Network Policies

You can also create network policy to control traffic using the created IP prefix sets. Similar to service policy, network policy also requires you to create policy rules. For more information, see Configure a Network Policy.

Perform the following to configure network policy:

Step 1: Select Security -> Network Policies and click Add network policy rule to open network policy rule configuration form. Configure name and set labels as per your requirement.

Step 2: Select action as Allow or Deny depending on your requirement and select IP prefix set for the Remote Endpoint field.

Step 3: Click Select ref in the Reference field and select the IP prefix set created in the Create IP Prefix Sets chapter. Click Select ref and Add network policy rule to complete creating the network policy rule.

Step 4: Click Add network policy to open network policy creation form. Configure name and set labels as per your requirement.

Step 5: Select Prefix or Prefix selector for the Local Endpoint field and set the corresponding prefix or label expression using Add prefix or Selector expression respectively.

Step 6: Click Select ingress rule and apply the created policy rule. Click Select ingress rule and Add network policy to complete creation of the network policy.

Note: You can also create another IP prefix set and create a rule with action opposite to that of the current rule and attach that rule as the egress rule in the network policy.

Step 7: Optionally, create a network policy set using the Add network policy set option. Configure name and set the labels as per your requirement. Click Select policy and apply the policy created in Step 6. Click Select policy and Add network policy to complete creating the policy set.


Create Fast ACLs


Create Objects Required for Virtual Hosts

Securing and accelerating applications require you to apply AppProtect functionalities to your applications through virtual hosts. It is required to create a minimum of 2 virtual hosts for your application with one virtual host of type HTTP proxy and other of type HTTPS proxy. HTTP virtual host configuration is required to include redirection to HTTPS virtual host.

Configuring virtual host requires you to first create endpoints, routes, clusters, and advertise policies. For more information on virtual host concepts, see Virtual Host.

Perform the following to create objects required for virtual hosts:

Step 1: Change to your namespace and select Manage from the configuration menu. Create endpoints, clusters, routes, and advertise policies using the respective options as per the instructions mentioned in the Create and Advertise a Virtual Host document. Ensure that you configure these to support HTTP to HTTPS redirection. For a sample, see the Redirect HTTP to HTTPS example.

vHostComps
Figure: Endpoint, Cluster, Route, and Advertise Policy Configuration

Note: Configure only till advertise policies as instructed in the Redirect HTTP to HTTPS example and not the virtual host. This is because first WAF and other relevant security functionalities are required to be configured before applying them in virtual host configuration.

Step 2: Select Security from the configuration menu and App Firewall from the options. Create a WAF as per the Create WAF example.

WAFObj
Figure: Create WAF

Note: You can also configure WAF for specific events by configuring event type using the Detection Tag field.

Create HTTP Virtual Host

Perform the following to create the HTTP virtual host:

Step 1: Select Manage from the configuration menu and Virtual Hosts from the options. Click Add virtual host and set the proxy type as HTTP Proxy. Configure virtual host for HTTP to HTTPS redirection by applying the HTTP advertise policy and the redirect route created in the Create Objects Required for Virtual Hosts chapter.

vHostHttp
Figure: Virtual Host with HTTP Proxy

Step 2: Select WAF for the WAF Config field and click Select WAF for the WAF field. Select the created WAF object and click Select WAF to associate WAF with virtual host. Click Add virtual host to create the virtual host.

vHostWaf
Figure: Virtual Host WAF Configuration

Create HTTPS Virtual Host

Perform the following to create the HTTPS virtual host:

Step 1: Select Manage from the configuration menu and Virtual Hosts from the options. Click Add virtual host and set the proxy type as HTTPS Proxy.

Step 2: Apply HTTPS advertise policy and direct route configured in the Create Objects Required for Virtual Hosts chapter.

vHostHttps
Figure: Virtual Host with HTTPS Proxy

Note: Do not click Add virtual host to complete creation of virtual host at this Step. The next chapters provide list of instructions on configuring the App Protect services and only after applying all of those, complete the virtual host creation.

Configure TLS and WAF

Perform the following steps to configure TLS parameters and apply cipher suites:

Step 1: Click TLS Parameters field and open the TLS parameters configuration form.

VHTls
Figure: Virtual Host TLS Parameters

Step 2: Click Add TLS certificate and add the URL path to the certificate. Click Private key to open the private key configuration form. Select one of the options for the Secret Info field and set the rest of the fields as per the selected option.

VHTlsCert
Figure: Virtual Host TLS Certificate and Private Key

Refer to the following guidelines while setting the private key configuration fields:

  • See Blindfold for instructions on how to encrypt the private key using Volterra Blindfold.
  • See Vault for instructions on how to encrypt private key using Hashicorp Vault.
  • See Wingman for instructions on how to encrypt private key using Volterra Wingman. This is applicable if you select the Bootstrap Secret option.
  • Do not select Clear Secret option as it does not encrypt the private key.

Step 3: Click Apply and Add TLS certificate to add the TLS certificate with encrypted private key.

Step 4: Enter the URL for the Trusted CA field and set minimum and maximum TLS versions as per your choice. Click Cipher Suites and Add cipher suite. Enter cipher suites of your choice.

VHTlsCiph
Figure: Virtual Host TLS Cipher Suites

Note: For more information on cipher suites, see https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#Cipher-suite-configuration.

Step 5: Check the Require Client Certificate(enable mTLS) option and click Apply.

Step 6: Select WAF for the WAF Config field and click Select WAF for the WAF field. Select the created WAF object and click Select WAF to associate WAF with virtual host.

vHostWaf
Figure: Virtual Host WAF Configuration

Note: Do not click Add virtual host to complete creation of virtual host at this Step. The next chapters provide list of instructions on configuring the rest of the App Protect services and only after applying those, complete the virtual host creation.


Configure HTTP Header Processing

You can also configure to add or remove specific headers for HTTP request as well as HTTP response.

Step 1: Click Request headers to add field to open the request headers to add form. Click Add request headers to add and enter the header name and value. This example shows a sample header cookie with value as ingress123. Click Apply.

ReqHeadAdd
Figure: Virtual Host Request Header to Add

Step 2: Click Request headers to remove field to open the request headers to remove form. Click Add request headers to remove and enter the header name and value. This example shows removing of a header accept.

ReqHeadRem
Figure: Virtual Host Request Header to Remove

Step 3: Click Add request headers to remove and enter values as x-forwarded-for. This preserves the requester's original IP address by removing the x-forwarded-for header. Click Apply.

PreserveOriginIP
Figure: Preserve Original IP Address of HTTP Requester

Note: The Volterra proxy adds x-forwarded-for header by default for all requests.

Step 4: Click Response headers to add field to open the response headers to add form. Click Add response headers to add and enter the header name and value. This example shows a sample header cookie with value as Test1234567.

ResHeadAdd
Figure: Virtual Host Response Header to Add

Step 5: Click Add response headers to add and set the HTTP Strict Transport Security (HSTS) by adding the Strict-Transport-Security response header. Enter the value as max-age=31536000. Click Apply.

HSTS
Figure: Configure HSTS

Step 6: Click Response headers to remove field to open the response headers to remove form. Click Add response headers to remove and enter the header name and value. This example shows removing of a header content-length. Click Apply.

ReqHeadRem
Figure: Virtual Host Response Header to Remove

Step 7: Set a value for the Maximum Request Header Size field to limit the allowed maximum size of the header in the request. The maximum value allowed is 96 KiB and default is 60 KiB.

MaxReqHead
Figure: Maximum Allowed Size for the Request Header

Note: Do not click Add virtual host to complete creation of virtual host at this Step. The next chapters provide list of instructions on configuring the rest of the App Protect services and only after applying those, complete the virtual host creation.


Configure Cross-Origin Resource Sharing (CORS)

You can control Cross-Origin Resource Sharing (CORS) by configuring a CORS policy. Perform the following steps to apply a CORS policy on the virtual host.

Step 1: Click CORS Policy to open the CORS policy configuration form. Click Add allow origin and enter the origin server domain name.

Note: You can also use regular expression pattern to match an origin by configuring the Add allow origin regex field.

Step 2: Configure the policy fields as per the following guidelines:

  • Enter supported methods for the Allow Methods field. This example uses GET, POST, and OPTIONS.
  • Enter headers for the Allow Headers field. This example allows the cookie headers.
  • Enter headers for the Expose Headers1 field. This example exposes the Content-Type headers.
  • Enter a value for the Max Age field. This example sets maximum age for the header as 86400 seconds.

vHostCORS
Figure: Virtual Host CORS Policy

Step 3: Select the Allow Credentials field and click Apply.

Step 4: Click Add virtual host to complete creation of the virtual host.


Configure HTTP/2 Support

You can enable HTTP/2 support by the following 2 ways:

  • Configure the virtual host Proxy Type field as TCP Proxy with SNI.
  • Enable HTTP/2 for the cluster object associated with the virtual host.

Configure Virtual Host of Type TCP Proxy with SNI

Step 1: Create endpoint, route, and cluster as per the instructions mentioned in the Create and Advertise a Virtual Host document.

Step 2: Create a HTTPS advertise policy as per the instructions mentioned in the Create and Advertise a Virtual Host document. Ensure that you set the port to 443.

Step 3: Create a virtual host with the Proxy Type field set as TCP Proxy with SNI. Enter a domain and apply the route and advertise policy created in Step 1 and Step 2. Configure TLS parameters and click Add virtual host to create the virtual host.

Enable HTTP/2 for Cluster

Step 1: Navigate to your namespace and select Manage from the configuration menu and Clusters from the options. Find your cluster and click ... -> Edit to open the cluster object edit form.

Step 2: Select the Enabled field and click Save Changes.


Configure Websocket Support

You can also enable websocket communication for your application. However, this is optional and dependent on your requirement. Perform the following to enable websocket communication:

Step 1: Change to your namespace. Select Manage from the configuration menu and Routes from the options. Find the route that is associated with your virtual host and click ... -> Edit.

Step 2: Click ... -> Edit against your route in the Routes field to edit your route. Click Websocket Configuration to open websocket configuration form.

RouteWS
Figure: Websocket Configuration

Step 3: Select the Use Websocket checkbox and click Apply to return to the Routes configuration form. Click Apply to return to the edit route form and click Save changes.

EnWS
Figure: Enable Websocket Communication

Note: You can also configure Idle Timeout and Maximum Connection Attempts for finer control over the websocket communication. The default value for maximum number of connection attempts is 1.


Configure OCSP Stapling

System provides support for OCSP stapling and OCSP must stapling. It is required that you configure virtual host or advertise policy with TLS certificates with OCSP support. The clients require to generate certificates with OCSP support and the requests must include the same.

Note: You must obtain a CA-signed certificate with support for OCSP. Self-signed certificates are not supported for OCSP staling.

Perform the following to enable OCSP stapling:

Step 1: Create a TLS configuration file with the CN and DNS entries pointing to your CA domain name. This example shows the sample configuration file tls_config with ocsp-must-2.helloedge.app as the sample domain name.

$ cat tls_config
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[req_distinguished_name]
CN = ocsp-must-2.helloedge.app
[v3_req]
keyUsage = keyEncipherment, digitalSignature
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
tlsfeature = status_request
[alt_names]
DNS.1 = ocsp-must-2.helloedge.app

Step 2: Create a Certificate Signing Request (CSR) with the OCSP Must-Staple extension.

$ openssl req -new -out out.csr -newkey rsa:2048 -nodes -sha256 -keyout out.key -config tls_config

Step 3: Request and obtain a certificate from the CA. This example shows a sample request from the Let's Encrypt CA.

$ sudo certbot certonly --register-unsafely-without-email --manual --preferred-challenges dns --must-staple --csr out.csr -d ocsp-must-2.helloedge.app

Step 4: Verify that the certificate is enabled with OCSP support.

Check for the method from the command line:

$ openssl x509 -in <cert-name>.crt -noout -text

Import and view the certificate from browser:

OCSPchk
Figure: OCSP Enabled CA-Signed Certificate

Step 5: Configure a virtual host with HTTPS proxy and apply TLS certificates with OCSP support.


Configure Volterra AppProtect for Network Cloud Applications


Concepts


API References