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 2015/02/21 01:29:44 UTC
[Bug 57615] New: HTTPS CONNECT target hostname incorrectly validated
against HTTPS SNI hostname, which prevents CONNECTions to anywhere but the
same hostname
https://bz.apache.org/bugzilla/show_bug.cgi?id=57615
Bug ID: 57615
Summary: HTTPS CONNECT target hostname incorrectly validated
against HTTPS SNI hostname, which prevents CONNECTions
to anywhere but the same hostname
Product: Apache httpd-2
Version: 2.4.10
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mod_ssl
Assignee: bugs@httpd.apache.org
Reporter: smkent@extrahop.com
Given the scenario:
- Client wants to connect through HTTPS proxy to destination (using the CONNECT
method).
- The proxy HTTPS server has multiple configured HTTPS VirtualHosts on the same
port (443). Only one of the hosts allows proxying (using mod_proxy_connect and
AllowCONNECT), and that host is selected by the client using SNI when the
connection is first established.
Perhaps easier, this is the intended conversation with the proxy server:
- Client: Opens SSL connection to proxy.example.com, with the SNI hostname
"proxy.example.com"
- Client: "CONNECT destination.example.com:80 HTTP/1.1"
- Client: "Host: proxy.example.com:443"
- Proxy server: "HTTP/1.0 200 Connection Established"
- Further data sent over this connection is proxied to destination.example.com
HERE'S THE BUG: Apache incorrectly validates the hostname of the CONNECT
request, rather than the hostname from the Host request header, against the
destination hostname. This results in a conversation such as:
- Client: Opens SSL connection to proxy.example.com, with the SNI hostname
"proxy.example.com"
- Client: "CONNECT destination.example.com:80 HTTP/1.1"
- Client: "Host: proxy.example.com:443"
- Proxy server: "HTTP/1.0 400 Bad Request"
In other words, the target hostname in the CONNECT request currently must match
the SNI certificate hostname in the initial connection request. --> This
prevents CONNECT requests to anywhere but the local machine. It is currently
not possible to allow CONNECT proxying through an HTTPS virtualhost if more
than one is configured in Apache.
I believe the cause of this bug is in two parts.
FIRST PART: I'm not sure how Apache populates request_rec.hostname, but it
appears that value can come from *either* the Host header or the request URI.
In the case of CONNECT requests, this seems to come from the request URI
(CONNECT destination). Hostname validation fails in
modules/ssl/ssl_engine_kernel.c around line 200. I can solve this by not
running this check if the request method is CONNECT (see attached for this
patch), but that's probably not the best solution here. Instead, request_rec
should be populated with the contents of the Host header for CONNECT requests,
but I don't know where in the code that occurs.
SECOND PART: With the temporary patch above applied, I still can't CONNECT to
anywhere but the same hostname. Instead of a 400 Bad Request, I receive a 405
Method Not Allowed. I have verified that the request is reaching the correct
virtual host, but it appears the hostname is still being compared against the
VirtualHost's ServerName or something similar. I looked briefly but I am not
familiar enough with Apache's code base to find where this happens.
If CONNECT requests are to work on HTTPS proxies that use SNI to distinguish
VirtualHosts, then both of the above parts should be fixed.
Thanks.
--
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 57615] HTTPS CONNECT target hostname incorrectly validated
against HTTPS SNI hostname, which prevents CONNECTions to anywhere but the
same hostname
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57615
--- Comment #1 from Stephen Kent <sm...@extrahop.com> ---
Created attachment 32503
--> https://bz.apache.org/bugzilla/attachment.cgi?id=32503&action=edit
Skip SNI hostname validation for CONNECT method requests
--
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 57615] HTTPS CONNECT target hostname incorrectly validated
against HTTPS SNI hostname, which prevents CONNECTions to anywhere but the
same hostname
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57615
Kaspar Brand <as...@velox.ch> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |RESOLVED
Resolution|--- |WORKSFORME
--- Comment #3 from Kaspar Brand <as...@velox.ch> ---
Closing due to lack of feedback from reporter.
--
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 57615] HTTPS CONNECT target hostname incorrectly validated
against HTTPS SNI hostname, which prevents CONNECTions to anywhere but the
same hostname
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57615
Kaspar Brand <as...@velox.ch> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #2 from Kaspar Brand <as...@velox.ch> ---
(In reply to Stephen Kent from comment #0)
I have quite some doubts that this applies to 2.4.10 - did you really reproduce
it with this specific version?
A fix similar to the one you're proposing was originally suggested on httpd-dev
in December 2013 [1], and somewhat more generic solution was finally backported
to 2.4.8 with r1573362.
> SECOND PART: With the temporary patch above applied, I still can't CONNECT
> to anywhere but the same hostname. Instead of a 400 Bad Request, I receive a
> 405 Method Not Allowed.
This might be caused by mod_proxy_connect not being loaded in your setup.
> If CONNECT requests are to work on HTTPS proxies that use SNI to distinguish
> VirtualHosts, then both of the above parts should be fixed.
Just for the records: this continues to be non-standard use of the CONNECT
method. As discussed in [1], the RFCs don't apply to CONNECT requests being
sent in a TLS protected connection - section 4.3.6 in RFC 7231 (from the series
of the rewritten HTTP/1.1 RFCs) states:
> Tunnels
> are commonly used to create an end-to-end virtual connection, through
> one or more proxies, which can then be secured using TLS (Transport
> Layer Security, [RFC5246]).
(note the "which can then [...]")
[1]
https://mail-archives.apache.org/mod_mbox/httpd-dev/201312.mbox/%3C52B08B29.9060907%40velox.ch%3E
--
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