All data must be sent over an encrypted channel to remain secure:

• Use Transport Layer Security (TLS). TLS is generally referred to as Secure Socket Layer (SSL) because TLS is based on the SSL protocol.

• Refuse any plaintext login or authentication requests.

Secure TLS/SSL communication offered by the application using these steps:

1. Do not support SSLv1, SSLv2, and SSLv3 as they are considered insecure.
2. Provide support for TLSv1.2 and TLSv1.3. TLSv1.3 provides faster speed and enhanced security compared to TLSv1.2.
3. Refuse insecure ciphers. (See the "Choice of cipher" Additional Requirements below this countermeasure for more details about ciphers.)
4. Prevent using ciphers that provide SSL/TLS compression to protect against Crime Attack Vectors that use compression side channels to extract information from encrypted channels.
5. Use the latest version of the SSL library and web servers:

- SSL v1.0, v2.0, and v3.0 are no longer considered secure.
- OpenSSL is an open-source, commercial-grade toolkit for TLS/SSL protocols, and a cryptography library. It includes default protocol level mitigation factors enabled against BEAST (Browser Exploit Against SSL/TLS) attacks.
- Apache 2.2.24 provides a directive for disabling SSL/TLS Compression.

6. Ensure that the server side selects the most secure cipher from the list of ciphers common to both client and server by providing preference ordering of the ciphers.
7. Where possible, disable HTTP compression for dynamic content where confidential information such as CSRF tokens might be included within the body of the HTTP response. This mitigates the HTTP compression side channel attack vector named BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext).
8. Log backend TLS connection failures.

Note: Enforce TLS/SSL on all parts of the application where possible. Read the amendment for this countermeasure for more information.

Enforce TLS/SSL on all pages

Enforcing TLS/SSL (We use the word "TLS" to also refer to the secure versions of SSL after this) across your entire site limits the ability of phishers to pull off impersonation attacks on your application and provides a higher level of security to your users. However, whole-site TLS has some cons that should be considered:

• TLS requires more processing power and bandwidth and increases server overhead.
• Content Distribution Networks (CDN) may face challenges distributing your protected pages.
• Ad networks used by your application may not support TLS.

So, in minimum, use TLS for the parts of your site that need security such as login pages, authenticated pages, sensitive submission forms and other content that needs to be encrypted. And if the above-mentioned problems are not critical to you, force TLS on all pages to enable a higher level of security for your application.

Note: Even if part of the application does not particularly perform any sensitive actions or collect sensitive data, allowing non-TLS access to those parts causes non-secure cookies (the ones that don't have "secure" flag set to true on them, [see T22|/library/tasks/T22/]) to be sent over unencrypted channels. Those cookies can be stolen by any eavesdropper on the network. Other small problems in the application could also be exploited much more easily when the whole application is not TLS-enforced.

Choice of cipher

Choice of cipher

Use the following guidelines for selecting an appropriate cipher for encryption:

• Strictly avoid using NULL ciphers as they do not provide encryption for confidentiality (they only provide integrity checks).
• Strictly avoid using EXPORT ciphers (EXPORT ciphers use shorter keys and are weak and breakable by design). The server component must explicitly disable EXPORT ciphers to protect the clients against Factoring RSA Export Keys (FREAK) attacks.
• Strictly avoid DES ciphers (not to be confused with 3DES). They have a short key and can be broken easily by brute force using inexpensive off-the-shelf hardware.
• Where available, use Ephemeral key exchange ciphers over standard ones. That is, use ECDHE over ECDH and DHE over DH.
• Regarding DH-based key changes, choose ECDH_ over DH_ due to better performance. ECDH_ provides the same amount of protection as DH_ but the former requires fewer resources.
• Never use ciphers that use MD5 for MAC.

  - MD5 has two known weaknesses: collision and pre-image.
  

• Never use SHA1. Use SHA384 or SHA256 instead.

  - SHA1 has been fully and practically broken.
  
  

  The following provides a list of recommended ciphers:

• TLS_ECDHE_ECDSA_WITH_AES_128_CCM
• TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CCM
• TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
• TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
• TLS_DHE_DSS_WITH_CAMELLIA_128_GCM_SHA256
• TLS_DHE_DSS_WITH_CAMELLIA_256_GCM_SHA384
• TLS_DHE_PSK_WITH_AES_128_CCM
• TLS_DHE_PSK_WITH_AES_128_GCM_SHA256
• TLS_DHE_PSK_WITH_AES_256_CCM
• TLS_DHE_PSK_WITH_AES_256_GCM_SHA384
• TLS_DHE_PSK_WITH_CAMELLIA_128_GCM_SHA256
• TLS_DHE_PSK_WITH_CAMELLIA_256_GCM_SHA384
• TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256
• TLS_DHE_RSA_WITH_AES_128_CCM
• TLS_DHE_RSA_WITH_AES_128_CCM_8
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CCM
• TLS_DHE_RSA_WITH_AES_256_CCM_8
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256
• TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384
• TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_PSK_DHE_WITH_AES_128_CCM_8
• TLS_PSK_DHE_WITH_AES_256_CCM_8

Secure files transfer

Do not transmit files in cleartext in a communication channel as it jeopardizes the integrity and confidentiality of data as unauthorized actors may sniff it. Use secure file transfer tools that:

1. Employ secure File Transfer protocols (e.g., Secure File Transfer Protocol (SFTP), FTP over SSL (FTPS), and Applicability Statement 2 (AS2)) that encrypt the data in motion and at rest.
2. Use robust authentication methods.
3. Protect against unauthorized data modifications.
4. Have reporting and logging capabilities.

Connect to a remote system securely

• Connect securely to a remote system using the SSH (Secure Shell) protocol that encrypts the traffic between a client and a server, preventing interception and identity spoofing.
• Do not use Telnet to connect to a system remotely. Telnet sessions between a client and a server are not encrypted, exposing the connection to various threats, including eavesdropping and identity spoofing.

Imported from SD Elements: https://redhat.sdelements.com/bunits/psse-secure-development/group-2-extended-functionality-offerings/openshift-source-to-image-s2i-builder-image/tasks/phase/requirements/106-T21/

How Tos:

Go: TLS

Use the ListenAndServeTLS function of the net/http package to serve HTTP with TLS.

import "log"
import "net/http"

func handler(w http.ResponseWriter, req *http.Request) {
    w.Header().Set("Content-Type", "text/plain")
    w.Write([]byte("Example HTTP/TLS server.\n"))
}

func main() {
    http.HandleFunc("/", handler)
    log.Printf("Going to listen on port 443.")
    // cert.pem and key.pem are paths to the server certificate and private key.
    err := http.ListenAndServeTLS(":443", "cert.pem", "key.pem", nil)
    log.Fatal(err)
}

Use generate_cert.go in the crypto/tls package to generate key.pem and cert.pem.

References

• Package http - ListenAndServeTLS
• Source file src/crypto/tls/generate_cert.go