Turbonomic

Turbonomic

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

Understanding Proxy Servers and Why Turbonomic Secure Connect Requires Special Configuration

By Michael Crawford posted 5 hours ago

  

Introduction: The Value of Turbonomic Secure Connect

Turbonomic Secure Connect (TSC) represents a significant advancement in secure hybrid cloud management, offering organizations a way to leverage Turbonomic's SaaS platform while maintaining the highest security standards for their on-premises infrastructure. But this enhanced security comes with specific networking requirements that differ from traditional web-based applications.

Why Invest in TSC?

For Organizations:

  • Zero Trust Security Model: TSC implements mutual TLS (mTLS) authentication, ensuring both the client and server verify each other's identity before any data exchange occurs
  • End-to-End Encryption: Unlike traditional proxies that may decrypt and inspect traffic, TSC maintains encryption from your data center to the Turbonomic SaaS platform
  • Reduced Attack Surface: By eliminating the need for inbound firewall rules, TSC significantly reduces your organization's exposure to external threats
  • Simplified SaaS Adoption: Access Turbonomic's latest features and updates without exposing your infrastructure to the internet

For IT Teams:

  • No Inbound Firewall Rules: TSC uses outbound-only connections, eliminating the security risks and complexity of managing inbound access
  • Automatic Updates: Benefit from continuous platform improvements without managing on-premises upgrades
  • Reduced Infrastructure Overhead: Minimize the hardware, maintenance, and operational costs of self-hosted deployments
  • Seamless Hybrid Cloud Management: Manage both cloud and on-premises resources through a single, secure interface

The Trade-off: Enhanced Security Requires Specialized Configuration

The same security features that make TSC valuable, i.e. mutual authentication, end-to-end encryption, and zero-trust architecture, also mean it cannot work with traditional HTTP proxies. This blog post explains why TSC requires specific proxy configurations and how to implement them successfully.

What you'll learn:

  1. The fundamentals of different proxy types
  2. How TSC's security architecture works
  3. Why TSC requires TLS passthrough proxies
  4. How to configure your network to support TSC

Part 1: Proxy Server Basics

What is a Proxy Server?

A proxy server acts as an intermediary between clients and servers, forwarding requests from clients to servers and returning responses back to clients. Proxy servers serve multiple purposes in enterprise environments:

  • Security: Control and filter outbound traffic
  • Privacy: Hide client IP addresses from external servers
  • Performance: Cache frequently accessed content
  • Compliance: Log and audit network traffic
  • Access Control: Enforce organizational policies

Types of Proxy Servers

HTTP Proxy

An HTTP proxy is designed specifically for HTTP traffic (web browsing). It operates at the application layer (Layer 7) and understands the HTTP protocol.

How it works:

  1. Client sends an HTTP request to the proxy
  2. Proxy parses the HTTP headers to determine the destination
  3. Proxy establishes a new HTTP connection to the destination server
  4. Proxy forwards the request and returns the response to the client

Key characteristics:

  • Operates at the application layer
  • Can inspect and modify HTTP headers
  • Can cache HTTP responses
  • Requires client configuration (browser or application settings)
  • Typically uses the HTTP_PROXY environment variable

HTTPS Proxy (HTTP CONNECT)

An HTTPS proxy handles encrypted HTTPS traffic using the HTTP CONNECT method. This is more complex than a simple HTTP proxy because the traffic is encrypted.

How it works:

  1. Client sends an HTTP CONNECT request to the proxy
  2. Proxy establishes a TCP tunnel to the destination server
  3. Client and server perform TLS handshake through the tunnel
  4. Encrypted traffic flows through the proxy without inspection

Key characteristics:

  • Uses HTTP CONNECT method to establish a tunnel
  • Cannot inspect encrypted payload (unless using SSL/TLS interception)
  • Proxy sees destination hostname and port, but not the encrypted content
  • Still operates at the application layer for connection establishment
  • Common for web browsers accessing HTTPS sites

Transparent Proxy

A transparent proxy intercepts network traffic without requiring client configuration. Clients are unaware they're using a proxy.

How it works:

  1. Network routing directs traffic to the proxy
  2. Proxy intercepts packets at the network layer
  3. Proxy forwards traffic to the destination
  4. Responses are routed back through the proxy

Key characteristics:

  • No client configuration required
  • Operates at the network layer (Layer 3/4)
  • Can be implemented using iptables or similar tools
  • Commonly used for content filtering and caching
  • May require DNS manipulation or routing changes

TLS/SSL Terminating Proxy

A TLS terminating proxy (also called SSL interception or SSL inspection) decrypts HTTPS traffic, inspects it, then re-encrypts it before forwarding.

How it works:

  1. Client establishes TLS connection with the proxy
  2. Proxy decrypts the traffic using its own certificate
  3. Proxy inspects the decrypted content
  4. Proxy establishes a new TLS connection to the destination
  5. Proxy re-encrypts and forwards the traffic

Key characteristics:

  • Allows deep packet inspection of encrypted traffic
  • Requires installing proxy's CA certificate on clients
  • Breaks end-to-end encryption
  • Can cause issues with certificate pinning
  • Common in corporate environments for security scanning

