httpoxy - does TLS/SSL mitigate the vulnerability of HTTP Proxy header?

I did not know about this until I read the link you posted, so do not view this answer as authorative. I would recommend you to take the precautions listed under "Immediate Mitigation" now, until you are completely sure you are not affected.

First, how does this vulnerability work? This is a short form of the PHP example explained under "How it works":

1. The attacker sends a request with the Proxy header set to an evil IP controlled by the attacker.
2. If the server runs CGI, the values of all headers end up in getenv("HTTP_NAME_OF_HEADER"), or in this case getenv("HTTP_PROXY").
3. If the script running on the server also uses an HTTP client (like Guzzle) to send requests of its own, it might also read getenv("HTTP_PROXY"), but not to get the header but to know if it should use a proxy for the outgoing traffic. The IP sent by the attacker will then be used as a proxy.
4. The attacker can now MITM all the outgoing requests the server makes.

The important thing to note is that there are two requests being made here:

• A. One in step #1, where the attacker makes a request to the vulnerable server.
• B. One in step #3, where the vulnerable server acts as a client and makes a request somewhere else.

If you use HTTPS for A it does not matter (I guess that is what "sites served via TLS" would mean). It gets encrypted to plain old HTTP anyway. So you are vulnerable.

However, if you use HTTPS for B it can matter, since (as hectorct pointed out in comments) the attacker will not be able to MITM the request anyway, assuming the client checks the certificate and the TLS is good and so on. It is that second request that they are talking about in these passages (my highlight):

A few things are necessary to be vulnerable:

• Code running under a CGI-like context, where HTTP_PROXY becomes a real or emulated environment variable
• An HTTP client that trusts HTTP_PROXY, and configures it as the proxy
• That client, used within a request handler, making an HTTP (as opposed to HTTPS) request

And, of course, another defense-in-depth strategy that works is to use HTTPS for internal requests, not just for securing your site’s connections to the outside world. Those aren’t affected by HTTP_PROXY.