For backwards compatibility reasons I need a Geode Jetty server to use TLSv1 and not 1.1 or 1.2
With ssl-enabled-components=web and ssl-protocols=TLSv1.0 set in gemfire.properties then when I start the Geode and check the HTTPS connectivity with SSL Labs then I get a TLS result:
I am looking for the TLS 1.1 and TLS 1.0 checks to also say Yes not No
The Geode SSL docs say Make sure your Java installation includes the JSSE API and familiarize yourself with its use.
The JSSE is about the java.security config in the JRE/lib/security directory. I set this not to disable any security algorithms and restarted Geode but the results are the same. TLS 1.1 and 1.0 are failing the SSL Labs test above.
Is there a way to force Geode to start with https.protocols=TLSv1 ?
When I try to start a locator with that using --J=-XX:https.protocols=TLSv1 then I get
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Unrecognized VM option 'https.protocols=TLSv1'
There is no separate Jetty config I can find...
Update --J=-Dhttps.protocols=TLSv1 is the correct setting to assign TLS protocols to the JVM and that works on starting Geode locator and server.
Update When I set java.security setting jdk.tls.disabledAlgorithms=TLSv1.1, TLSv1.2 like the opposite of this then it's not possible to communicate via HTTPS with the Jetty server at all. This makes me think the Geode / Jetty ssl-protocols=TLSv1.0 setting does not apply either?
The Jetty config says TLS v1.0, v1.1 and SSL v3 are no longer supported by default. If your Jetty implementation requires these protocols for legacy support, they can be enabled manually.
Is there a way to configure Jetty with Geode?
I don't believe you can currently achieve this. Mainly because of how Jetty is being configured internally. Jetty maintains a list of excluded ciphers defined by the regex ^.*_(MD5|SHA|SHA1)$. Unfortunately, it seems that this list trumps any ciphers which may be added as 'included'. Here's a very simple Jetty example that I used for testing: https://gist.github.com/jdeppe-pivotal/c0c6e7de4282bc077357749fc91bc44f. Jetty will produce a nice dump of the ciphers and protocols it is using when you run this.
As it stands, you can perform a successful request with the following curl: curl -k -v --tlsv1.2 https://localhost:8081/. Now, if you try that with tlsv1.0 it will fail because the necessary cipher suites are all disabled. However, if you uncomment the line: sslContextFactory.setExcludeCipherSuites() then things should start working. What this does is to remove all the current excluded ciphers (and allow them to be used). Unfortunately if you only try and add ciphers (without also excluding everything) things still don't work. Note that by doing this, Jetty is still configured for TLSv1.2 (and 1.1 and 1.0) but the client can use a lower protocol version.
The bottom line is that Geode does not explicitly exclude any ciphers from Jetty. Thus if you're hoping to add the necessary ciphers, they will most likely not be effective. I've opened a bug for this: https://issues.apache.org/jira/browse/GEODE-3891
Related
I am trying to set up MTLS on a Jetty Server. From the documentation I have seen typically the server certificate is set up such as this
SslContextFactory.Server sslContextFactory = new SslContextFactory.Server();
sslContextFactory.setKeyStorePath("/Users/name/Downloads/server.jks");
sslContextFactory.setKeyStorePassword("changeit");
sslContextFactory.setTrustStorePath("/Users/name/Downloads/server_truststore.jks");
sslContextFactory.setTrustStorePassword("changeit");
sslContextFactory.setNeedClientAuth(true);
However, I want to have different server certificates to validate against depending on which device sent the client certificate? What settings do i need to change, or classes can I override to dynamically validate certificates?
You'll have to download it and then configure your SslContextFactory.Server to use the local copy.
This is a Java SSL engine limitation.
Use the prior answer on how to download a file from Amazon S3 ...
https://stackoverflow.com/a/28569038/775715
For mTLS, just set the SslContextFactory.Server features you want to use for your set of features.
SslContextFactory.Server.setNeedClientAuth(boolean)
This is the javax.net.ssl.SSLParameters.setNeedClientAuth(boolean) feature in the Java JVM.
SslContextFactory.Server.setWantClientAuth(boolean)
This is the javax.net.ssl.SSLParameters.setWantClientAuth(boolean) feature in the Java JVM.
The behavior is standard Java JVM behavior, Jetty does very little here (Jetty only configures the JVM SSLEngine and SSLParameters objects, and handles host/alias matching if using SNI), all of the mTLS behaviors are baked into the JVM.
Everything from this point forward is standard Java behaviors of Client Auth, and Server Keystore/Truststore, there is nothing unique or special about Jetty. It's all a matter of configuring your Keystore/Truststore and issuing valid client certificates from those stores.
If you want multiple server certificates, go for, that's supported by the keystore / truststore.
If you want the client to validate against different server certificates, then the client needs to use the appropriate combination of server hostname and SNI information (this is an extremely common TLS extension).
Please bear with me. I'm no SSL encrpytion expert. I just want to make connections to a server, using their API. I am unable to. When I use this api as indicated in the documentation, the following error occurs:
[Errno 1] _ssl.c:510: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
This API seems to be hosted on an AWS server somewhere, and the support person for it has referred me to this AWS document with the added information that their server uses TLSv1_2016. I'm not sure that that's correct, but that's what I was told.
This version of TLS is not supported by the OpenSSL that ships with Ubuntu 14.0.4 (openssl v1.0.1f). Version 1.2 IS supported. I upgrade my system on a regular basis, and it doesn't seem that there is any approved Ubuntu release that supports this protocol. I've been advised to upgrade, but it's not clear to what.
This is all Greek to me. Can someone tell me what upgrade I might be able to do my system to solve this?
UPDATE problem persists after installing Ubuntu-18.04, which comes with openssl 1.1.0g.
Answer mostly from comments.
The problem is apparently that the server, like many SSL/TLS servers today especially those handling multiple domains like Cloudfront, requires the SNI (Server Name Indication) extension in SSL/TLS. This was (and easily is) checked with openssl s_client which (unlike most programs) has an option that controls whether to send SNI.
You didn't previously say that this code is Python. It is Python that links to and invokes OpenSSL. (The OS is not involved in SSL/TLS, only in the lower-level TCP/IP protocols.) According to http://docs.python-requests.org/en/master/community/faq/ (at the bottom)
Python3 and Python 2.7.9+ include native support for SNI in their SSL modules. For information on using SNI with Requests on Python < 2.7.9 refer to this Stack Overflow answer.
linking to using requests with TLS doesn't give SNI support which has several answers that appear to consist mostly of updating various things (and I am not in a position to test even if you gave details of your Python and Requests which you didn't).
I am using ColdFusion 10. How can I specify my connection is TLS 1.1, TLS 1.0, etc. Can I use the cfhttp tag?
How to add TLS 1.2 in cfhttp tag using ColdFusion?
ColdFusion 10 will handle the TLS 1.2 protocol using CFHTTP without any issues as long as you are running Coldfusion on Java 1.8.0_nn. You need to upgrade your Java version. Also see this article I wrote on which SSL/TLS protocols are usable for each ColdFusion/Java version combinations.
https://www.trunkful.com/index.cfm/2014/12/8/Preventing-SSLv3-Fallback-in-ColdFusion
To install a new Java version I always install the JDK in a non-default location that is only used for ColdFusion. ie C:\java\jdk1.8.0_nn\ This way you know it's for ColdFusion and not for the OS. Of course if you're on Linux then the location would be different, but you'd know that already.
Regards,
Wil
The easiest way that I've found so far to use native CF 10 tags and TLS 1.2 is to upgrade the JDK/JRE to 1.8 on the CF server.
I've been using ColdFusion 10 with Server JRE 1.8 u151 for a while now.
You can download the Server JRE here:
http://www.oracle.com/technetwork/java/javase/downloads/server-jre8-downloads-2133154.html
For my Windows Server, I just unzip/tar the server-jre-8u151-windows-x64.tar.gz file to "C:\Program Files\Java". This creates a folder named jdk1.8.0_151.
Log into your CF Administrator
Server Settings > Java and JVM
Set [Java Virtual Machine Path] to C:/Program Files/Java/jdk1.8.0_151/jre
Add this phrase to [JVM Arguments]: -Dhttps.protocols=TLSv1.2
Submit Changes
After you restart ColdFusion, it will now be using Server JRE 1.8u151 and force SSL to use TLS 1.2.
I've been performing TLS 1.2 connections using ColdFusion 4.5, 5.0, 6MX, 7, 8, 9, 10, 11 & 2016 using CFX_HTTP5, a C/C++ tag (0% Java; 0% COM; 0% MFC).
http://www.adiabata.com/cfx_http5.cfm
PayPal is in the process of upgrading their API endpoints to allow only TLS 1.2 and HTTP/1.1 connections.
https://www.paypal-knowledge.com/infocenter/index?page=content&widgetview=true&id=FAQ1914&viewlocale=en_US
The only way I could connect to https://tlstest.paypal.com/ was to use CFX_HTTP5 w/CF9 & 10 was to set SSL="5". CFX_HTTP5 also enables you to specify which protocol version to use per-request. It's not a setting that is enabled and forced on all connections... no guessing, interfering w/other website requirements hosted on same server or need to restart the server when changing protocols.
SSL =
0 - SSL3 and TLS1;
1 - SSL2;
2 - SSL3;
3 - TLS1;
4 - TLS1.1;
5 - TLS1.2;
I've also encountered situations where SSL certificates are temporarily invalid due to accidental expiration. In those cases, CFX_HTTP5's SSLERRORS="OK" flag enabled me to consume the API while ignoring the temporary certificate error. (I don't believe that ColdFusion can do this.)
I'm a bit confused about using OpenSSL in my Delphi webservice in relation to the available ciphers for a HTTPS connection.
Setup:
My webservice runs on a client's server. OpenSSL is installed there. The webservice uses Indy (a TIdHTTPWebBrokerBridge) and the OpenSSL DLLs (with TIdServerIOHandlerSSLOpenSSL) to load the client's certificate
Our Android/iOS apps connect to this webservice over HTTPS
The client has configured a domain and IP that the app users can connect to and reach my webservice. If we test that domain using e.g. the SSLLabs server test we get an overview of the supported ciphers and protocols (SSLLabs even mimics handshakes from devices and browsers and shows what ciphers were negotiated).
Question: Is there anything my webservice (in combination with OpenSSL) has to do/can do to influence the available ciphers for the TLS handshake between app and webservice? Is there anything additional that needs to be setup with OpenSSL?
I thought the answer is 'no', i.e. that it is just the server setup that (in the handshake with the app through Android/iOS) determines which cipher to use from the available server ones. Is this a correct assumption? Or do I miss something?
(As a matter of fact, I am not actually interested in limiting or expanding the available ciphers, but the client insists that something "should be done" in/with the webservice/OpenSSL to have it communicate "safely" with the apps. The SSLLabs test shows that their domain only supports TLS 1.0 and ciphers with the RSA key exchange mechanism, so e.g. no Perfect Forward Secrecy. To me, that looks like something that needs to be fixed anyway).
Notes:
This SO question suggests I may have to do something, but it has no answers.
I posted an earlier somewhat related question, but that has no answers.
This SO post states OpenSSL honors the client's cipher preference, not the server's, during the SSL handshake, which again suggest there are things I can do?
I had some doubts whether this question is in the proper place here (also because Why we are not customer support), but since this may be relevant to more programmers I decided to put it on SO.
You can specify available ciphers via TIdServerIOHandlerSSLOpenSSL.SSLOptions.CipherList (as well as SSL/TLS versions via TIdServerIOHandlerSSLOpenSSL.SSLOptions.SSLVersions).
If you want Perfect Forward Secrecy, you has to create DHParam keys using openssl.exe (fill TIdServerIOHandlerSSLOpenSSL.SSLOptions.DHParamsFile by result file name). If you want not only DHE, but ECDHE ciphers you need to call some additional openssl api, see a Support for Perfect Forward Secrecy in SSL with indy 10 for example.
I'm using BURP and I always get this alert after a while (maybe like 2-3 minutes of use)
javax.net.ssl.SSLHandshakeException: server certificate change is restrictedduring renegotiation
any idea where that could come from? I don't see anyone talking about it on internet
You're having the exact same issue that has been asked previously: What means "javax.net.ssl.SSLHandshakeException: server certificate change is restrictedduring renegotiation" and how to prevent it?
In short the issue is due to security controls in the newer Java versions that check whether the certificate that it received for the hostname has the same contents (Subject, Issuer, SANs) as the one it previously received.
This has to do with newer versions of Java with older versions (or the free version) of Burp Suite, and using an upstream proxy. Burp Suite Pro v1.6.07+ fixes this, as well as turning off the upstream proxy or downgrading your Java (though not recommended).