Why TSC cannot use TLS terminating proxies: This type of proxy breaks the mutual authentication chain that TSC relies on for security. When the proxy terminates TLS, it presents its own certificate instead of the client's certificate, preventing the Turbonomic SaaS platform from authenticating the client.

TLS Passthrough Proxy

A TLS passthrough proxy forwards encrypted traffic without decryption, maintaining end-to-end encryption.

How it works:

  1. Client initiates TLS connection
  2. Proxy uses SNI (Server Name Indication) to determine destination
  3. Proxy forwards encrypted packets without decryption
  4. End-to-end encryption is maintained

Key characteristics:

  • Preserves end-to-end encryption
  • Cannot inspect encrypted payload
  • Uses SNI for routing decisions
  • Supports mutual TLS (mTLS)
  • Operates at Layer 4 (TCP) with Layer 7 (SNI) awareness

Why TSC requires TLS passthrough: This is the only proxy type that maintains the end-to-end security properties TSC needs, specifically: mutual authentication, certificate validation, and encrypted communication without intermediary inspection.

Server Name Indication (SNI)

Server Name Indication (SNI) is a TLS extension that allows a client to specify which hostname it's trying to connect to during the TLS handshake. This is crucial for proxy servers that need to route traffic without decrypting it.

Why SNI matters:

  • Allows proxies to route traffic based on hostname
  • Enables TLS passthrough without decryption
  • Supports multiple virtual hosts on a single IP address
  • Transmitted in plaintext during the TLS handshake

A proxy can read the SNI value and route the connection to the appropriate backend server without decrypting the payload.

Part 2: How TSC's Underlying Technology Communicates

TSC's Communication Model: Security by Design

Turbonomic Secure Connect was architected from the ground up with a zero-trust security model. Every design decision prioritizes security, which is why it uses specialized communication protocols rather than standard HTTP.

mTLS over TCP: Not HTTP Traffic

Critical distinction: TSC uses mutual TLS (mTLS) over raw TCP connections, not HTTP or HTTPS.

What this means:

  • TSC establishes direct TCP connections on port 443
  • These connections use TLS for encryption and authentication
  • The payload is not HTTP, it's application-layer messages
  • Both client and server authenticate each other using certificates (mutual authentication)

Why TSC Uses This Architecture

Security Rationale:

  1. Mutual Authentication: Unlike standard HTTPS (where only the server is authenticated), mTLS requires both parties to prove their identity with certificates. This prevents unauthorized clients from connecting to the Turbonomic platform and prevents man-in-the-middle attacks.

  2. Certificate-Based Trust: TSC uses X.509 certificates for authentication rather than passwords or API keys. Certificates are:

    • Harder to steal or compromise
    • Can be revoked instantly if compromised
    • Provide cryptographic proof of identity
    • Support automated rotation and management

  3. End-to-End Encryption: By using direct TLS connections without HTTP intermediaries, TSC ensures that data is encrypted from the moment it leaves your data center until it reaches the Turbonomic SaaS platform. No intermediate system can decrypt or inspect the traffic.

  4. Reduced Protocol Overhead: By not using HTTP, TSC eliminates unnecessary protocol layers that could introduce vulnerabilities or performance bottlenecks. The custom protocol is optimized for secure, efficient communication of management data.

  5. Outbound-Only Connections: TSC initiates connections from your environment to the SaaS platform, never the reverse. This means:

    • No inbound firewall rules required
    • Reduced attack surface
    • Easier compliance with security policies
    • Natural protection against external scanning and attacks

Why This Matters for Proxies

Traditional HTTP proxies expect HTTP protocol traffic. When they receive TSC's mTLS over TCP traffic, they encounter problems:

  1. No HTTP CONNECT method: TSC doesn't send an HTTP CONNECT request because it's not using HTTP
  2. Direct TLS handshake: TSC immediately begins a TLS handshake on the TCP connection
  3. Mutual authentication: Both endpoints must present valid certificates
  4. Application-layer protocol: After TLS, TSC uses its own protocol, not HTTP

Comparison:

Aspect HTTPS (Web Browser) TSC (mTLS over TCP)
Protocol HTTP over TLS Custom protocol over TLS
Proxy method HTTP CONNECT Direct TCP connection
Authentication Server-only (typically) Mutual (client + server)
Port 443 443
Proxy type HTTP/HTTPS proxy TLS passthrough proxy
Security model Trust server certificate Zero-trust mutual authentication

Part 3: Turbonomic and Proxy Support

Turbonomic's Diverse Proxy Requirements

Turbonomic is a comprehensive platform with multiple components that communicate with various targets and services. Different components have different proxy requirements.

Components That Support HTTP Proxies

Many Turbonomic components do support traditional HTTP/HTTPS proxies because they use standard HTTP-based protocols:

1. Target Configuration

When Turbonomic connects to various targets (cloud providers, virtualization platforms, etc.), many of these connections use HTTP/HTTPS APIs:

Examples:

  • AWS: Uses HTTPS REST APIs
  • Azure: Uses HTTPS REST APIs
  • VMware vCenter: Uses HTTPS SOAP/REST APIs
  • Kubernetes: Uses HTTPS REST APIs

