httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 55866] When ProxyPreserveHost is on, SSL expects the wrong CN from the backend
Date Thu, 12 Dec 2013 01:01:50 GMT

--- Comment #3 from Mikhail T. <> ---
(In reply to Yann Ylavic from comment #1)
> If your backend does not use the same host name (and hence certificate CN)
> the client is requesting on the frontend, you shouldn't use
> ProxyPreserveHost (or expect SSLProxyCheckPeerCN to accept the peer
> certificate).

I'm using ProxyPreserveHost because the back-end's behavior depends on the
Host-header, that's simple enough. In our particular case, the back-end needs
to set a cookie for mod_auth_form. Though cookie-verification happens on the
front-ends, the cookie-settings is proxied to the central server.

That central server is setting the same cookie for dozens (if not hundreds) of
domains. Placing them all into its certificate -- and remaking the certificate
each time a new front is added -- is impractical. The cookie-issuing back
should not even need to know about all possible fronts -- indeed, there may be
an infinite number of them.

Nor should it be necessary -- the purpose of using SSL on the proxy->back
connection is to ensure the integrity of THAT connection only. The
client->proxy may or may not even be using SSL at all, but the SSL's rejection
of the back-end should signal the danger of back-end having been hijacked.

Disabling SSLProxyCheckPeerCN defeats the major purpose of using SSL --
allowing man-in-the-middle attack against the proxy->back connections.

> Possible duplicate of Bug 54656.

Well, they are related, yes. And I agree with William's comment-3 there. But
whereas Bug 54656 seeks to add a new configuration directive to allow turning
the alternative behavior on, I argue, that the current behavior is plainly
incorrect and ought to be corrected.

You are receiving this mail because:
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message