How do you disable SSLv3 protocol in Openfire and make it use only TLS ?
I am using Openfire 3.8.2 version.Is it any changes related to Jetty ?
Related
I've got a web application with nginx supporting https with TLSv1, TLSv1.1, TLSv1.2 protocols. We'd like to stop supporting TLSv1 and TLSv1.1 due to well known security vulnerabilities. Unfortunately, we have some legacy clients running very old OSes that cannot be upgraded to connect over TLSv1.2. As a solution would it be possible to place a proxy in front of our web app that takes traffic solely from these legacy clients and have that proxy support decrypting TLSv1 but re-encrypt that traffic using TLSv1.2 before proxying it forward? Is this something that nginx can do? Would the responses returned to the client be encrypted with TLSv1?
When using a VPN-like connection between the two servers (not web servers or anything like it), besides authentication I would like to enable encryption.
The authentication portion is already working, wanted some help at the encryption level.
I know that TLSv1.2 and v1.1 is supported alongside wih SSLv3.
I would only like to use TLSv1.2 and nothing else.
TLSv1.2:!aNULL:!eNULL
Is the the correct cipher suite to use?
Information from https://www.openssl.org/docs/manmaster/apps/ciphers.html seems not to be very helpful...
Can anyone help this this matter?
I would only like to use TLSv1.2 and nothing else.
If you want to use TLS 1.2 only you have to configure the protocol and not the ciphers. Limiting the ciphers to only TLS 1.2 ciphers drops support for all ciphers which are available since SSL 3.0 and which are still supported by TLS 1.2. Depending on the peer you might end up with no shared ciphers this way.
If you still want to restrict the ciphers you might try the string TLSv1.2:!aNULL:!eNULL. This will make it only use ciphers newly introduced in TLS 1.2 and thus implicitly enforce the protocol. But again, it is no guarantee that the server supports these ciphers even if the server can do the TLS 1.2 protocol.
To enable SSL/TLS protocols I had updated tls-default.conf file with "enabledProtocols=TLSv1.2"entry. And also add wrapper.java.additional.=-Djavax.net.debug=ssl to enable SSL debugging.
After running Mule I got the logs mentioned below:
ClientHello, TLSv1
RandomCookie:...
..
ServerHello, TLSv1
From the above logs it is clear that TLSv1 is used instead of TLSv1.2
I am using Mule Version 3.5.2
And JDK 7 which has SunJSSE security provider which allows (PKCS12, SunX509 key/trust factories, SSLv3, TLSv1) protocols.
Is there any way to find out the enabled protocols apart from looking into SSL Handshake logs?
I am trying to enable TLS 1.2 on Tomcat on Spring-boot 1.2.1. Android 5.0 is failing to connect to the default SSL settings, due to an SSL handshake failure. Android 4.4, iOS, Firefox, and Chrome all connect to the default version. I think this is because of a mismatch in the TLS protocols supported in Android 5.0 and the spring boot tomcat defaults (TLS v1?).
I imagine I want to change this application.properties setting:
server.ssl.protocol=TLS
but I have not located the other acceptable strings (or if there are any, even). There is no enumeration that I can find by searching on "protocol" in spring boot github.
I have tried "TLSv1.2", but this appears to have no effect.
The current SSL configuration in application.properties is:
server.ssl.key-store = chainedcertificates.p12
server.ssl.key-store-password = secret
server.ssl.key-store-type = PKCS12
How do you enable TLS 1.2 in spring boot?
If it matters, I am using Java 1.7. The documentation for this seems to indicate it should support TLS 1.2.
Tomcat 8 seems to have support present. I am not sure how to check exactly which version is running in spring boot.
You may experience an SSL handshake error due to the default ciphers that spring boot includes. It is recommended that you define a set of ciphers. We had a similar issue, and the way we fixed it was by using SSLScan on the caller and then scanning our system to see if there were any matches. This lead us to find out that there were no matches and helped us define a list of ciphers we should support.
Using SSLScan these are the default ciphers spring boot will use:
Preferred TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA256 Curve P-256 DHE 256
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-SHA Curve P-256 DHE 256
Accepted TLSv1.2 128 bits DHE-RSA-AES128-GCM-SHA256 DHE 1024 bits
Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA256 DHE 1024 bits
Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA DHE 1024 bits
To enable TLS 1.2 and to define the cipher list please do the following:
#enable/diable https
server.ssl.enabled=true
#ssl ciphers
server.ssl.ciphers=TLS_RSA_WITH_AES_128_CBC_SHA256, INCLUDE_ANY_OTHER_ONES_YOU_NEED_TO_SUPPORT
# SSL protocol to use.
server.ssl.protocol=TLS
# Enabled SSL protocols.
server.ssl.enabled-protocols=TLSv1.2
For a list of of ciphers you can use https://testssl.sh/openssl-rfc.mapping.html and https://msdn.microsoft.com/en-us/library/windows/desktop/mt813794(v=vs.85).aspx
TLS 1.2 is enabled by default in spring-boot 1.2.1. This can be verified by running the following from the command line
openssl s_client -connect serverAddress:port
which outputs
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-SHA384
So my problem must be something separate.
Exactly as the title states: Is it okay to set OpenSSL to use SSLv3 as a client from a compatibility standpoint?
I have recently run into websites which don't support the SSLv2 helo, therefore I was thinking that from a compatability standpoint it would be better to use SSLv3. Ultimately, Im asking whether or not it is true that SSLv3 will be more compatible than SSLv23 (i.e. SSLv23_client_method).
Well you have to support whatever the websites require that you need to talk to, but ideally at this stage you should forget all about SSlv2 and SSLv3 with the V2 handshake. You should be using TLS as the primary protocol and SSLv3 as a fallback, with the RSA and 256 bit cipher suites given priority.