As far as I can tell tinyproxy simply does not support incoming HTTPS connections. It will permit you to access HTTPS sites by using the CONNECT method, but for that to be used, the browser/client must know that it is talking to a proxy server, and use the correct connection methods.
The ConnectPort directives simply defines which ports it is permissible ...
I am not sure,but please take a look with this checklist:
Edit the the squid.conf file and change the following line to enable transparent proxy mode:
http_port 3128 intercept
service squid restart
service squid reload
Add an entry to iptables NAT table to port-forward inbound traffic on the inside interface (LAN side) to the Squid ...
Here it means that Caddy doesn't modify the request by stripping out the HTTP Host header when passing the request to your web server in Docker container.
These can be the reasons why it is required now:
Your blog software was updated and now it wants Host header to match the hostname set up in the software.
Caddy's proxying behaviour was modified so that ...
I'm not sure i get the whole picture but since you are writing about websites i think you are using a tool that is not exactly suitable for the task.
imho you are looking for that information (the visited domain name) at the wrong level: you should have a proxy and analyze its logs to gather that info.
A proxy is 'near' the client and has the exact and ...
Most likely their content filter, edge devices, or DNS servers are registering a lot of hits to chat.google.com (or whatever). If you're using SSL, then it's likely that they're only monitoring what you're connecting to and not the content of the chat itself.
You cannot easily determine what the user typed into their browser's URL bar using just an IP address log: You can't tell if someone accessing 220.127.116.11 got there by typing aviation.stackexchange.com or tex.stackexchange.com (the best you can determine is that it's a CloudFlare IP address).
In order to get the information you seek you would need to ...
You are tackling this problem at the wrong layer. Literally, layer 4 when you should use layer 7.
Don't log TCP connections in iptables. Instead, capture HTTP traffic and inspect the Host header in the requests that the clients are making.
I know this is an old question, but if the OP only wants to blacklist/whitelist certain domain names, they don't have to use a proxy at all, they could just use a DNS based blacklist.
setup your onsite DNS servers to return 127.0.0.1 for any domain you want to blacklist
at your internet gateway block all IPs except your DNS servers from accessing TCP/UDP ...
but all the ones I found describe the creation of a certificate pair to decrypt/re-encrypt the traffic - something I do not want to do.
What you are asking for simply isn't possible because of how the https protocol works. Your options are:
Permit outgoing https through your firewall, and don't attempt to use any proxies
Configure clients to use your ...
Just some basic info about this topic.
There are only a few devices that I know of that can succesfully pull off this action. However they are not really available to the common public. I myself am using a Fortinet Fortigate with SSL Offloading.
What it basically does is; it intercepts the SSL Connection made to the host and decrypts the connection in ...
On SUse 11 Sp2
node01:~ # grep TPROXY /boot/config-3.0.38-0.5-default
node01:~ # uname -r
I don't know the kernel version of ubuntu 14, but anyway, try grep in your kernel config under /boot Filesystem
Thank you all for your time to answer. Basically what I'm trying to do is to proxy the outgoing/originated traffic of the 2nd container (NOTE: I'm NOT trying to proxy the incoming traffic, so cannot use the Apache mod_proxy or Nginx proxy_pass. These modules works for incoming traffic). 1st container runs a proxy service on port 8080.
As Thierno suggested I ...
Doing any kind of proxying based on the DNS hostname used also requires that the application protocol carries the host header in some way.
To my knowledge there are no such headers involved in FTP, so I don't see how this will be possible. Maybe with a custom FTP proxy, that sends you to different servers based on the username or something like that.
You simply need a new server block with the server_name set to the second domain and a proxy_pass in the location. If you need it to be https you can list either another certificate, or the same certificate if it has the correct alternate names. This is covered in the Nginx beginners guide.
listen 443 ssl ...
Well... There is a lot to say about your iptables rules (for exemple the state ESTABLISHED should be first)... But about the specific problem you are asking for, remember that INPUT is for incoming traffic ending locally, not for traffic going through, about which you should use FORWARD for that.
Yes, it is possible. You can use policy routing in Linux machine to redirect traffic to squid proxy as shown in this page.
To summarize the steps:
Setup mangle rule in iptables to mark traffic to be redirected.
Setup another routing table with default route towards squid machine.
Setup an IP rule to use the new defined routing table when packet is marked ...
How proxies work
How a transparent proxy works
The browser thinks it is talking to the web server, and the proxy intercepts this traffic, and performs whatever tasks it needs to.
How an explicit proxy works
The browser knows it is talking to a proxy, and asks the proxy to load up the site that it wants to load instead.
Benefits of each type
Meowbify is in fact open source, so you can take a look at the code on github and inspire yourself as need be: https://github.com/mobify/meowbify
It uses a pretty simple means of encoding the desired URL: cat/cats to designate http or https protocol, then the original hostname, then .meowbify.com, and then the path and query string as they are in the ...
Here's what you should do to redirect the traffic from one host to another one in a specific port, please note that EVERY request for port 443 will be redirect to the host you are pointing on iptables:
1) Open port 443 to traffic:
iptables -A INPUT -p tcp -m tcp --sport 443 -j ACCEPT
iptables -A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
2) Add specific ...
Transparent HTTP proxying typically has little to no impact to user sessions in my experience.
Your strategy and what you actually intend to accomplsih seems unclear to me, though. I think the reality of how HTTP works is going to present a problem for you. Perhaps you can talk more about what you're really trying to accomplish from an end-result ...
Best practices are to separate the role of network firewall from everything else. Generally.
The reasoning behind this is that the more software you have running alongside your firewall, the greater the risk of it becoming compromised through a bug in other software -- and if someone compromises your firewall, they effectively own your network (or at least ...
Just confirming, you don't want the SSL to terminate at the load balancer? So your backend server is going to be serving up https.
This is what I'd do. Under Ubuntu or debian.
Setup a couple of servers as your loadbalancer/proxy servers (for HA if you want it). They don't really need to be super high end but reasonable.
1) Install keepalived
Found this in the apache server access logs
192.168.1.70 - - [02/Oct/2014:16:20:02 -0300] "GET /wpad.dat HTTP/1.1" 404 493 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36"
Firefox, is attempting to fetch the file from http://wpad/wpad.dat instead of http://wpad.example.com/...