We're writing an app that must communicate with a few servers using HTTPS.
It needs to communicate with AWS (using the AWS libraries) and also with some of our internal services that use TLS 1.2.
I started off by changing my HttpClient to use a TLS 1.2 SSLContext:
public static SchemeRegistry buildSchemeRegistry() throws Exception {
final SSLContext sslContext = SSLContext.getInstance("TLSv1.2");
sslContext.init(createKeyManager(), createTrustManager(), new SecureRandom());
final SchemeRegistry schemeRegistry = new SchemeRegistry();
schemeRegistry.register(new Scheme("https", 443, new SSLSocketFactory(sslContext)));
return schemeRegistry;
}
and injecting this SchemeRegistry into the DefaultHttpClient object (via spring), but doing that I get errors from AWS and so I assume (I may be wrong) that AWS doesn't support TLS 1.2 (I don't get this message if I just use the normal DefaultHttpClient):
AmazonServiceException: Status Code: 403, AWS Service: AmazonSimpleDB, AWS Request ID: 5d91d65f-7158-91b6-431d-56e1c76a844c, AWS Error Code: InvalidClientTokenId, AWS Error Message: The AWS Access Key Id you provided does not exist in our records.
If I try to have two HttpClients defined in spring, one that uses TLS 1.2 and one that is the default, I get the following error, which I assume means that Spring doesn't like instantiating and autowiring two HttpClient objects:
SEVERE: Servlet /my-refsvc threw load() exception
java.lang.NullPointerException
at com.company.project.refsvc.base.HttpsClientFactory.<clinit>(BentoHttpsClientFactory.java:25)
...
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1031)
at
...
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
I haven't used HTTPS much in java so could you kind people give me some advice please?
1) How would I get Spring to allow two HttpClient objects and for one to be wired to the AWS stuff beans and the other to be wired to the other beans for accessing the TLS1.2 services
2) Or is it possible to change the one HttpClient object to be able to try TLS1.2 (via SSLContext, or the SchemeRegistry or something) and if that fails then try TLS1.1 or 1.0?
3) If both are possible, what would be the 'better' way of doing it?
TLS has an in-built mechanism to negotiate which version of the protocol is to be used. From RFC 5246 (Appendix E):
TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and
use compatible ClientHello messages; thus, supporting all of them
is relatively easy. Similarly, servers can easily handle clients
trying to use future versions of TLS as long as the ClientHello
format remains compatible, and the client supports the highest
protocol version available in the server.
A TLS 1.2 client who wishes to negotiate with such older servers
will send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS
1.2) in ClientHello.client_version. If the server does not support this version, it will respond with a ServerHello containing an
older version number. If the client agrees to use this version,
the negotiation will proceed as appropriate for the negotiated
protocol.
In addition, changing the version number in SSLContext.getInstance(...) only changes which protocols are enabled by default. Setting the actual protocol versions is done with SSLSocket.setEnabledProtocols(...) (see this question). I'm not sure about the rest of the libraries you're using, but it's possible that it sets the enabled protocols somewhere.
There are a few possibilities:
What you're doing in your createKeyManager() differs from the default behaviour. If the service is using client-certificate authentication, bad configuration there would certainly lead to a 403 error.
(Less likely, I guess, but hard to say without seeing your createKeyManager() and createTrustManager()). Perhaps the server you're using isn't compatible with TLS 1.2 and the version negotiation mechanism. There is this comment in sun.security.ssl.SSLContextImpl:
SSL/TLS protocols specify the forward compatibility and version
roll-back attack protections, however, a number of SSL/TLS server
vendors did not implement these aspects properly, and some current
SSL/TLS servers may refuse to talk to a TLS 1.1 or later client.
Related
Small question regarding the Spring WebClient from Spring Webflux, and how to configure the TLS versions when sending outbound http request (where I'm the client).
In a SpringBoot MVC project (not Webflux), I am using the Webflux Webclient (which is possible to mix the two).
I am using the client to call two external parties HTTP servers I have absolutely no control over.
First service is AliceService. Alice service is configured to accept only requests that are TLSv1.2
Second service is BobService. Bob Service is configured the accept only requests that are TLSV1.3
Hence, I am currently facing an issue. I am never able to call both of them at the same time.
I tried different combinations of
-Djdk.tls.client.protocols=TLSv1.2
-Djdk.tls.client.protocols=TLSv1.3
server.ssl.enabled-protocols=TLSv1.2
server.ssl.enabled-protocols=TLSv1.3
Every time, I will either change all my outbound requests to TLSv1.2 (hence the service accepting only TLSv1.3 will fail) or change all my outbound call to TLSv1.3 (hence the service accepting only TLSv1.2 will fail).
I even have two different instances of WebClient.
May I ask how to configure which TLS version is used when sending the outbound request?
How to resolve this problem please?
Thank you
You can create two separate web clients for this purpose. One for TLSv1.2 and one for TLSv1.3.
Here is the minimum code snippet that you can use to build your WebClient along with other configuration that you need.
WebClient for TLSv1.2
final SslContext sslContextForTls12 = SslContextBuilder.forClient()
.protocols("TLSv1.2")
.build();
final HttpClient httpClientForTls12 = HttpClient.create()
.secure(ssl -> ssl.sslContext(sslContextForTls12));
final WebClient webClientForTls12 = WebClient.builder()
.clientConnector(new ReactorClientHttpConnector(httpClientForTls12))
.build();
WebClient for TLSv1.3
final SslContext sslContextForTls13 = SslContextBuilder.forClient()
.protocols("TLSv1.3")
.build();
final HttpClient httpClientForTls13 = HttpClient.create()
.secure(ssl -> ssl.sslContext(sslContextForTls13));
final WebClient webClientForTls13 = WebClient.builder()
.clientConnector(new ReactorClientHttpConnector(httpClientForTls13))
.build();
I have tested this configuration for a website that supports various TLS versions.
This answer has mentioned the list of sites that I used for testing.
This should not be hardcoded/-configured but auto negotiated during TLS handshake, based on the capabilities of server and client, otherwise it becomes a maintenance nightmare. You do not need to worry about downgrade attacks as TLS has a protection mechanism to detect that.
You should be able to see this with: -Djavax.net.debug=all or similar. See the JSSE Reference Guide, Debugging Utilities
If you want to avoid certain older versions of TLS the correct solution is to blacklist insecure old ciphers (due to security/compliance) which can be accomplished through changing: jdk.tls.disabledAlgorithms in the config file: jre/lib/security/java.security, which on up-to-date Java installations contains reasonably secure defaults.
I want to implement a DTLS 1.0 client in Java and after googling a bit I found that the JSSERefGuide says the following:
The JSSE API is capable of supporting SSL versions 2.0 and 3.0 and TLS
version 1.0. These security protocols encapsulate a normal
bidirectional stream socket, and the JSSE API adds transparent support
for authentication, encryption, and integrity protection. The JSSE
implementation shipped with the JDK supports SSL 3.0, TLS (1.0, 1.1,
and 1.2) and DTLS (version 1.0 and 1.2). It does not implement SSL
2.0.
So I thought I could implement it in pure Java without using any library (e.g. BouncyCastle)
But when I try running (and a few other, like DTLSv1.2, DTLSv1...):
final SSLContext sslContext = SSLContext.getInstance("DTLSv1.0", "SunJSSE");
It throws:
Exception in thread "main" java.security.NoSuchAlgorithmException: no such algorithm: DTLSv1.0 for provider SunJSSE
at sun.security.jca.GetInstance.getService(GetInstance.java:87)
at sun.security.jca.GetInstance.getInstance(GetInstance.java:206)
at javax.net.ssl.SSLContext.getInstance(SSLContext.java:199)
while for example the following works:
final SSLContext sslContext = SSLContext.getInstance("TLSv1.2", "SunJSSE");
Listing all Security Providers I find no DTLS stuff at all.
So is there actually a DTLS implementation? And if so how are you supposed to use it?
You can use https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java (or https://github.com/twosigma/OpenJDK/blob/master/test/jdk/javax/net/ssl/DTLS/DTLSOverDatagram.java , its the same)
For the person which killed my previous answer because of the links: Even if the link breaks this is no problem - because at looking at the link you'll see with ease that DTLSOverDatagram is part of the official open-jdk 11 tests - so even if the link vanishes you can easily find other sources.
While these are tests for the DTLS implementation, with little refactoring this can be used as a base for DTLS over (udp-) datagrams. For both client and server - in fact, they are almost the same.
The doc is right and you get an Exception because there is no DTLS protocol :
https://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#SSLContext
Choosing DTLS comes at the moment of creating the socket, as it will be one of TCP or datagram types. As beginning, it will look like :
DatagramSocket s = new DatagramSocket();
...
final SSLContext sslContext = SSLContext.getInstance("TLSv1.0", "SunJSSE");
sslContext.init(null, yourSSLTrustManager, null);
SSLSocketFactory factory = (SSLSocketFactory)sslContext.getSocketFactory();
SSLSocket daSocket = (SSLSocket) factory.createSocket(s, host, port, false);
DTLS is present in JavaSE 9: SSLContext Algorithm Names
I'm trying to make a third-party SOAP service call that uses HTTPS from local (development environment) AEM 5.6.1. The SOAP service accepts the requests with a minimum TLS Protocols of TLSv1.1.
I have AEM 5.6.1 that uses JDK7 and for JDK7 the default TLSv1.
To achieve the minimum acceptable TLS. I tried the below two approaches:
Approach 1:
Made AEM start with -Dhttps.protocols=TLSv1.2
Approach 2:
Updated the SSLContext to update TLS.
SSLContext context = null;
try {
context = SSLContext.getInstance("TLSv1.2");
context.init(null, null, new java.security.SecureRandom());
SSLContext.setDefault(context);
LOGGER.info("Currecnt TLS:" + SSLContext.getDefault().getProtocol());
}catch (Exception e){
LOGGER.error("Error while updating TLS:",e);
}
First one doesn't work will, but the other one to update the TLS protocol for AEM to TLSv1.2.
But I'm still unable to access the service. The error remains the same.
Error:
The required TLS connection level has not been met. SSL Protocol level: TLSv1
Reference:
https://stackoverflow.com/a/42291244/4802007
https://stackoverflow.com/a/32346644/4802007
I would like to know 2 things here,
Am'I missing anything that is stopping the proper TLS update.
Is there any way to update the TLS only for this particular service, instead of changing it globally.
Thanks
This is a bug in CQ 5.5/5.6. The core issue boils down to the fact that in older CQ version SSLv3 was not allowed to be disabled by config and therefore TLS parameters never took effect.
You need to contact Daycare support and ask for a hotfix for your version.
Alternatively, check out this HF from your package share account: HOTFIX-5220 as this may have the fix for your TLS issue.
AEM 6.0 released a hotfix for this issue available via package share. Use your login and search for HOTFIX-5238 under 6.0 and ask Daycare for a back port or a compatible package for your version of AEM if the above mentioned hot fix does not work for you.
If I try to connect to a https url with Apache Http client 3.1 like so..
HttpClient httpClient = new HttpClient()
HttpMethod method = new GetMethod("https://federation/galaxy-class/enterprise/getSheildFrequencies")
int responseCode = httpClient.executeMethod(method)
which SSL version does it use in the handshake?
If it is SSLv2, is there any way to tell it to use a later version or TLS?
At least Apache HTTP Client 4 uses the underlying JRE for SSL connections. So it's a matter of configuring the JRE (I would imagine the higher versions are enabled by default).
In an SSL handshake, the client presents it's highest supported version to the server by default. Then it's up to the server how high version it supports.
Try setting the "javax.net.debug" system property to value "ssl" so you can see the SSL handshake where the version is also displayed.
Regarding the POODLE vulnerability, if I understand it correctly, it requires a client that automatically downgrades TLS protocol to SSLv3 when failing to establish a secure channel with a server using higher version protocol advertised by the server.
Do the common java HTTP client libraries, specifically javax.net.ssl.HttpsURLConnection and Apache HttpClient, automatically downgrade the TLS protocol when failing to establish TLS session with a server? If not, am I correct that they are immune from he POODLE attack unless either (a) the server only supports SSLv3, or (b) a logic at a higher level performs the downgrade?
I'm looking for something like http://blog.hagander.net/archives/222-A-few-short-notes-about-PostgreSQL-and-POODLE.html but for Java clients.
Apache HttpClient does not implement any of the TLS protocol aspects. It relies on JSSE APIs to do TLS/SSL handshaking and to establish secure SSL sessions. With the exception of SSL hostname verification logic, as far as TLS/SSL is concerned Apache HttpClient is as secure (or as vulnerable) as the JRE it is running in.
Update: HttpClient 4.3 by default always uses TLS, so, unless one explicitly configures it to use SSLv3 HttpClient should not be vulnerable to exploits based on POODLE.
This turned out to be wrong. One MUST explicitly remove SSLv3 from the list of supported protocols!
SSLContext sslContext = SSLContexts.custom()
.useTLS() // Only this turned out to be not enough
.build();
SSLConnectionSocketFactory sf = new SSLConnectionSocketFactory(
sslContext,
new String[] {"TLSv1", "TLSv1.1", "TLSv1.2"},
null,
SSLConnectionSocketFactory.BROWSER_COMPATIBLE_HOSTNAME_VERIFIER);
CloseableHttpClient client = HttpClients.custom()
.setSSLSocketFactory(sf)
.build();
Update 2: As of version 4.3.6 HttpClient disables all versions of SSL (including SSLv3) by default.
You MUST disable SSL v3.0 on java clients if you use https.
This can be done by adding this property on java 6/7:
-Dhttps.protocols="TLSv1"
And for Java 8 :
-Dhttps.protocols="TLSv1,TLSv1.1,TLSv1.2"
-Djdk.tls.client.protocols="TLSv1,TLSv1.1,TLSv1.2"
Source :
http://www.oracle.com/technetwork/java/javase/documentation/cve-2014-3566-2342133.html
Apache HttpClient 4.3.6 disables SSLv3 by default.
Here's an excerpt from Apache HC 4.3.6 release notes
Release 4.3.6
HttpClient 4.3.6 (GA) is a maintenance release that fixes several
problems with HttpClient OSGi bundle as well as some other issues
reported since release 4.3.5.
Please note that as of this release HttpClient disables all versions
of SSL (including SSLv3) in favor of the TLS protocol by default.
Those users who wish to continue using SSLv3 need to explicitly
enable support for it.
Users of all HttpClient versions are advised to upgrade.
Changelog:
SSLv3 protocol is disabled by default Contributed by Oleg Kalnichevski
Update: If you are running on JVM having version >= Java 1.8 Update 31 SSLv3 is disabled by default.Check out the release notes
After spending considerable time trying to figure out why TLSv1.2 was being used despite setting -Dhttps.protocols="TLSv1" we finally found this post.
The magic flag is indeed -Djdk.tls.client.protocols="TLSv1" and our Apache Axis 1.4 client works again.
So in case you move from Java 7 to Java 8 you may need to add this flag as pre JAVA 8 used TLSv1 as default whereas JAVA 8 uses TLSv1.2
Thanks!