TLS termination
Last updated October 03, 2018
Identifying TLS terminated requests
To maintain optimal caching performance, Fastly uses a TLS terminator separate from the caching engine. This means, however, that the caching engine doesn't know that it was originally a TLS request. As a result, we set the Fastly-SSL
header when fetching the content from your servers.
Because we set this header, you can check for its presence on your backend by doing something like:
1
2
3
if (req.http.Fastly-SSL) {
set resp.http.X-Is-SSL = "yes";
}
and that should tell you if the request was a TLS request or not.
When using WordPress
If you're using Fastly TLS services with WordPress, you'll want to add a check for the HTTP_FASTLY_SSL
header so that WordPress can build URLs to your CSS or JS assets correctly. Do this by placing a check in your wp-config.php
file to override the SSL flag that is checked later:
1
2
3
if (!empty( $_SERVER['HTTP_FASTLY_SSL'])) {
$_SERVER['HTTPS'] = 'on';
}
As usual, this must be placed anywhere before the require_once
line with wp-settings.php
.
Finding the original IP when using TLS termination
Because Fastly uses a TLS terminator, separate from the caching engine for performance, the engine overwrites the original IP address briefly due to the re-request to your origin servers once decrypted and causes anything that references the original IP to show up as 127.0.0.0/8 IPs. To find the original IP via VCL:
- use
req.http.Fastly-Client-IP
if you're using shielding - use
client.ip
if you're not using shielding or if you're building an ACL
Fastly also sends along the client IP to the origin in a HTTP header, Fastly-Client-IP
, which can be used by server software to adjust as needed.