edge 2016 keeping tls secure
Post on 08-Jan-2017
27 Views
Preview:
TRANSCRIPT
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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
© 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)
© 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
© 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
top related