You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2013/03/09 02:07:51 UTC
[Bug 54656] New: SNI and SSLProxyCheckPeerCN based on "connection"
instead of "request" hostname
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: bugs@httpd.apache.org
Reporter: eugenel@amazon.com
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/%3C50462600.7010607@kippdata.de%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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54656] SNI and SSLProxyCheckPeerCN based on "connection"
instead of "request" hostname
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54656
William A. Rowe Jr. <wr...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #3 from William A. Rowe Jr. <wr...@apache.org> ---
Earlier guidance on dev@httpd was misguided.
A similar problem is present for all forward-proxied requests.
The SNI defined hostname can only be used to help route the correct
certificate.
The SNI definition of a hostname is independent of the definition of the
HTTP Host: field and any assumptions that they would be identical is misguided.
The SNI hostname may not be an IP-address, while the Host: header may be.
The SNI hostname is the next-hop hostname (without a port), while the Host:
header
is the hostname (including optional port) component of the target URI. In the
forward proxy case, these always differ.
The SNI logic further fails to test alt-subject names, wildcard cn's and a host
of other design errors.
I expect your report has equal validity in light of these other design flaws
and
I'm evaluating this within the context of the current mis-implementation.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54656] SNI and SSLProxyCheckPeerCN based on "connection"
instead of "request" hostname
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54656
EugeneL <eu...@amazon.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #30029|0 |1
is obsolete| |
--- Comment #1 from EugeneL <eu...@amazon.com> ---
Created attachment 30172
--> https://issues.apache.org/bugzilla/attachment.cgi?id=30172&action=edit
new mod_ssl directive to use proxy-connection-hostname instead of
proxy-request-hostname for SNI and SSLProxyCheckPeerCN
re-uploading with proper content type
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
[Bug 54656] SNI and SSLProxyCheckPeerCN based on "connection"
instead of "request" hostname
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54656
EugeneL <eu...@amazon.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #2 from EugeneL <eu...@amazon.com> ---
Discussions on dev@httpd.apache.org last month suggests that backend webservers
behind reverse proxies should be obeying HTTP standards by always returning
certs that has a CN equal to the Host: header.
A next action should be to correct the ProxyPreserveHost documentation to warn
users against this new default behavior in 2.4
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org