Overview of Session Key Intercept - The Problem and The Answer

Our March 2021 technical brown bag has received praise from our customers, prospects, and partners for its in-depth informative content. As such, we wanted to break this session down, allowing you to dig into the areas of interest in a consumable blog format. Main topics included in this series: 

• Part 1: Overview of Session Key Intercept - The Problem and The Answer
• Part 2: The Case for SKI - Pro's and Con's
• Part 3: Security of SKI 
• Part 4: SKI Usecases: OEM Applications and Service Meshes 

With that, let's get to it. 

Nubeva SKI is a Better-Faster-Easier and More Secure TLS Decryption Solution - Nubeva SKI (Session Key Intercept) is an evolved alternative/augmentation to legacy decryption techniques. In this webinar, we specifically dive into how it is also more secure than other options on the market. 

SKI is a universal TLS decryption solution that enables full packet inspection of network traffic for security and performance monitoring. This includes inspection for outbound traffic, inline data center traffic, host-based inspection, and for Kubernetes, and Service Mesh on 5G networks. We work with commercial tools, open-source tools, homegrown applications. 

As of March 2021, we are primarily focusing our market efforts on the OEM opportunity of the SKI technology - working with application monitoring and security systems/suppliers. Secondarily, we are working with end-users looking to enhance and augment their existing systems.

Part 1a: Setting the Stage and The Problem with Legacy Decryption Techniques

A Connected Digital World 

It's no secret that we live in a connected world where everything is software. Threats are everywhere - and not just cyber-threats but also threats to application performance. If everything is connected - speed, performance, and the ability to monitor, detect and respond to threats are critical to business. To do that, it is mission-critical to look at the actual data moving on the wire - and all of this data is TLS encrypted and must be decrypted to inspect. 

Problem with Standard Decryption Options

Most of the options available were invented years ago, but protocols and networking have evolved, and these solutions are now unsound. This leaves manufacturers, solution providers, and their customers with growing visibility and performance issues. 

Each of the legacy decryption methods has its own shortcomings: 

Passive Intercept

• With passive intercept, also known as out-of-band inspection, server private keys are installed on the inspection device. Traffic is mirrored to the device, which replays the TLS handshakes to calculate session keys using the server private keys. These session secrets are used to decrypt the traffic. Passive intercept can only be applied if one has the right to distribute a server's private and public keys. 
• Used by Intrusion Detection Systems, Network Detection Systems, Application Performance Analytics, Application Performance Monitoring, and SEIMs
• Problem: With PFS-based traffic - TLS 1.3 and most of TLS 1.2 - the passive intercept technique is obsolete. Even when this was a viable method, this technique was never an option if you didn't have the public/private key pair, which includes any session going to a foreign entity, a cloud platform, and a third-party service on the internet - you couldn't inspect. These challenges of managing certificates, key pairs, and security vulnerabilities surrounding the practice are a massive headache.

Forward-Proxy

• • A forward proxy is also known as a man-in-the-middle (MITM) or certificate resigning. A forward proxy inserts itself into a TLS session by creating a TLS session between the proxy and the client, resigning the server certificate, and creating a session between the proxy and the server. MITM decrypts for inspection and re-encrypts to forward the traffic to its destination
  • Used by systems such as Secure Web Gateways, Next-Generation Firewalls, Intrusion Prevention Systems, Data Loss Prevention Technology and CASB's
  • Problem: Forward-Proxy technique doesn't work with pinned certificates, fails with mutual authentication and client certificates, and introduces enormous latency, high compute resource cost - which limits throughput. This method requires CA pushes which is problematic in specific environments and adds costly management overhead.

Proxy-Termination

