Understanding Wireguard, TLS and Workload Identity

1 | Copyright © 2022
Understanding Wireguard, TLS and Workload Identity:
The Backbone of Modern Service Networking

CHRISTIAN POSTA
VP, Global Field CTO, Solo.io
@christianposta
christian@solo.io

01
02
03
04
05
Why do we need modern
security?
Case Study: Google ALTS
Modern Networking Security
Workload Identity
Demos!
Agenda

c
Application Networking
Well Funded ($175M), $1B valuation
Satisfied Customers (130% Renewals)
Cloud-native Technology Leadership
Cloud-native Education Leadership
TODAY’S
BUSINESS
DIGITAL
BUSINESS
The Service Mesh and API Platform
for Kubernetes | Zero-Trust | Microservices

Service A can talk to Service B

Long Live IP!

Containerized Workloads

Beware!
https://www.theverge.com/2014/12/8/7352581/sony-pictures-hacked-storystream

Tenets of a Modern, Secure Network
• Assume a Hostile Environment - There are malicious persona both inside and outside the
environment
• Presume Breach - Operate and Defend resources with the assumption that an adversary
has presence in your environment
• Never Trust, Always Verify - Deny by default. Every resource is explicitly authorized using
least privilege multiple attributes, and dynamic cybersecurity principles
• Scrutinize Explicitly - Access to resources is conditional and access can dynamically
change based on action and confidence levels resulting from those actions
• Apply Unified Analytics - for data, applications, assets, services to include behavioristics
and log each transaction

Writing Networking Policy
● Who is calling whom
● Constraining who can call whom
● Avoid MiTM, eavesdropping
● Quota / QoS / Limits
● Logging, auditing
● Policy enforcement via fine-grained authz

Example from Google
ALTS

Application Layer Transport Security
• Built in 2007 (TLS 1.1 was the latest version at this point)
• TLS 1.1 did not meet Google’s minimum security standards
• A simpler, more tailored impl of TLS
• More flexible workload identity model
• Certs use ECDH keys, Uses DH key exchange, can provide PFS and AE
• Uses Protocol Buffers to serialize certificates and protocol messages
https://cloud.google.com/docs/security/encryption-in-transit/application-layer-transport-security

ALTS Design
• Transparent to applications / RPC invocations
• Simplified cryptography (limited key exchange/cipher algorithms)
• Authentication based on Identity NOT host machines
• Identity tied to chain of trust / key distribution (transparent to application)
• Authorization policies built around Identity model
https://cloud.google.com/docs/security/encryption-in-transit/application-layer-transport-security

Transparent ALTS

Handshake / Record Protocol

ALTS is Proven at Scale
Should we build ALTS?

No. Modern Building Blocks Exist
Let’s take a look

Modern, Secure Service Networking
• Transparent encryption

Wireguard
Transparent encryption made easy

Wireguard

Wireguard
• A Kernel/OS module aimed at transparently encrypting IP between two nodes
for VPN use cases
• Simple code base (around 7k LOC vs e.g., 100K+ IPSec)
• No cipher/protocol negotiation; fixed cryptography
• For L3, encapsulate encrypted packets in UDP
• Intended to use ciphers that afford more performance
• Simplified configuration, out of band public-key exchange
https://www.wireguard.com/papers/wireguard.pdf

Configure public keys and it just works

Opinionated Crypto (Based on the Noise Framework)
• Elliptic Curve Diffie Hellman with Curve22519
• ChaCha20+Poly1305 for Authenticated Encryption
• BLAKE2s for hashing
• Optional Pre-Shared Key (PSK)
• If a vulnerability is found, upgrade everything
https://www.wireguard.com/papers/wireguard.pdf

Downsides of Wireguard
• Could be very difficult to upgrade “everything” all at once for a discovered
vulnerability
• Not FIPS compliant
• Will not be FIPS compliant
− https://twitter.com/matthew_d_green/status/1443558648878350339
• Doesn’t solve for workload Mutual Authentication, Identity, or Authorization

Options to Layer Authentication for svc-to-svc?
• Wireguard “authenticates” its peers but has no knowledge of svc identities
• JWT access tokens (ie, OAuth 2.0 + Secure Token Service)
• Custom mutual authentication mechanism (see Cilium)
• Layer client certificates and TLS on top

Cilium’s approach to mutual authentication

Transport Layer Security
TLS 1.3

Transport Layer Security

Transport Layer Security (TLS 1.2)

Transport Layer Security (TLS 1.3)

Client Authentication (mTLS)

Why use TLS 1.3?
• Faster
− Handshake takes fewer round trips
• Safer (drop support for unsafe cryptographic algorithms)
− Remove RSA key exchange (doesn’t provide Forward Secrecy)
− Remove CBC/RC4 ciphers
− Restrict DH parameters to known secure params
− Handshake is signed by the server, cannot be tricked into downgrade
− Chose AEAD ciphers

TLS Can do Authentication, Encryption, Integrity Checks
• FIPS compliant implementations
• Private keys do not get sent over the wire (like JWT tokens)
• Can be terminated at the applications for end-to-end session
• TLS 1.3 brings simplification for ciphers/protocol negotiation
• Looks a lot more like Google ALTS!

Downsides to TLS
• No standard way to specify identity
• Key issuance, revocation, rotation can be complex
• How do the applications handle key material safely?
• What if applications mis-configure?
• Every language/framework/library is different

Standard Workload Identity Framework
with SPIFFE

Secure Production Identity Framework (for Everyone)
• Open Source Identity Specification for workloads
• Intended to solve the “universal workload identity problem”
• Independent of application type, network, or platform/cloud
• Specified with URI strings
• Verified via signed credentials (x509, JWT, etc)
• API and workflow for attestation built into SPIFFE implementations
• Intended to eliminate passwords, other secrets, etc

Who is Service A?

Identity described in SVID

Identity for Workloads

SPIRE is a Production Implementation of SPIFFE

Bringing it Together Transparently
TLS 1.3 + SPIFFE

Now we know who Service A is…

An example implementation: Istio Ambient Mesh
https://istio.io/latest/blog/2022/introducing-ambient-mesh/

Istio Ambient Mesh (w/ TLS 1.3 + SPIFFE)
• Transparent encryption

Additional Resources
● https://lp.solo.io/white-paper-zero-trust
● https://cloud.google.com/docs/security/encryption-in-transit/applica
tion-layer-transport-security
● https://istio.io/latest/blog/2022/introducing-ambient-mesh/
● https://www.wireguard.com/papers/wireguard.pdf
● https://www.solo.io/zero-trust/
● https://academy.solo.io
● https://istio.io
● https://cilium.io
https://lp.solo.io/istio-ambient-mesh-explained

Understanding Wireguard, TLS and Workload Identity

Understanding Wireguard, TLS and Workload Identity

Recommandé

Contenu connexe

Similaire à Understanding Wireguard, TLS and Workload Identity

Similaire à Understanding Wireguard, TLS and Workload Identity(20)

Plus de Christian Posta

Plus de Christian Posta(20)

Dernier

Dernier(20)

Understanding Wireguard, TLS and Workload Identity