# Reject a TLS-only destination for Docker GELF TCP output > Docker documents that its GELF driver does not support TLS for TCP and can silently fail against TLS-protected inputs. Resolve the receiver protocol before treating logging as operational. - Canonical URL: https://update.dsesecurity.com/updates/reject-a-tls-only-destination-for-docker-gelf-tcp-output/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T17:40:48+00:00 - Modified: 2026-10-29T17:41:39+00:00 - Last reviewed by DSE: 2026-10-29 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Docker documents that its GELF driver does not support TLS for TCP and can silently fail against TLS-protected inputs. Resolve the receiver protocol before treating logging as operational. ## Potentially affected Review scope: the Docker GELF logging driver and its documented TCP/UDP endpoint options; receiver configuration and any alternative protected transport need separate vendor review. ## DSE recommendation Confirm the receiver's protocol requirement before selecting a GELF endpoint, and verify actual ingestion with harmless identifiers rather than relying on container startup. ## Article Bottom line: Resolve the receiver’s transport requirement before accepting a Docker GELF logging configuration. If the intended input requires TLS, keep that requirement visible and select a separately reviewed delivery design instead of treating a TCP address as sufficient. ## Source fact: documented behavior The [Graylog Extended Format logging driver](https://docs.docker.com/engine/logging/drivers/gelf/) documentation is the primary reference. Docker’s GELF documentation says the driver does not support TLS for TCP connections and that messages to TLS-protected inputs can silently fail. The gelf-address option requires a port and accepts only tcp or udp URI specifiers. The documented reconnection-count and reconnection-delay options are TCP-only; the compression-type option is UDP-only. ## What the source does not establish This article identifies a driver transport limit. It does not recommend unprotected transport, certify a receiver or choose a tunnel, relay or replacement driver. Have the security and logging owners review any alternative against their actual requirements; do not weaken the receiver simply to make the proposed configuration connect. ## Applicability questions - Does the receiving input require TLS? - Which URI scheme and port does the proposed driver configuration select? - Do the chosen options apply to that transport? - Where will the operator verify that the actual receiver retained the test message? ## DSE recommendation: agree the endpoint contract before deployment DSE recommends a short endpoint contract shared by the container and logging owners. Record the destination, scheme, port and transport-protection requirement from the receiver’s own configuration. Compare it with the driver’s documented limits before changing a workload definition. For a TLS-only input, stop the direct GELF TCP proposal and identify a separately documented alternative with the responsible owners. Keep the original protection requirement in the decision. Do not add a plausible-looking protocol option or assume a reconnect setting supplies missing transport protection. Review selected driver options against the actual protocol. Keep TCP reconnection settings distinct from UDP compression settings. Record the approved configuration in the workload’s managed definition, with secret or environment data excluded from shared examples. Make the receiver identity and expected ingestion route reviewable without exposing sensitive connection material. Define an ingestion check before calling the configuration operational. Choose a harmless marker and a destination-side observation that can identify that exact record. Pair the observation with workload and daemon diagnostics. Treat an unexplained absence as an unresolved delivery problem, even when the container itself appears healthy. Assign a recovery action without claiming that retry settings guarantee retention. ## Verification and evidence Proposed verification, not performed: use a dedicated test workload and approved test input. First reconcile the configured receiver protocol with the endpoint contract. Do not send important operational records through an intentionally incompatible input as an experiment. Generate a small numbered sequence of harmless messages and inspect the intended receiver for their identities and order. If a controlled connectivity interruption is approved, record reconnect observations separately from message continuity. Retain the selected transport, relevant options, daemon observations and received identifiers. Do not generalize one successful ingestion test into a guarantee of confidentiality or lossless delivery. ## Official references - [Graylog Extended Format logging driver](https://docs.docker.com/engine/logging/drivers/gelf/) — Docker Docs. Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Docker Docs — Graylog Extended Format logging driver - Authority: docs.docker.com - URL: https://docs.docker.com/engine/logging/drivers/gelf/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Reject a TLS-only destination for Docker GELF TCP output,” DSE Security, https://update.dsesecurity.com/updates/reject-a-tls-only-destination-for-docker-gelf-tcp-output/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.