DO280 - ch04s02

Bookmark this page

Guided Exercise: Protect External Traffic with TLS

Expose an application that is secured by TLS certificates.

Outcomes

Deploy an application and create an unencrypted route for it.
Create an OpenShift edge route with encryption.
Update an OpenShift deployment to support a new version of the application.
Create an OpenShift TLS secret and mount it to your application.
Verify that the communication to the application is encrypted.

As the student user on the workstation machine, use the lab command to prepare your system for this exercise.

The command ensures that the cluster API is reachable, and creates the network-ingress OpenShift project. The command also gives the developer user edit access on the project.

[student@workstation ~]$ lab start network-ingress

Instructions

As an application developer, you are ready to deploy your application in OpenShift. In this activity, you deploy two versions of the application: one that is exposed over unencrypted traffic (HTTP), and one that is exposed over secure traffic (HTTPS).

The container image, which is accessible at https://registry.ocp4.example.com:8443/redhattraining/todo-angular, has two tags: v1.1, which is the insecure version of the application, and v1.2, which is the secure version. Your organization uses its own certificate authority (CA) that can sign certificates for the following domains:

*.apps.ocp4.example.com
*.ocp4.example.com

The CA certificate is accessible at ~/DO280/labs/network-ingress/certs/training-CA.pem. The passphrase.txt file contains a unique password that protects the CA key. The certs directory also contains the CA key.

[student@workstation ~]$ oc login -u developer -p developer \
    https://api.ocp4.example.com:6443
Login successful.

...output omitted...

Create the network-ingress project.

[student@workstation ~]$ oc new-project network-ingress
Now using project "network-ingress" on server "https://api.ocp4.example.com:6443".

...output omitted...

The OpenShift deployment file for the application is accessible at ~/DO280/labs/network-ingress/todo-app-v1.yaml. The deployment points to registry.ocp4.example.com:8443/redhattraining/todo-angular:v1.1, which is the initial and unencrypted version of the application. The file defines the todo-http service that points to the application pod.
Create the application and expose the service.
1. Use the oc create command to deploy the application in the network-ingress OpenShift project.
```
[student@workstation ~]$ oc create -f \
    ~/DO280/labs/network-ingress/todo-app-v1.yaml
deployment.apps/todo-http created
service/todo-http created
```
2. Wait a few minutes, so that the application can start, and then review the resources in the project.
```
[student@workstation ~]$ oc status
...output omitted...
In project network-ingress on server https://api.ocp4.example.com:6443

svc/todo-http - 172.30.247.75:80 -> 8080
  deployment/todo-http deploys registry.ocp4.example.com:8443/redhattraining/todo-angular:v1.1
    deployment #1 running for 16 seconds - 1 pod
...output omitted...
```
3. Run the oc expose command to create a route for accessing the application. Give the route a hostname of todo-http.apps.ocp4.example.com.
```
[student@workstation ~]$ oc expose svc todo-http \
    --hostname todo-http.apps.ocp4.example.com
route.route.openshift.io/todo-http exposed
```
4. Retrieve the name of the route and copy it to the clipboard.
```
[student@workstation ~]$ oc get routes
NAME        HOST/PORT                         PATH   SERVICES    PORT   ...
todo-http   todo-http.apps.ocp4.example.com          todo-http   8080   ...
```
5. On the workstation machine, open Firefox and access the application URL. Confirm that you can see the application.
  - http://todo-http.apps.ocp4.example.com
6. Open a new terminal tab and run the tcpdump command with the following options to intercept the traffic on port 80:
  - -i eth0 intercepts traffic on the main interface.
  - -A strips the headers and prints the packets in ASCII format.
  - -n disables DNS resolution.
  - port 80 is the port of the application.
    Optionally, use the grep command to filter on JavaScript resources.
    Start by retrieving the name of the main interface, whose IP is 172.25.250.9.
```
[student@workstation ~]$ ip addr | grep 172.25.250.9
inet 172.25.250.9/24 brd 172.25.250.255 scope global noprefixroute eth0

[student@workstation ~]$ sudo tcpdump -i eth0 -A -n port 80 | grep "angular"
```
    Note
    The full command is available at ~/DO280/labs/network-ingress/tcpdump-command.txt.
