I am using Apache 2.2.15 as reverse proxy and I would like to modify the requested address in the HTTP header.
Clients request:
https://nameA.domain.com (external DNS)
The reverse Proxy should change the request in the HTTP header to the internal host:
http://nameB.OTHERdomain.com (internal host)
I don't know how to manage this.
I added a picture:
SSL setup and everything else works.
I found it.
RequestHeader set Host "nameB.OTHERdomain.com"
Related
I have set up a reverse proxy in my Apache 2.4 virtual host configuration file. However, the additional headers such as API_KEY that get added by the authentication system are not being passed on to the server. How do I get Apache to include these headers? I have been able to find NO documentation on this...
This is the proxy line:
ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:8999/var/www/production/public/$1
I am having a backend that is not able when running behind a reverse proxy since I cannot configure a custom base URL.
For the login process the backend makes heavy use of HTTP redirects but due to the fact that is behind a reverse proxy it sends redirection URL that are not reachable by the client.
So I was wondering if there is a way to rewrite the upstream HTTP HEADER Location
If the backend responses
HTTP/1.1 301
Location: http://backend-hostname/auth/login
Caddy should rewrite the Location header to
HTTP/1.1 301
Location: http://www.my-super-site.com/service/a/auth/login
Is something like this possible?
I've that we can remove headers by declaring
header / {
- Location
}
but it possible to replace the header and rewrite the URL?
I was also looking for answer for this question and unfortunately I've found this responses:
https://caddy.community/t/v2-reverse-proxy-but-upstream-server-redirects-to-nonexistent-path/8566
https://caddy.community/t/proxy-url-not-loading-site/5393/7
TLDR:
You need to use sub-domains rather than sub-paths for services that are not design for being after proxy (or at least configure base URL). :(
I'm building a proxy chain to access an internal proxy from the outside with additional authentication:
Internet -> [Apache Forward Proxy] -> [Internal Squid Proxy] -> Internal Website
The Apache Forward Proxy is doing TLS including Certificate Based Authentication (CBA), the Squid Proxy requires basic auth with username / password. Authentication works as expected for both components.
Challenge is now to get the Apache to act as a Forward Proxy and to forward the Proxy-Authorization header from the user to the internal Proxy.
Here is the current configuration I'm using (mod_proxy and mod_proxy_connect are enabled):
# Enable forward proxy
ProxyRequests On
# Pass all requests on to the squid proxy
ProxyRemote * http://proxy.internal:3128
# Only allow proxy connect to port 443
AllowCONNECT 443
With this setup the Apache doesn't forward the Proxy-Authorization header to the internal proxy. All settings I could find for this topic (Proxy-Chain-Auth, ProxyAddHeaders, rewrite rules etc.) only work in Reverse Proxy mode using ProxyPass. But a Reverse Proxy doesn't fit here since in this mode the Apache modifies the header and the CONNECT for TLS webservers won't work.
The Apache doesn't forward any header fields from the client, in the end a request from the Apache to the internal Proxy looks like this:
CONNECT someserver.de:443 HTTP/1.0\r\n
Proxy-agent: Apache/2.4.18 (Ubuntu)\r\n
\r\n
I'm aware the Proxy-Authorization field is a Hop-by-hop field which is normally not allowed to passed to the next proxy.
Is it still possible to get the Apache to forward a Proxy-Authorization header to the internal Proxy when acting as Forward Proxy?
There is a bug for a related topic in the Apache bugtracker. But this one is to specify the username/password hard-coded in the apache config which is not what I need. I want to forward the client authorization individually.
https://bz.apache.org/bugzilla/show_bug.cgi?id=37355
We run a website which is hosted using WCF.
The website is hosted on: https://foo.com and the ssl certicate is registered using the following command:
netsh http add sslcert hostnameport=foo.com:443
When we browse the website on the server, all is fine, and the certificate is valid.
There is a loadbalance in front of the server which listens to bar.com and then redirects the request to our server.
The loadbalancer doesn't rewrite the get URL, but only the Host Header.
The rewritten header looks like this:
GET https://foo.com/ HTTP/1.1
Host: bar.com
Connection: keep-alive
Now we have some issues which indicates that the ssl certificate is invalid in this case.
The Loadbalancer itself has a certificate registered listening to https://bar.com
Questions:
Is it ok/allowed that the get URL and the Host in the http header are different?
If it is ok to have different values in the header, under which url should we run the site? get URL or Host url?
Well, referencing the RFC2616:
If Request-URI is an absolute URI, the host is part of the
Request-URI. Any Host header field value in the request MUST be
ignored.
So, back to your questions:
It is allowed but a bad idea as it will create confusion, better to use relative path. i.e.
GET /path HTTP/1.1
instead of
GET https://foo.com/path HTTP/1.1.
Modify the loadbalance configuration to do so. Or make the both values the same.
If Host header has a value different than the request URI, then the URI is taking priority over the Hosts header.
First of all I want to make clear that i am not talking about accessing content which is on origin servers that deliver using https which can be done using the module mod_proxy_connect.
What I want is a secured connection between the client and the proxy, also when the origin that is requested actually is served by an unsecured standard http server.
I am using apache 2.2 and also would like to make this possible with apache if that works.
I sniffed some requests using wireshark and noted the following:
A usual http of the url http://example.com/file looksl ike this:
on a connection to the origin server:
GET /file HTTP 1.1
Host: example.com
Note that the host information is stripped from the actual request and the host header is supplied instead (which can be handled server side in named virtual hosts).
When the request goes through a proxy server it looks slightly different:
on a connection to the proxy server:
GET http://example.com/file HTTP 1.1
Host: example.com
Note that the request line now actually contains the full url including protocol and hostname.
The host header is probably redundant, bus if I read the RFC correctly it is required by HTTP 1.1.
So I think about setting up an apache webserver listening on port 443, enable a virtualhost with ssl engine and certificates up and do not bind it to any hostname.
I think that should get apache to talk ssl, but however the certificates common name will not match the host specfied in the connect line to the proxys server ip adress.
Is what I want to to even possible with current standards and if so how can I do it?
Yes of course, that's what HTTPS proxy is.
Client connects to proxy over SSL, sends commands to proxy in text.
It is also possible to use HTTP CONNECT to establish HTTPS connection "inside" the SSL connection to HTTPS proxy, though not all clients support this:
HTTPS connection over HTTPS proxy
client proxy server
ssl \-------/ ssl
connect---------200 OK
ssl \---------------------------/ ssl
data-------------------------------data
/---------------------------\
/-------\
HTTP connection over HTTPS proxy
client proxy server
ssl \-------/ ssl
GET http://server/ ->
GET /
Host: server ->
<---------OK, data
<--------------OK, data
/-------\