Cannot connect to proxy on Google Compute Engine - java

I have a Java Google App Engine webapp, which I am trying to connect to a Google Compute Engine instance running a Squid proxy. However it does not seem that the connection is working at all. Can anyone advise?
What I've done:
Set up a GCE f1 micro instance with Squid installed
Added username and password authentication for Squid
Set up a Google Cloud firewall rule to allow requests from port 3128 (the default Squid port)
Added the following to my GAE webapp:
System.setProperty("http.proxyHost", address);
System.setProperty("http.proxyPort", port);
System.setProperty("http.proxyUser", user);
System.setProperty("http.proxyPassword", password);

If you feel like you can provide more information about witch component of your solution is not working (maybe providing some logs) editing the question and I can help more with the debug that right now is only superficial.
By the way first of all I advise you to go through this small step to step guide from the official Google documentation describing how to use a gateway instance as a Squid proxy server. Maybe you can notice that you merely forgot a rule in the configuration of the Squid Proxy or to run it.
However, I would follow these classical steps in order to debug:
First of all I would try to install tcpdump if you didn't do it yet to check if it is a configuration issue or a network issue. Filter all the packets to highlight only the ones having source IP, protocol and port you expect.
In case you see no packet received, it can be a firewall issue dropping your packets or a client misconfigured that is not issuing any request.
Add a rule in your project allowing the incoming traffic from every protocol and port and try again with tcpdump
If the firewall was not the issue, try to connect the proxy from the different terminal disabling the authentication of Squid Proxy.
if you notice that your Squid Proxy is working fine then go through the debug of your client to understand why no request was sent.
If there are no issue with the traffic, try to disable authentication and to setup the debug mode of Squid to understand what is happening.
By the way are you sure you messing with HTTP and HTTPS requests?
Try to retrieve a simple webpage with the proxy and not the external API to reduce the area where error can be hidden.

Related

Ktor project localhost:8080 refuses to connect

I was working on a ktor project and everything was working fine. I started the server and it was working fine on port 8080 but now for some reason suddenly it stopped working. I killed the task and tried everything, I'm not sure what's wrong. I tried to reinstall IntelliJ Idea and I'm still facing the same issue. I tried using 127.0.0.1
, 0.0.0.0
, localhost but none of them work idk what to do. I've wasted like 2 hours on this thing. I've tried changing port, blocking firewall and antivirus.
change 127.0.0.1(localhost) to your private ip like 172.30.1.59 if you use wifi. if you use fixed ip then use it. i have same problem, but solve it with this. Nice!
cmd -> ipconfig -> use ip address
I usually had the same issue using Ktor and it is frustrating. Then I am gonna post the following possible fixes that you should try in order and reading the steps. I am going to consider that you are running a WebSocket server and a WebSocket client for your Android app in a unique computer.
You are running the server side and the client using the same ip and
it should not work, because the client can not connect to the
server. When I am testing a project that requires server-side and
client-side I use my computer to run the Android app and the laptop
to run the server side. If this is not your case, then, do
not pay attention.
In the client-side, when you create the instance of the HttpClient,
do you pass any value to the client as engine or you simply go
directly with lambda? From my experience, when I create the
HttpClient instance, only works these two following first ones:
val client = HttpClient {
install(WebSockets)
}
or
val client = HttpClient(CIO){
install(WebSockets)
}
The engine that doesn't work for me is:
val client = HttpClient(OkHttp) {
install(WebSockets)
}
Finally, when you create the WebSocket using the past client
instance, you should use
client.ws(
HttpMethod.Get,
"localhost",
8080,
"/"
)
{
//Client code
}
and not client.wss. That is because in local connection, your client
do not connect using TLS security and it will throw an exception. If
you're deploying your server-side in a hosting that has TLS security
as Heroku, then you can use the wss one, because the client-side
will connect using TLS certificate.
Hope that my response can help. Good luck!
I had the same problem and it turned out that it was because I had the HttpsRedirect and HSTS plugins installed. Due to this it refused to handle the http request and since I don't have any certificate for localhost or my local IP it didn't work.
Disabling these two plugins when running locally makes things work for me.