7. On Firefox, refresh the page and notice the activity in the terminal. Press Ctrl+C to stop the capture.
```
...output omitted...
<script type="text/javascript" src="assets/js/libs/angular/angular.min.js">
<script type="text/javascript" src="assets/js/libs/angular/angular-route.min.js">
<script type="text/javascript" src="assets/js/libs/angular/angular-animate.min.js">
...output omitted...
```
Create a secure edge route. Edge certificates encrypt the traffic between the client and the router, but leave the traffic between the router and the service unencrypted. OpenShift generates its own certificate that it signs with its CA.
In later steps, you extract the CA to ensure that the route certificate is signed.
1. Go to ~/DO280/labs/network-ingress and run the oc create route command to define the new route.
  Give the route a hostname of todo-https.apps.ocp4.example.com.
```
[student@workstation ~]$ cd ~/DO280/labs/network-ingress
[student@workstation network-ingress]$ oc create route edge todo-https \
    --service todo-http \
    --hostname todo-https.apps.ocp4.example.com
route.route.openshift.io/todo-https created
```
2. To test the route and read the certificate, open Firefox and access the application URL.
  - https://todo-https.apps.ocp4.example.com
    Click the padlock, and then click the arrow next to Connection secure.
    Firefox displays a message that the connection is verified by a certificate issuer that Mozilla does not recognize. This message is displayed because the route signed certificate comes from an internal CA that is installed on the classroom OS. This CA, although not recognized by Mozilla, is valid for the lab environment purposes. If your organization uses a custom public key infrastructure (PKI), then you might see the same message.
    Click More Information to display the page information window.
    Click View Certificate to display the certificate information.
    Locate the CN entry to see that the OpenShift ingress operator created the certificate with its own CA.
3. From the terminal, use the curl command with the -I and -v options to retrieve the connection headers.
  The Server certificate section shows some information about the certificate. The alternative name matches the name of the route. The output indicates that the remote certificate is trusted because it matches the CA.
```
[student@workstation network-ingress]$ curl -I -v \
    https://todo-https.apps.ocp4.example.com
...output omitted...
* Server certificate:
*  subject: O=EXAMPLE.COM; CN=.api.ocp4.example.com
*  start date: May 10 11:18:41 2021 GMT
*  expire date: May 10 11:18:41 2026 GMT
*  subjectAltName: host "todo-https.apps.ocp4.example.com" matched cert's "*.apps.ocp4.example.com"
*  issuer: O=EXAMPLE.COM; CN=Red Hat Training Certificate Authority
*  SSL certificate verify ok.
...output omitted...
```
4. Although the traffic is encrypted at the edge with a certificate, you can still access the insecure traffic at the service level, because the pod behind the service does not offer an encrypted route.
  Retrieve the IP address of the todo-http service.
```
[student@workstation network-ingress]$ oc get svc todo-http \
    -o jsonpath="{.spec.clusterIP}{'\n'}"
172.30.102.29
```
5. Create a debug pod in the todo-http deployment. Use the Red Hat Universal Base Image (UBI), which contains tools to interact with containers.
```
[student@workstation network-ingress]$ oc debug -t deployment/todo-http \
    --image registry.ocp4.example.com:8443/ubi8/ubi:8.4
Starting pod/todo-http-debug ...
Pod IP: 10.131.0.255
If you don't see a command prompt, try pressing enter.
sh-4.4$
```
6. From the debug pod, use the curl command to access the service over HTTP. Replace the IP address with the one that you obtained in a previous step.
  The output indicates that the application is available over HTTP.
```
sh-4.4$ curl -v 172.30.102.29
* Rebuilt URL to: 172.30.102.29/
*   Trying 172.30.102.29...
* TCP_NODELAY set
* Connected to 172.30.102.29 (172.30.102.29) port 80 (#0)
> GET / HTTP/1.1
> Host: 172.30.102.29
> User-Agent: curl/7.61.1
> Accept: */*
>
< HTTP/1.1 200 OK
...output omitted...
```
7. Exit the debug pod.
```
sh-4.4$ exit
Removing debug pod ...
```
8. Delete the edge route. In the following steps, you define the passthrough route.
```
[student@workstation network-ingress]$ oc delete route todo-https
route.route.openshift.io "todo-https" deleted
```

