I have SQUID as https froward proxy in my network. One of my application sends a SAOP request out of the network. The SOAP webservice needs client certificate for auth. I have configured the keystore and truststore for my application. Application is working fine directly without SQUID proxy.
It also works fine with SQUID tunneling (i.e. ssl_bump splice ).
But We do not want to use splice. We need SQUID to decrypt SSL traffic and also authenticate and pass the authentication certificate (client certificate) to webservice server.
What are the possible configurations for SQUID for this case ?
For information: SQUID proxy is working fine with HTTP and HTTPS traffic where client certificate for auth is not required. Example "https://www.google.com"
Related
I try to get Cloudflare work with my website.
I have my website running on port 80 and my api on port 8443.
My proxy doesn't have a ssl certificate, I rely only on the one on Cloudflare.
I have set ssl to flexible.
I can access my website, but when I make an API call to my api on port 8443, I have the following message : CloudFlare is unable to establish an SSL connection to the origin server.
Do I need to have a certificate on my proxy for the API ?
Thanks for your help.
It sounds like you're using Cloudflare's Flexible SSL option whereby traffic is unencrypted to the origin web server (but encrypted from Cloudflare's Edge to the end-user).
This setting will only work for port 443->80, not for the other ports Cloudflare supports like 2053 (or 8443 in your case).
If you want to serve SSL traffic through a port other than 443, you will need to ensure your web server is configured to work with Cloudflare in either Full or Full (Strict) SSL mode.
For more info:
What do the SSL options mean?
Okay, so I know that we can either forward HTTPS traffic via haproxy to backend servers intact or have SSL terminated at the proxy server, and let remaining course of the traffic be unencrypted. But is there a way to make haproxy work such that the traffic is decrypted at the server and recrypted before being sent to the backend nodes?
Basically I am getting half the job done with SSL termination, but I want traffic to be encrypted again once it leaves the proxy server.
Is this possible with haproxy on its own? or is there some other tool I could use in combination with haproxy to create and manage HTTPS/SSL sessions with backend servers?
Have you tried setting it up like this:
Haproxy terminates the SSL then, instead of forwarding the unencrypted traffic to your backend on a HTTP port, try forwarding it to a HTTPS port on the backend and wrap that in a self signed cert.
i.e:
SSL Traffic -> haproxy:443(domain cert) -> backend:443(internal cert)
I have set this up before and it worked fine
I have configured apache reverse proxy. In that configuration https connection is possible between client to reverse proxy and again reverse proxy to server. But I want https connection between client to server like forward proxy. The https connection should not be broken at reverse proxy.
Https tunnel New Https tunnel
<===============> <===================>
Client-----------------------Apache Reverse proxy ----------------------------Server
Above solution is not desirable.
Https Tunnel
<========================================>
Client--------------------Apache Reverse proxy ----------------Server
Above solution is desirable.
If end to end https tunnel is not possible in reverse proxy then how can it be ensured that ssl proxying option is safe and even the Reverse proxy administrator(if reverse proxy got compromised) can not decrypt the tunnel or man in middle attack can't be done.
You can't. Because HTTPS by design guarantees that the sender is talking to the receiver via certificates. Your proxy here would be "the man in the middle" :-)
See http://en.wikipedia.org/wiki/Reverse_proxy
In the case of secure websites, a web server may not perform SSL
encryption itself, but instead offloads the task to a reverse proxy
that may be equipped with SSL acceleration hardware. (See SSL
termination proxy.)
What you can do
Client------Apache Reverse proxy----SC--------------SS---------Server
HTTPS SSL HTTP
(listen to 443)
Where SC = Stunnel Client and SS = Stunnel Server
SC must run in the same machine as your apache reverse proxy, while SS must run in your server target.
I have built an application called Tun2Socks GUI. It's program to make Socks proxy o be transparent.
Usually it use SSH port forward or TOR as SOCKS service, but I want it can use HTTP proxy too. So I build SOCKS5 proxy my self that connect to that HTTP proxy. It's working good with capturing HTTP request from client to be sent to HTTP Proxy.
The problem when the client send SSL request, I cannot capture the request to be forwarded. How the best method to make SSL request from SOCKS proxy through HTTP Proxy?
Schema of request transportation like here :
Client SSL request > SOCKS Proxy > HTTP Proxy > Internet
Thanks
When a client intentionally wants to establish an SSL session with a target server through a proxy, it does not establish an SSL session with the proxy itself. The client first tells the proxy to establish a connection to the target server, and THEN the client initiates an SSL session with the target server. In that situation, it is not possible for the proxy to sniff the traffic as it is encrypted, nor should it be trying to. A proxy is just a pass-through, it exchanges raw data back and forth between client and server as needed. The proxy should not care what kind of requests the client is sending, since the client tells the proxy where to connect.
If you have injected your proxy in between the client and server in such a way that the client has no knowledge that your proxy exists, the client will not know that it needs to adjust its requests to make them proxy-friendly. The client will be connected to your proxy but it will think it is connected to the target server, and thus will initiate an SSL handshake that your proxy will have to respond to. Only then will your proxy have access to the client's request data (provided the handshake is successful, such as if the client does not verify peer certificates), and can then tunnel the unencrypted data to the next proxy as needed.
Update: I just thought of another scenario that should work for both cleartext and SSL connections. Regardless of whether you are transparently redirecting the client's outbound connection to your SOCKS proxy without the client knowing about it, or the client intentionally connects to the SOCKS proxy and tells it where to go, the SOCKS proxy knows the client's target host/IP:port. The SOCKS proxy can either connect directly to the target, or it can connect to the HTTP proxy and ask it to create a tunnel to the target via the HTTP CONNECT method. If successful, the client has a viable connection to the target, and any data the client sends, SSL or otherwise, will flow as-is to the target, and vice versa. Neither the SOCKS proxy nor the HTTP proxy needs to know anything about the client's request other than the target host/IP:port. That is in the initial SOCKS request, either captured from the intercepted TCP header, or explicit from the client.
I just read over node-tls-proxy (http://code.google.com/p/node-tls-proxy/), a https proxy. I like the idea of it, but I'm not getting why this proxy needs a local http server (see the local-proxy.js script).
So I was wondering if this is necessary?
My idea of the proxy was actually like this: Client -> HTTPS Connection to trusted Server/Proxy -> Internets
In this case network sniffing between the Client and the Server wouldn't (hardly) be possible because it would be ssl encrypted.
Thanks,
Seb
If I get the idea correctly, the goal is to set up a "remote" proxy in a location that one trusts to be secure. Your client shall only communicate with this remote proxy using TLS, the remote proxy is then allowed to do the actual (no longer encrypted) HTTP requests.
What you do on the client side now is this: you configure the "local" proxy in your browser. Since you type "http://..." in your browser even when using the proxy, your browser will initiate an unencrypted HTTP connection to the local proxy first. Then the local proxy will open an encrypted TLS connection to the remote proxy and forward your request over a secured channel.
This means you need the local proxy for the purpose of "transforming" HTTP into HTTPS requests because your browser will dutifully only use HTTP when asked to make an actual HTTP request.