I can't connect to my dropwizard application remotely

I am able to succesfully use my dropwizard application when accessing with localhosts, but it doesnt work when I access with a different machine. Is there something you need to do make your web application respond to hosts besides localhosts?
I know with flask you must run with the flask run --host=0.0.0.0 is there a setting in the config file which controls this.
If you connect from the same network you´ll probably have an windows firewall issue (if you run on windows) or any other firewall depending on the OS.
You´ll have to allow inbound connections for the specific application on or port 80/443 TCP.
If you´re trying to connect from another network then it probably still is the above but you also have to setup port-forwarding to the machine running your application.
If it´s HTTP, probably port 80. If HTTPS then probably 443, for any other protocol you have to find out the correct port.
Since it´s dropwizard it´s probably HTTP/HTTPS, depending if it has to be secure (definatly recommended for REST APIs)

UnboundID LDAP and Squid Proxy

I chose the UnboundID LDAP SDK for Java. I deployed, somewhere in cloud, a Bastion server and a Microsoft Active Directory in the same network. If I run the LDAP client code on the Bastion server, it works. Now I want to run the code locally. For this, I installed the Squid on the Bastion and I configured it to allow everything. I start the Java application with -Dhttp.proxyHost, -Dhttp.proxyPort, -Dhttps.proxyHost and -Dhttps.proxyPort.
I use the following method:
LDAPConnection(String host, int port, String bindDN, String password).
Using this approach doesn't work for me. I don't see the requests that are forwarded to the Squid proxy. I want to achieve this for developing purposes. I am new to this library.
Question: Does anybody achieved this before? Is it possible?
It won't work. I am not aware of any open source LDAP client in Java or C which will utilize CONNECT to tunnel through an HTTP proxy. Especially as soon as you will use certs or Kerberos your jump server will not work.

Use Javamail through a proxy

I have a Java application which uses Javamail (v.1.5.4) for send and review mails into a POP/SMTP mail server. This application must run in our coporate network, where we have a proxy (f*ck!) that blocks my requests. I have googled possible solutions and Javamail says that we can use SOCKS5:
Q: How do I configure JavaMail to work through my proxy server? [updated!]
A: JavaMail does not currently support accessing mail servers through a web proxy server. One of the major reasons for using a proxy server is to allow HTTP requests from within a corporate network to pass through a corporate firewall. The firewall will typically block most access to the Internet, but will allow requests from the proxy server to pass through. In addition, a mail server inside the corporate network will perform a similar function for email, accepting messages via SMTP and forwarding them to their ultimate destination on the Internet, and accepting incoming messages and sending them to the appropriate internal mail server.
That solution is not valid for me, so I have to look for new alternatives. Some people say that they implements a custom SocketFactory, but I am not sure if that is enough. Someone has tried?
Another possible solution could be use another library, but I don't find anything that could avoid this proxy.
Has anyone treat this problem? How do you solve it?
Summary
Problem: I have to send and read e-mails in a Java application, but my proxy blocks the requests.
What I have tried? Using javamail, I have tried to use SOCKS5 solution, but with no effect.
What I am looking for? A way to avoid this proxy. Someone tells about a custom SocketFactory(but I am not sure if this is valid). I don't find any alternative to Javamail.
Regards!!
Actually JavaMail does support SOCKS proxy, just not authenticated proxies.
That solution is not valid for me
But you don't explain why.
There's another way of configuring Java Mail with SOCKS proxy (even authenticated one) that doesn't involve configuring your own socket factory. There's an open source library called Simple Java Mail (full disclosure: I maintain it), which is really simple to use:
new Mailer(
new ServerConfig("smtp.host.com", 587, "user#host.com", "password"),
TransportStrategy.SMTP_TLS,
new ProxyConfig("socksproxy.host.com", 1080, "proxy user", "proxy password")
).sendMail(email);
However, if your proxy is actually an HTTP proxy, you're out of luck and you will need to resort to something like Corkscrew or connect.
Although it's not a programmatic solution, the cleanest way would be to check if your company has an internal mail server and use that one to send your emails. It doesn't require using SOCKS or proxies, just configuration.
A nice side-effect may be that emails sent in name of your company are also sent by your company. If the mail administrators have set-up SPF records correctly, it greatly reduces the risk of your emails ending up in someone's junk / spam folder.
Using your own mail server is generally the best solution, but if you don't have your own mail server the JavaMail FAQ describes other solutions, such as using Corkscrew or connect to work through your web proxy server.
As per the latest release of Javamail API 1.6.2 , JavaMail supports accessing mail servers through a web proxy server and also authenticating to the proxy server. See my answer here stackoverflow.com/questions/36278073/how-to-let-javamail-support-http-proxy/52855090#52855090

