Beast Attack in Phoenix with Mutual Tls

A Beast Attack (Browser Exploit Against SSL/TLS) targets predictable initialization vectors (IVs) in TLS block ciphers such as AES-CBC. In a typical web context, an attacker can iteratively request chosen plaintext and observe ciphertext changes to gradually recover session cookies. When Mutual TLS is enabled in Phoenix, the server authenticates the client using a client certificate, but this does not alter the per-request IV handling for application data. The TLS channel still uses CBC-based cipher suites if negotiated, and the server-side endpoint logic may expose the same predictable IV behavior for successive requests from the same client. Therefore, the combination of Beast Attack techniques with Mutual TLS in Phoenix can expose the same IV predictability, even though client authentication is verified early in the handshake.

Consider a Phoenix endpoint that reads a session cookie from the request after the TLS and client certificate validation steps. If the server uses TLS cipher suites that involve CBC mode and does not enforce per-record random IVs or proper mitigations (such as the TLS_FALLBACK_SCSV or AEAD preferences), an attacker can perform a Man-in-the-Middle position to observe ciphertexts for crafted requests. The Mutual TLS aspect ensures the client possesses a valid certificate, but it does not prevent the attacker from launching iterative plaintext recovery against the encrypted application payload if the IV handling is weak. middleBrick can detect such risky configurations by scanning the unauthenticated attack surface, identifying whether the endpoint supports CBC suites and whether randomness in IVs is evident across requests.

middleBrick runs 12 security checks in parallel, including Input Validation and Encryption checks, which can surface weak cipher suite usage or IV handling issues even when Mutual TLS is present. For example, if the server accepts TLS_RSA_WITH_AES_128_CBC_SHA and does not implement robust mitigations, a Beast-related risk may be surfaced in the Encryption category. The scanner does not attempt to fix the issue but provides findings with severity and remediation guidance, helping teams understand how IV predictability can undermine Mutual TLS benefits in Phoenix.

To remediate Beast Attack risks in Phoenix when Mutual TLS is used, focus on cipher suite configuration and ensuring strong IV handling. Disable CBC-based cipher suites in favor of AEAD suites such as AES-GCM, and enforce TLS 1.2 or higher. Below are concrete configuration and code examples for a Phoenix endpoint using Plug.SSL and :ssl to require client certificates and prefer secure ciphers.

# config/config.exs
import Config

config :my_app, MyAppWeb.Endpoint,
  url: [host: "localhost", port: 443],
  https: [
    port: 443,
    cipher_suite: :strong,
    keyfile: "priv/cert/selfsigned_key.pem",
    certfile: "priv/cert/selfsigned.pem",
    cacertfile: "priv/cert/ca.pem",
    verify: :verify_peer,
    versions: ["TLSv1.2", "TLSv1.3"]
  ]

The cipher_suite: :strong option instructs the underlying SSL layer to prioritize AEAD suites and avoid CBC-based ciphers where feasible. For finer control, you can explicitly define allowed cipher strings using the :ciphers option, for example:

# config/config.exs — explicit cipher list preferring AES-GCM
config :my_app, MyAppWeb.Endpoint,
  https: [
    port: 443,
    ciphers: "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305",
    versions: ["TLSv1.2", "TLSv1.3"]
  ]

In your endpoint module, ensure you initialize SSL options and handle client certificate verification consistently. The following snippet shows how to set up the socket with required client certificate verification and strong protocol settings:

# lib/my_app_web/endpoint.ex
defmodule MyAppWeb.Endpoint do
  use Phoenix.Endpoint, http: [transport_options: transport_options()]

  def transport_options do
    [
      certfile: "priv/cert/server.pem",
      keyfile: "priv/cert/server.key",
      cacertfile: "priv/cert/ca.pem",
      verify: :verify_peer,
      depth: 1,
      customize_hostname_check: [match_fun: :public_key.pkix_verify_hostname_match_fun(:https)],
      ciphers: "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384",
      versions: ["TLSv1.2", "TLSv1.3"]
    ]
  end
end

Additionally, review your application-level session handling to avoid exposing sensitive identifiers in URLs or predictable cookies. Even with strong cipher suites and Mutual TLS, ensure that session identifiers are generated with sufficient entropy and that Secure, HttpOnly, and SameSite attributes are set where applicable. middleBrick’s Input Validation and Encryption checks can highlight insecure cookie attributes and weak TLS configurations, giving you actionable remediation guidance without attempting to patch or block traffic.