I moved from okhttp 2.7.5 to 3.10.0 and when I'm on a VPN where my proxy is not valid/accessible and the system properties -Dhttp.proxyHost and -Dhttp.proxyPort are set, the client requests fail with a connection timeout. On 2.7.5, even with these system properties set, if I'm on a network where these values were invalid, it still worked. My guess is that if the proxy was not accessible, the client would fall through to attempt the requests without the proxy.
Is this expected?
This behavior changed in OkHttp 3.5. From the changelog:
OkHttp no longer attempts a direct connection if the system's HTTP proxy fails. This behavior was surprising because OkHttp was disregarding the user's specified configuration. If you need to customize proxy fallback behavior, implement your own java.net.ProxySelector.
Related
I have a setup which involves devices connecting to a server via web sockets. I'm experiencing a strange problem where they can connect to one test server without issues, but cannot connect to a different server (hosted on Azure).
I've installed Wireshark on both of them, and can watch both the successful connection and the unsuccessful connection. It appears that the unsuccessful one attempts to initiate an SSL handshake.
Here is the successful connection:
Here is the unsuccessful connection:
It seems like the client in the successful connection is simply setting up an HTTP web socket, but in the unsuccessful setup it's try to set up a secure connection.
Why would the client be setting up different connections depending upon the server address?
The client code to create the websocket is just javascript, invoking new Websocket(address), and in both cases the address begins with the 'ws' prefix.
I have done some further investigation and found another weird behavior. As it happens, there are two domain names pointing to the same server.
If I used the domain name with the top level domain "com" (XXXX.australiaeast.cloudapp.azure.com), then the connection works.
If I used the domain name with the top level domain "dev" (comutername.mydomainname.dev) then the connection fails, with the weird TLSV1 packet.
Both works fine if I run the same client code on the Microsoft Edge browser.
This appears to be a defect in Chrome's implementation of The WebScoket API
I have posted a defect here, let's see how it goes. https://bugs.chromium.org/p/chromium/issues/detail?id=1067076
The issue in play here is HTTP Strict Transport Security (HSTS)
A browser can be configured so that certain domains have an HSTS policy attached, meaning any insecure link will automatically be converted to a secure link.
This policy will be applied if a request returns a Strict-Transport-Security header. But, and here's the significant bit, the Chrome and Firefox browsers automatically apply the policy to all dev domains.
It appears that up until recently, the Chrome browser and Chrome OS was not observing the policy with regard to WebSocket connections. This has changed, and now WebSockets will observe the HSTS policy.
The upshot is, if you have a websocket using the ws protocol and not the wss protocol, and it's on a .dev domain, your Chrome and Firefox browser will not be able to connect to it.
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
I am trying to build a SOCKS solution for forward proxy. I am using dante SOCKS proxy as I have heard that big companies like google uses it as forward proxy solution.
on the SOCKS server, I am allowing based on FQDN's like google.com:443
Now the problem is, when the client constructs the packet, it tries to resolve google.com and gets X.X.X.X and sends connect request to SOCKS server. Now when the server receives the packets, it tries to reconstruct the packet to send out to internet, the server again does DNS resolution and if the server gets response as Y.Y.Y.Y, then it doesn't allow client's request as the destination IP in the client's request is different then the server's resolved IP address.
There was a solution in dante client which tells client to put a dummy destination address 0.0.0.1 and sends request to server and server processes it properly then. However that is creating a problem with internal domains as after using that dns resolution method, every requests goes through dante server :(
Please let me know
If there is any solution through which would help me in maintaining a DNS record expiry DC wide for e.g. google.com resolves to X.X.X.X and I should be able to resolve to this same IP address on 100's of DNS client and in case if the record changes, then it should immediately change/expire on client.
Any other proxy/socks solution which should be transparent to applications for forward proxy
I went ahead with this solution in case anyone is curious to see the solution.
I used PowerDNS Auth Server with Pipe backend. The requests would land to PowerDNS server for resolution, it will pass on all the data to Pipe backend script with ABI, the script analysis the requests, sees if it is present under cached variable/memory map, if it is cache hit, it will respond using cached DNS records else it will use a DNS resolver to resolve that query like a resolver resolves normally.
PowerDNS version lower than 4.1 supports Pipe backend + resolver. This way, the request would first land to pipe backend script, if the script doesn't have any entries cached, it will not respond or will respond blank and then PowerDNS would resolve it with the mentioned resolver server in the configuration. However with version 4.1 and above, the resolver part is removed from PowerDNS Auth server hence you need to handle that behaviour via Pipe backend script.
It depends on your client. Firefox, for example, sends hostname to SOCKS proxy without resolving it. You can confirm that by Wireshark.
PS. assume you are using a SOCKS5/4a proxy. SOCKS4 does not support hostname. Ref: https://en.wikipedia.org/wiki/SOCKS#SOCKS4a
I have been looking for a web socket client implementation for few days to pass through Proxy, which is setup with NTLM Negotiate protocol.
I verified below implementations with NO success:
1. Glassfish's Tyrus client:
Tried both client managers below,
a. org.glassfish.tyrus.client.ClientManager ("org.glassfish.tyrus.bundles:tyrus-standalone-client:1.13")
b. org.glassfish.tyrus.container.jdk.client.JdkClientContainer ("org.glassfish.tyrus:tyrus-container-jdk-client:1.13.1")
2. Eclipse Tyrus client:
According to below issue, they does not support it yet.
https://github.com/eclipse-ee4j/tyrus/issues/381
3. Apache Tomcat client:
Verified Spring web socket client with underlying tomcat implementation.
org.apache.tomcat.websocket.WsWebSocketContainer ("org.apache.tomcat.embed:tomcat-embed-websocket:8.5.11")
4. Jetty:
Verified with 'org.eclipse.jetty.websocket:websocket-client:9.4.8.v20171121'.
Found (correct me if I am wrong here) that they only support 'BASIC' and 'DIGEST'.
NOTE: Most of above implementations support authentication scheme 'BASIC' and in some cases 'DIGEST'.
Proxy setup:
We have Squid proxy setup with NTLM (Negotiate) with Active Directory as a domain controller.
Our customer has a Blue coat proxy running with similar setup.
Client:
We have Java client (desktop application) runs on windows system and connects to various other servers (On HTTP 1.1 and WS/WSS) via a proxy.
NTLM Negotiate:
Client needs to accept the authentication challenge from proxy server and respond with logged-in user name with domain and a password hash (which it gets it from windows) to proxy server, which in turn validates against domain controller (active directory).
Java's HttplURLConnection and Apache Http Client implementations already support this mechanism while connecting to proxy for all Http requests. My need is to find a web socket client implementation to do the similar mechanism to support all requests (Http and WS/WSS) that my Java client makes on outbound traffic.
Summary of my request:
Please let me know, if anyone already came across this need and know an web socket implementation, which already supports connecting to NTLM (Negotiate) based proxy on windows systems.
If a similar question already exists and answered, please point me to that.
If UDP is blocked, i need to enable HTTP(s) fallback with aspera connect plugin thru HAProxy. Has anyone successfully done this ? I have read all the documentation but there is nothing that describes the HAProxy use case
I assume you talk about a client side forward proxy.
If you use the IBM Aspera Connect Client, it comes with HTTP (forward) proxy configuration.
http://download.asperasoft.com/download/docs/connect/3.9.6/user_osx/webhelp/index.html#dita/network_environment.html
This will work when the client falls back to HTTP.
Note that the client will fallback to HTTP only if this feature is enabled on the server side.
You can see that by examining the parameters provided to the client by the browser (put in dev mode). In that case, it has http parameters (port).
Typically, parameter: https_fallback_port
If not, then there is no possible http fallback, and it will not use the (forward) proxy.
If you are talking about reverse proxy in front of a server configured with fallback, this is part of the (public) documentation of the IBM Aspera Proxy.