• • For inline inspection of inbound traffic, a reverse proxy or session termination impersonates a server using the server certificate and terminates TLS sessions before forwarding the encrypted clear text to the server. Installing server certificates and private keys on a proxy violates end-to-end session integrity, increasing security risks maintenance overhead.
  • Used by systems such as Next-Generation Firewalls, Intrusion Prevention Systems, Application Load Balancers, and Network Load Balancer
  • Problem: This technique has crippling architectural limitations and breaks end-to-end sessions which violates TLS session integrity and increases security risks. A reverse proxy, same with passive inspection, cannot inspect traffic to 3rd party services including computing, storage, network, database, analytics, machine learning, or any other service provided by AWS, Azure, or GCP, or any other third party.

•  

Standard/Legacy decryption methods may "work," - but they are showing more and more limitations, they are expensive, and more disruption is coming that will continue to stress these systems

Part 1b: Nubeva Session Key Intercept is a New Method for a New Era. 

For a comprehensive overview of Session Key Intercept, the following video digs into Nubeva's Session Key Intercept, and we summarize below.

Nubeva essentially perfected and commercialized an age-old idea used by DevOps - keylogging. Traditional keylogging has never been treated as an enterprise solution as it has reliability, security, management, and other issues. Nubeva SKI offers a new option to transparently, automatically, reliably, efficiently, and securely learn and extract session secrets out of endpoints without modifying applications or changing their configuration in any way.

How does SKI Work?

Using our family of endpoint software, Nubeva SKI Sensors, extract final session secrets quickly and in real-time, forward them to inspection systems where they are paired with mirrored traffic for decryption and then ultimately destroyed. Nubeva's technology works with existing decryption technologies or decryptors supplied by Nubeva.

What are the Keys"?: When we use the words "Keys" or "Session Secrets," we are talking about individual session secrets, the symmetric keys that are used in the symmetric bulk encryption. These are low-risk, ephemeral keys - not the permanent public-private key pair used for authentication and key exchange, which are high-risk keys.

Nubeva's core IP has invented a technology (patented) to discover and extract session secrets from the TLS library code in process memory. We do this without changes to TLS libraries, application code, or their runtime environment configurations. Users provision the system service to run on an endpoint, server, or client., The service loads key extraction signatures. When a process is started the service detects which library it uses and selects the appropriate signature to locate keys in memory.  Then the service waits and listens for a client hello (at the beginning of a TLS session), and from there, the sensor knows where the session secrets will appear, in what sequence. The sensor extracts those secrets in under 200 microseconds, which is before the handshake even completes. The sensor does not extract the traffic, the keys only (which has added benefits we will discuss later - both in performance and security). From there, the secrets are securely forwarded, via encrypted tunnels, to authorized destinations.

Nubeva Key Sensor Is Universal: 

FOR ANY TLS TLS 1.3 TLS 1.2 with PFS/ECDHE TLS 1.2, 1.1, 1.0/SSL3.0 Pinned Certificates MTLS/Client Certificates Resumed Sessions Payload, Handshakes(TLS1.3), eSNI… FOR ANY TRAFFIC North-South-East-West To/from Owned Servers To/from Owned Clients “Outbound” to 3rd Parties (Web Services, Cloud Platforms…) FOR ANY ENVIRONMENT Metal VM’s Container Kubernetes and Service-Mesh Private-Cloud-Hybrid

The FastKey Protocol  used DTLS, with a HTTPS/REST back-up for reliability. Keys are sent over PFS encrypted tunnels to customer-defined destinations using secured credentials. Essentially, Nubeva has created a "KeyPlane," if you will. Keys are not derived from the traffic, they are derived from the endpoints, and therefore the traffic is never touched, architecture isn't impacted, authentication isn't messed with, and the TLS connection integrity end-to-end is maintained. This FastKey protocol enables secure and high-speed decryption. All you need to do now is send the traffic from any source, tap, span, existing packet broker, or native when inline and match the keys with the client random for the specific session to decrypt - it is just that simple. And you're done!

This concludes Part 1 of our Brownbag recap. In Part 2, we will dig into the pros and cons of Nubeva's Session Key Intercept approach.