https://issues.apache.org/bugzilla/show_bug.cgi?id=54656
Bug ID: 54656
Summary: SNI and SSLProxyCheckPeerCN based on "connection"
instead of "request" hostname
Product: Apache httpd-2
Version: 2.4.3
Hardware: All
OS: Linux
Status: NEW
Severity: major
Priority: P2
Component: mod_ssl
Assignee: [email protected]
Reporter: [email protected]
Classification: Unclassified
Created attachment 30029
--> https://issues.apache.org/bugzilla/attachment.cgi?id=30029&action=edit
new mod_ssl directive to use proxy-connection-hostname instead of
proxy-request-hostname for SNI and SSLProxyCheckPeerCN
It seems that `SSLProxyCheckPeerCN on` doesn't work well with
`ProxyPreserveHost on`. I have a patch for a new directive that would allow
it.
The use case: An Apache-based reverse proxy gets https traffic for multiple
domains: e.g. CN=www.example.com, CN=www.example.org, etc. The reverse proxy
has `ProxyPreserveHost on` so that multiple domains can be served by the same
backend server (e.g. backend.example.com) . The backend server recovers the
requested domain by inspecting Host header (I know there's also
X-Forwarded-Host, but let's say the backend isn't running Apache or anything as
extensible). Unlike the reverse proxy, the backend server has only one SSL
port, which has the backend domain name in its cert's CN (e.g.
CN=backend.example.com).
The problem: When a request with Host: www.example.com is handled by the
reverse proxy, mod_proxy_http assigns "www.example.com" to the
proxy-request-hostname connection note. ssl_engine_io.c will pull out this
note and use it for SNI and SSLProxyCheckPeerCN. Unfortunately,
www.example.com does not match backend.example.com. ssl_engine_io.c will abort
the connection like so:
[Tue Mar 05 02:27:51.522901 2013] [ssl:info] [pid 12902] [remote 1.2.3.4:1443]
AH02005: SSL Proxy: Peer certificate CN mismatch: Certificate CN:
backend.example.com Requested hostname: www.example.com
[Tue Mar 05 02:27:51.522923 2013] [ssl:info] [pid 12902] [remote 1.2.3.4:1443]
AH01998: Connection closed to child 0 with abortive shutdown (server
reverse-proxy-1.example.com:443)
Previous discussion here ...
http://mail-archives.apache.org/mod_mbox/httpd-dev/201209.mbox/%[email protected]%3E
... suggests that the 2.4.3 is the "correct" behavior. I believe it is correct
only when X-Forwarded-Host can be used. But if ProxyPreserveHost is on and the
backend server is truely doing "mass name-based virtual hosting" and doesn't
have all the certs, then it seems the Apache-based reverse proxy should be not
be picky about the mismatch. The reverse proxy shouldn't expect
CN=www.example.com, CN=www.example.org, etc. when the backend only has
CN=backend.example.com.
My proposed fix: Patch mod_proxy_http to also add a note named
"proxy-connection-hostname" which will always refer to the hostname in the
ProxyPass or [proxy] RewriteRule. Then, depending on a new directive
(SSLProxyHostnameSource) mod_ssl will consult either proxy-request-hostname or
proxy-connection-hostname to perform SNI and SSLProxyCheckPeerCN.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
