Skip to main content

Insecure Network Communication

Securing TLS configuration​

About Insecure TLS Configuration

What is insecure TLS configuration?​

Insecure TLS (Transport Layer Security) configuration refers to the use of weak or vulnerable cryptographic algorithms or protocols in the configuration of TLS on a system or application.

TLS is used to secure communication channels between clients and servers. Insecure TLS configuration can lead to a range of security vulnerabilities.

Check out these videos for a high-level explanation:

  • Weak Algorithms

  • Weak Cipher Suites

What is the impact of insecure TLS configuration?​

Insecure TLS (Transport Layer Security) configuration can have significant impacts on the security and privacy of communication channels between clients and servers.

Here are some of the potential impacts:

  • Man-in-the-middle (MITM) attacks: Weak or outdated cryptographic algorithms can be exploited by attackers to intercept and modify data in transit between a client and server. This can enable attackers to steal sensitive data or manipulate communication channels to launch other attacks.
  • Information disclosure: Insecure TLS configuration can allow attackers to gain access to sensitive data, such as login credentials or personal information, transmitted between the client and server. This can lead to data breaches or compromise of sensitive information.

How to prevent insecure TLS configuration?​

To prevent insecure TLS (Transport Layer Security) configuration, several measures can be taken, including:

  • Use strong cryptographic algorithms and protocols: Use strong cryptographic algorithms and protocols, such as TLS 1.2 or higher, and disable outdated or weak algorithms, such as SSLv2 and SSLv3. This can help prevent attackers from exploiting vulnerabilities in the encryption and authentication processes.
  • Use appropriate key sizes: Use appropriate key sizes to ensure that the cryptographic keys used in the TLS communication are strong enough to resist attacks. Key sizes of 2048 bits or higher are recommended.
  • Regularly update software and systems: Regularly update software and systems to ensure that the latest security patches are applied and known vulnerabilities are addressed.

References​

Taxonomies​

Explanation & Prevention​

Training​

Option A: Don't share the host network namespace​

Sharing the host's network namespace permits processes in the pod to communicate with processes bound to the host's loopback adapter, which could expose internal services to attackers.

Solution-specific references:

  1. Go through the issues that GuardRails identified in the PR/MR

  2. Look for code like this:

    apiVersion: policy/v1beta1
    kind: PodSecurityPolicy
    metadata:
      name: host-network
    spec:
      hostNetwork: true

  3. Replace the line containing hostNetwork: true with:

    spec:
      hostNetwork: false

  4. Test it

  5. Ship it 🚢 and relax 🌴

Option B: Don't use hostAliases to manage DNS entries​

Managing /etc/hosts aliases can prevent the container from modifying the file after a pod's containers have already been started. DNS should be managed by the orchestrator and not via /etc/hosts entries.

Solution-specific references:

  1. Go through the issues that GuardRails identified in the PR/MR

  2. Look for code like this:

    apiVersion: v1
    kind: Pod
    metadata:
      name: hostaliases-pod
    spec:
      restartPolicy: Never
      hostAliases:
      - ip: "127.0.0.1"
        hostnames:
        - "foo.local"
        - "bar.local"

  3. Remove the hostAliases from the spec:

    apiVersion: v1
    kind: Pod
    metadata:
      name: hostaliases-pod
    spec:
      restartPolicy: Never

  4. Test it

  5. Ship it 🚢 and relax 🌴

Last updated on by Stefan Streichsbier