To verify that you're talking to the remote server you want directly, two points are required:

• You need to check you trust the server certificate (typically done via RFC 3280/RFC 5280).
• You need to check that the certificate was issued for the host name you're trying to reach (RFC 2818 Section 3.1 and RFC 6125).

What constitutes that remote server is up to the service provider. You're confusing multiple kinds of proxy servers here.

• There are normal HTTP proxy servers that can be used for HTTPS connections. This is done using the HTTP CONNECT verb and the entire SSL/TLS traffic between the browser and the target server is merely relayed by the proxy server. As far as the SSL/TLS connection is concerned, this is roughly equivalent to IP routing: the proxy won't see anything.

• There are HTTP reverse proxy servers. This is what's discussed in the question you link to. However the request is then handled internally is up to the service provider.

  In the same way as for database connections, it may be useful for the service provider to protect its internal HTTP traffic using SSL/TLS, if the requests are served by HTTP worker nodes. In this case, the head node of the load-balancer/reverse proxy will be the client to those internal web servers.

  As far as you're concerned, the "true site" is the head node/reverse proxy. https://www.google.com/ certainly has more than just one box to handle the requests it gets. As far as you're concerned, the entire cluster behind it is the (big) machine.

• MITM proxy servers. Some HTTP proxy servers will be able to look into the HTTP traffic (for example Squid + SSL Bump). To do so, they will re-generate a certificate using their own Certification Authority on the fly. Such certificates will fail validation in your browser (step 1 above), unless your machine has explicitly been configured to trust this local CA.

To verify that you're talking to the remote server you want directly, two points are required:

• You need to check you trust the server certificate (typically done via RFC 3280/RFC 5280).
• You need to check that the certificate was issued for the host name you're trying to reach (RFC 2818 Section 3.1 and RFC 6125).

What constitutes that remote server is up to the service provider. You're confusing multiple kinds of proxy servers here.

• There are normal HTTP proxy servers that can be used for HTTPS connections. This is done using the HTTP CONNECT verb and the entire SSL/TLS traffic between the browser and the target server is merely relayed by the proxy server. As far as the SSL/TLS connection is concerned, this is roughly equivalent to IP routing: the proxy won't see anything.

• There are HTTP reverse proxy servers. This is what's discussed in the question you link to. However the request is then handled internally is up to the service provider.

  In the same way as for database connections, it may be useful for the service provider to protect its internal HTTP traffic using SSL/TLS, if the requests are served by HTTP worker nodes. In this case, the head node of the load-balancer/reverse proxy will be the client to those internal web servers.

  As far as you're concerned, the "true site" is the head node/reverse proxy. https://www.google.com/ certainly has more than just one box to handle the requests it gets. As far as you're concerned, the entire cluster behind it is the (big) machine.

• MITM proxy servers. Some HTTP proxy servers will be able to look into the HTTP traffic (for example Squid + SSL Bump). To do so, they will re-generate a certificate using their own Certification Authority on the fly. Such certificates will fail validation in your browser (step 1 above), unless your machine has explicitly been configured to trust this local CA.

To verify that you're talking to the remote server you want directly, two points are required:

• You need to check you trust the server certificate (typically done via RFC 3280/RFC 5280).
• You need to check that the certificate was issued for the host name you're trying to reach (RFC 2818 Section 3.1 and RFC 6125).

What constitutes that remote server is up to the service provider. You're confusing multiple kinds of proxy servers here.

• There are normal HTTP proxy servers that can be used for HTTPS connections. This is done using the HTTP CONNECT verb and the entire SSL/TLS traffic between the browser and the target server is merely relayed by the proxy server. As far as the SSL/TLS connection is concerned, this is roughly equivalent to IP routing: the proxy won't see anything.

• There are HTTP reverse proxy servers. This is what's discussed in the question you link to. However the request is then handled internally is up to the service provider.

  In the same way as for database connections, it may be useful for the service provider to protect its internal HTTP traffic using SSL/TLS, if the requests are served by HTTP worker nodes. In this case, the head node of the load-balancer/reverse proxy will be the client to those internal web servers.

  As far as you're concerned, the "true site" is the head node/reverse proxy. https://www.google.com/ certainly has more than just one box to handle the requests it gets. As far as you're concerned, the entire cluster behind it is the (big) machine.

• MITM proxy servers. Some HTTP proxy servers will be able to look into the HTTP traffic (for example Squid + SSL Bump). To do so, they will re-generate a certificate using their own Certification Authority on the fly. Such certificates will fail validation in your browser (step 1 above), unless your machine has explicitly been configured to trust this local CA.

To verify that you're talking to the remote server you want directly, two points are required:

• You need to check you trust the server certificate (typically done via RFC 3280/RFC 5280).
• You need to check that the certificate was issued for the host name you're trying to reach (RFC 2818 Section 3.1 and RFC 6125).

What constitutes that remote server is up to the service provider. You're confusing multiple kinds of proxy servers here.

• There are normal HTTP proxy servers that can be used for HTTPS connections. This is done using the HTTP CONNECT verb and the entire SSL/TLS traffic between the browser and the target server is merely relayed by the proxy server. As far as the SSL/TLS connection is concerned, this is roughly equivalent to IP routing: the proxy won't see anything.

• There are HTTP reverse proxy servers. This is what's discussed in the question you link to. However the request is then handled internally is up to the service provider.

  In the same way as for database connections, it may be useful for the service provider to protect its internal HTTP traffic using SSL/TLS, if the requests are served by HTTP worker nodes. In this case, the head node of the load-balancer/reverse proxy will be the client to those internal web servers.

  As far as you're concerned, the "true site" is the head node/reverse proxy. https://www.google.com/ certainly has more than just one box to handle the requests it gets. As far as you're concerned, the entire cluster behind it is the (big) machine.

• MITM proxy servers. Some HTTP proxy servers will be able to look into the HTTP traffic (for example Squid + SSL Bump). To do so, they will re-generate a certificate using their own Certification Authority on the fly. Such certificates will fail validation in your browser (step 1 above), unless your machine has explicitly been configured to trust this local CA.