Generate TLS certificates for the application.

In the following steps, you generate a CA-signed certificate that you attach as a secret to the pod. You then configure a secure route in passthrough mode and let the application expose that certificate.

Go to the ~/DO280/labs/network-ingress/certs directory and list the files.

[student@workstation network-ingress]$ cd certs
[student@workstation certs]$ ls -l
total 20
-rw-rw-r--. 1 student student  604 Nov 29 17:35 openssl-commands.txt
-rw-r--r--. 1 student student   33 Nov 29 17:35 passphrase.txt
-rw-r--r--. 1 student student 1743 Nov 29 17:35 training-CA.key
-rw-r--r--. 1 student student 1363 Nov 29 17:35 training-CA.pem
-rw-r--r--. 1 student student  406 Nov 29 17:35 training.ext

Generate the private key for your CA-signed certificate.
Note
The following commands for generating a signed certificate are all available in the ~/DO280/labs/network-ingress/certs/openssl-commands.txt file.
```
[student@workstation certs]$ openssl genrsa -out training.key 4096
```
Generate the certificate signing request (CSR) for the todo-https.apps.ocp4.example.com hostname.
```
[student@workstation certs]$ openssl req -new \
    -key training.key -out training.csr \
    -subj "/C=US/ST=North Carolina/L=Raleigh/O=Red Hat/\
    CN=todo-https.apps.ocp4.example.com"
```
Warning
Type the request subject on one line. Alternatively, remove the -subj option and its content. Without the -subj option, the openssl command prompts you for the values; indicate a common name (CN) of todo-https.apps.ocp4.example.com.

Finally, generate the signed certificate. Notice the use of the -CA and -CAkey options for signing the certificate against the CA. Use the -passin option to reuse the password of the CA. Use the extfile option to define a Subject Alternative Name (SAN).

[student@workstation certs]$ openssl x509 -req -in training.csr \
    -passin file:passphrase.txt \
    -CA training-CA.pem -CAkey training-CA.key -CAcreateserial \
    -out training.crt -days 1825 -sha256 -extfile training.ext
Certificate request self-signature ok
subject=C = US, ST = North Carolina, L = Raleigh, O = Red Hat, CN = todo-https.apps.ocp4.example.com

Ensure that the newly created certificate and key are present in the current directory.

[student@workstation certs]$ ls -lrt
total 36
-rw-r--r--. 1 student student  599 Jul 31 09:35 openssl-commands.txt
-rw-r--r--. 1 student student   33 Aug  3 12:38 passphrase.txt
-rw-r--r--. 1 student student  352 Aug  3 12:38 training.ext
-rw-------. 1 student student 1743 Aug  3 12:38 training-CA.key
-rw-r--r--. 1 student student 1334 Aug  3 12:38 training-CA.pem
-rw-------. 1 student student 1675 Aug  3 13:38 training.key
-rw-rw-r--. 1 student student 1017 Aug  3 13:39 training.csr
-rw-rw-r--. 1 student student   41 Aug  3 13:40 training-CA.srl
-rw-rw-r--. 1 student student 1399 Aug  3 13:40 training.crt

Return to the network-ingress directory. This step is important, because the next step involves creating a route that uses the self-signed certificate.
```
[student@workstation certs]$ cd ~/DO280/labs/network-ingress
```

Deploy a new version of your application.
The new version of the application expects a certificate and a key inside the container at /usr/local/etc/ssl/certs. The web server in that version is configured with SSL support. Create a secret to import the certificate from the workstation machine. In a later step, the application deployment requests that secret and exposes its content to the container at /usr/local/etc/ssl/certs.
1. Create a tls OpenShift secret named todo-certs. Use the --cert and --key options to embed the TLS certificates. Use training.crt as the certificate, and training.key as the key.
```
[student@workstation network-ingress]$ oc create secret tls todo-certs \
    --cert certs/training.crt --key certs/training.key
secret/todo-certs created
```
2. The deployment file at ~/DO280/labs/network-ingress/todo-app-v2.yaml points to version 2 of the container image. Examine how the new version of the application is configured to support SSL certificates.
```
[student@workstation network-ingress]$ cat todo-app-v2.yaml
apiVersion: apps/v1
kind: Deployment
...output omitted...
        volumeMounts:
        - name: tls-certs
          readOnly: true
          mountPath: /usr/local/etc/ssl/certs
...output omitted...
      volumes:
      - name: tls-certs
        secret:
          secretName: todo-certs
---
apiVersion: v1
kind: Service
...output omitted...
  ports:
  - name: https
    port: 8443
    protocol: TCP
    targetPort: 8443
...output omitted...
```
  The todo-certs secret with the SSL certificate is mounted in the container in the /usr/local/etc/ssl/certs directory to enable TLS for the application. Additionally, the todo-app-v2 deployment changes the service to include port 8443.
