Is it possible to update password in Active Directory where SSL is not enabled from a Java application?
It's not possible until you will have at least 128-bit connection. That is with TLS or SSL connection. You can use LDAPS to have secure connection, for example from here:
http://docs.oracle.com/javase/jndi/tutorial/ldap/security/ssl.html
Or you can just setup SSL checking this tutorial:
http://blogs.msdn.com/b/alextch/archive/2012/05/15/how-to-set-active-directory-password-from-java-application.aspx
Related
This question already has answers here:
Writing a SSL Checker using Java
(2 answers)
Closed 5 years ago.
This question is NOT a duplicate of question pointed to. There is NOWHERE in mentioned question anything about fact that TLS does not perform hostname verification by itself.
I have ActiveMQ instance and client in Java. Client uses JMSTemplate (org.springframework.jms.core.JmsTemplate) with factory org.apache.activemq.ActiveMQSslConnectionFactory. I have created self-signed certificates and with them trust store and keystore. Trust stores and keystores are read by both programs, I checked it by running both programs with
-Djavax.net.debug=all
Now my problem is that it seems that client absolutely ignores server hostname verification. Client connects to ActiveMQ using URL:
ssl://localhost:61616?jms.useCompression=true
Now, I tried to check whether everything will fail as expected if I change CN on ActiveMQ's certificate and well, it didn't went well. I changed to CN to e.g:
CN=google.com
or to:
CN=some.random.xxx333aaa.net.pp
but all these values seem to be OK with Java. Also note that there are no SANs (that is subjectAltNames). What more I tried to connect to ActiveMQ with such certificate but installed on different machine, and it seems that it all works well. Which is NOT what I want.
Also: I have finally uninstalled all Java versions and installed 1.8.0_144, using only JDK installer, installed jce_policy-8 in both places (it installs both JRE and JDK), did the same on remote machine too.
If you will examine RFC 2246 (TLS) and RFC 2818 (HTTPS) you will discover that hostname verification is part of HTTPS, not part of TLS. In TLS it is entirely up to the application to perform an authorization step.
So in fact my question is: how to force hostname verification?
See this answer.
Ok, I think I found an answer. Check this link:
https://issues.apache.org/jira/browse/AMQ-5443
and link mentioned in link above:
https://tersesystems.com/2014/03/23/fixing-hostname-verification/
It seems that TLS against what I thought DOES NOT PERFORM HOSTNAME VERIFICATION. This is absolutely stunning, but it seems that this is exactly the case. If no one will provide better answer I'll accept my own answer.
EDIT: Also see this:
https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html
and look specifically at this part:
Cipher Suite Choice and Remote Entity Verification
The SSL/TLS protocols define a specific series of steps to ensure a protected connection. However, the choice of cipher suite directly affects the type of security that the connection enjoys. For example, if an anonymous cipher suite is selected, then the application has no way to verify the remote peer's identity. If a suite with no encryption is selected, then the privacy of the data cannot be protected. Additionally, the SSL/TLS protocols do not specify that the credentials received must match those that peer might be expected to send. If the connection were somehow redirected to a rogue peer, but the rogue's credentials were acceptable based on the current trust material, then the connection would be considered valid.
When using raw SSLSocket and SSLEngine classes, you should always check the peer's credentials before sending any data. The SSLSocket and SSLEngine classes do not automatically verify that the host name in a URL matches the host name in the peer's credentials. An application could be exploited with URL spoofing if the host name is not verified.
Protocols such as HTTPS (HTTP Over TLS) do require host name verification. Applications can use HostnameVerifier to override the default HTTPS host name rules. See HttpsURLConnection for more information.
I'm working on a java mail client (part of a web application running in tomcat 8)
and the web application needs to be able to send (not recieve) mails.
My web application allows to be configured in a few different ways and I cannot test them all at the moment.
Im using the standard java mail api (https://javamail.java.net/nonav/docs/api/com/sun/mail/smtp/package-summary.html)
At the moment I do have an exchange account and my application is working with STARTTLS & Auth. Mechanisms LOGIN & PLAIN to send mails.
The thing I cannot test is SSL (instead of STARTTLS) and NTLM as the Auth. Mechanism. The exchange server is not my own and I cannot have it configured to be working with these settings.
Does anyone know a way to set up a local mail server so I can test a configuration using SSL & NTLM?
Edit:
I tried hMailServer to test at least the SSL setting but I came across the following problem:
IMAP/SMTP over SSL (using my own SSL cert) is working fine untill I uncheck TLS v1, v1.2 & v1.2 in Settings -> Advanced -> SSL/TLS.
The hMailServer Logfile shows that the connection upon sending mails (using thunderbird with 2 accounts added) is always using TLS.
I would want the connection to run on SSL v3.0 (I know its not the best option but I want to give my application the option to use SSL instead of TLS anyways)
How can I get the connection to be using SSL v3.0?
You can try installing hMailServer in Windows.
https://www.hmailserver.com or you can try setting SMTP in windows8.
http://www.neatcomponents.com/enable-SMTP-in-Windows-8
I have a couple of java servlets which need to be secured with Mutual authentication with X509 certificates. I used the information from here to
implement mutual authentication and it works fine on my machine.
Now our integration environment has BigIP for load balancing traffic to weblogic. The SSL is terminated at BigIP and it forwards the https request to weblogic using an internal certificate instead of the client's certificate it got with the original https request. So mutual auth is not working.
The BigIP team says they can put the client's certificate in the HTTP header (SSL_CLIENT_CERT), and I am not sure how to configure weblogic to read client's cert from http header.
Do I need to write a custom Identity assertion provider and configure it in weblogic?? Is this the best approach or do I have any other option?
Any help on this is greatly appreciated!!
It is necessary to configure the identity asserter if you are using two way ssl to verify the client identity
and to use it to restrict access to application.If you are using two way ssl with signed CA(Verisign etc.) it
will be only used for trust -not for authentication or any type of application access restriction.
Check below link for detail clarification on above
http://www.oracle.com/technetwork/articles/damo-howto-091164.html.
You can follow your steps for configuring the X509 Certificate Authentication for weblogic server.
Along with above you need to follow below steps
1) Make sure that BIG IP handles client certitifcate and client key which can be configured in the HTTPS monitor in BiG IP.
2) Configure the BIG-IP to insert a header named WL-Proxy-SSL: with a value of true into each request.
3) Enable weblogic proxy plugin tab in
AdminConsole —> Servers —-> [Your_Server_Name] —> Configuration [Tab]
—> General [Sub-Tab]
Click on “Advanced” Link
Check the CheckBox in this Page “WebLogic Plug-In Enabled”
Above changes will help in undersatnding the weblogic that request coming from BIG IP was initially the SSL enabled.
Check below link for configuring WL-Proxy-SSL with BIGIP
https://support.f5.com/kb/en-us/solutions/public/4000/400/sol4443.html?sr=10058313
I am trying at write a java program that hits a url over ssl, and prints out the response to find out if the application on this port is running or not. We are using 2way ssl. I am fairly new to working with ssl and java security. Right now I am getting this error
Remote host closed connection during handshake
I am using this command to run the program
java -Djavax.net.ssl.trustStore=rs.truststore TmpUtil
Is there a way to find out what am I doing wrong and where exactly is the problem ?
You can generally debug an SSL/TLS connection that uses the JSSE in Java using the javax.net.debug system property. You'll find more details in the documentation.
Since you're after client-certificate authentication, it's most likely that your application needs a keystore to be configured. You'll find some details about the difference between keystore and truststore in this answer, and in the JSSE Reference Guide of course.
On client side I have Apache HTTP client on jdk5u22. On server side I have tomcat on jdk6u27.
With this setup if I try SSL Client authentication (2 way SSL) then it cause "javax.net.ssl.SSLHandshakeException: Insecure renegotiation is not allowed" on the server and handshake fails. It succeeds if I set system properties sun.security.ssl.allowUnsafeRenegotiation=true and sun.security.ssl.allowLegacyHelloMessages=true on server.
As per the link http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html this is coz JRE6u27 has the RFC 5746 implementation and JRE5u26 below doesnt have this and so both are incompatible. Unfortunately 5u22 is the latest freely available java 5 version. So I want to know if it is possible to have SSL client authentication without ssl re-negotiation.
Regards,
Litty Preeth
As per the redhat site https://access.redhat.com/kb/docs/DOC-20491#Renegotiations_disabled_in_Apache_Tomcat :
Tomcat may ask the client to renegotiate in certain configurations using client certificate authentication, for example, configurations where:
A client certificate is not required on the initial connection, such as when:
1. The clientAuth attribute of the HTTPS connector using JSSE is set to
false. Or The SSLVerifyClient attribute of the HTTPS connector using
OpenSSL is set to none.
AND
2. A web application specifies the CLIENT-CERT authentication method in
the login-config section of the application's web.xml file.
So to avoid re-negotiation in tomcat just make the whole site secure and not just a part of it by setting clientAuth="true" for ssl .
Hope this helps someone.
Regards,
Litty