The Turbonomic probe establishes an HTTP CONNECT tunnel through the proxy, then communicates with the target using HTTPS.

2. API Integrations

Third-party integrations that use Turbonomic's REST API can use HTTP proxies:

  • ServiceNow integration
  • Webhook notifications
  • Custom scripts using the API

These all use standard HTTPS, which works with HTTP CONNECT proxies.

Why Turbonomic Secure Connect is Different

Turbonomic Secure Connect (TSC) is fundamentally different because it uses a specialized secure communication layer for communication with the SaaS platform.

The Key Difference: Security Over Convenience

TSC prioritizes security over compatibility with legacy proxy infrastructure. This design choice reflects the reality that:

  1. Traditional proxies were designed for web traffic, not secure application-to-application communication
  2. HTTP CONNECT was created for browser-to-website connections, not mutual authentication scenarios
  3. Modern zero-trust architectures require end-to-end security, which HTTP proxies cannot provide

The trade-off: Organizations gain significantly enhanced security but must ensure their proxy infrastructure supports TLS passthrough. For most modern enterprise proxies, this is a configuration change rather than a hardware replacement.

TSC Technical Requirements

To support Turbonomic Secure Connect, the underlying technology requires specific proxy capabilities:

Requirement 1: TLS over TCP on Port 443

The proxy must support raw TCP connections with TLS on port 443. This is not the same as HTTPS proxy support.

What this means:

  • Accept TCP connections on port 443
  • Allow TLS handshake to pass through
  • Don't expect HTTP CONNECT method
  • Don't expect HTTP protocol

Why this is more secure: Direct TCP connections eliminate the HTTP protocol layer, reducing the attack surface and potential vulnerabilities associated with HTTP parsing and handling.

Requirement 2: TLS Passthrough (No Termination)

The proxy must not terminate the TLS connection. This is sometimes called "TLS passthrough mode."

What this means:

  • Don't decrypt the TLS traffic
  • Don't present a proxy certificate
  • Don't inspect the encrypted payload
  • Maintain end-to-end encryption

Why this matters for security:

  • Preserves mutual TLS authentication: The Turbonomic SaaS platform can verify the client's certificate directly
  • Maintains certificate chain validation: The full trust chain remains intact
  • Ensures secure communication: No intermediate system has access to decrypted data
  • Prevents man-in-the-middle scenarios: Even a compromised proxy cannot intercept or modify the communication
  • Supports compliance requirements: Many regulations require end-to-end encryption without intermediate decryption

Security benefit: This architecture means that even if your proxy server is compromised, the attacker cannot decrypt or tamper with TSC communications.

Requirement 3: Server Name Indication (SNI) Support

The proxy must support SNI to route traffic to the correct backend without decrypting it.

What this means:

  • Read SNI extension from TLS ClientHello
  • Route based on SNI hostname
  • Support multiple backend destinations
  • Make routing decisions before decryption

TSC endpoints requiring SNI routing:

Example endpoints shown below:

  • claims-turbonomic.apps.acme.com:443
  • edge-turbonomic.apps.acme.com:443

Why SNI is secure: SNI allows routing decisions without decryption, maintaining the zero-trust principle that no intermediate system should have access to encrypted payloads.

Requirement 4: Firewall Rules

If TSC is behind a firewall, it must allow outbound connections to:

  • Port 443 (TLS)
  • The two TSC endpoints listed above

Security advantage: Outbound-only rules are significantly easier to audit and maintain than inbound rules, and they align with defense-in-depth principles.

Conclusion: Security Requires Specialized Infrastructure

Understanding the difference between HTTP proxies and TLS passthrough proxies is crucial when deploying Turbonomic Secure Connect. While many Turbonomic components work perfectly with traditional HTTP proxies, TSC's use of mTLS over TCP communication requires a fundamentally different proxy configuration.

The key takeaway: TSC's specialized proxy requirements are not a limitation but they're a feature. The architecture ensures:

  • Maximum security: Mutual authentication and end-to-end encryption
  • Zero-trust model: No intermediate system can access or modify data
  • Compliance-ready: Meets the strictest regulatory requirements
  • Reduced attack surface: Outbound-only connections with no inbound exposure

For organizations evaluating TSC: The investment in configuring TLS passthrough proxies pays dividends in security, compliance, and peace of mind. Most modern enterprise proxy solutions support TLS passthrough, therefore it's typically a configuration change rather than a hardware investment.

For IT teams implementing TSC: Work with your network security team to enable TLS passthrough mode on your existing proxy infrastructure. The enhanced security model TSC provides is worth the initial configuration effort, and once configured, TSC requires minimal ongoing maintenance while providing continuous access to Turbonomic's latest SaaS features.

The future of secure hybrid cloud management requires moving beyond traditional HTTP-based architectures. Turbonomic Secure Connect represents this evolution, providing enterprise-grade security for organizations that refuse to compromise on protecting their infrastructure.

0 comments
12 views

Permalink

https://community.ibm.com/community/user/blogs/michael-crawford/2025/12/18/tsc-and-proxy-servers