3. Run the oc create command to create a deployment that uses that image.
```
[student@workstation network-ingress]$ oc create -f todo-app-v2.yaml
deployment.apps/todo-https created
service/todo-https created
```
4. Wait a couple of minutes to ensure that the application pod is running. Use the oc set volumes command to review the volumes that are mounted inside the pod.
```
[student@workstation network-ingress]$ oc set volumes deployment/todo-https
 todo-https
  secret/todo-certs as tls-certs
    mounted at /usr/local/etc/ssl/certs
```

Create the secure route.

Run the oc create route command to define the new route.

Give the route a hostname of todo-https.apps.ocp4.example.com.

[student@workstation network-ingress]$ oc create route passthrough todo-https \
    --service todo-https --port 8443 \
    --hostname todo-https.apps.ocp4.example.com
route.route.openshift.io/todo-https created

Use the curl command in verbose mode to test the route and to read the certificate. Use the --cacert option to pass the CA certificate to the curl command.

The output indicates a match between the certificate chain and the application certificate. This match indicates that the OpenShift router forwards only packets that are encrypted by the application web server certificate.

[student@workstation network-ingress]$ curl -vv -I \
    --cacert certs/training-CA.pem \
    https://todo-https.apps.ocp4.example.com
...output omitted...
* Server certificate:
*  subject: C=US; ST=North Carolina; L=Raleigh; O=Red Hat; CN=todo-https.apps.ocp4.example.com
*  start date: Jun 15 01:53:30 2021 GMT
*  expire date: Jun 14 01:53:30 2026 GMT
*  subjectAltName: host "todo-https.apps.ocp4.example.com" matched cert's "*.apps.ocp4.example.com"
*  issuer: C=US; ST=North Carolina; L=Raleigh; O=Red Hat; CN=ocp4.example.com
*  SSL certificate verify ok.
...output omitted...

Create a debug pod to further confirm proper encryption at the service level.

Retrieve the IP address of the todo-https service.

[student@workstation network-ingress]$ oc get svc todo-https \
    -o jsonpath="{.spec.clusterIP}{'\n'}"
172.30.121.154

Create a debug pod in the todo-https deployment with the Red Hat UBI container image.

[student@workstation network-ingress]$ oc debug -t deployment/todo-https \
    --image registry.ocp4.example.com:8443/ubi8/ubi:8.4
Starting pod/todo-https-debug ...
Pod IP: 10.128.2.129
If you don't see a command prompt, try pressing enter.
sh-4.4$

From the debug pod, use the curl command to access the service over HTTP. Replace the IP address with the one that you obtained in a previous step.
The output indicates that the application is not available over HTTP, and the web server redirects you to the secure version.
```
sh-4.4$ curl -I http://172.30.121.154
HTTP/1.1 301 Moved Permanently
Server: nginx/1.14.1
Date: Tue, 15 Jun 2021 02:01:19 GMT
Content-Type: text/html
Connection: keep-alive
Location: https://172.30.121.154:8443/
```

Finally, access the application over HTTPS. Use the -k option, because the container does not have access to the CA certificate.

sh-4.4$ curl -s -k https://172.30.121.154:8443 | head -n5
<!DOCTYPE html>
<html lang="en" ng-app="todoItemsApp" ng-controller="appCtl">
<head>
    <meta charset="utf-8">
    <title>ToDo app</title>

Exit the debug pod.
```
sh-4.4$ exit
Removing debug pod ...
```

Clean up the exercise directory and project.

Change to the home directory.

[student@workstation network-ingress]$ cd

Delete the network-ingress project.

[student@workstation ~]$ oc delete project network-ingress
project.project.openshift.io "network-ingress" deleted

