Related
I wrote an Http Client using Apache HttpClient 4.1.13 which call a remote HTTP service using 2way-ssl.
I configured:
keystore.jks : contains the private key and the client certificate
keystore password: the password of keystore.jks
truststore.jks: contains the certificate of CA e intermediate CA of the server
truststore password: the password of truststore.jks
the code:
KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
FileInputStream instream = new FileInputStream(new File(keystore));
try {
keyStore.load(instream, keyStorePassword.toCharArray());
} finally {
instream.close();
}
KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType());
instream = new FileInputStream(new File(trustore));
try {
trustStore.load(instream, trustorePassword.toCharArray());
} finally {
instream.close();
}
SSLContext sslContext = SSLContexts.custom()
.loadKeyMaterial(keyStore, keyStorePassword.toCharArray())
.loadTrustMaterial(trustStore, new TrustSelfSignedStrategy())
.build();
SSLConnectionSocketFactory sslsf = new SSLConnectionSocketFactory(
sslContext,
new String[] {"TLSv1.1","TLSv1.2"},
null,
SSLConnectionSocketFactory.BROWSER_COMPATIBLE_HOSTNAME_VERIFIER);
poolingConnManager = new PoolingHttpClientConnectionManager(
RegistryBuilder.<ConnectionSocketFactory>create()
.register("http", PlainConnectionSocketFactory.INSTANCE)
.register("https", sslsf)
.build());
If I run a java main (JDK Java(TM) SE Runtime Environment (build 1.8.0_231-b11) which does the call, I got a successful connection and I see in the logs
[2022-01-25 17:49:18][][][][][main][DEBUG]o.a.h.c.s.SSLConnectionSocketFactory - Secure session established
[2022-01-25 17:49:18][][][][][main][DEBUG]o.a.h.c.s.SSLConnectionSocketFactory - negotiated protocol: TLSv1.2
[2022-01-25 17:49:18][][][][][main][DEBUG]o.a.h.c.s.SSLConnectionSocketFactory - negotiated cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[2022-01-25 17:49:18][][][][][main][DEBUG]o.a.h.c.s.SSLConnectionSocketFactory - peer principal: XXXXX
[2022-01-25 17:49:18][][][][][main][DEBUG]o.a.h.c.s.SSLConnectionSocketFactory - peer alternative names: [YYYYY]
[2022-01-25 17:49:18][][][][][main][DEBUG]o.a.h.c.s.SSLConnectionSocketFactory - issuer principal: XXXXX
If I run the same code with the same keystores and passwords in Docker OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_252-b09)) I got the following handshake error
http-nio-8080-exec-1, READ: TLSv1.2 Alert, length = 2
http-nio-8080-exec-1, RECV TLSv1.2 ALERT: fatal, handshake_failure
%% Invalidated: [Session-1, SSL_NULL_WITH_NULL_NULL]
%% Invalidated: [Session-2, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
http-nio-8080-exec-1, called closeSocket()
http-nio-8080-exec-1, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
[2022-01-25 16:47:45][SESSION_NOT_INITIALIZED][10.60.168.202][http-nio-8080-exec-1] [DEBUG]o.a.h.i.c.DefaultManagedHttpClientConnection - http-outgoing-0: Shutdown connection
[2022-01-25 16:47:45][SESSION_NOT_INITIALIZED][10.60.168.202][http-nio-8080-exec-1] [DEBUG]o.a.h.impl.execchain.MainClientExec - Connection discarded
What should I search ? Any hints?
UPDATE:
The keystore contains the private key and the certificate chain : certificate -> intermediate CA -> Root CA; I don't understand why the client doesn't find the right certificate to send to the server.
In the working test I got this log
*** ServerHelloDone
[read] MD5 and SHA1 hashes: len = 4
0000: 0E 00 00 00 ....
matching alias: 1
*** Certificate chain
In the failed test I got:
*** ServerHelloDone
Warning: no suitable certificate found - continuing without client authentication
*** Certificate chain
It was my mistake and the problem was in totally different point.
The above code was right.
Here is the situation: SSLServerSocket timeout is set to 10 seconds. Everything works as expected, BUT if client is trying to establish TLS connection and "hangs" during negotiation - socket waits forever, ignores 10 second timeout.. and connection is terminated only by client. This is some hacker activity or some kind of other activity.. Is this Java secure socket vulnerability?
Activity log:
SMTP PID=184 Date=2019-08-26,07:32:45 DEBUG: new connection from host [66.45.239.113] to port 465 (United States)
javax.net.ssl|DEBUG|CE|Thread-191|2019-08-26 07:32:45.547 EEST|HandshakeContext.java:296|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLS13
javax.net.ssl|DEBUG|CE|Thread-191|2019-08-26 07:32:45.548 EEST|HandshakeContext.java:296|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for TLS13
javax.net.ssl|DEBUG|CE|Thread-191|2019-08-26 07:32:45.548 EEST|HandshakeContext.java:296|Ignore unsupported cipher suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 for TLS13
javax.net.ssl|DEBUG|CE|Thread-191|2019-08-26 07:32:45.548 EEST|HandshakeContext.java:296|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLS13
javax.net.ssl|DEBUG|CE|Thread-191|2019-08-26 07:32:45.548 EEST|HandshakeContext.java:296|Ignore unsupported cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384 for TLS13
javax.net.ssl|DEBUG|CE|Thread-191|2019-08-26 07:35:03.253 EEST|SSLSocketInputRecord.java:458|Raw read (
0000: 80 4C 01 03 01 .L...
)
javax.net.ssl|ERROR|CE|Thread-191|2019-08-26 07:35:03.254 EEST|TransportContext.java:312|Fatal (HANDSHAKE_FAILURE): SSLv2Hello is not enabled (
"throwable" : {
javax.net.ssl.SSLHandshakeException: SSLv2Hello is not enabled
at java.base/sun.security.ssl.SSLSocketInputRecord.handleUnknownRecord(SSLSocketInputRecord.java:366)
at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:184)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1180)
at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1091)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
at java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:721)
at java.base/sun.security.ssl.SSLSocketImpl.getSession(SSLSocketImpl.java:331)
at com.xsistema.xmailserver.mail.smtp.session.SMTPConnection.getTLSVersion(SMTPConnection.java:141)
at com.xsistema.xmailserver.mail.smtp.session.SMTPConnection.run(SMTPConnection.java:240)}
)
javax.net.ssl|DEBUG|CE|Thread-191|2019-08-26 07:35:03.254 EEST|SSLSocketOutputRecord.java:71|WRITE: TLS13 alert(handshake_failure), length = 2
javax.net.ssl|DEBUG|CE|Thread-191|2019-08-26 07:35:03.254 EEST|SSLSocketOutputRecord.java:85|Raw write (
0000: 15 03 03 00 02 02 28 ......(
)
javax.net.ssl|DEBUG|CE|Thread-191|2019-08-26 07:35:03.254 EEST|SSLSocketImpl.java:1389|close the underlying socket
javax.net.ssl|DEBUG|CE|Thread-191|2019-08-26 07:35:03.254 EEST|SSLSocketImpl.java:1408|close the SSL connection (initiative)
javax.net.ssl|ERROR|CE|Thread-191|2019-08-26 07:35:03.254 EEST|SSLSocketImpl.java:334|handshake failed (
"throwable" : {
javax.net.ssl.SSLHandshakeException: SSLv2Hello is not enabled
at java.base/sun.security.ssl.SSLSocketInputRecord.handleUnknownRecord(SSLSocketInputRecord.java:366)
at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:184)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1180)
at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1091)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
at java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:721)
at java.base/sun.security.ssl.SSLSocketImpl.getSession(SSLSocketImpl.java:331)
at com.xsistema.xmailserver.mail.smtp.session.SMTPConnection.getTLSVersion(SMTPConnection.java:141)
at com.xsistema.xmailserver.mail.smtp.session.SMTPConnection.run(SMTPConnection.java:240)}
)
SMTP PID=184 Date=2019-08-26,07:35:03 DEBUG: SSL socket cipher suite: NONE:SSL-NULL-WITH-NULL-NULL
SMTP PID=184 Date=2019-08-26,07:35:03 DEBUG: connection from remote host [66.45.239.113] was closed and removed. Current active or waiting connections: 3
Client connected at 07:32:45, and sent some bytes only after more than 2 minutes, at 07:35:03. So in this scenario it can send first bytes after hour or more, and connection will be opened. And if it sends 1000 requests and waits - 1000 connections will be opened forever?? Perhaps the solution is to measure the time before reading InputStream?
I recently added SSL to my website and it can be accessed over https. Now when my java application tries to make requests to my website and read from it with a buffered reader it produces this stack trace
Im not using a self signed certificate the cert is from Namecheap who uses COMODO SSL as the CA to sign my certificate. im using java 8
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
at sun.security.ssl.Handshaker.activate(Handshaker.java:503)
at sun.security.ssl.SSLSocketImpl.kickstartHandshake(SSLSocketImpl.java:1482)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1351)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
My code is very basic and simply tries to read the page on my site using a buffered reader
private void populateDataList() {
try {
URL url = new URL("https://myURL.com/Data/Data.txt");
URLConnection con = url.openConnection();
con.setRequestProperty("Connection", "close");
con.setDoInput(true);
con.setUseCaches(false);
BufferedReader in = new BufferedReader(new InputStreamReader(con.getInputStream()));
String line;
int i = 0;
while((line = in.readLine()) != null) {
this.url.add(i, line);
i++;
}
} catch (Exception e) {
e.printStackTrace();
}
}
Ive tried adding my SSL certificate to the JVM's Keystore and Ive also even tried to accept every certificate (which defeats the purpose of SSL I know) with this code
private void trustCertificate() {
TrustManager[] trustAllCerts = new TrustManager[] {
new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return new X509Certificate[0];
}
public void checkClientTrusted(
java.security.cert.X509Certificate[] certs, String authType) {
}
public void checkServerTrusted(
java.security.cert.X509Certificate[] certs, String authType) {
}
}
};
try {
SSLContext sc = SSLContext.getInstance("TLS");
sc.init(null, trustAllCerts, new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
} catch (GeneralSecurityException e) {
}
try {
URL url = new URL("https://myURL.com/index.php");
URLConnection con = url.openConnection();
BufferedReader br = new BufferedReader(new InputStreamReader(con.getInputStream()));
String line;
while((line = br.readLine()) != null) {
System.out.println(line);
}
} catch (Exception e) {
}
}
Im stumped and any help would be much appreciated!
In $JRE/lib/security/java.security:
jdk.tls.disabledAlgorithms=SSLv3, TLSv1, RC4, DES, MD5withRSA, DH keySize < 1024, \
EC keySize < 224, 3DES_EDE_CBC, anon, NULL
This line is enabled, after I commented out this line, everything is working fine. Apparently after/in jre1.8.0_181 this line is enabled.
My Java version is "1.8.0_201.
I also run into this with the Java8 update 1.8.0.229 on Ubuntu 18.04.
I changed the following part:
# Example:
# jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048
#jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
# DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
# include jdk.disabled.namedCurves
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, \
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
include jdk.disabled.namedCurves
I removed TLSv1 and TLSv1.1 from the list of jdk.tls.disabledAlgorithms inside the file
/etc/java-8-openjdk/security/java.security
After checking this:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 28
Server version: 5.7.33-0ubuntu0.18.04.1 (Ubuntu)
Copyright (c) 2000, 2021, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> SHOW GLOBAL VARIABLES LIKE 'tls_version';
+---------------+-----------------------+
| Variable_name | Value |
+---------------+-----------------------+
| tls_version | TLSv1,TLSv1.1,TLSv1.2 |
+---------------+-----------------------+
1 row in set (0.00 sec)
mysql> exit
protocol is disabled or cipher suites are inappropriate
The key to the problem lies in that statement. What it basically means is either:
The TLS implementation used by the client does not support the cipher suites used by the server's certificate.
The TLS configuration on the server has disabled cipher suites supported by the client.
The TLS configurations on the client disable cipher suites offered by the server.
TLS version incompatibility between the client and server.
This leads to handshake failure in TLS, and the connection fails. Check one or all of the three scenarios above.
You can add the expected TLS protocol to your connection string like this:
jdbc:mysql://localhost:3306/database_name?enabledTLSProtocols=TLSv1.2
That fixed the problem for me.
Edit 04-02-2022:
As Yair's comment says:
Since Connector/J 8.0.28 enabledTLSProtocols has been renamed to tlsVersions.
In my case I am runnig Centos 8 and had the same issue with Imap/Java.
Had to update the system-wide cryptographic policy level.
update-crypto-policies --set LEGACY
reboot machine.
Thats it.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/considerations_in_adopting_rhel_8/security_considerations-in-adopting-rhel-8#tls-v10-v11_security
We started experiencing this problem after upgrading to jre1.8.0_291. I commented out "jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA,
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL,
include jdk.disabled.namedCurves" in java.security located in C:\Program Files\Java\jre1.8.0_291\lib\security which resolved the problem.
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
For posterity, I recently bumped up against this using IBM's JDK8 implementation which specifically disables TLS1.1 and 1.2 by default (sic). If you want to see what TLS versions are supported by the JVM, run something like the following code:
SSLContext context = SSLContext.getInstance("TLS");
context.init(null, null, null);
String[] supportedProtocols = context.getDefaultSSLParameters().getProtocols();
System.out.println(Arrays.toString(supportedProtocols));
The code spits out [TLSv1] by default under AIX JDK8. Not good. Under Redhat and Solaris it spits out [TLSv1, TLSv1.1, TLSv1.2].
I could not find any values in the java.security file to fix this issue but there might be some for your architecture. In the IBM specific case, we have to add:
-Dcom.ibm.jsse2.overrideDefaultTLS=true
In my case I had to upgrade the mysql client library to the latest version and it started working again:
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>8.0.24</version>
</dependency>
I have encountered
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
error when accessing TLS 1.3 enabled endpoint from a Java 11 application. That is a usual case in GCP, for example.
The problem has gone away without any changes in my code just by upgrading from Java 11 to Java 14.
The Java 11 doesn't deprecate earlier TLS protocol versions by default. Instead of configuring it, simple upgrade of the runtime to Java 14 has helped.
Apparently, if you have TLS 1.0 disabled the emails won't be sent out. TLS Versions 1.1 and 1.2 do not work. Peter's suggestion did the trick for me.
I was face with the same situation on a tomcat7 server, 5.7.34-0ubuntu0.18.04.1, openjdk version "1.8.0_292"
I tried many approaches like disabling SSL in the server.xml file, changing the connection strings etc etc
but in the end all i did was to edit the file java.security with
sudo nano /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/java.security
comment out and remove TLSv1 and TLSv1.1
# Comment the line below
#jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
# DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
# include jdk.disabled.namedCurves
# your new line should read as beloew
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, \
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
include jdk.disabled.namedCurves
For ME in this case :
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
I found that this is JDK/JRE (Java\jdk1.8.0_291\jre\lib\security) config related, and in order to solve it you need to Disable the TLS anon and NULL cipher suites.
You can found how to do this in the oficial documentation here:
https://www.java.com/en/configure_crypto.html
Also before doing this, consider the implications of using LEGACY algorithms.
upgraded from 1 to 2 + modifying the $JRE/lib/security/java.security file did the trick.
before after mysql driver
Need some help fixing an error for an application that connects to an SMTP Server (Lotus Notes Server). I have already tried several suggestions in SO but none of it worked. The application is able to connect to the SMTP server and do a handshake.
However it gives an error after starttls is initiated. Also comment out a line in java.security file as suggested on Oracle website since we are using Java 8 but its still not working.
Also have some small utility to check which SSL protocols are enabled and SSLv3, TLS, TLSv1, TLSv1.2 are all enabled. Can't understand why the server would want to use SSLv3 and then say could not convert socket to TLS. It doesn't make any sense.
Code Truncated
#Service
public class ManifestEmailService {
private static final Logger logger = Logger.getLogger(ManifestEmailService.class);
#Autowired
private JavaMailSender mailSender;
public void sendManifestMail(MailProperties prop, String recipient, String msgBody) {
logger.info("Creating Email Body");
logger.info("Sender mail: "+ prop.getSender()+ " Sender Subject: "+ prop.getMailSubject());
SimpleMailMessage msg = new SimpleMailMessage();
msg.setFrom(prop.getSender());
msg.setTo(recipient);
msg.setSubject("FHL");
msg.setText(msgBody);
try {
logger.info("Sending mail message");
mailSender.send(msg);
} catch (MailException mEx) {
logger.error("Problem sending email..." + mEx);
}
}
}
#Configuration
public ManifestoConfig {
#Bean
public JavaMailSender getJavaMailSender() {
JavaMailSenderImpl mailSender = new JavaMailSenderImpl();
FileProcessor io = new FileProcessor();
Properties props = io.loadManifestoProperties(manifestoPropPath);
logger.info("Configure Mail Properties ... ");
mailSender.setHost(props.getProperty("sender.mail.host"));
mailSender.setPort(Integer.valueOf(props.getProperty("sender.mail.port")));
mailSender.setUsername(props.getProperty("sender.mail.username"));
mailSender.setPassword(props.getProperty("sender.mail.password"));
mailSender.setJavaMailProperties(io.loadManifestoProperties(manifestoPropPath));
return mailSender;
}
}
Properties File
sender.mail.username=rubbishemail1#lt.com
sender.mail.password=rubbishpassword1
sender.mail.subject=FHL
sender.mail.host=smtp.lotus.server.com
sender.mail.port=25
mail.transport.protocol=smtp
mail.smtp.auth=true
mail.smtp.starttls.enable=true
mail.smtp.timeout=5000
mail.smtp.ssl.enable=false
mail.debug=true
ERROR LOG
2017-05-18 11:53:27.206 INFO 4804 --- [nio-8080-exec-6] org.fhl.service.Manifes
tEmailService : Sending mail message
DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.s
mtp.SMTPTransport,Oracle]
DEBUG SMTP: useEhlo true, useAuth true
DEBUG SMTP: trying to connect to host "smtp.lotus.server.com", port 25, isSSL fals
e
220 lotus.mail.server ESMTP Service (Lotus Domino Release 8.5.3FP6) read
y at Thu, 18 May 2017 08:53:27 +0100
DEBUG SMTP: connected to host "smtp.lotus.server.com", port: 25
EHLO client_user
250-lotus.mail.server Hello client_user ([10.210.136.6]), pleased
to meet you
250-TLS
250-HELP
250-STARTTLS
250-DSN
250-SIZE 52428800
250 PIPELINING
DEBUG SMTP: Found extension "TLS", arg ""
DEBUG SMTP: Found extension "HELP", arg ""
DEBUG SMTP: Found extension "STARTTLS", arg ""
DEBUG SMTP: Found extension "DSN", arg ""
DEBUG SMTP: Found extension "SIZE", arg "52428800"
DEBUG SMTP: Found extension "PIPELINING", arg ""
STARTTLS
220 Ready to start TLS
2017-05-18 11:53:28.236 ERROR 4804 --- [nio-8080-exec-6] org.fhl.service.Manifes
tEmailService : Problem sending email...org.springframework.mail.MailSendExc
eption: Mail server connection failed; nested exception is javax.mail.MessagingE
xception: Could not convert socket to TLS;
nested exception is:
javax.net.ssl.SSLHandshakeException: Server chose SSLv3, but that protoc
ol version is not enabled or not supported by the client.. Failed messages: java
x.mail.MessagingException: Could not convert socket to TLS;
nested exception is:
javax.net.ssl.SSLHandshakeException: Server chose SSLv3, but that protoc
ol version is not enabled or not supported by the client.; message exceptions (1
) are:
Failed message 1: javax.mail.MessagingException: Could not convert socket to TLS
;
nested exception is:
javax.net.ssl.SSLHandshakeException: Server chose SSLv3, but that protoc
ol version is not enabled or not supported by the client.
SSL Logs
[DEBUG] 2017-06-07 11:27:34.171 [JavaFX Application Thread] ManifestEmailService
- Load Mail Properties in into Javamail Session
DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.s
mtp.SMTPTransport,Sun Microsystems, Inc]
DEBUG SMTP: useEhlo true, useAuth true
DEBUG SMTP: useEhlo true, useAuth true
DEBUG SMTP: trying to connect to host "164.39.7.92", port 25, isSSL false
220 lotus.mail.server ESMTP Service (Lotus Domino Release 8.5.3FP6) read
y at Wed, 7 Jun 2017 08:27:34 +0100
DEBUG SMTP: connected to host "smtp.lotus.server.com", port: 25
EHLO CHOL162
250-lotus.mail.server Hello CHOL162 ([10.210.136.21]), pleased to meet y
ou
250-TLS
250-HELP
250-STARTTLS
250-DSN
250-SIZE 52428800
250 PIPELINING
DEBUG SMTP: Found extension "TLS", arg ""
DEBUG SMTP: Found extension "HELP", arg ""
DEBUG SMTP: Found extension "STARTTLS", arg ""
DEBUG SMTP: Found extension "DSN", arg ""
DEBUG SMTP: Found extension "SIZE", arg "52428800"
DEBUG SMTP: Found extension "PIPELINING", arg ""
STARTTLS
220 Ready to start TLS
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
EHLO CHOL162
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for T
LSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for TLS
v1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 for TL
Sv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 for TLSv
1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_GCM_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
%% No cached client session
*** ClientHello, TLSv1
RandomCookie: GMT: 1496754662 bytes = { 245, 148, 158, 245, 226, 89, 218, 187,
38, 214, 67, 188, 66, 204, 91, 194, 210, 37, 14, 168, 255, 103, 89, 232, 246, 99
, 61, 8 }
Session ID: {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128
_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS
_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WI
TH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3D
ES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_
SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_
DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
Extension elliptic_curves, curve names: {secp256r1, secp384r1, secp521r1, sect28
3k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension server_name, server_name: [type=host_name (0), value=gbahelbv3.gb.tntp
ost.com]
***
JavaFX Application Thread, WRITE: TLSv1 Handshake, length = 140
JavaFX Application Thread, READ: SSLv3 Handshake, length = 58
*** ServerHello, SSLv3
RandomCookie: GMT: 1499415798 bytes = { 174, 160, 140, 96, 215, 83, 21, 198, 21
4, 57, 208, 183, 191, 65, 44, 179, 197, 159, 101, 44, 176, 53, 215, 81, 122, 49,
174, 189 }
Session ID: {193, 186, 187, 85, 52, 17, 137, 84, 154, 122, 240, 123, 100, 244,
27, 22}
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA
Compression Method: 0
***
JavaFX Application Thread, handling exception: javax.net.ssl.SSLHandshakeExcepti
on: Server chose SSLv3, but that protocol version is not enabled or not supporte
d by the client.
JavaFX Application Thread, SEND TLSv1.2 ALERT: fatal, description = handshake_f
ailure
JavaFX Application Thread, WRITE: TLSv1.2 Alert, length = 2
JavaFX Application Thread, called closeSocket()
[ERROR] 2017-06-07 11:27:34.911 [JavaFX Application Thread] ManifestEmailService
- Mail Message crap!!!javax.mail.MessagingException: Can't send command to SMTP
host;
nested exception is:
javax.net.ssl.SSLHandshakeException: Server chose SSLv3, but that protoc
ol version is not enabled or not supported by the client.
javax.net.ssl.SSLHandshakeException: Server chose SSLv3
This means that you connected to a server which is using an obsolete and insecure protocol version of SSL/TLS, namely SSL 3.0. This protocol is disabled in Java 8 by default for security reasons.
The best way is to fix the broken server so that it supports newer versions of SSL/TLS. Apart from that a server supporting only SSL 3.0 is probably not only insecure regarding SSL/TLS but also has several other security problems.
If upgrading the server is no option see How to enable SSL 3 in Java how to work around this broken server by allowing the insecure SSL 3.0 protocol.
what is wrong with this code, it is supposed to trust all hosts, but it doesn't..
It works fine with for example google.com but not with an API Gateway service running locally on my machine, why?
SSL DEBUG OUTPUT
trigger seeding of SecureRandom done seeding SecureRandom Ignoring
unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 ...
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256
Allow unsafe renegotiation: false Allow legacy hello messages: true Is
initial handshake: true Is secure renegotiation: false Thread-6,
setSoTimeout(0) called %% No cached client session
*** ClientHello, TLSv1 RandomCookie: GMT: 1434280256 bytes = { 216 ... 40 } Session ID: {} Cipher Suites:
[TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, ....
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5,
TLS_EMPTY_RENEGOTIATION_INFO_SCSV] Compression Methods: { 0 }
Extension elliptic_curves, curve names: {secp256r1 .. secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Thread-6, WRITE: TLSv1 Handshake, length = 163 Thread-6, READ: TLSv1
Alert, length = 2 Thread-6, RECV TLSv1 ALERT: fatal,
handshake_failure Thread-6, called closeSocket() Thread-6, handling
exception: javax.net.ssl.SSLHandshakeException: **
Received fatal alert: handshake_failure
**
import java.io.InputStreamReader;
import java.io.Reader;
import java.net.URL;
import java.net.URLConnection;
import javax.net.ssl.HostnameVerifier;
import javax.net.ssl.HttpsURLConnection;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSession;
import javax.net.ssl.TrustManager;
import javax.net.ssl.X509TrustManager;
import java.security.cert.X509Certificate;
public class ConnectHttps {
public static void main(String[] args) throws Exception {
/*
* fix for
* Exception in thread "main" javax.net.ssl.SSLHandshakeException:
* sun.security.validator.ValidatorException:
* PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException:
* unable to find valid certification path to requested target
*/
TrustManager[] trustAllCerts = [
[ getAcceptedIssuers: { -> null },
checkClientTrusted: { X509Certificate[] certs, String authType -> },
checkServerTrusted: { X509Certificate[] certs, String authType -> } ] as X509TrustManager
]
SSLContext sc = SSLContext.getInstance("SSL");
sc.init(null, trustAllCerts, new java.security.SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
// Create all-trusting host name verifier
HostnameVerifier allHostsValid = new HostnameVerifier() {
public boolean verify(String hostname, SSLSession session) {
return true;
}
};
// Install the all-trusting host verifier
HttpsURLConnection.setDefaultHostnameVerifier(allHostsValid);
/*
* end of the fix
*/
//URL url = new URL("https://google.com"); //WORKS
URL url = new URL("https://localhost:8090"); // DOES NOT WORK, WHY?
URLConnection con = url.openConnection();
Reader reader = new InputStreamReader(con.getInputStream());
while (true) {
int ch = reader.read();
if (ch==-1) {
break;
}
System.out.print((char)ch);
}
}
}
Running the code found here it shows that TLSv1.2 is not enabled on the client side:
Supported Protocols: 5
SSLv2Hello
SSLv3
TLSv1
TLSv1.1
TLSv1.2
Enabled Protocols: 2
SSLv3
TLSv1
.. it is supposed to trust all hosts, but it doesn't..
.. RECV TLSv1 ALERT: fatal, handshake_failure Thread-6
A handshake failure alert from the server is unrelated to the validation of the servers certificate on the client and can thus not stopped by disabling certificate validation. Lots of things can cause such a failure, like no common ciphers, unsupported protocol version, missing SNI extension (only supported starting with JDK7). Since the error is issued by the server you might find more details about the problem in the servers log messages.
EDIT: from the server logs the cause of the problem is visible:
error handling connection: SSL protocol error error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
This means that there is no common cipher between client and server.
A typical cause for this is a wrong setup of the certificates at the server. If you don't configure any certificates the server might require anonymous authentication with ADH ciphers, which are usually not enabled on the client side. I suggest that you check if you could connect with a browser.
Another common misconfiguration is disabling all SSLv3 ciphers at the server in the believe that this is necessary to disable the SSL3.0 protocol (it is not). This effectively disables all ciphers except some new ciphers introduced with TLS 1.2. Modern browsers will be still able to connect but older clients not. This misconfiguration can be seen in this case (from the comment):
From server log,, interface ciphers: FIPS:!SSLv3:!aNULL,,
!SSLv3 disables all ciphers available for version SSL3.0 and higher. This in effect leaves only the TLS1.2 ciphers because there are no new ciphers with TLS1.0 and TLS1.1. Since the client seems to be only support TLS1.0 there will be no shared ciphers:
...WRITE: TLSv1 Handshake
Use of !SSLv3 in the ciphers is usually caused by a lack of understanding of the difference between protocol version and ciphers. To disable SSLv3 you should only set the protocol accordingly but not the ciphers.