When you use a re-webber proxy (a website where you enter a URL and it shows you the content of that url in its own context), using TLS between you and the end-website becomes impossible, even when the proxy would want to provide it.
When you enter https://google.com
in the proxy you linked, you get redirected to https://www.zend2.com/vip3.php?u=RyhEPtB1SQ6bFRGMjVSDaC2jhw%3D%3D&b=29
. Note that the domain you connect to is https://www.zend2.com
. That's the domain you make your TLS handshake with. Anything else would lead to a certificate warning, because your browser expects a valid certificate from www.zend2.com
, not from google.com
. The proxy then does its own TLS handshake with the destination site, requests the content, decrypts it, COULD look at it, re-encrpyts it for you and sends it to you.
You might also notice that this service performs a man-in-the-middle attack right before your eyes! It adds its own HTML code to each website you load through it, even when you load it through HTTPS. This code includes Javascript, which is executed in the context of the website you load. They could use this for all kinds of XSS attacks when they would want to. The website demostrated that they can and will manipulate any content you access through it, so you should not use it to send or access any confidential information.
To avoid this, do not use a rewebber service. Use a proxy server properly by entering it into the connection settings for your web browser. In that case your web browser is aware that it is using a proxy server and will expect a TLS certificate from the actual destination, not from the proxy. Any eavesdropping or manipulation by the proxy become impossible in that case.