DEV Community

禾
禾

Posted on

Listener TLS vs Upstream TLS: How to Place a TLS 1.2 and TLS 1.3 Requirement

#websecurity #tlscompliance #reverseproxy #firewall

Searching for a control that sets WAF SSL compliance to TLS 1.2 and TLS 1.3 usually starts one step too late. The supplied SafeLine documents describe a reverse proxy, an application form, and a separate management console. They do not describe a protocol allow-list, a cipher editor, or a command that limits handshakes to TLS 1.2 and TLS 1.3. Until that control exists in the docs, the decision is placement: which hop completes the handshake you need to constrain, and which hop only filters HTTP after decryption.

SafeLine is a self-hosted web application firewall placed in front of an application. Clients pass through it before they reach the origin. It filters and monitors HTTP traffic, including HTTP/S, and blocks malicious requests rather than acting as a forward proxy for the client. The introduction lists defenses for attacks such as SQL injection, XSS, code injection, OS command injection, CRLF injection, XXE, SSRF, and path traversal, along with IP-based rate limiting, a web access control list, bot defense, CAPTCHA challenge, authentication challenge, and dynamic protection that encrypts HTML and JavaScript on each visit (https://docs.waf.chaitin.com/en/home).

The application guide is more specific about the data path. SafeLine is developed based on nginx and works as an HTTP/HTTPS reverse proxy. It receives traffic for the original site, cleans malicious attack traffic, and forwards safe and reliable traffic to the original application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). That sentence defines the product job. It does not define a TLS version policy.

Those facts leave two configuration choices. They are not two labels for the same SSL checkbox.

Choice A: listener TLS on the application proxy

Choice A puts the client handshake on the SafeLine application listener. In the web admin console, open the Applications page and click Add Application. Enter the original app domain, hostname, or IP, the port SafeLine will listen on, and the upstream address. For an HTTPS app, check the SSL option. The guide uses ports such as 80 or 443 as examples, then tells you to resolve that domain to the IP of the server where SafeLine runs (https://docs.waf.chaitin.com/en/GetStarted/AddApplication).

This is the placement that can affect a browser, because the browser completes TLS with this listener. It is the placement people usually mean by WAF SSL compliance. The documented action is still only to check SSL and choose the listen port. Checking SSL means the proxy will handle an HTTPS application. The guide does not say that this disables TLS 1.0 or TLS 1.1, and it does not say that only TLS 1.2 and TLS 1.3 remain enabled.

If client compliance is the goal, Choice A is the layer to reason about, but only with a control the terminator actually documents. Do not add a guessed nginx directive, a custom container edit, or an extra compose key and call that a SafeLine feature. The supplied pages do not support that procedure.

Choice B: protocol policy on the upstream hop

Choice B keeps the TLS 1.2 and TLS 1.3 requirement on the upstream hop, or on a TLS terminator you already operate, and uses SafeLine for the filtering path the docs describe. Upstream is the real address through which SafeLine forwards traffic to the original application (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). If that origin, or a proxy dedicated to it, already refuses legacy TLS, the requirement stays with the process that finishes the handshake.

Choice B fits when the origin must keep its own certificate, when an existing terminator already publishes the protocol floor, or when public DNS cannot point at SafeLine yet. It does not make public clients compliant by itself. Clients are constrained only by the stack they handshake with. A strict upstream policy never sees a browser that terminated TLS on a permissive edge.

The deploy guide shows why this cannot be patched in through installation variables. The environment file includes the data directory, image tag, management port, database password, subnet prefix, image prefix, architecture suffix, release channel, region, console proxy layer count, database image, and detector tokens. It does not include an application TLS minimum version or an SSL compliance flag (https://docs.waf.chaitin.com/en/GetStarted/Deploy). That absence is not a suggestion to invent a variable. Protocol allow-listing is outside the documented install contract.

How the two choices differ

Listener TLS and upstream TLS fail in different ways, so they should not be changed in the same window.

Client compliance belongs on the listener browsers reach. If that listener is the SafeLine application port with SSL checked, you still need a documented protocol control before you can claim TLS 1.2 and TLS 1.3 only. The application guide stops at domain, port, SSL, upstream, and DNS.

Hop confidentiality belongs between the proxy and the application. A strict upstream policy can protect that connection even when client TLS is unchanged. It does not replace a public listener policy, and a public listener policy does not prove that the upstream hop rejects old protocols.

Blast radius differs too. A bad change on the public listener can lock browsers out while the origin is healthy. A bad change on the upstream address can break forwarding while the listener still accepts TCP connections. Test the handshake and the forward path separately.

The management console is a third surface. After install, the web console is opened at https://:9443/, and MGT_PORT is the console port variable. MGT_PROXY counts console proxy layers and should be used only when configuring a proxy for the console (https://docs.waf.chaitin.com/en/GetStarted/Deploy). Resetting the administrator with the documented resetadmin command only prints the initial console username and password. None of those console steps sets SSL compliance for the protected site.

Placement checklist

Work through the handshake before you touch the form.

  1. Name the handshake that must be limited to TLS 1.2 and TLS 1.3: browser to proxy, or proxy to origin.
  2. Name the process that terminates it. If you cannot name that process, you cannot honestly set its protocol floor.
  3. If SafeLine terminates the client handshake, use only documented application fields: domain, listen port, SSL for an HTTPS app, and upstream. Resolve the domain to the SafeLine server IP.
  4. If another host terminates that handshake, set TLS 1.2 and TLS 1.3 with that host's own supported method. Do not record the change as a SafeLine SSL compliance setting.
  5. Leave console TLS on 9443, or on the MGT_PORT you actually configured, outside the application change.
  6. After proxying, confirm attack handling with the guide's test cases for SQL injection, XSS, path traversal, code injection, and XXE, pointed at your own domain (https://docs.waf.chaitin.com/en/GetStarted/AddApplication). A block page and an entry in the console attack list show filtering. They do not show which TLS versions are allowed.
  7. Probe protocol versions with a client aimed at the terminating host. File that result against that host, not against an assumed WAF toggle.

If the requirement lands on step 4, treat this as a placement decision rather than an integration procedure. The supplied sources do not document a SafeLine feature that sets SSL compliance to TLS 1.2 and TLS 1.3.

Does checking SSL limit clients to TLS 1.2 and TLS 1.3?

No documented behavior says that. The application guide says to check SSL for HTTPS apps and to choose a listen port such as 443. That turns on HTTPS proxying. It does not list allowed protocol versions.

Is the console port the same policy as the website listener?

No. The console is the admin UI, documented on port 9443 unless MGT_PORT is changed. The website listener is the application port entered on Add Application. Hardening one surface does not harden the other.

Which placement should I pick when the origin already terminates HTTPS?

Pick upstream TLS when that origin, or a terminator in front of it, already owns the protocol floor and clients do not need a new public handshake on SafeLine. Pick listener TLS when browsers must handshake with the SafeLine application port. In that second case, still do not assume the SSL checkbox is a version lock.

Can an environment variable set the protocol floor?

Not with the variables shown in the deploy guide. None of them is an application TLS allow-list. Adding an undocumented key is not a supported configuration step.

How do I confirm protection after the placement choice?

Resolve the application domain to the SafeLine server, send the documented attack requests through that domain, and check for the block page plus the attack detail view in the console. Treat that as proof of HTTP filtering, then verify TLS versions on the host that actually terminates the handshake.

SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.

Top comments (0)