2

Just say you are terminating http SSL connections on an intermediary server like Cloudflare, this will decrypt the data and then forward it onto the server for processing. What is the performance gain of doing this? If you unencrypt the data at the intermediary and then send it to the server, doesn't this mean the data can be sniffed in between? And if you get around this by making a further SSL connection from intermediary to server, doesn't this create so much overhead that there is no performance benefit to terminating at an earlier hop in the first place?

2

3 Answers 3

2

TL;DR: It doesn't.

The hop from the Internet-based CDN (e.g. Cloudflare) needs to use HTTPS or it won't be secure. If you had something like a VPN to the CDN, you could use that, or there are cases where an internal reverse proxy is used to terminate SSL/TLS and then the internal, behind-the-firewall, hop to the actual origin servers is just HTTP. Unless Cloudflare allows VPN-like connectivity to origin servers, it's not going to be useful for TLS offload (it's still useful for other things, like handling traffic spikes, and decreasing latency). Basically: "Flexible SSL" is no more secure than "Off"; if you need TLS for the content you're serving, I'd recommend using "Full Strict" with Cloudflare.

It's important to note that in this scenario, Cloudflare is essentially a man-in-the-middle. It's not an attack as such, since you authorised them, but they are able to do anything a successful man-in-the-middle attacker could do; it's very important that you trust them to execute their role properly! This is true any time TLS is terminated outside your sphere of control.

2
  • Still unclear: why this service exists and what performance benefits it has.
    – Peter
    Mar 27, 2014 at 2:54
  • @Peter Cloudflare is designed to offload traffic and latency. The origin server's bandwidth requirements will decrease, and the duration of users' requests will decrease (due to Cloudfront's servers being closer to them than the origin is). The "Flexible SSL" option exists so users may use either HTTP or HTTPS, whichever they happen to select, without issue; it's convenient, but not at all secure (as the path to the origin is still insecure). It's ok for a CDN to act as MITM, but you need to trust them. (If that's not what you meant, I'm not sure what 'service' you mean, sorry.)
    – Calrion
    Mar 27, 2014 at 4:41
3

A CDN edge node will provide the client with reduced HTTPS connection setup time if (likely) it is nearer to the client than the origin server.

The other performance gain comes from the CDN edge node being able to cache the origin server's response to a given client request, so the cached response can subsequently be delivered to similar requests from local end users, more quickly than if it were delivered by the origin server.

However, the edge node must have visibility of both the client request (cache key) and the corresponding origin's response (cache value). TLS termination is the only way the CDN edge node would have the required visibility into the TLS tunnel.

Also note that the CDN edge nodes can typically be configured to either (A) send plain HTTP back to your origin server, or (B) use HTTPS to form a second leg of encrypted communication to your origin server.

1

The reason you need early SSL termination at an edge closer to the customer it because it increase the performance of establishing connection for SSL by saving on round trip times. But why SSL has this issue? Normal unencrypted TCP connection has only 1 handshake. This means 1 round trip to the origin server. Let's say that round trip costs 70ms. Now, SSL connection have a 3 way handshake. This means that the cost will be 3 round trips which will increase the request latency to 210ms. When using CDN or edge SSL termination like this, you are minimizing this latency because your one round trip time is going to be much shorter resulting on your 3 way SSL handshake to be faster compared to going to the origin server.

1
  • Only if the content exists at the CDN endpoint. If all it's doing is acting as an intermediary node and fetches contain from the origin server, then this wouldn't apply.
    – Peter
    Aug 27, 2014 at 3:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .