Folks,
We have a Java Applet communicating with the server through a BigIp Load-Balancer. The Java Applet is using an HttpURLConnection and the communication protocol is https.
The Load-Balancer implements a cookie based persistence policy to maintain session affinity.
This all works fine when the Java Applet using Java 1.5, 1.6 and early versions of Java 1.7.
Somewhere around Java 1.7.0_21 something went wrong with the Java Applet and now when we open HttpURLConnection for the 2nd time and on, the load balancer does not pass the request to the server but instead replies with the same response sent for the 1st request from the Applet as if thinking the request is for static content that can be cached.
Any ideas what has changed in recent versions of Java with respect to HttpURLConnection ?
You may want to check that you are properly negotiating an SSL connection. You can do this two ways: create an iRule to log to /var/log/ltm:
when HTTP_REQUEST {
log local0. “Requested hostname: [HTTP::host] from IP: [IP::local_addr]”
}
Turn on SSL debug logging:
tmsh modify /sys db log.ssl.level value Debug
If you are failing to negotiate SSL, you will not see anything logged from the iRule, but should have an answer as to why you are failing to handshake. Most often you need to adjust your cipher string.
Related
This question already has an answer here:
Get SSL Version used in HttpsURLConnection - Java
(1 answer)
Closed 4 years ago.
I've got the following lines of code to set up an SSL connection:
HttpsURLConnection con = (HttpsURLConnection) new URL(url).openConnection();
I use the given connection to send a message and retrieve a response.
Now I've gotten the question: Which security technique is used in this connection? I'd like to know if the connection is, for example, TLS1.2. How can I retrieve this using Java?
HttpsURLConnection will use whatever scheme is negotiated between the client and the server. It is possible to get some information about the cipher suites used, and the client and server certificates, but the protocol / version are not directly exposed by the public APIs.
Retrieving the protocol that was actually used is tricky.
If you have enabled SSL debug, then the debug output will include the protocol version, and copious other information. However, since the format of the debug output is not specified / subject to change, it would not be a good idea to try to extract this programatically.
But if eyeballing debug output is acceptable, this is the answer.
If you read the Java SSL codebase, you will find a class called SSLEngineImpl, which has a private field called protocolVersion that gives the protocol and version that the connection is using. Unfortunately, the "engine" instance is deeply buried and it would be difficult to get to it at runtime.
If you implement your own SSLSocketFactory, you can get the protocol used from the SSLSession object after the session has been established; see Get SSL Version used in HttpsURLConnection - Java.
Finally, it is possible to figure out which protocol is used by decoding the initial messages sent over the TCP/IP connection. The messages are the "client hello" and "server hello" messages. The connection is not encrypted at this stage.
Oracle References:
Debugging SSL/TLS Connections
Java Secure Socket Extension JSSE) Reference Guide.
Our application uses Apache HttpClient 4.5.3 and we are observing a very weird behavior with communication between our client and the server using SNI capability
The server is configured to return a Go Daddy signed certificate if the SSL request comes in the with the server name expected from our client(ie: the host name of the server) and it will return a self signed certificate for all other domain names
Behavior observed
The client receives the correct server certificate on all server except on our production machine
The client code is running in an application deployed on tomcat 8, we have noticed that initial requests to the endpoint go through successfully. After some time of running we receive an SSL exception on the client.
The error is because the server is not sending the correct certificate(it sends the default self signed certificate)
If we restart the tomcat server on which the client is deployed, the calls again start to go through successfully.
We have used javax.net.debug for debugging purposes in the past but we cannot use it in this case as we need to restart the tomcat server for its effect to take place and when we restart the tomcat server, the calls to the endpoint server start to succeed.
Also the javax.net.debug logs a lot of information which will flood our logs and hence we wanted it enabled only for a specific request.
We are hoping to log only the Client Hello(which contains the server_name passed to the endpoint)
I have read through
https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#OwnX509ETM
But not sure of what we can use to print only the SSL server name indicator pushed down to the server.
I had the same concern as yours, then firstly I was thinking about dynamically adding environment variable, but it's always taking old value. Then I found out that javax.net.debug environment variable is read once only with static block in SSLSocketFactory.java. The full source code is available here.
static {
String s = java.security.AccessController.doPrivileged(
new GetPropertyAction("javax.net.debug", "")).toLowerCase(Locale.ENGLISH);
DEBUG = s.contains("all") || s.contains("ssl");
}
I am not able to run Java Play 2.5 application locally.I am using Mac OSX Sierra, before I was using Windows 10 and had no problems. If I try to use application through https://localhost:9000 I always receive error in chrome:
his site can’t provide a secure connection
On Mozilla:
An error occurred during a connection to localhost:9000. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG
Safari:
safari cant open the page because Safari cant establish secure connection to the server.
I am sure there is an issue with autogenerated self signed certificated by Play but I do not know how to solve it...
I tried http and it works, but my application forces https.
Use http://localhost:9000
I doubt you are set up to use HTTPS locally
Hi all Java/Applet gurus,
I've stumbled upon an interesting problem with the latest JDK build (1.8.0_b26).
When running Sandbox Java Applet with the latest JDK, from within Java code we try to connect back to the server with a different protocol - instead of original HTTPS we use WSS (secured Websockets connection, we use third party Websockets Client Java library). As the result, JVM tries to retrieve crossdomain.xml file from the server. The problem is, that the file is retrieved using HTTP (and not HTTPS) protocol.
For example, in our case the server IP is 192.168.1.1, the applet is loaded over HTTPS default port (443). Using trace level 5 in Java console we see that the crossdomain.xml is retrieved from http://192.168.1.1:443. And of course it doesn't work because the server listens only for HTTPS connections on port 443 (and not HTTP).
On the other hand, when we use HTTP protocol and open new WS (unsecured Websockets connection) to the server, the problem doesn't appear, because crossdomain.xml is retrieved from http://192.168.1.1:80 and it is completely correct.
As the problem was further investigated, we've made few more observations:
It is possible to provide alternative location of crossdomain.xml file using jnlp.altCrossDomainXMLFiles Java VM parameter. We've never succeed to make this parameter work for us though (tried both in java_arguments list and as lone applet parameter). The possible reason might be that the parameter should be used only with Webstart application (although it is not written specifically in specs).
While establishing Websockets connection, the connection stack trace is as follows:
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:790) at
sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) at
sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:787) at
sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647) at
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1534)
at
sun.net.www.protocol.http.HttpURLConnection.access$200(HttpURLConnection.java:90)
at
sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1431)
at
sun.net.www.protocol.http.HttpURLConnection$9.run(HttpURLConnection.java:1429)
at java.security.AccessController.doPrivileged(Native Method) at
java.security.AccessController.doPrivileged(AccessController.java:713)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1428)
at com.sun.deploy.net.CrossDomainXML.check(Unknown Source) at
com.sun.deploy.net.CrossDomainXML.check(Unknown Source) at
sun.plugin2.applet.SecurityManagerHelper.checkConnectHelper(Unknown
Source) at
sun.plugin2.applet.AWTAppletSecurityManager.checkConnect(Unknown
Source) at
sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:624)
So we looked at the latest publicly available source code of CrossDomainXML.java class (back from 2010 though). And from the code it is evident, that http connection is always used while retrieving crossdomain.xml file from server, regardless what is the original browser connection.
So the questions are:
Might it be a JDK bug or the strict usage of HTTP for crossdomain.xml is by design?
Is jnlp.altCrossDomainXMLFiles JVM parameter supported inside Sandbox applet?
Is there a way access the latest version of com.sun.deploy.net.CrossDomainXML.java source code to get a full picture of what is going on?
Thank you very much in advance.
Best regards,
Mark
in order to get rid of the http://myhost/crossdomain.xml request, there is nothing you can do except adding something like this into your java.policy file:
permission java.net.SocketPermission "myhost:1024-", "connect, resolve";
You can restrict that to a specific certificate signer in order to enforce this policy, see https://docs.oracle.com/javase/8/docs/technotes/guides/security/permissions.html#SocketPermission
We use it like this in an applet early in the init-process (applet constructor) and it works:
try
{
System.setProperty("jnlp.altCrossDomainXMLFiles", //
"http://www.some-domain.de/crossdomain.xml" //
+ ",https://www.secure-domain.de:8443/crossdomain.xml" //
);
}
catch (Exception e)
{
e.printStackTrace();
}
Currently at a loss for authenticating with a Microsoft Project Server 2007 instance running on IIS with Integrated Windows Authentication enabled from a Java 1.6(u19) client running on linux, RHEL 5.5.
Note: The client works on my Windows workstation.
I initially was trying to implement a JAX-WS call and found that I could not retrieve the WSDL due to authentication errors, specifically a 401.2, followed by a 500. So I simplified it to a Java class that:
Creates an Authenticator and sets it as the default with a user name/password in AD that has permissions to the project server site
Create a java.net.URL object
Create a java.net.HttpURLConnection and invoke getInputStream
It is at this point where a failure occurs.
With HttpURLConnection debugging turned on I can see:
the initial authentication failure (401.2) returned from the server with "negotiate" and "NTLM" included in the response.
the client creating an NTLM token and sending it back to the server
the server returning with a 500 status code
On the Windows server in the logs, I can see that there is no user name included in the log file only for my requestion and only a "-" which I believe means "anonymous".
My thought is that Project Server isn't liking the NTLM token that is being passed and choking. Based on the many postings on this, NTLM (v1 & v2) are suppose to be supported within Java 1.6.
Any help would be greatly appreciated...
UPDATE 6/20/12: narrowed the issue down to a local security policy setting for Network security: Minimum session security for NTLM SSP based (including RPC) servers. The setting that causes the Java client to fail is Require NTLMv2 security. The goes against what is claimed for NTLM support with the 1.6 JDK..
Some references:
Java HTTP Authentication
Blog showing Java Authenticator Impl
A while back when i had this problem, i ended up using a scheme created by somebody else.
http://devsac.blogspot.com/2010/10/supoprt-for-ntlmv2-with-apache.html
Worked for me when i had to get image files from and iis server with ntlm.
Snippet using the code above..
AuthPolicy.registerAuthScheme(AuthPolicy.NTLM, org.xyz.JCIFS_NTLMScheme.class);
HttpClient client = new HttpClient();
client.getState().setCredentials(AuthScope.ANY, new NTCredentials(userName, password, "", strDomain));
GetMethod get = new GetMethod(strImageFile);
get.setDoAuthentication(true);
client.executeMethod(get);