Finish

On the workstation machine, use the lab command to complete this exercise. This step is important to ensure that resources from previous exercises do not impact upcoming exercises.

[student@workstation ~]$ lab finish network-ingress

Discuss Red Hat OpenShift Administration II: Configuring a Production Cluster

Go to community

Red Hat OpenShift Administration II: Operating a Production Kubernetes Cluster (DO280)

Haley_Ruccio

26 lip 2023

Configure, manage, and troubleshoot OpenShift clusters and containerized applicationsRed Hat OpenShift Administration II: Operating a Production Kubernetes Cluster (DO280) prepares OpenShift Cluster Administrators to perform daily administration tasks on clusters that host applications provided by internal teams and external vendors, enable self-service for cluster users with different roles, and deploy applications that require special permissions such as such as CI/CD tooling, performance monitoring, and security scanners. This course focuses on configuring multi-tenancy and security features of OpenShift as well as managing OpenShift add-ons based on operators.The skills you learn in this course can be applied using all versions of OpenShift, including Red Hat OpenShift on AWS (ROSA), Azure Red Hat OpenShift, and OpenShift Container Platform.This course is based on OpenShift Container Platform 4.12.5-10 Course TopicsDeploying packaged applications using manifests, templates, kustomize, and helm.Configuring authentication and authorization for users and applications.Protecting network traffic with network policies and exposing applications with proper network access.Deploying and managing applications using resources manifests.Enabling developer self-service of application projects.Managing OpenShift cluster updates and Kubernetes operator updates.Target AudienceSystem Administrators and Platform Operators interested in the ongoing management of OpenShift clusters, applications, users, and add-ons.Site Reliability Engineers interested in the ongoing maintenance and troubleshooting of Kubernetes clusters.System and Software Architects interested in understanding the security of an OpenShift cluster.Recommended TrainingTake our free assessment to gauge whether this offering is the best fit for your skills.Prerequisite: Red Hat OpenShift I: Containers & Kubernetes (DO180 v4.12), or equivalent skills deploying and managing Kubernetes applications using the OpenShift web console and command-line interfaces.Technology considerationsThis course requires internet access to access the cloud-based classroom environment that provides an OpenShift cluster and a remote administrator’s workstation.

476

About pod security standards and warnings

alexcorcoles

17 kwi 2023

