I have an upstream proxy that requires HTTPS. I want all traffic to use this parent proxy. My current configuration looks like
acl localnet src 172.0.0.0/8 # RFC 1918 local private network (LAN)
acl localnet src 192.168.0.0/16 # RFC 1918 local private network (LAN)
http_access allow localhost manager
include /etc/squid/conf.d/*.conf
http_access allow all
http_port 3128
cache_peer myproxy.provider.com parent 443 0 default login=username:password tls ssldomain=myproxy.provider.com
never_direct allow all
When attempting to connect I get 502 Bad Gateway and looking at packet traces I see the Client Hello does not include the SNI field to my proxy provider (I'm expecting to see myproxy.provider.com).
I'm using squid 5.2, inside this docker container https://hub.docker.com/r/ubuntu/squid .
Log entries for an HTTPS request through this proxy and an HTTP request through this proxy are below:
1663639170.630 404 172.17.0.1 TCP_TUNNEL/502 0 CONNECT ipinfo.io:443 - FIRSTUP_PARENT/<ipaddr> -
1663642918.552 437 172.17.0.1 TCP_MISS/502 3901 GET http://ipinfo.io/ - FIRSTUP_PARENT/<ipaddr> text/html
How can I configure Squid to use the cache_peer hostname as the SNI field in the TLS session setup? I feel like I'm missing something fundamental here but can't find docs that help.
Related
I am new to Haproxy, and would like to learn how I go about writing the conf file to proxy to a secure website.
I currently am testing from localhost. What I basically want to do is if I enter localhost on my browser, it should proxy it to www.site24x7.com. The site has a SSL certificate. On following the guides, it all always ends in a 400 Bad request. My haproxy.cfg is below.
This is not a complete haproxy.cfg. I am not sure what all to put here. Since site24x7 has its own SSL certificate, do I provide my own cert? (can use a self-signed cert for now). I tried SSL Pass Through with Haproxy as well instead of SSL termination, but similar 400 Bad request.
frontend www-http
bind *:80
reqadd X-Forwarded-Proto:\ http
default_backend www-backend
backend www-backend
#redirect scheme https if !{ ssl_fc } #dont know about this
server www-1 www.site24x7.com:443 check
server www-1 www.site24x7.com:443 check ssl verify none
Either
curl http://127.0.0.1 -H "Host: www.site24x7.com"
or
mode http
http-request set-header Host www.site24x7.com
server www-1 www.site24x7.com:443 check ssl verify none
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
I am working with a Golang app and Caddy as the HTTP server. The golang app rejects every http connection, it only can be used over HTTPS. This app is a kind of API/service that is consumed by other apps. As, it requires HTTPS I installed Caddy so I can take advantage of the automatic SSL certificate and use proxy to switch between the ports.
The application is running in the port 9000, so, the consumers will only writte mysite.com and caddy should be in charge of redirect that petitions to the port 9000 but maintaining the HTTPS. The configuration in caddy for the site is:
mysite.com {
proxy / :9000 {
max_fails 1
}
log logfile
}
Nevertheless, it seems like when the proxy is made the HTTPS is lost. I checked the logs for the application (no the logs of caddy) and I get this:
http: TLS handshake error from xxx.xxx.xxx.xxx:xxxx: tls: oversized record received with length 21536
So, based in this error, to me looks like the HTTP proxy made by caddy is losing the HTTPS. What can I do?
From the caddy docs
to is the destination endpoint to proxy to. At least one is required,
but multiple may be specified. If a scheme (http/https) is not
specified, http is used. Unix sockets may also be used by prefixing
"unix:".
So maybe it is sending http requests to the proxied https endpoint.
Does
mysite.com {
proxy / https://localhost:9000 {
max_fails 1
}
log logfile
}
fix it?
If that is the case, you may not strictly need your app on :9000 to listen https. It may simplify your deployment or cert management to just have it listen http and have caddy manage all the certs.
In order to test every possible solution to get Socket.io working with a parallel Apache installation, I have now installed HAproxy that listens on port 80. It proxies everything to Apache, unless the hostname equals io.server.com.
We have two IPs connected to our server: 1 is for SSL, the other for all the NON-SSL subdomains we have. I have created the io.server.com subdomain to point to that NON-SSL IP-address. However, the following this occurs:
A visit to regular_http.server.com results in Apache handling that sub domain (OK)
A visit to io.server.com results in "Welcome to Socket.io" (OK)
Next visit to regular_http.example.com results in "Welcome to Socket.io"
Why is HAproxy sending requests from a subdomain not configured to go to Socket.io, to Socket.io ?
Yes, the two sub domains share the IP, but is HAproxy really proxying the whole IP under one? What is then the point with setting up ACLs based on host name?
Here's my configuration:
global
daemon
maxconn 4096
user haproxy
group haproxy
defaults
log global
#this frontend interface receives the incoming http requests
frontend http-in
mode http
bind *:80
timeout client 86400000
#default behavior sends the requests to apache
default_backend www_backend
#when "io.test.tld" is matched, an acl I call arbitrarily
# "websocket" triggers
acl websocket hdr_end(host) -i io.server.com
use_backend node_backend if websocket
Thank you!
This problem was solved using the option http-server-close configuration value in HAproxy.
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
/-------\