Authenticated Proxy for development purposes - proxy

I am looking for a simple solution to start a squid-like proxy server that supports username/password authentication.
It should be able to tunnel HTTPS requests using CONNECT.

A docker-based solution is
docker run --rm -it -p 3128:8080 mitmproxy/mitmproxy mitmdump --set proxyauth=user:pass
The --ignore-hosts option also enables TLS pass-through for stuff like mTLS and certificates not signed by a trusted root (i.e. via. mkcert or self-signed).

Related

how to add a trusted CA for local Consul docker container

how to add a trusted CA for local Consul docker container?
So I have a consul running as a docker container and I am able to access it using chrome at localhost:8500 after exposing the ports, as expected. But due to company setting there is a security CA being added that chrome trusts, since it is added to MacOS keychain, but consul does not seems to trust when I try to use golang library to connect to consul
x509: “Menlo Security Intermediate CA” certificate is not trusted"
I get a certificate is not trusted error. I am able to export the CA to a RootCA.cer file from the keychain but how do I configure consul image to trust this CA file?
https://iotech.force.com/edgexpert/s/article/secure-consul-tls
I see articles like this
ca_file is used to check the authenticity of the client and server connections
cert_file is provided to clients and server to verify the agent's authenticity
key_file is used with the certificate to verify the agent's authenticity
but for me, the .cer export file will be used as cert_file?
how should I do it in docker compose?
consul:
image: dockerproxy.comp.com/consul:latest
ports:
- "9500:9500"

Can't connect to internet via SOCKS5 proxy server

I have configured SOCKS5 proxy server in AWS with dante and it runs fine.
when I try the following command in CMD
curl -L -x socks5://user:password#23.29.xx.xx:1313 http://www.google.com/
it works,
But when I configure my LAN proxy configs, it can't access to the internet via any browser.
for CURL proxy server works but for browsers it doesn't.
please help.
The reason for this is, I have enabled the user authentication in the server. Unlikely in HTTP proxy servers, there is no signin popup in socks5. This was fixed after I added the username and password.

How to disable Keycloak SSL when running Keycloak in Docker?

I have a Spring Boot application and in that I have done Keycloak integration with my REST API.
Now I want to build a Docker image for my app to host in the cloud.
First I tried:
docker container run -d -p 8081:8080 -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin jboss/keycloak
That was not working; I couldn't open the login screen for Keycloak.
So I tried this:
docker container run -p 8443:8443 -d -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin jboss/keycloak
Using this now I can login to Keycloak.
Then I tried disabling SSL in Realm->Login tab.
I can do this as this is my development environment and I am not much worried about SSL.
Is there any option of disabling SSL while running Keycloak in Docker?
If not how I can disable it?
If it is not possible to disable SSL in Keycloak while running on Docker, how can I integrate the SSL connection of Keycloak with the Spring Boot REST API?
If you're going to run a reverse proxy in front of Keycloak anyway, PROXY_ADDRESS_FORWARDING=true is what you're looking for.
This will disable the TLS requirement if you also send X-Forwarded-Proto: https in the header.
Running without TLS at all is not supported.
Documented here:
https://github.com/keycloak/keycloak-containers/blob/master/server/README.md#enabling-proxy-address-forwarding
Update the REALM table to disable requiring SSL by :
UPDATE REALM SET SSL_REQUIRED='NONE' WHERE ID=<RECORD_ID>;

Letsencrypt renewal fails: Could not bind to IPv4 or IPv6.. Skipping

