Learn how the Akamai secure CDN ensures that it always serves the content that you intended. In this presentation David Kaufman will break down the secure CDN into three zones – Origin, Midgress, and Origin (as well as data at rest), and discuss how to manage your TLS configuration throughout to keep your content secure.

1. Keeping TLS Secure

2. © 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

3. © AKAMAI - EDGE 2016
Refresher: Akamai Network Architecture
● Lots of distributed servers
● Fastest path is not always most-direct path
● Protect TLS content throughout the network

4. © AKAMAI - EDGE 2016
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

5. © AKAMAI - EDGE 2016
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

6. © AKAMAI - EDGE 2016
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

7. © AKAMAI - EDGE 2016
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

8. © AKAMAI - EDGE 2016
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

9. © AKAMAI - EDGE 2016
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

10. © AKAMAI - EDGE 2016
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

11. © AKAMAI - EDGE 2016
Protecting content at the Edge
● Customer-specific configuration
● Protecting certificate private keys
● Elliptic Curve Cryptography is here
Edge Origin
Midgress
At
rest

12. © AKAMAI - EDGE 2016
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)

13. © AKAMAI - EDGE 2016
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

14. © AKAMAI - EDGE 2016
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

15. © AKAMAI - EDGE 2016
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