How to sniff communication between SSL protected Metro web service and WCF client?

Environment: NetBeans 7.0.1, GlassFish 3.1
I want to sniff the communication between a WCF (.NET Framework 4) client and a Metro (2.1.1) web service, and then check the messages to be sure everything is how I want it to be. The web service uses Transport Security (SSL). I already know of Fiddler, but I did not have any success using it; only HTTPS browser traffic was visible. Is there a way to set up Fiddler to capture traffic between my services? Is there any other way?
UPDATE
I tried to start client and server on different machines and then use Fiddler, but no success. I tried Wireshark to capture traffic, but did not have any success running both on localhost. If i tried them on different machines, all I could see was TCP data exchange between the services.
On localhost + Wireshark, the packet counter next to the interfaces remained the same however I was calling the service lots of times.
UPDATE2
Tried to set up the proxy for NetBeans manually in the options, and programatically, but no success:
System.setProperty("http.proxyHost", "localhost");
System.setProperty("http.proxyPort", "8888");
System.setProperty("https.proxyHost", "localhost");
System.setProperty("https.proxyPort", "8888");
Tried to start GlassFish with these JVM options, but no :( :
<jvm-options>-Dhttp.proxyHost=localhost</jvm-options>
<jvm-options>-Dhttp.proxyPort=8888</jvm-options>
<jvm-options>-Dhttps.proxyHost=localhost</jvm-options>
<jvm-options>-Dhttps.proxyPort=8888</jvm-options>
As an alternative to Fiddler, if you control the WCF client, you could enable WCF Message Logging, and it will save all the unencrypted SOAP messages to a trace log. The logging can be enabled in the app.config file, so you don't even have to rebuild the app to enable or disable the logging.
you can setup metro to dump SOAP messages, info here. personally, i use charles proxy to watch soap exchanges. you configure the java proxy using the system properties in your "update2", works very well.
Use http://portswigger.net/burp/
It has a proxy. The proxy can be used for viewing the http traffic. It can also display SSL traffic by generating self signed certificate on the fly. You need to import the generated certificate into the java key store at the jax-ws client. Ensure that you have enabled "Support invisible proxy for non-proxy aware clients"
I often use commview to monitor traffic over the local loopback adapter. One of the few tools allowing traffic capture when both your client and service are on the same computer.
You can download a trail at http://www.tamos.com/products/commview/ and see if it works for you.
May be WebScarab is what you need. There are many manuals for sniffing ssl traffic, for instance that.
One approach I've tried successfully, is to make sure SSLv2 is used (as opposed to SSLv3), and then use Wireshark as described on the SSL page on the Wikishark Wiki, but better on Citrix support page "How to decrypt SSL and TLS traffic using Wireshark ". This works by giving Wireshark the private key of the server's SSL certificate, so that it can decrypt the conversation.
To force SSLv2 in your scenario, it seems sufficient to set -Dhttps.protocols=SSLv2Hello on your server-side JVM, but I googled that together. (See, e.g., the "Why do I get a javax.net.ssl.SSLException" question on the Java 1.4.2 Troubleshooting page, and the part on https.protocols in the JavaTM Secure Socket Extension (JSSE) Reference Guide.) I haven't done this part myself, and I can't seem to find clear documentation on this point.
(P.S. In my case, when I was decrypting .NET-to-.NET SSL traffic, I thought it was the switch back to SSLv2 which made the traffic readable by Wireshark. However, this blog post suggests that I was switching at the same time from a Diffie-Hellman cipher to a non-DH one.)

Categories