(This material has been created with the inputs of instructors and other people. We are trying to get this material published as soon as possible to address some concerns with DO180 and DO280.)With the default configuration, any namespace that you create on OpenShift 4.12 has the following labels: pod-security.kubernetes.io/audit: restrictedpod-security.kubernetes.io/audit-version: v1.24pod-security.kubernetes.io/warn: restrictedpod-security.kubernetes.io/warn-version: v1.24 These labels activate auditing and warning of the restricted pod security standard. The Kubernetes documentation describes the restricted pod security standard. Pod security standards such as restricted are not directly related to security context constraints such as the restricted SCC.Kubernetes uses an admission controller to reject pods that do not comply with pod security standards. An admission controller is a Kubernetes component that inspects every Kubernetes resource before its creation, and acts before Kubernetes creates the resource. This action can include rejecting the creation of the resource, or modifying the resource.The pod security standards are policies that include properties that workloads must follow. For example, the restricted standard requires that containers set the securityContext.allowPrivilegeEscalation field to false.Pod security standards apply both to workloads, such as deployments and jobs, and to pods.When a pod is created, the admission controller inspects the container specifications and enumerates the fields that violate the pod security standard of the namespace. The admission controller inspects the pod-security labels in the namespace to decide which pod security standard to apply (restricted, baseline, or privileged), and which action to take on violations. Namespaces can audit, warn, or enforce pod security standard violations. When the pod-security.kubernetes.io/audit annotation is set to restricted, the admission controller prevents the creation of pods that violate the security standard. When the pod-security.kubernetes.io/audit and pod-security.kubernetes.io/warn annotations are defined in the project, the admission controller does not block the creation of pods, but registers audit events or warnings.The admission controller does not enforce pod security standards for workloads. If the namespace is configured to enforce a pod security standard, then you can create a violating workload. The admission controller enforces only pod security policies on pods.Cluster administrators can use pod security standards to ensure that pods and workloads in namespaces limit their privileges. By limiting privileges, cluster administrators can mitigate what malicious pods can do.The default configuration of user namespaces in OpenShift does not restrict any workload; it only notifies users when they create workloads that do not follow pod security standards that might be enforced in future OpenShift versions.Security Context ConstraintsOpenShift introduced security context constraints (SCC) before the introduction of pod security standards in Kubernetes. SCCs automatically make security modifications to pods when they are created. By default, the system:openshift:scc:restricted-v2 cluster role binding applies to all authenticated users, so regular user workloads use the restricted-v2 SCC. For example, when you execute the following command to create a workload without any security configuration, the SCC adds security configuration to the pods: [user@host ~]$ oc create deployment test --image registry.ocp4.example.com:8443/redhattraining/hello-world-nginx (You can add the --dry-run=client -o yaml options to view the deployment manifest. The deployment manifest does not contain the security properties, which are described later.)If you inspect the pods that the deployment created, the SCC makes the following changes: [user@host ~]$ oc get pod test-b8d5658b6-7bxfs -o yamlapiVersion: v1kind: Podmetadata: annotations:... output omitted... openshift.io/scc: restricted-v2 seccomp.security.alpha.kubernetes.io/pod: runtime/default...output omitted...spec: containers: - image: registry.ocp4.example.com:8443/redhattraining/hello-world-nginx imagePullPolicy: Always name: hello-world-nginx resources: {} securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL runAsNonRoot: true runAsUser: 1000690000... output omitted... securityContext: fsGroup: 1000690000 seLinuxOptions: level: s0:c26,c20 seccompProfile: type: RuntimeDefault... output omitted... These restrictions satisfy the restricted pod security policy.The result of these defaults means that when creating a workload (such as a deployment) in a namespace without any customization, the restricted pod security standard applies, but the admission controller only warns and audits. If the workload does not satisfy the pod security standard, then the admission controller allows the workload to be created, but prints a message such as the following warning: Warning: would violate PodSecurity "restricted:v1.24": allowPrivilegeEscalation != false (container "example" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "example" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "database" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "example" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost") However, by default Kubernetes creates the deployment pods with the restricted-v2 SCC, with the restrictions that the previous warning included. Due to the following factors, workloads generate only a warning, and the pod security standard admission controller allows their pods:The pod security standard admission controller never enforces pod security standards on workloads (only on pods).By default, namespaces do not enforce pod security standards on pods.By default, regular workloads create pods by using the restricted-v2 SCC, which satisfies the restricted pod security standard.Even if future versions of OpenShift change the default namespace configuration to enforce the restricted pod security standard, users will continue to be able to create workloads without explicitly declaring the restrictions that the pod security standard requires, because the restricted-v2 SCC will apply such restrictions automatically.You can take the following approaches to handling pod security:For most workloads, the restricted-v2 SCC limits pod privileges adequately. When creating a workload, you receive the warning, but the workload creates pods and works correctly.You can also create your workloads by providing a full specification of the security constraints to apply, without relying on the SCC to provide the configuration. By following this approach, privileges are more explicit, and you have greater control, so you can adjust more precisely the specific privileges that are granted to workloads.When the restricted-v2 SCC and the default restricted pod security standard are not adequate for your workload, because either you require further privileges, or you need further restrictions, you must use an existing SCC, or create a custom SCC, and provide explicit security specifications. You can also adjust the namespace labels to choose a different pod security standard, and decide to audit, log, or enforce the standard.

1473

Welcome to the Red Hat OpenShift Administration II (DO280) group in the Red Hat Learning Community!

Deanna

17 kwi 2023

We are excited to launch a space dedicated to the Red Hat Training course Red Hat OpenShift Administration II: Operating a Production Kubernetes Cluster!To gain the most value from this group - click the "Join Group" button in the upper right hand corner.We encourage group members to collaborate in this group to discuss topics, ask questions, share best practices and tips, provide course feedback, and share their accomplishments as it relates to DO280.Read more about Red Hat OpenShift Administration II here.Thanks!

1334

Revision: do280-4.14-08d11e1

Red Hat OpenShift Administration II: Configuring a Production Cluster

Guided Exercise: Protect External Traffic with TLS

Note

Note

Warning