The full error message I'm getting is:
Attempting to renew cert from /etc/letsencrypt/renewal/somedomain.com.conf produced an unexpected error: Problem binding to port 443: Could not bind to IPv4 or IPv6.. Skipping.
This is running on an AWS ubuntu 14.04 instance. All ports are open outgoing and 443 is open incoming.
You just need to stop all running servers like Apache, nginx or OpenShift before doing this.
Stop Nginx
sudo systemctl stop nginx
Stop Apache2
sudo systemctl stop apache2
you probably run the script with (preconfigurated) --standalone when your server is already running at port 443.
You can stop server before renew and start them after.
man says:
--apache Use the Apache plugin for authentication & installation
--standalone Run a standalone webserver for authentication
--nginx Use the Nginx plugin for authentication & installation
--webroot Place files in a server's webroot folder for authentication
--manual Obtain certificates interactively, or using shell script hooks
If I run renew with --apache I can't get any error.
As hinted in the other answers, you need to pass the option for your running webserver, for example:
Without webserver param:
sudo certbot renew
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges:tls-sni-01 challenge for example.com
Cleaning up challenges
Attempting to renew cert (example.com) from /etc/letsencrypt/renewal/example.com.conf produced an unexpected
error:
Problem binding to port 443: Could not bind to IPv4 or IPv6..
Skipping.
Then, again with the webserver param (success):
sudo certbot renew --nginx
Cert is due for renewal, auto-renewing...
Renewing an existing certificate
Performing the following challenges: tls-sni-01 challenge for example.com
Waiting for verification...
Cleaning up challenges
new certificate deployed with reload of nginx server; fullchain is
/etc/letsencrypt/live/example.com/fullchain.pem
Congratulations, all renewals succeeded. The following certs have been
renewed: /etc/letsencrypt/live/example.com/fullchain.pem (success)
[This is specifically for ubuntu]
Login as root user to your server
Stop your server using the following command (for nginx)
service nginx stop
Then renew your certificate
certbot renew
Start your server
service nginx start
[TIP] To check the expiry date of your renewed certificate, enter the command below
ssl-cert-check -c [Path_to_your_certificate]/fullchain.pem
For example
ssl-cert-check -c /etc/letsencrypt/live/[your_domain_name]/fullchain.pem
Or
ssl-cert-check -c /etc/letsencrypt/live/[your_domain_name]/cert.pem
If you don't have ssl-cert-check already installed in your server, install it using
apt install ssl-cert-check
Note: The certificate can be renewed only if it is not expired. If it is expired, you have to create new one.
For NodeJS/PM2 users
I was using PM2 for my NodeJS service and when trying to renew the certificate I also got the "Problem binding to port 80: Could not bind to IPv4 or IPv6." error message.
As mentioned in above answers for Apache/Ngnix, Stopping my service and then trying to renew solved the problem.
pm2 stop all
sudo certbot renew
pm2 start all
First you need to install NGiNX lets encrypt plugin (if you work with NGiNX):
sudo apt install python-certbot-nginx
Then you can safely run:
sudo certbot renew --nginx
and it will work.
Note: certbot should already be installed.
For ngnix
sudo certbot renew --nginx
This happened because you used --standalone. The purpose of that option is to launch a temporary webserver because you don't have one running.
Next time use the --webroot method, and you'll be able to use your already running nginx server.
Borrowing from #JKLIR Simply run
/etc/letsencrypt/letsencrypt-auto renew --apache >> /var/log/letsencrypt/renew.log
to renew the ssl certificate
If you're trying to perform the certbot command as a regular user, you may not have access to bind to port 80 and other lower ports. If this is the case, you can grant python access to bind via:
First, see if you can find python 3+ (adjust as needed)
echo "$(readlink -f "$(which python3)")"
Allow python to open port 80 as a regular user (adjust as needed)
sudo setcap CAP_NET_BIND_SERVICE=+eip "$(readlink -f "$(which python3)")"
Re-run the failing certbot command.
Important: On Ubuntu 18.04, Python is called python3. It may be called a number of different things depending on the OS and how you obtained certbot. This command WILL VARY between OSs.
Warning: These lower ports are restricted for good reason. There are security considerations with the setcap command. You may read more about them here: https://superuser.com/a/892391
I use Nginx and needed to stop the server before I can proceed. Then I run the command:
$ sudo ./certbot-auto certonly --standalone -d chaklader.ddns.net
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for chaklader.ddns.net
Waiting for verification...
Cleaning up challenges
Subscribe to the EFF mailing list (email: xxx.chakfffder#gmail.com).
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/cdddddder.ddns.net/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/chaklader.ddns.net/privkey.pem
Your cert will expire on 2045-01-10. To obtain a new or tweaked
version of this certificate in the future, simply run certbot-auto
again. To non-interactively renew *all* of your certificates, run
"certbot-auto renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
I had a similar issue when I was running two websites (hosts) on a single instance. I stopped Nginx and then ran sudo certbot certonly --standalone --preferred-challenges http -d domain.com -d www.domain.com. After restarting Nginx everything started to work fine.

etcd2 in proxy mode doesn't do anything useful

I have an etcd cluster using TLS for security. I want other machines to use etcd proxy, so the localhost clients don't need to use TLS. Proxy is configured like this:
[Service]
Environment="ETCD_PROXY=on"
Environment="ETCD_INITIAL_CLUSTER=etcd1=https://master1.example.com:2380,etcd2=https://master2.example.com:2380"
Environment="ETCD_PEER_TRUSTED_CA_FILE=/etc/kubernetes/ssl/ca.pem"
Environment="ETCD_PEER_CERT_FILE=/etc/kubernetes/ssl/worker.pem"
Environment="ETCD_PEER_KEY_FILE=/etc/kubernetes/ssl/worker-key.pem"
Environment="ETCD_TRUSTED_CA_FILE=/etc/kubernetes/ssl/ca.pem"
And it works, as far as the first connection goes. But the etcd client does an initial query to discover the full list of servers, and then it performs its real query against one of the servers in that list:
$ etcdctl --debug ls
start to sync cluster using endpoints(http://127.0.0.1:4001,http://127.0.0.1:2379)
cURL Command: curl -X GET http://127.0.0.1:4001/v2/members
got endpoints(https://1.1.1.1:2379,https://1.1.1.2:2379) after sync
Cluster-Endpoints: https://1.1.1.1:2379, https://1.1.1.2:2379
cURL Command: curl -X GET https://1.1.1.1:2379/v2/keys/?quorum=false&recursive=false&sorted=false
cURL Command: curl -X GET https://1.1.1.2:2379/v2/keys/?quorum=false&recursive=false&sorted=false
Error: client: etcd cluster is unavailable or misconfigured
error #0: x509: certificate signed by unknown authority
error #1: x509: certificate signed by unknown authority
If I change the etcd masters to --advertise-client-urls=http://localhost:2379, then the proxy will connect to itself and get into an infinite loop. And the proxy doesn't modify the traffic between the client and the master, so it doesn't rewrite the advertised client URLs.
I must not be understanding something, because the etcd proxy seems useless.
Turns out that most etcd clients (locksmith, flanneld, etc.) will work just fine with a proxy in this mode. It's only etcdctl that behaves differently. Because I was testing with etcdctl, I thought the proxy config wasn't working at all.
If etcdctl is run with --skip-sync, then it will communicate through the proxy rather than retrieving the list of public endpoints.
etcdctl cluster-health ignores --skip-sync and always touches the public etcd endpoints. It will never work with a proxy.
With option --endpoints "https://{YOUR_ETCD_ADVERTISE_CILENT_URL}:2379".
Because you configured TLS for etcd, you should add options --ca-file, --cert-file, --key-file.

Resources