I have a Spring Boot application running on 2.5.3.
I have configured (hopefully) secure ciphers using:
server:
port: 8443
servlet:
context-path: /somepath
ssl:
enabled-protocols: [ TLSv1.2,TLSv1.3 ]
ciphers: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
Funny thing is, when I now run SSLyze against my server I just get:
* TLS 1.2 Cipher Suites:
Attempted to connect using 156 cipher suites.
The server accepted the following 2 cipher suites:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Still runs fine and browsers can connect. But now we would like to connect a different server and call a REST endpoint on my server. That external server doesn't support either of those two suites.
I am wondering, in Spring Boot, why are only two of my requested suites accepted?
Where can I configure this (if I can)?
Thanks in advance!
Sascha
Yeah, it was more obvious than anticipated.
I requested some ciphers in the yaml file, Spring Boot can handle some suites (probably though the JVM). What I saw is the intersection of suites supported by Spring and suites that I requested. And that came out to two.
I removed the ciphers restriction. Got the full list of supported ciphers (around 12). Then we picked one secure cipher that they support and that I can do. And added that back to the "ciphers".
Related
In my Spring Boot app part of my application.yml is as follows:
spring:
activemq:
broker-url: ssl://10.68.84.40:61617
user: admin
password: admin
packages:
trust-all: true
Where 10.68.84.40:61617 is an endpoint added to activemq.xml:
<transportConnector name="ssl" uri="ssl://0.0.0.0:61617?maximumConnections=1000&wireFormat.maxFrameSize=104857600"/>
Spring Boot official document is way too brief about usage of ActiveMQ. I dig into org.springframework.boot.autoconfigure.jms.activemq.ActiveMQProperties source code and see that setting spring.activemq.packages.trust-all to true should trust all server certs, but it still gets sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.
Then I see another property spring.activemq.packages.trusted , but I wonder what should be put there.
Added: using openssl, sees CN of the server cert is just localhost. The application is calling using an IP.
The setting spring.activemq.packages.trust-all has nothing to do with SSL certificates and Spring's source code gives no indication that it does. It's related to the deserialization of JMS ObjectMessage instances. See more in the ActiveMQ "Classic" documentation.
If you really want the client to trust all SSL certificates then simply add trustAll=true to your broker-url, e.g.:
spring:
activemq:
broker-url: ssl://10.68.84.40:61617?trustAll=true
...
Is there any property in Spring Boot that could be used for setting allowed version of TLS for Redis?
I have found properties for host and password spring.redis.host=${HOST} spring.redis.password=${PASSWORD} and I'd like a way to set minimum allowed version of TLS to 1.2.
I don't think there is such configuration property in Spring, but there is one in Java itself. You can use
-Djdk.tls.client.protocols=TLSv1.2
The value of the property should be a comma-delimited list of allowed protocols. All other protocols are disabled.
I created a very simple project for you to demonstrate.
Here is the traffic with the server without any configuration:
Here is the traffic when running with only the TLSv1.2 enabled:
Beware! Java versions from 12 to 14 do not respect this property!
There are more options how to configure this behavior.
We have an application using Mule standalone 3.5 (I know...) and need to force it to use TLS 1.1 or 1.2 for HTTPS.
We have upgraded to the latest Java 8 (8u112).
We have modified the mule's tls-default.conf to include the following:
enabledProtocols=SSLv2Hello,
TLSv1.1
TLSv1.2
Our HTTPS GET request results in the exception:
No appropriate protocol (protocol is disabled or cipher suites are
inappropriate) (javax.net.ssl.SSLHandshakeException)
Is there anyway to get Mule 3.5's https connector to use TLS 1.1 or 1.2 for HTTPS?
Our application also uses a Salesforce connector <sfdc:...> which works correctly using TLS 1.2 after our Java upgrade and configuration changes.
Note that Mule 3.5 still has a separate connector for HTTPS (not the combined connector for HTTP/HTTPS that was introduced in 3.6).
We are looking to avoid upgrading to a newer version of Mule since we intended to replace our use of Mule in the near future anyway, and our investigations into upgrading do not indicate that it will be easy.
UPDATE:
In addition to using the fix in Ryan Carter's answer, I also had to fix the mistake in the tls-default.conf by escaping the newlines:
enabledProtocols=SSLv2Hello, \
TLSv1.1 \
TLSv1.2
Yes the Salesforce connector automatically uses JDK's default TLS version.
But for the https connector you need to add a property to your https connector:
<https:connector name="https">
<spring:property name="sslType" value="TLSv1.2"/>
</https:connector>
I have Weblogic server 10.3.3 and one of our clients wants to use SHA2 type certificate. We enabled JSSE=true in 10.3.3 and noticed slow performance while talking to this SHA2 using client.
Now we plan to upgrade Weblogic server to support communication with clients using SHA2 type certificates.
1) What lowest(10.3.6 ? )version of Weblogic server should we upgrade to?
2) Where can I find a mapped table of supported cipher suites and Weblogic server versions?
Regards,
DivyaTV
1) 10.3.3 is the lowest version that supports the option to enable SHA2.
2) Since JSSE is the only SSL implementation that is supported, you can use these links to find the supported cipher suites:
JDK 6: http://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
JDK 7:
http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
I haven't found any solution about this. It seems Jetty doesn't support this feature yet. I might be wrong so please, enlighten me.
I've got a very simple Java client which connects to a Java server at localhost:8080. I would like to add a transparent proxy between them in order to simulate what we could find in a company's private network.
Update: May, 2017
Starting in Jetty 9.4.0 and onwards, the native Jetty WebSocketClient supports Proxies via the Jetty HttpClient.
This works by declaring an HttpClient, along with its proxy configurations, and then handing that off to the WebSocketClient constructor to use.
This only works with the following:
HTTP/1.1 upgrade to WebSocket
Native Jetty WebSocket APIs
This does not work with the following:
HTTP/2 (there is no spec for WebSocket over HTTP/2 as of yet)
JSR356 javax.websocket (there are ideas for API breaking changes to the JSR356 ClientContainer to allow passing in a Jetty HttpClient via a constructor, let us know if this is viable option for you by filing a new issue on github saying so)
Original Answer
With Jetty 9, there's no Proxy support for either the Jetty Native WebSocket client, or the JSR-356 (javax.websocket) client implementation.
This support is scheduled for Jetty 10 (which is tracking Servlet 4), and will result in a complete reworking of the entire client library suite in Jetty to have equal support for :
HTTP/1.1
HTTP/2 (native/direct)
HTTP/1.1 upgrade to HTTP/2 (h2c)
HTTP/1.1 upgrade to WebSocket
HTTP/2 websocket channel (currently in draft specs)
Proxy support
Cookie support
etc ...
The existing WebSocket client implementations on Jetty are standalone, due to the JSR-356 support requirements.
The existing WebSocket client does not leverage the existing Jetty HttpClient in Jetty 9.x. If it did then proxy support could, maybe, under a very limited set of scenarios, work.
This is a low priority feature request, as there are few existing proxies out there that support WebSocket so far (actually, they have generally bad support for HTTP/1.1 upgrade). Even Jetty's own Server side Proxy does not currently support HTTP/1.1 upgraded connections.
According to Figure 2 in How HTML5 Web Sockets Interact With Proxy Servers, if you are trying to use a transparent proxy, you don't have to require a proxy support on the client side. On the other hand, an explicit proxy requires client libraries to support proxy.
Jetty WebSocket client won't have any problem if your proxy is transparent.