I'm trying to set up a proxy server on my local mac.
http - seems to work.
But Safari is not connecting via https.
Did I miss something?
No it doesn't. You need to specify a separate https port and a ssl certificate, as documented in the squid config:
The socket address where Squid will listen for client requests made
over TLS or SSL connections. Commonly referred to as HTTPS.
This is most useful for situations where you are running squid in
accelerator mode and you want to do the TLS work at the accelerator
level.
You may specify multiple socket addresses on multiple lines, each
with their own certificate and/or options.
The tls-cert= option is mandatory on HTTPS ports.
See http_port for a list of modes and options.
http://www.squid-cache.org/Doc/config/https_port/
By design, it is quite hard to intercept https traffic:
When a browser creates a direct secure connection with an origin
server, there are no HTTP CONNECT requests. The first HTTP request
sent on such a connection is already encrypted. In most cases, Squid
is out of the loop: Squid knows nothing about that connection and
cannot block or proxy that traffic.
You also need to load the proxy settings for the browser as a PAC file, otherwise the browsers won't connect or throw a certificate warning:
Chrome The Chrome browser is able to connect to proxies over SSL
connections if configured to use one in a PAC file or command line
switch. GUI configuration appears not to be possible (yet).
More details at
http://dev.chromium.org/developers/design-documents/secure-web-proxy
Firefox The Firefox 33.0 browser is able to connect to proxies over
TLS connections if configured to use one in a PAC file. GUI
configuration appears not to be possible (yet), though there is a
config hack for embedding PAC logic.
There is still an important bug open:
Using a client certificate authentication to a proxy:
https://bugzilla.mozilla.org/show_bug.cgi?id=209312
https://wiki.squid-cache.org/Features/HTTPS
Related
I'm working on a desktop C++ application which uses OpenSSL sockets (a raw TLS socket, not HTTPS) to communicate with our server.
One of our clients are required to route their traffic through a proxy. The client is using ZScaler in Tunnel with Local Proxy mode.
In theory, it's possible to reconfigure ZScaler to force our traffic through a proxy chosen by ZScaler. However, I want to investigate solutions where our application uses the Windows OS-level proxy settings rather than relying on ZScaler configuration.
I've read this post:
openssl s_client using a proxy
But I'm uncertain whether those answers apply to my situation, because that user didn't mention whether they're using Windows or Linux, and they appear to be talking about an HTTP/HTTPS proxy. Also, that question appears to be asking about the s_client function, rather than simply creating a TLS socket to my server through a "Tunnel with Local Proxy" on Windows.
So, my questions are:
Can OpenSSL be used to open an SSL socket to a server through Tunnel with Local Proxy?
Can we make an OS call to determine the IP/socket for the Tunnel with Local Proxy configuration?
If this is possible, then I have another question: suppose we have a single proxy at 10.100.10.0:5000.
If one user in our client's office opens a socket to our server via their proxy, will a 2nd user be unable to connect from their office because they're bottlenecked at single proxy socket?
Put another way: what is the standard way of implementing proxy-awareness for a Windows application using OpenSSL?
Note: This question was originally posted to Network Engineering stack exchange, but it was closed because it refers to an issue above OSI layer 4.
Note: I'm looking for a solution that does not require administrator permissions on the user PC. I would prefer for our application to discover and use OS-level proxy settings without making any administrative changes to the machine, i.e. by calling netsh.
Can OpenSSL be used to open an SSL socket to a server through Tunnel with Local Proxy?
OpenSSL doesn't do it for you but OpenSSL does not prevent it either. The tunnel has to be established before you do the TLS handshake to the endpoint. Depending on what kind of proxy this is you might need to use a HTTP CONNECT method for this or might need to use the SOCKS protocol or whatever your proxy requires. In case of ZScaler this is likely the HTTP CONNECT method but you need to make sure that the connection to the target IP and port is actually allowed by the security policy.
Once you've established the tunnel to the endpoint using the proxy you can just build the SSL socket on top of the TCP socket for the tunnel. Just do the usual SSL setup (i.e. SSL_new etc) and then associate the SSL object with the existing socket using SSL_set_fd. Then proceed as usual with the handshake, i.e. SSL_connect or similar.
Can we make an OS call to determine the IP/socket for the Tunnel with Local Proxy configuration?
I don't know but Winsock use system proxy settings might answer this part.
If one user in our client's office opens a socket to our server via their proxy, will a 2nd user be unable to connect from their office because they're bottlenecked at single proxy socket?
This should not be a problem. It is perfectly normal to have multiple connections through the proxy.
We are hosting an application in the preprod azure PCF environment which exposes websocket endpoints for client devices to connect to. Is there a prescribed methodology to secure the said websocket endpoint using TLS/SSL when hosted on PCF and running behind the PCF HAProxy?
I am having trouble interpreting this information, as in, are we supposed to expose port 4443 on the server and PCF shall by default pick it up to be a secure port that ensures unsecured connections cannot be established? Or does it require some configuration to be done on HAProxy?
Is there a prescribed methodology to secure the said websocket endpoint using TLS/SSL when hosted on PCF and running behind the PCF HAProxy?
A few things:
You don't need to configure certs or anything like that when deploying your app to PCF. The platform takes care of all that. In your case, it'll likely be handled by HAProxy, but it could be some other load balancer or even Gorouter depending on your platform operations team installed PCF. The net result is that TLS is first terminated before it hits your app, so you don't need to worry about it.
Your app should always force users to HTTPS. How you do this depends on the language/framework you're using, but most have some functionality for this.
This process generally works by checking to see if the incoming request was over HTTP or HTTPS. If it's HTTP, then you issue a redirect to the same URL, but over HTTPS. This is important for all apps, not just ones using WebSockets. Encrypt all the things.
Do keep in mind that you are behind one or more reverse proxies, so if you are doing this manually, you'll need to consider what's in x-forwarded-proto or x-forwarded-port, not just the upstream connection which would be Gorouter, not your client's browser.
https://docs.pivotal.io/platform/application-service/2-7/concepts/http-routing.html#http-headers
If you are forcing your user's to HTTPS (#1 above), then your users will be unable to initiate an insecure WebSocket connection to your app. Browsers like Chrome & Firefox have restrictions to prevent an insecure WebSocket connection from being made when the site was loaded over HTTPS.
You'll get a message like The operation is insecure in Firefox or Cannot connect: SecurityError: Failed to construct 'WebSocket': An insecure WebSocket connection may not be initiated from a page loaded over HTTPS. in Chrome.
I am having trouble interpreting this information, as in, are we supposed to expose port 4443 on the server and PCF shall by default pick it up to be a secure port that ensures unsecured connections cannot be established? Or does it require some configuration to be done on HAProxy?
From the application perspective, you don't do anything different. Your app is supposed to start and listen on the assigned port, i.e. what's in $PORT. This is the same for HTTP, HTTP, WS & WSS traffic. In short, as an app developer you don't need to think about this when deploying to PCF.
The only exception would be if your platform operations team uses a load balancer that does not natively support WebSockets. In this case, to work around the issue they need to separate traffic. HTTP and HTTPS go on the traditional ports 80 and 443, and they will route WebSockets on a different port. The PCF docs recommend 4443, which is where you're probably seeing that port. I can't tell you if your platform is set up this way, but if you know that you're using HAproxy, it is probably not.
https://docs.pivotal.io/platform/application-service/2-8/adminguide/supporting-websockets.html
At any rate, if you don't know just push an app and try to initiate a secure WebSocket connection over port 443 and see if it works. If it fails, try 4443 and see if that works. That or ask your platform operations team.
For what it's worth, even if your need to use port 4443 there is no difference to your application that runs on PCF. The only difference would be in your JavaScript code that initiates the WebSocket connection. It would need to know to use port 4443 instead of the default 443.
HTTP proxy with SSL and DNS support.
I must be lacking some key concepts about proxy-ing because I cannot grasp this. I am looking to run a simply http or https proxy without interfering with SSL. Simply, a fully transparent proxy that can passthrough all the traffic to the browser connected via HTTP or HTTPS proxy without modifying or intercepting any packets. Not able to find any code online or I'm not using the right keywords.
EX. On the browser adding server.someVPN.com:80 on the HTTP proxy field and as soon as you try to visit a website, it prompts for authentication. Then it works perfectly with any domain, any security, any ssl, no further steps needed. Most VPN providers have this.
How's this possible? it even resolves DNS itself. I thought on transparent proxy the dns relies on the client. Preferably looking for a nodeJS solution but any lang works.
Please don't propose any solutions such as SOCKS5 or sock forwarding or DNS overriding or CA based MITM. According to HTTP 1.1 which supports 'CONNECT' this should be easy.
Not looking to proxy specific domains, looking for an all inclusive solution just like most VPN Providers providers.
----Found the answer too quickly, feel free to delete this post/question admins.
The way it works is that the browser knows it is talking to a proxy server, so for example if the browser want to connect to htttp://www.example.com it sends a CONNECT www.example.com:443 HTTP/1.1 to the proxy server, the proxy server resolves wwww.example.com via DNS and then opens a TCP connection to wwww.example.com port 443 and proxies the TCP stream transparently to the client.
I don't know any solution for nodejs. Common proxy servers include Squid, Privoxy and Apache Traffic Server
See also: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/CONNECT
Found the solution right after I asked...
This module works perfectly https://github.com/mpangrazzi/harrier
Does exactly what I was asking for.
My clients are using a proxy server on their corporation,and I want to set up dev environment for testing development related to proxy issues.
So, I want to set up a proxy server which blocks all port 80 requests, unless the request is requested by the proxy server.
This is what I tried:
Installing fiddler2 on port 8888.
Setting up two rules on windows firewall:
Block all port 80 requests.
Allow all requests from fiddler exe.
Then, I opened FF and changed the proxy server to be 127.0.0.1:8888.
Unfortunately, the requests from the fiddler are still blocked.
What am I doing wrong?
Is there other program which do that easier? (Tried also with CCProxy without success).
Found the answer this great post:
Block all the outbound connections on the firewall.
Allow request from fiddler.exe
How we can enable squid to cache web content (let says from firefox) for SSL connection, i mean for https URLs?
Actually SQUID can be used to access HTTPS traffic - it is in essence a man-in-the-middle attack - and there are caveats:
See: http://wiki.squid-cache.org/Features/SslBump
I have not tried cacheing this data yet, so can't say that it will work with absolute certainty. If/when I do, I'll update this post.
SSL encrypts the traffic between server and client so it cannot be read by a middle man. When using Squid as a proxy it simply cannot see the actual content in the traffic and therefore it has no means of caching it. The SSL traffic is just random bits that look different each time even if the same content is transferred multiple times and that is how encryption should work. It simply cannot be cached.
I have no problems getting Firefox (version 23.0.1 on Windows) to route SSL traffic via Squid. In Firefox Network Connection settings I just point SSL Proxy and HTTP Proxy to the same Squid installation.
After that I can successfully access https URLs in Firefox and in Squid's access_log I see entries like these:
1379660084.878 115367 10.0.0.205 TCP_MISS/200 6581 CONNECT www.gravatar.com:443 - DIRECT/68.232.35.121 -
Do you have any details about how it doesn't work for you? Squid has quite complicated possibilities to deny and allow certain types of traffic, so it is possible there is a configuration issue in Squid. Do you get any error messages in Squid's logfiles?