Alternative Server Name for Selective mTLS in Service Mesh

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Legacy clients in service mesh systems are unable to handle mutual transport layer security (mTLS) handshakes, leading to connection termination when unexpected Client Certificate Requests are initiated by proxies, as they are not configured to perform mTLS, affecting health checks and other requests.

Innovation Solution

A system generates an alternative server name in response to detecting a legacy client and associates it with a pod's address, configuring the proxy to disable mTLS when receiving this alternative server name, allowing legacy clients to function within mTLS environments without code changes or impacting existing clients.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If proxies in service mesh systems enforce mTLS handshakes for all connections, then security is improved, but legacy clients are unable to connect because they cannot handle Client Certificate Requests

Engineering Contradiction:

ImprovesecurityVSAvoidlegacy client compatibility

Core Design Contradiction:

ReliabilityVSAdaptability or versatility

Solution Approach 1:

The system applies different security policies to different clients by detecting whether a client is legacy-based and selectively enabling or disabling mTLS handshakes accordingly. This allows the proxy to have local quality variations in security enforcement, maintaining high security for modern clients while ensuring compatibility with legacy clients that cannot handle mTLS requests.

Inventive Principle:

Principle #3Local quality

2Adaptability or versatility

If proxies disable mTLS to support legacy clients, then legacy client compatibility is improved, but security is reduced

Engineering Contradiction:

Improvelegacy client compatibilityVSAvoidsecurity

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The proxy implements local quality by applying different security configurations to different client types. Modern clients receive full mTLS protection while legacy clients are served with mTLS disabled, allowing the system to maintain high security standards overall while providing targeted compatibility support where needed.

Inventive Principle:

Principle #3Local quality

3Device complexity

If the system uses a single server name for all clients, then device complexity is reduced, but the ability to selectively provide mTLS is limited

Engineering Contradiction:

Improveserver name managementVSAvoidselective mTLS provisioning

Core Design Contradiction:

Device complexityVSAdaptability or versatility

Solution Approach 1:

The system changes the server_name parameter based on client type detection. When a legacy client is detected, the proxy modifies the server_name to trigger appropriate mTLS behavior. This parameter change enables selective mTLS provisioning without requiring complex infrastructure, using the server_name as a control mechanism to switch between security modes.

Inventive Principle:

Principle #35Parameter changes

Data Source

PatentUS10841336B2Selectively providing mutual transport layer security using alternative server names

Publication Date: 2020.11.17 INTERNATIONAL BUSINESS MACHINE CORPORATION

AI summary

Examples of techniques for selectively providing mTLS using alternative server names are described herein. An example system includes a processor to generate an alternative server name in response to detecting a legacy indicator. The processor is to also associate the alternative server name with an address of a pod. The processor is to further configure a proxy associated with the pod to selectively provide mutual transport layer security (mTLS) based on the alternative server name.