0

Let the load balancer pass SSL/TLS-encrypted data through to the servers. I wonder how a hanshake is processed if a new HTTPS connection to a client is established: Handshaking is a stateful communication. For instance, in order to verify the client's finished message, the server needs to know all handshake messages that has been exchanged between server (farm) and client so far. Hence, - as far as I can see - there are three possibilities:

  1. SSL/TLS data are hold in a cache that is shared by all servers

  2. The content of the handshake messages is replicated to all servers.

  3. The load balancer directs all handshake messages from the client to the same server.

Question: Which scenario is typically used in such an environment ? Are there further policies in handling handshakes that I missed ?

Added: I'm faced with the claim that my question is a duplicate and I'm told to edit my question in order to explain why it is different from Load balancing and HTTPS strategies. So here is my comparison between my question and the other question:

a) I figured out three options to handle https state in an load balancing environment and asked which of these (or maybe other ones) are used in practise.

b) In the other question the OP uses option 3 ("same server"), i.e. all requests with same IP are routed to the same server. However, since most of their clients use the same IP lb doesn't work well and OP asks for a way out. Four and a half out of five answers give suggestions that, in effect, keep option 3 above. One part of an answer there ("DNS for target server"), I didn't understand.

So the question is still, if the options 1 ("ssl cache") and 2 ("replication of ssl hanshake data") are in used in practise. The article http://wtarreau.blogspot.de/2006/11/making-applications-scalable-with-load.html seems to favor option 1 (see "4. Dedicated SSL-Cache Farm").

user120513
  • 117
  • 3
  • It's never pointless to write a better question. You will get better answers. – Michael Hampton Mar 02 '18 at 21:47
  • @Michael Hampton: Unfortunately, the text you removed is not irrelevant.Your edit changed the coherence of my question , as it brought in logically unrelated stuff. Apart from that, comparing a clearly written question to a question that addresses another problem, doesn't make a question better. – user120513 Mar 02 '18 at 21:56
  • Did you try to check if there are any products implementing either strategy 1 or strategy 2? – Tero Kilkanen Mar 02 '18 at 23:06

2 Answers2

0

If the requirement is to have HTTPS on all parts of the setup, it's easier/more feasible to have the handshake be done between client and lb, then have a separate set of certificates between the lb and servers.

SSL passthrough is possible and some CDN's offer it. As far as I understand it, all traffic is forwarded as is, but this doesn't allow for loadbalancing.

To have this working you would need session stickiness on LB level.

Gothrek
  • 531
  • 2
  • 8
  • Wouldn't a shared cache for ssl data allow for SSL passthrough without session stickiness ? – user120513 Mar 02 '18 at 21:28
  • I would imagine that maintaining such a shared TLS data cache would add complexity to the setup, and would be really difficult to implement so that performance is reasonable. – Tero Kilkanen Mar 02 '18 at 23:03
  • Why would you even *want* to spread (round-robin) a single TLS handshake? It's a uniform predictable chunk of computation, so let one CPU do it and be done. Is there even an algorithm to parallelize it? @user120513 – kubanczyk Mar 02 '18 at 23:04
  • @Tero Kilkanen: Not more complex than a db that runs on a db server (which is common in a server farm). Also, using the IP address for mapping clients to servers as ngnix does could lead to a bottleneck if many clients use the same IP (cf. the question in Andrews link above). – user120513 Mar 03 '18 at 01:03
  • @kubanczyk: "let one CPU do it" - how is this possible in a SSL passthrough scenario ? – user120513 Mar 03 '18 at 01:08
  • Having ssl pass through doesn’t mean you don’t need load balancing. Still you never said what’s your use case. And unless you are a CDN provider having ssl pass through is useless. – Gothrek Mar 03 '18 at 09:25
  • @kubanczyk the point here is not to spread the handshakes, but the actual sessions. TLS handshake is only a small part of the whole TLS session, while the goal here is to balance the actual session between multiple servers. This would require shared database for the TLS session data, which would be used by all servers participating to serving the TLS connection. – Tero Kilkanen Mar 03 '18 at 12:31
  • @user120513 Having a separate DB server which needs to be accessed to process every incoming packet will lead to performance issues. If one wants to cache the session data on the individual servers, that leads to more complexity. Using the IP address for mapping clients can lead to performance issues. That is why the LB itself is used for terminating TLS sessions, and if needed, there are multiple LBs and multiple A records for the host name so that the DNS will handle the round-robin load balancing between LBs. – Tero Kilkanen Mar 03 '18 at 12:35
  • This should be done on app level, not lb level with a dedicated kv store like redis or Cassandra. The proposed solution is reinventing the wheel and making it square ;) – Gothrek Mar 03 '18 at 14:20
  • @TeroKilkanen can you please explain this in more detail “ This would require shared database for the TLS session data” – Frank Q. Jul 13 '22 at 16:31
0

You can do SSL pass-through via TCP stream proxies in Nginx

https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/

Andrew
  • 2,142
  • 2
  • 19
  • 25
  • How does it work, i.e. which of the options (if any) from the question do they choose ? This information seems not to be in the linked page. – user120513 Mar 02 '18 at 21:24
  • This would prevent nginx from handling the SSL data and offload that to the remote server directly. Most like your "option 3" and would "Let the load balancer pass SSL/TLS-encrypted data through to the servers". Are you trying to do something specific or trying to solve some specific problem? – Andrew Mar 02 '18 at 21:31
  • OK, I found the information in the link: "As the hash function is based on client IP address, connections from a given client are always passed to the same server". This corresponds to opt. 3. -- I'm trying to understand how https is handled basically with load balancing; no specific problem. – user120513 Mar 02 '18 at 21:51