Correct. The browser (or whatever the SSL client is) remains the SSL client and you backend server remeains the SSL server, without local encryption. This is end-to-end encryption, and haproxy would never be able to access the plaintext.
In this case/proposal, haproxy would make health checks with SSL verification enabled, and when it fails, it would mark the server down, so that connections would no longer be established to that server (that’s what normal load-balancing with health checks does).
Connections from clients would still be end-to-end, and haproxy would still not verify the backend server certificate for every connection that is passed through (only health-checks, which impacts new connections indirectly, because haproxy would not send traffic to backend servers that are declared down).
Encrypting/decrypting SSL on the proxy is a common enough configuration; but I don’t know what your requirements are and what you actually want to achieve, so I can’t give you any indications about what is “correct” or “incorrect”.
If you are terminating SSL on haproxy, you need to trust haproxy, because it means unencrypted traffic is handled by haproxy internally (and in memory). But (when we are talking about HTTP for example) you will be able make load-balancing decisions based on HTTP headers, use cookies for persistence, etc.
If you want the proxy to only handle encrypted traffic, maintaining end-to-end encryption between the client and the server, then you need to pass it through without local SSL termination. You won’t be able to access or modify application data, so cookie persistence will not work.