Reading an article about the cost of SSL handshake, I saw the possibility to have session tickets and session resumption to avoid paying the cost of re-establishing the session.
In my architecture, I use Netty in the client side and Tomcat on the server side. Googling I saw several guides to enable it on nginx and other server implementation, but for the netty implementation on the client side, I couldn't find anything.
At this point, I was wondering if it was directly managed by SSLEngine for me at the client side, and I have to do nothing, or there is some "secretive" config I have to turn on to benefit from the SSL resumption on the client side.
Is there any reason why I would like to disable it? (I saw several questions on SO)
Unfortunately Java's SSL implementaion don't support session tickets, I lodged a feature request for this a few years go.
https://bugs.openjdk.java.net/browse/JDK-8134497
Luckily Netty lets you switch to OpenSSL implementations that do support session tickets and better yet can be directly swapped into your code.
See http://netty.io/wiki/forked-tomcat-native.html for details but you basically just add:
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-tcnative-boringssl-static</artifactId>
<version>2.0.0.Final</version>
</dependency>
to your POM file and specify OpenSSL as your provider when setting up the context.
SslContext sslContext =
SslContextBuilder.forClient()
.sslProvider(SslProvider.OPENSSL)
.build();
Apache Portable Runtime and OpenSSL need to be installed on the system.
Related
For my current project i need to implement http over tls at client ,for this i need a local server able to simulate this . is there any online or offline tool. which i can use and and see the handshake in wireshark .
For watching the TLS handshake you might not get far enough with wireshark. For such kind of monitoring you would ensure the security is low enough for wireshark to be able getting the session key from watching the handshake for decoding the later parts. Thus, you need to avoid any forward secrecy.
Otherwise any (https) server that is accessible (and willing to talk) to your client will do.
In case you are in an environment that is supported (e.g. any unix/linux), you might try using openssl. It allows setting up a server that will do handshake. And it will log the handshake such that you will be able looking at what is going on. This will eliminate the need for using wireshark for debugging.
For achieving this you need a Web Server accepting connection over TLS.I have achieved this on Apache Tomcat web Server.
TLS configuration needs to be done in the server.xml file present in config directory of Tomcat webserver. Connector tag needs to be added in the server.xml file that contains information like
TLS version to be used, port, List of supported Cipher Suites, Keystore path and password, Truststore path and password.
Any regular Rest client can be used to make a call like Postman client. But to use that over TLS/SSL certificate is needed to be installed in Chrome browser.
Hope this answers your doubt.
I want to enable SSL keys renegotiation in Tomcat as described in https://www.rfc-editor.org/rfc/rfc5746. Tomcat will use JSSE implementation for SSL. Which cipher suite should I use to enable the same?
Tomcat Version: 6.0.44
Java version: Java 1.8
Protocol - TLS 1.2
Meta: I'm not sure this is ontopic here, but security is on-hold. Migrate if necessary.
All Java 8 and 7, and 6 from 6u22 up, enable secure renegotiation per 5746. See the documentation. By default, it is used if the peer offers or accepts it; if the peer does not, the connection is still made but renegotiation is not done because it would/could be insecure. This can be varied two ways:
set system property sun.security.ssl.allowLegacyHelloMessages false. JSSE will not make the connection if the peer does not agree to 5746. This is not actually more secure, but it is more visibly secure to simple minded basic scanners, and people who care about simple minded basic scanners like auditors
set system property sun.security.ssl.allowUnsafeRenegotiation true. This is less secure if the application depends on peer credentials checked after a message. Since client always checks server before any data, this means if server requests (not requires) client authentication, and checks auth status after a request, it can wrongly accept a forged-prefix request.
The protocol implementation of 5746 sometimes uses a fake "ciphersuite" (officially SCSV -- Signalling Cipher Suite Value) in ClientHello. JSSE client can be configured using the "ciphersuite" name TLS_EMPTY_RENEGOTIATION_INFO_SCSV whether to use this SCSV or the extension. All servers always use the extension, and thus this configuration has no effect on JSSE server.
When programming for a SSL, no matter which language you choose (C++, Java, Ruby etc.), you probably encounter SSLContext object which would be used. I do not know what does SSLContext semantically means? When I search google for it, there just come many pages explaining the syntactical usage of such object for various programming languages.
My Question: What does SSLContext mean/do in terms of SSL? Regardless of the language which implements it.
SSL Context is a collection of ciphers, protocol versions, trusted certificates, TLS options, TLS extensions etc. Since it is very common to have multiple connections with the same settings they are put together in a context and the relevant SSL connections are then created based on this context. And to create a new connection you need only refer to the context which thus saves time and memory compared to the case you would have to re-create of all these settings.
EDIT: #EJP nicely describes this "collection" as factory. A SSL context is not the same as a SSL session even both are collections of settings. A session is what you get after the SSL handshake and covers only the cipher and protocol version both parties agreed on and also the exchanged key. Whereas the context covers all the ciphers and protocol versions and also the list of trusted certificates the local system (client or server) is willing to support when establishing a new TLS connection. Thus a SSL session describes an established SSL relation while the SSL context describes what you need to establish an SSL relation.
SSLContext: Instances of this class represent a secure socket protocol implementation which acts as a factory for secure socket factories or SSLEngines. This class is initialized with an optional set of key and trust managers and source of secure random bytes.
SSLSession: In SSL, sessions are used to describe an ongoing relationship between two entities. Each SSL connection involves one session at a time, but that session may be used on many connections between those entities, simultaneously or sequentially. The session used on a connection may also be replaced by a different session. Sessions are created, or rejoined, as part of the SSL handshaking protocol. Sessions may be invalidated due to policies affecting security or resource usage, or by an application explicitly calling invalidate. Session management policies are typically used to tune performance.
SSLSessionContext: A SSLSessionContext represents a set of SSLSessions associated with a single entity. For example, it could be associated with a server or client who participates in many sessions concurrently. An SSLSessionContext can be configured with a session timeout.
The use of SSLv3.0/TLSv1.0 in combination with certain encryption techniques (CBC block
ciphers) may allow for an attacker to predict the so-called Initialization Vector of subsequent SSL packets. Using this information the attacker can access the secure session of another user. This attack, named BEAST (Browser Exploit Against SSL/TLS), is aimed at the user’s browser and not at the web server. Nevertheless, it is possible to take countermeasures at the server side as well to prevent a successful attack.
The complete solution to this problem is disabling or deprioritizing the support for
vulnerable encryption ciphers (CBC block ciphers) when using SSLv3.0/TLSv1.0. Commonly, this can be achieved by prioritizing RC4 ciphers in the cipher negotiation process.
For Apache web servers that support SSLv3.0/TLSv1.0 this can be configured by adding the
following configuration:
SSLProtocol All –SSlv2
SSLHonorCipherOrder On
SSLCipherSuite RC4-SHA:HIGH:!ADH
For Apache web servers that support SSLv3.1/TLSv1.1 and higher, it is recommended to use the following configuration:
SSLProtocol All –SSlv2
SSLHonorCipherOrder On
SSLCipherSuite ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM
As far as I know, JBoss 7 is based on a version of Apache that supports SSLv3.1/TLSv1.1 (maybe I am wrong), so the second alternative can be applied to JBoss 7.
My question is: Where/How should I configure it?
Dont paranoid with beast attack. According to this Oracle fix the issue, its not related directly with JBoss its an JVM issue. As stated here its hard to apply beast attack in real world. Just make sure that your JVM and JBoss is up-to-date. If you have still question in your mind its best practice to run JBoss behind a reverse proxy such as apache or nginx.
I'm pretty far out of my depth here, so bear with me. We're using JDBC via com.intersys.jdbc.cachedriver to run stored procedures in Intersystems Cache and get the results in Java. However, there are other clients that connect directly to the Cache using a terminal over telnet. We have to lock down Cache's telnet port so that only telnet over SSL is possible. However, the Cache experts here say that locking down one port in Cache locks them all down, so the Java to Cache connection will also have to use SSL. I understand vaguely that some JDBC drivers support SSL, but I don't see that the Cache one does. What I need to know is:
What's needed to configure SSL for the JDBC connections? (We're using JBoss 4.2.3)
What about certificates? I assume those have to go somewhere.
Is it actually true that locking down the telnet connections is also going lock down JDBC in the same way?
Configuring Java Clients to Use SSL/TLS with Caché
Using SSL/TLS with Caché
Telnet vs ssh is a question about what the OS allows and only relates to Cache peripherally. It doesn't mean anything regarding items 1 or 2. So in answer to the direct question you are asking, "No".
1. What's needed to configure SSL for the JDBC connections? (We're using JBoss 4.2.3)
See http://docs.intersystems.com/cache20102/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_ssltls#GCAS_ssltls_javacli for details. This section doesn't explicitly mention JDBC, but it's true for JDBC (and the reference has been added for the documentation 2011.1 [next release] .)
2. What about certificates? I assume those have to go somewhere.
To quote the documentation: "If the client has a private key and certificate, these are stored in the client’s keystore; the keystore can also hold the client’s root CA certificate and any intermediate CA certificates. To authenticate the server, the client may need to have the root CA certificate for the server and any intermediate CA certificates, these can be stored either in the client’s truststore or along with client certificate information in the keystore. For more information on keystores and truststores, see the section “Keystores and Truststores” in the Java Secure Socket Extension (JSSE) Reference Guide."
3. Is it actually true that locking down the telnet connections is also going lock down JDBC in the same way?
Yes -- if telnet connections are to require TLS, then the superserver TLS setting needs to be Required, which means that you have to use TLS for anything that goes through the superserver (including JDBC). If you just want to allow the use of TLS for telnet connections, set the TLS value to Enabled, which allows non-TLS connections by other means (such as JDBC).