Niagara Networks - Network Visibility
close
close-x

Site Search

    Decrypt What Matters. Bypass What Is Private.

    ECH-Aware TLS 1.3 Selective Decryption

    Talk to a TLS Visibility Expert Explore ePacketron

    When does ECH-aware TLS inspection fit your visibility architecture?

    Choose a dedicated TLS inspection layer when your organization needs to inspect approved encrypted connections and share selected decrypted traffic with multiple security and monitoring tools. ePacketron brings ECH-aware TLS 1.3 selective decryption into Niagara Networks' visibility architecture, helping SOC and NOC teams maintain inspection as encryption evolves.

    Encrypted Client Hello (ECH) protects the real destination hostname inside the encrypted TLS handshake. This limits the hostname information available to conventional passive monitoring and policies based on visible Server Name Indication (SNI). Supported active interception provides the destination context needed to apply inspection policies to eligible connections.

    Decrypt What Matters. Bypass What Is Private.

    Apply destination categories and configured policies to decrypt selected traffic, leave designated sensitive communications encrypted, or block connections. Deliver selected decrypted copies through Niagara Network Packet Brokers to existing NDR, IDS, DLP, forensic, and monitoring tools. Hybrid and standalone post-quantum key-exchange support helps maintain inspection across compatible TLS environments.

    ECH-aware inspection requires appropriate enterprise certificate trust, compatible clients, and supported configurations. Applications using certificate pinning or other interception restrictions may require encrypted bypass or alternative controls.

    ePacketron unified policy and decryption panel-2
    ePacketron processes supported TLS connections between a managed enterprise client and destination server, with selected decrypted copies delivered through a Niagara packet broker to security and monitoring tools.

    High-performance TLS inspection

    90+ Gbps TLS Decryption

    Offload TLS processing and deliver selected decrypted traffic to downstream tools. The reported throughput benchmark includes mirroring every decrypted byte to an out-of-band tool.

    Policy-based traffic handling

    Inspect Selectively

    Use supported destination categories and organizational policies to decrypt eligible connections, bypass designated sensitive traffic, or block connections.

    Post-quantum key exchange

    Support Evolving TLS

    Support hybrid X25519MLKEM768 and standalone ML-KEM-1024 key exchange across compatible client-facing and server-facing TLS connections.

    Why encrypted traffic inspection needs selective control

    Encryption protects users and applications, while limiting the information available to security and monitoring tools. ECH adds another visibility challenge by concealing the real destination hostname from conventional passive SNI inspection.

    > Retain inspection context:  Obtain destination context through supported, authorized interception before applying category-based handling policies.

    > Prioritize security analysis:  Select eligible traffic for deeper inspection based on destination intelligence and organizational requirements.

    > Limit sensitive data exposure:  Leave designated private communications encrypted and apply selection and masking to approved monitoring feeds.

    > Reduce repeated TLS processing:  Centralize decryption and distribute selected copies to the tools that need them.

    > Prepare for changing cryptography:  Support compatible classical, hybrid, and post-quantum TLS key-exchange environments.

     

    How ePacketron integrates TLS inspection with network visibility

    For ECH-aware TLS 1.3 inspection, ePacketron participates in the production connection path and establishes separate client-facing and server-facing TLS sessions. Supported destination intelligence and configured policy determine how eligible connections are handled. Selected decrypted copies can then be filtered, optimized, replicated, and distributed through Niagara Network Packet Brokers.

     

    Component Processing Capability Operational Benefit
    Traffic access & placement Physical and virtual access options, with an active connection path for authorized ECH-aware interception. Aligns collection and inspection with the required environment and deployment model.
    TLS processing ePacketron terminates and re-establishes supported TLS connections, including compatible hybrid and standalone post-quantum key exchange. Centralizes cryptographic processing and makes selected decrypted copies available to tools.
    Connection policy Supported destination categories and configured decrypt, encrypted bypass, or block policies. Prioritizes eligible inspection and limits unnecessary exposure of sensitive communications.
    Monitoring distribution Packet broker filtering, replication, load balancing, and supported optimization and masking functions. Delivers relevant traffic to NDR, IDS, DLP, forensic, and monitoring tools.
    Operational resilience External bypass options and deployment-specific failure and recovery policies. Provides an alternate forwarding path where configured; TLS session recovery and failback require validation.

    Match the TLS inspection model to your environment

    Deployment scenario Appropriate application Design consideration
    Active TLS interception Authorized inspection of supported enterprise-managed TLS 1.3 and ECH connections. Requires connection-path control, appropriate certificate trust, client compatibility, and validated failure handling.
    Active interception with out-of-band tools Selected decrypted copies are delivered to monitoring and analysis tools. The tools receive copies; the interception appliance still participates in the production connection path.
    Shared inspection feeds Multiple tools require traffic from the same approved decrypted connection. Decrypt once, then filter and distribute selected copies according to tool requirements.
    Encrypted bypass and metadata analysis Designated traffic remains encrypted under privacy or compatibility policies. Use policy to decide which traffic is decrypted, masked, sliced, converted to metadata, or excluded.
    Centralized visibility operations Traffic access, inspection, and monitoring delivery span multiple sites or tools.

    Coordinate policy, capacity, and supported platform integrations as the environment changes.

     

    Use Cases for Niagara Networks TLS Decryption

    Investigate threats in supported encrypted connections

    Prioritize eligible connections to suspicious destinations for analysis. ECH-aware inspection and supported destination intelligence help provide selected decrypted traffic to NDR, IDS, malware-analysis, and forensic tools according to organizational policy.

    Offload TLS processing from monitoring tools

    Centralize decryption in ePacketron and distribute selected copies through Niagara Network Packet Brokers. Filtering and traffic optimization reduce unnecessary delivery and help existing tools concentrate on analysis.

    Apply privacy policies to inspection and evidence collection

    Define which communications may be inspected, which must remain encrypted, and which monitoring feeds require masking or restricted delivery. Align packet capture and forensic collection with approved data handling and retention requirements.

    Add application context to approved monitoring feeds

    Combine selected TLS inspection with supported application filtering and packet-processing functions. Deliver relevant traffic to designated tools while maintaining configured exclusions for sensitive or incompatible applications.

    Plan resilience for inline inspection

    Use an appropriate bypass and availability design when TLS interception participates in the production path. Physical bypass can route around an unavailable appliance; existing inspected sessions may need to reconnect. Validate detection, recovery, and failback for the deployment.

    Coordinate inspection and tool delivery policies

    Align connection handling with destination intelligence, organizational security policies, and downstream tool capacity. Plan supported visibility management and integration across packet brokers, traffic access points, and inspection appliances.

    Plan an ECH-aware TLS deployment

    Decision Why it matters Recommended approach
    Client trust and inspection placement Unsupported trust or placement can prevent interception or disrupt applications. Use a validated active architecture with appropriate enterprise certificate trust and compatible clients.
    ECH and cryptographic compatibility Client behavior, ECH negotiation, and supported key-exchange groups vary. Validate the required TLS, ECH, hybrid, and standalone PQ configurations with representative peers.
    Sensitive traffic and policy exclusions Broad inspection can expose information unnecessarily or conflict with approved handling policies. Configure category-based selection, encrypted bypass, and appropriate masking of monitoring feeds.
    Processing and tool capacity Packet-processing capacity, TLS throughput, connection rate, and concurrency describe different limits. Size each stage using representative traffic and the enabled inspection and optimization functions.
    Failure and recovery policy Forwarding availability and continued inspection require different design considerations. Select appropriate fail-open or fail-closed behavior and validate bypass, TLS session recovery, and failback.

    Build an integrated network visibility architecture

    Niagara Networks visibility architecture combining traffic access, ePacketron processing, packet brokering, bypass options, and delivery to security and monitoring tools.

     

     

    Combine ePacketron TLS inspection with Niagara Networks' traffic access, packet brokering, bypass, and visibility management capabilities.

    Collect traffic from the required environments, apply approved processing, and deliver relevant packets and metadata to SOC and NOC tools.

     

    Visit Niagara Networks Appliance Comparison Matrix

     

     

    Network TAPs

    Collect packet copies from critical physical links to support monitoring, investigation, and performance analysis. Explore Network TAPs

    Network Packet Brokers

    Aggregate, filter, deduplicate, replicate, and load balance traffic for multiple security and monitoring tools. Explore Packet Brokers

    Hybrid TAPs and Bypass

    Design alternate forwarding paths for inline tool failure or maintenance. Validate bypass policy and session recovery for the inspection architecture. Explore Bypass Options

    ePacketron Network Intelligence

    Combine ECH-aware TLS 1.3 selective inspection, supported post-quantum key exchange, and advanced packet processing within the visibility architecture. 

    Explore ePacketron

    Virtual Traffic Access and Brokering

    Extend visibility into virtualized and cloud environments, capturing east-west traffic and optimizing virtual traffic delivery where physical TAP deployment is not possible.

    §

    Visibility Management

    Coordinate supported traffic access and delivery policies across Niagara Networks' visibility infrastructure.

    Explore Visibility Orchestration
    See what encryption is hiding from your tools.

    Decrypt What Matters. Bypass What Is Private.

    Plan your ECH-aware TLS inspection architecture

     

    Discuss how ePacketron can support approved inspection, privacy-aware bypass, post-quantum key exchange, and delivery to your existing security tools.

    • Review managed clients, certificate trust, and application compatibility.
    • Assess TLS throughput, connection scale, and downstream tool capacity.
    • Discuss supported configurations, bypass design, release availability, and licensing.

    Talk to a TLS Visibility Expert

    FAQ

    ECH protects the real destination hostname within the encrypted TLS handshake, limiting conventional passive SNI inspection. In supported enterprise-managed environments, ePacketron uses authorized active interception to provide destination context and apply selective TLS handling policies. It does not imply that every encrypted connection can be intercepted.

    Centralized decryption reduces repeated cryptographic processing across downstream tools. Packet brokers can distribute selected decrypted copies and apply supported filtering, optimization, and masking functions before delivery to security and monitoring platforms.

    Yes. For a supported connection selected for decryption, ePacketron can provide a decrypted copy for packet broker distribution to multiple approved tools. Each tool receives traffic selected for its role rather than independently terminating the original TLS connection.

    Supported destination intelligence and customer-defined policies determine whether eligible traffic is decrypted, forwarded encrypted, or blocked. Organizations can configure exclusions for designated sensitive categories and applications that cannot support interception. Masking and restricted delivery provide additional controls on approved monitoring feeds.

    ePacketron supports authorized TLS 1.3 inspection, including supported Perfect Forward Secrecy configurations, through separate client-facing and server-facing connections. The release adds ECH-aware handling and support for hybrid X25519MLKEM768 and standalone ML-KEM-1024 key exchange. Each TLS leg negotiates with its respective compatible peer.

    Note: Key-exchange support alone does not establish full post-quantum authentication or CNSA compliance.

    No. In the ECH-aware workflow, the interception appliance participates in the production connection path. Monitoring tools can receive selected decrypted copies out of band. A passive TAP copy alone does not supply the TLS processing context needed for this active interception workflow.

    Evaluate TLS throughput, new connection rate, concurrent sessions, cryptographic configuration, and tool delivery under representative traffic conditions. Apply approved policies to inspect eligible connections and keep designated traffic encrypted.

    Note: The 90+ Gbps TLS benchmark is separate from up to 600 Gbps overall packet processing; performance depends on the tested configuration and enabled functions.