Edge 2016 keeping tls secure

Keeping TLS Secure

© AKAMAI - EDGE 2016

Keeping TLS Secure

● How do we ensure that the Akamai Secure CDN serves the content you intended?○ Akamai techniques and technology○ Customer best practices


Refresher: Akamai Network Architecture

● Lots of distributed servers● Fastest path is not always most-direct path● Protect TLS content throughout the network


Secure CDN as Three Zones (plus one)

● Edge: Akamai servers that end-user clients connect to● “Midgress”: Akamai servers talking to other Akamai servers● “At rest”: cached content on an Akamai server● Origin connection: Akamai servers talking to your servers

Edge Origin

Midgress

At rest


Protecting content on the Origin connection

● Prevent man-in-the-middle attacks○ For privacy - keep customer information confidential○ For integrity - actually serve your content

● What should you do?○ Secure with TLS (actually we make you)○ Keep TLS versions and ciphers up-to-date○ Validate origin certificates

Edge Origin

Midgress

At rest


Origin certificate validation

● Origin certificate is customer-managed○ Plan for rotation - and rotate!○ Configure Akamai appropriately

● Simplest case - commercial certificate○ Use Akamai trust store (similar to browser store)

● Tighter security - certificate pinning○ Please don’t pin the origin (“leaf”) certificate! Pin the root, or an intermediate○ More effort for customer

● Special case - Third-party trust store○ Especially Amazon Web Services○ Akamai updates trust store when third-party rotates


Protecting content at rest

● Still a lot of HTTP traffic on the network○ HTTP and HTTPS share the same URLs○ HTTP is vulnerable to man-in-the-middle attacks

Edge Origin

Midgress

At rest


Separating HTTP and HTTPS

● Cache partitioning○ “secure cache” vs “non-secure cache”○ Happens before customer configuration

● Maintained throughout the network○ Midgress connections keep secure content separate from non-secure

Cache

http://www.example.com/common.jsp

https://www.example.com/common.jsp


Protecting content through “Midgress”

● Prevent man-in-the-middle attacks○ For privacy - keep customer information confidential○ For integrity - actually serve your content

● Similar to origin connection, but multi-tenant and greater scale○ Under Akamai control (mostly)

Edge Origin

Midgress

At rest


Midgress content protection

● Identity certificates○ Identify server in network and role○ Only released to authentic Akamai server, at startup time

● TLS connection with mutual authentication○ Maintain current TLS version and ciphers○ Parent (server) validates client certificate○ Child (client) validates server certificate

● Multiple policies applied○ Apply geographic restrictions○ Defend against server impersonation

● Content separation○ Secure content separate from non-secure


Protecting content at the Edge

● Customer-specific configuration● Protecting certificate private keys● Elliptic Curve Cryptography is here

Edge Origin

Midgress

At rest


Independent per-customer configuration

● Concept of a “slot”○ Certificate + customer-specific, certificate-specific configuration○ Many thousands of “slots” on Secure CDN

● Certificate management○ Automatic rotation, with customer notification at each stage○ Let’s Encrypt (DV): hands-free renewals○ Symantec (OV, EV), Geotrust (OV): supported renewals○ Third-party (any type)

● Connection configuration○ TLS version, ciphers, other fine details

■ Use up-to-date Cipher Profiles○ Mutual authentication (with help)


Isolated Software Security Module (ISSM)

● Who remembers Heartbleed?○ Widespread 2014 OpenSSL vulnerability○ Allowed attacker to read sections of web server memory○ Potentially exposed SSL certificate private keys

● ISSM○ A separate system that holds private key information○ Removes private keys from the attack surface○ Layer of protection against the next buffer over-read bug


ECDSA certificates are here

● Elliptic Curve Digital Signature Algorithm○ Delivers equivalent protection from much smaller public keys

(160-bit ECDSA public key similar to 1024-bit DSA public key)○ But, not ubiquitously supported yet

● Compatible ECDSA deployment○ Each Secure CDN slot will combine an ECDSA and an RSA certificate○ Proxy server offers the correct certificate, based on each request

● Limitations○ Currently available for Symantec-brand certificates○ Default-on for new certificate enrollments○ Watch out for certificate pinning


Any questions?

Customer takeaways:● Manage your origin TLS configuration● Please don’t pin leaf certificates (Origin or Edge)

○ On the Edge: use Change Management, maybe disable ECDSA

Edge Origin

Midgress

At rest

Edge 2016 keeping tls secure

Technology

Transcript of Edge 2016 keeping tls secure