On 21.02.2014 04:08, Yann Ylavic wrote:
> Similarly, a new "SSLProxyCheckPeerCN canon" option could be handled
> so that admins needing "ProxyPreserveHost on" could still forward the
> client's Host but check the backend's CN against ServerName.
It remains my humble opinion, that this behavior should be the default
-- as the most natural one. The connection from proxy to the back-end is
completely distinct from that between user-agent and the proxy. Although
SSL can be used to assure the proxy, it reached the correct back-end, it
should not matter to this verification, which host the user-agent asked
for in the other connection.
Suppose, for example, you call a corporate office... You dial the number
and the pleasant voice answers, stating, you've reached Acme Industries
and would you, please, state your business.
You do so and the employee decides, the matter is to be handled by
executive N. He puts you on hold, while he dials the executive via
internal line.
Would it not be silly for the secretary to drop both connections (to you
and to N.), if N. answers his phone as N., rather than as "Acme Industries"?
Just in case I'm not sufficiently clear, in the above example "you" are
the user's agent (browser), "Acme Industries" is a web-site, secretary
is the Internet-facing proxy, and N. is the back-end server...
Yours,
-mi
