Kafka SSL connection failure on handshake - ssl

Kafka client cannot connect to server via SSL connection for some reason. It goes through SSL handshake, I can see it in the client trace log, but then occasionally fails with "disconnected" message. Looks like Kafka server closes the connection after receives Client Hello.
It fails only when I try it from the OpenShift environment. The same build, configuration settings and SSL certificates work when I'm trying to connect from my local developer machine. Tools like OffsetExplorer are also able to connect from my local PC.
I'm trying to understand what can be different in terms of SSL between OpenShift and my local PC.
Here is the log I grep by KafkaListenerEndpointContainer#5-0-C-1 thread:
Line 93734: 2022-05-24 11:10:26,409 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [TRACE] (org.apache.kafka.clients.NetworkClient) [org.apache.kafka.clients.NetworkClient::leastLoadedNode:722] mdc:()| [Consumer clientId=ADCAB-0, groupId=ADCAB_GROUP] Found least loaded node 10.53.15.97:9093 (id: -1 rack: null) with no active connection
Line 93735: 2022-05-24 11:10:26,409 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [DEBUG] (org.apache.kafka.clients.NetworkClient) [org.apache.kafka.clients.NetworkClient$DefaultMetadataUpdater::maybeUpdate:1176] mdc:()| [Consumer clientId=ADCAB-0, groupId=ADCAB_GROUP] Initialize connection to node 10.53.15.97:9093 (id: -1 rack: null) for sending metadata request
Line 93736: 2022-05-24 11:10:26,409 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [DEBUG] (org.apache.kafka.clients.NetworkClient) [org.apache.kafka.clients.NetworkClient::initiateConnect:1005] mdc:()| [Consumer clientId=ADCAB-0, groupId=ADCAB_GROUP] Initiating connection to node 10.53.15.97:9093 (id: -1 rack: null) using address /10.53.15.97
Line 93736: 2022-05-24 11:10:26,409 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [DEBUG] (org.apache.kafka.clients.NetworkClient) [org.apache.kafka.clients.NetworkClient::initiateConnect:1005] mdc:()| [Consumer clientId=ADCAB-0, groupId=ADCAB_GROUP] Initiating connection to node 10.53.15.97:9093 (id: -1 rack: null) using address /10.53.15.97
Line 94113: 2022-05-24 11:10:27,386 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [TRACE] (org.apache.kafka.common.network.SslTransportLayer) [org.apache.kafka.common.network.SslTransportLayer::doHandshake:339] mdc:()| [SslTransportLayer channelId=-1 key=channel=java.nio.channels.SocketChannel[connection-pending remote=/10.53.15.97:9093], selector=sun.nio.ch.EPollSelectorImpl#41c9572a, interestOps=8, readyOps=0] SSLHandshake NEED_WRAP channelId -1, appReadBuffer pos 0, netReadBuffer pos 0, netWriteBuffer pos 0
Line 94115: 2022-05-24 11:10:27,386 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [TRACE] (org.apache.kafka.common.network.SslTransportLayer) [org.apache.kafka.common.network.SslTransportLayer::handshakeWrap:472] mdc:()| [SslTransportLayer channelId=-1 key=channel=java.nio.channels.SocketChannel[connection-pending remote=/10.53.15.97:9093], selector=sun.nio.ch.EPollSelectorImpl#41c9572a, interestOps=8, readyOps=0] SSLHandshake handshakeWrap -1
Line 94117: 2022-05-24 11:10:27,386 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [TRACE] (org.apache.kafka.common.network.SslTransportLayer) [org.apache.kafka.common.network.SslTransportLayer::doHandshake:356] mdc:()| [SslTransportLayer channelId=-1 key=channel=java.nio.channels.SocketChannel[connection-pending remote=/10.53.15.97:9093], selector=sun.nio.ch.EPollSelectorImpl#41c9572a, interestOps=8, readyOps=0] SSLHandshake NEED_WRAP channelId -1, handshakeResult Status = OK HandshakeStatus = NEED_UNWRAP
Line 94122: 2022-05-24 11:10:27,387 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [TRACE] (org.apache.kafka.common.network.SslTransportLayer) [org.apache.kafka.common.network.SslTransportLayer::doHandshake:365] mdc:()| [SslTransportLayer channelId=-1 key=channel=java.nio.channels.SocketChannel[connection-pending remote=/10.53.15.97:9093], selector=sun.nio.ch.EPollSelectorImpl#41c9572a, interestOps=8, readyOps=0] SSLHandshake NEED_UNWRAP channelId -1, appReadBuffer pos 0, netReadBuffer pos 0, netWriteBuffer pos 307
Line 94124: 2022-05-24 11:10:27,387 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [TRACE] (org.apache.kafka.common.network.SslTransportLayer) [org.apache.kafka.common.network.SslTransportLayer::handshakeUnwrap:499] mdc:()| [SslTransportLayer channelId=-1 key=channel=java.nio.channels.SocketChannel[connection-pending remote=/10.53.15.97:9093], selector=sun.nio.ch.EPollSelectorImpl#41c9572a, interestOps=8, readyOps=0] SSLHandshake handshakeUnwrap -1
Line 94126: 2022-05-24 11:10:27,387 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [TRACE] (org.apache.kafka.common.network.SslTransportLayer) [org.apache.kafka.common.network.SslTransportLayer::handshakeUnwrap:519] mdc:()| [SslTransportLayer channelId=-1 key=channel=java.nio.channels.SocketChannel[connection-pending remote=/10.53.15.97:9093], selector=sun.nio.ch.EPollSelectorImpl#41c9572a, interestOps=8, readyOps=0] SSLHandshake handshakeUnwrap: handshakeStatus NEED_UNWRAP status BUFFER_UNDERFLOW
Line 94128: 2022-05-24 11:10:27,387 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [TRACE] (org.apache.kafka.common.network.SslTransportLayer) [org.apache.kafka.common.network.SslTransportLayer::doHandshake:387] mdc:()| [SslTransportLayer channelId=-1 key=channel=java.nio.channels.SocketChannel[connection-pending remote=/10.53.15.97:9093], selector=sun.nio.ch.EPollSelectorImpl#41c9572a, interestOps=8, readyOps=0] SSLHandshake NEED_UNWRAP channelId -1, handshakeResult Status = BUFFER_UNDERFLOW HandshakeStatus = NEED_UNWRAP
Line 94134: 2022-05-24 11:10:27,387 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [TRACE] (org.apache.kafka.clients.NetworkClient) [org.apache.kafka.clients.NetworkClient::leastLoadedNode:719] mdc:()| [Consumer clientId=ADCAB-0, groupId=ADCAB_GROUP] Found least loaded connecting node 10.53.15.97:9093 (id: -1 rack: null)
Line 94137: 2022-05-24 11:10:27,388 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [TRACE] (org.apache.kafka.common.network.SslTransportLayer) [org.apache.kafka.common.network.SslTransportLayer::doHandshake:365] mdc:()| [SslTransportLayer channelId=-1 key=channel=java.nio.channels.SocketChannel[connection-pending remote=/10.53.15.97:9093], selector=sun.nio.ch.EPollSelectorImpl#41c9572a, interestOps=8, readyOps=0] SSLHandshake NEED_UNWRAP channelId -1, appReadBuffer pos 0, netReadBuffer pos 0, netWriteBuffer pos 307
Line 94139: 2022-05-24 11:10:27,388 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [TRACE] (org.apache.kafka.common.network.SslTransportLayer) [org.apache.kafka.common.network.SslTransportLayer::handshakeUnwrap:499] mdc:()| [SslTransportLayer channelId=-1 key=channel=java.nio.channels.SocketChannel[connection-pending remote=/10.53.15.97:9093], selector=sun.nio.ch.EPollSelectorImpl#41c9572a, interestOps=8, readyOps=0] SSLHandshake handshakeUnwrap -1
Line 94141: 2022-05-24 11:10:27,388 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [TRACE] (org.apache.kafka.common.network.SslTransportLayer) [org.apache.kafka.common.network.SslTransportLayer::handshakeUnwrap:519] mdc:()| [SslTransportLayer channelId=-1 key=channel=java.nio.channels.SocketChannel[connection-pending remote=/10.53.15.97:9093], selector=sun.nio.ch.EPollSelectorImpl#41c9572a, interestOps=8, readyOps=0] SSLHandshake handshakeUnwrap: handshakeStatus NEED_UNWRAP status BUFFER_UNDERFLOW
Line 94143: 2022-05-24 11:10:27,388 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [TRACE] (org.apache.kafka.common.network.SslTransportLayer) [org.apache.kafka.common.network.SslTransportLayer::handshakeUnwrap:499] mdc:()| [SslTransportLayer channelId=-1 key=channel=java.nio.channels.SocketChannel[connection-pending remote=/10.53.15.97:9093], selector=sun.nio.ch.EPollSelectorImpl#41c9572a, interestOps=8, readyOps=0] SSLHandshake handshakeUnwrap -1
Line 94145: 2022-05-24 11:10:27,388 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [TRACE] (org.apache.kafka.common.network.SslTransportLayer) [org.apache.kafka.common.network.SslTransportLayer::handshakeUnwrap:519] mdc:()| [SslTransportLayer channelId=-1 key=channel=java.nio.channels.SocketChannel[connection-pending remote=/10.53.15.97:9093], selector=sun.nio.ch.EPollSelectorImpl#41c9572a, interestOps=8, readyOps=0] SSLHandshake handshakeUnwrap: handshakeStatus NEED_UNWRAP status BUFFER_UNDERFLOW
Line 94148: 2022-05-24 11:10:27,388 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [DEBUG] (org.apache.kafka.common.network.Selector) [org.apache.kafka.common.network.Selector::pollSelectionKeys:606] mdc:()| [Consumer clientId=ADCAB-0, groupId=ADCAB_GROUP] Connection with /10.53.15.97 disconnected
Line 94178: 2022-05-24 11:10:27,389 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [DEBUG] (org.apache.kafka.common.network.SslTransportLayer) [org.apache.kafka.common.network.SslTransportLayer::close:198] mdc:()| [SslTransportLayer channelId=-1 key=channel=java.nio.channels.SocketChannel[connection-pending remote=/10.53.15.97:9093], selector=sun.nio.ch.EPollSelectorImpl#41c9572a, interestOps=8, readyOps=0] Failed to send SSL Close message
Line 94208: 2022-05-24 11:10:27,390 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [WARN] (org.apache.kafka.clients.NetworkClient) [org.apache.kafka.clients.NetworkClient::processDisconnection:775] mdc:()| [Consumer clientId=ADCAB-0, groupId=ADCAB_GROUP] Connection to node -1 (/10.53.15.97:9093) terminated during authentication. This may happen due to any of the following reasons: (1) Authentication failed due to invalid credentials with brokers older than 1.0.0, (2) Firewall blocking Kafka TLS traffic (eg it may only allow HTTPS traffic), (3) Transient network issue.
Line 94210: 2022-05-24 11:10:27,390 [org.springframework.kafka.KafkaListenerEndpointContainer#5-0-C-1] [WARN] (org.apache.kafka.clients.NetworkClient) [org.apache.kafka.clients.NetworkClient$DefaultMetadataUpdater::handleServerDisconnect:1079] mdc:()| [Consumer clientId=ADCAB-0, groupId=ADCAB_GROUP] Bootstrap broker 10.53.15.97:9093 (id: -1 rack: null) disconnected
And here is the listener configuration:
2022-05-24 11:10:23,199 [main] [INFO] (org.apache.kafka.clients.consumer.ConsumerConfig) [org.apache.kafka.common.config.AbstractConfig::logAll:361] mdc:()| ConsumerConfig values:
allow.auto.create.topics = true
auto.commit.interval.ms = 5000
auto.offset.reset = latest
bootstrap.servers = [10.53.15.97:9093, 10.53.15.96:9093]
check.crcs = true
client.dns.lookup = use_all_dns_ips
client.id = ADCAB-0
client.rack =
connections.max.idle.ms = 540000
default.api.timeout.ms = 60000
enable.auto.commit = false
exclude.internal.topics = true
fetch.max.bytes = 52428800
fetch.max.wait.ms = 500
fetch.min.bytes = 1
group.id = ADCAB_GROUP
group.instance.id = null
heartbeat.interval.ms = 3000
interceptor.classes = []
internal.leave.group.on.close = true
internal.throw.on.fetch.stable.offset.unsupported = false
isolation.level = read_uncommitted
key.deserializer = class org.apache.kafka.common.serialization.StringDeserializer
max.partition.fetch.bytes = 1048576
max.poll.interval.ms = 300000
max.poll.records = 500
metadata.max.age.ms = 300000
metric.reporters = []
metrics.num.samples = 2
metrics.recording.level = INFO
metrics.sample.window.ms = 30000
partition.assignment.strategy = [class org.apache.kafka.clients.consumer.RangeAssignor]
receive.buffer.bytes = 65536
reconnect.backoff.max.ms = 1000
reconnect.backoff.ms = 50
request.timeout.ms = 30000
retry.backoff.ms = 100
sasl.client.callback.handler.class = null
sasl.jaas.config = null
sasl.kerberos.kinit.cmd = /usr/bin/kinit
sasl.kerberos.min.time.before.relogin = 60000
sasl.kerberos.service.name = null
sasl.kerberos.ticket.renew.jitter = 0.05
sasl.kerberos.ticket.renew.window.factor = 0.8
sasl.login.callback.handler.class = null
sasl.login.class = null
sasl.login.refresh.buffer.seconds = 300
sasl.login.refresh.min.period.seconds = 60
sasl.login.refresh.window.factor = 0.8
sasl.login.refresh.window.jitter = 0.05
sasl.mechanism = GSSAPI
security.protocol = SSL
security.providers = null
send.buffer.bytes = 131072
session.timeout.ms = 10000
socket.connection.setup.timeout.max.ms = 127000
socket.connection.setup.timeout.ms = 10000
ssl.cipher.suites = null
ssl.enabled.protocols = [TLSv1.2]
ssl.endpoint.identification.algorithm =
ssl.engine.factory.class = null
ssl.key.password = [hidden]
ssl.keymanager.algorithm = SunX509
ssl.keystore.certificate.chain = null
ssl.keystore.key = null
ssl.keystore.location = /opt/keystore/kafka/sbercms/kafka_keystore.jks
ssl.keystore.password = [hidden]
ssl.keystore.type = JKS
ssl.protocol = TLS
ssl.provider = null
ssl.secure.random.implementation = null
ssl.trustmanager.algorithm = PKIX
ssl.truststore.certificates = null
ssl.truststore.location = /opt/keystore/kafka/sbercms/kafka_truststore.jks
ssl.truststore.password = [hidden]
ssl.truststore.type = JKS
value.deserializer = class ru.sberbank.pprb.sbbol.adcab.utils.kafka.LoggingJsonDeserializer

Sorry, there was an environment problem with the SSL certificates. DevOps managed to resolve it.

Related

Kerberos SSO with weblogic

I have managed to configure the weblogic for the SSO with windows AD, however there are several questions on which I need clarity
1) When I access the application from my browser with the apache web server sitting in between, why is the weblogic requesting for a TGT with the SPN everytime(I can see that in weblogic console), even if it wants to get authenticated with the KDC this should have happened only once during start up and not with every request from same browser.
Theoretically Weblogic should never contact the KDC to validate the existing user's TGT.
2) If the same session key provided by the KDC is used between client and weblogic server for secure communication, they would never require to hit KDC in between unless the session key expires, in which case they also have an option to renew it, so a TGT is never required to be created for each request from browser to weblogic. Is it correct.
Weblogic console logs->
Found ticket for HTTP/APPDEV2011.domain.com#DOMAIN.COM to go to krbtgt/DOMAIN.COM#DOMAIN.COM expiring on Fri May 11 21:06:46 CDT 2018
Debug is true storeKey true useTicketCache true useKeyTab true doNotPrompt true ticketCache is null isInitiator true KeyTab is http_weblogic_test.keytab refreshKrb5Config is false principal is HTTP/APPDEV2011.domain.com#DOMAIN.COM tryFirstPass is false useFirstPass is false storePass is false clearPass is false
Acquire TGT from Cache
KinitOptions cache name is D:\Users\ayadav.DOMAIN.000\krb5cc_ayadav
Acquire default native Credentials
default etypes for default_tkt_enctypes: 17 23.
LSA contains TGT for ayadav#DOMAIN.COM not HTTP/APPDEV2011.domain.com#DOMAIN.COM
Principal is HTTP/APPDEV2011.domain.com#DOMAIN.COM
null credentials from Ticket Cache
Looking for keys for: HTTP/APPDEV2011.domain.com#DOMAIN.COM
Added key: 17version: 14
Added key: 18version: 14
Added key: 23version: 14
Found unsupported keytype (3) for HTTP/APPDEV2011.domain.com#DOMAIN.COM
Found unsupported keytype (1) for HTTP/APPDEV2011.domain.com#DOMAIN.COM
Looking for keys for: HTTP/APPDEV2011.domain.com#DOMAIN.COM
Added key: 17version: 14
Added key: 18version: 14
Added key: 23version: 14
Found unsupported keytype (3) for HTTP/APPDEV2011.domain.com#DOMAIN.COM
Found unsupported keytype (1) for HTTP/APPDEV2011.domain.com#DOMAIN.COM
default etypes for default_tkt_enctypes: 17 23.
KrbAsReq creating message
KrbKdcReq send: kdc=wcosp-dc01.domain.com UDP:88, timeout=30000, number of retries =3, #bytes=163
KDCCommunication: kdc=wcosp-dc01.domain.com UDP:88, timeout=30000,Attempt =1, #bytes=163
KrbKdcReq send: #bytes read=207
Pre-Authentication Data:
PA-DATA type = 19
PA-ETYPE-INFO2 etype = 17, salt = DOMAIN.COMHTTPAPPDEV2011.domain.com, s2kparams = null
PA-ETYPE-INFO2 etype = 23, salt = null, s2kparams = null
Pre-Authentication Data:
PA-DATA type = 2
PA-ENC-TIMESTAMP
Pre-Authentication Data:
PA-DATA type = 16
Pre-Authentication Data:
PA-DATA type = 15
KdcAccessibility: remove wcosp-dc01.domain.com
KDCRep: init() encoding tag is 126 req type is 11
KRBError:
sTime is Fri May 11 11:06:46 CDT 2018 1526054806000
suSec is 633784
error code is 25
error Message is Additional pre-authentication required
sname is krbtgt/DOMAIN.COM#DOMAIN.COM
eData provided.
msgType is 30
Pre-Authentication Data:
PA-DATA type = 19
PA-ETYPE-INFO2 etype = 17, salt = DOMAIN.COMHTTPAPPDEV2011.domain.com, s2kparams = null
PA-ETYPE-INFO2 etype = 23, salt = null, s2kparams = null
Pre-Authentication Data:
PA-DATA type = 2
PA-ENC-TIMESTAMP
Pre-Authentication Data:
PA-DATA type = 16
Pre-Authentication Data:
PA-DATA type = 15
KrbAsReqBuilder: PREAUTH FAILED/REQ, re-send AS-REQ
default etypes for default_tkt_enctypes: 17 23.
Looking for keys for: HTTP/APPDEV2011.domain.com#DOMAIN.COM
Added key: 17version: 14
Added key: 18version: 14
Added key: 23version: 14
Found unsupported keytype (3) for HTTP/APPDEV2011.domain.com#DOMAIN.COM
Found unsupported keytype (1) for HTTP/APPDEV2011.domain.com#DOMAIN.COM
Looking for keys for: HTTP/APPDEV2011.domain.com#DOMAIN.COM
Added key: 17version: 14
Added key: 18version: 14
Added key: 23version: 14
Found unsupported keytype (3) for HTTP/APPDEV2011.domain.com#DOMAIN.COM
Found unsupported keytype (1) for HTTP/APPDEV2011.domain.com#DOMAIN.COM
default etypes for default_tkt_enctypes: 17 23.
EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
KrbAsReq creating message
KrbKdcReq send: kdc=wcosp-dc01.domain.com UDP:88, timeout=30000, number of retries =3, #bytes=250
KDCCommunication: kdc=wcosp-dc01.domain.com UDP:88, timeout=30000,Attempt =1, #bytes=250
KrbKdcReq send: #bytes read=96
KrbKdcReq send: kdc=wcosp-dc01.domain.com TCP:88, timeout=30000, number of retries =3, #bytes=250
KDCCommunication: kdc=wcosp-dc01.domain.com TCP:88, timeout=30000,Attempt =1, #bytes=250
DEBUG: TCPClient reading 1602 bytes
KrbKdcReq send: #bytes read=1602
KdcAccessibility: remove wcosp-dc01.domain.com
Looking for keys for: HTTP/APPDEV2011.domain.com#DOMAIN.COM
Added key: 17version: 14
Added key: 18version: 14
Added key: 23version: 14
Found unsupported keytype (3) for HTTP/APPDEV2011.domain.com#DOMAIN.COM
Found unsupported keytype (1) for HTTP/APPDEV2011.domain.com#DOMAIN.COM
EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType
KrbAsRep cons in KrbAsReq.getReply HTTP/APPDEV2011.domain.com
principal is HTTP/APPDEV2011.domain.com#DOMAIN.COM
Will use keytab
Commit Succeeded
>
Thanks

java 8 soap client Received fatal alert: handshake_failure

I have a the following exception :
com.sun.xml.internal.ws.client.ClientTransportException: HTTP
transport error: javax.net.ssl.SSLHandshakeException: Received fatal
alert: handshake_failure
when I try to send a soap request to a customer's web service
I use jre1.8.0_66 and I get UnlimitedJCEPolicyJDK8 jars in "Java\jre1.8.0_66\lib\security" folder
and I get Cipher.getMaxAllowedKeyLength("AES") = 2147483647
and for some reason I can't communicate with the customer to get the protocol in use or the cipher suite in the server side.
and here my javax.net.debug related logs :
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
http-nio-9700-exec-1, setSoTimeout(0) called
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
%% No cached client session
*** ClientHello, TLSv1.2
RandomCookie: GMT: 1515623991 bytes = { 212, 12, 195, 65, 98, 206, 121, 198, 232, 203, 220, 162, 207, 122, 217, 87, 121, 168, 220, 246, 60, 50, 9, 61, 214, 181, 16, 190 }
Session ID: {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, 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_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_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, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA, MD5withRSA
***
[write] MD5 and SHA1 hashes: len = 237
http-nio-9700-exec-1, WRITE: TLSv1.2 Handshake, length = 237
[Raw write]: length = 242
[Raw read]: length = 5
0000: 15 03 01 00 02 .....
[Raw read]: length = 2
0000: 02 28 .(
http-nio-9700-exec-1, READ: TLSv1 Alert, length = 2
http-nio-9700-exec-1, RECV TLSv1.2 ALERT: fatal, handshake_failure
http-nio-9700-exec-1, called closeSocket()
http-nio-9700-exec-1, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
http-nio-9700-exec-1, called close()
http-nio-9700-exec-1, called closeInternal(true)
Try adding these parameters to your project configuration:
-Dhttps.cipherSuites=SSL_RSA_WITH_RC4_128_MD5
and comment the parameter for disabled algorithms in the java.security file in the jre folder:
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768
Can you check if this (Diagnosing TLS, SSL and HTTPS from blogs.oracle.com) helps you?

Celery RabbitMQ broker failover connect issue

I have 3 RabbitMQ nodes in cluster in HA mode. Each node is on separate Docker container.
I am using Celery version 4 and kombu version 4.
I have used this command to set HA policy:
rabbitmqctl set_policy ha-all "" '{"ha-mode":"all","ha-sync-mode":"automatic"}'
Celery config looks like this:
CELERY = dict(
broker_url=[
'amqp://guest#rabbitmq1:5672',
'amqp://guest#rabbitmq2:5672',
'amqp://guest#rabbitmq3:5672',
],
celery_queue_ha_policy='all',
...
)
Everything works fine until I stop master RabbitMQ application in order to test Celery failover feature using command:
rabbitmqctl stop_app
Immediately after RabbitMQ application is stopped I started seeing errors in log bellow. Frequency of log messages is very high and it doesn't slow down with number of attempts.
According to logs Celery tries to reconnect using next failover, but it gets interrupted by another try to reconnect to master node that was stopped. The same thing happens over and over like in infinite loop.
[2017-03-17 15:10:28,084: ERROR/MainProcess] consumer: Cannot connect to amqp://guest:**#rabbitmq1:5672//: [Errno 111] Connection refused.
Will retry using next failover.
[2017-03-17 15:10:28,300: DEBUG/MainProcess] Start from server, version: 0.9, properties: {'information': 'Licensed under the MPL. See http://www.rabbitmq.com/', 'product': 'RabbitMQ', 'copyright': 'Copyright (C) 2007-2016 Pivotal Software, Inc.', 'capabilities': {'exchange_exchange_bindings': True, 'connection.blocked': True, 'authentication_failure_close': True, 'direct_reply_to': True, 'basic.nack': True, 'per_consumer_qos': True, 'consumer_priorities': True, 'consumer_cancel_notify': True, 'publisher_confirms': True}, 'cluster_name': 'rabbit#rabbitmq1', 'platform': 'Erlang/OTP', 'version': '3.6.6'}, mechanisms: [u'PLAIN', u'AMQPLAIN'], locales: [u'en_US']
[2017-03-17 15:10:28,302: DEBUG/MainProcess] ^-- substep ok
[2017-03-17 15:10:28,303: DEBUG/MainProcess] | Consumer: Starting Mingle
[2017-03-17 15:10:28,303: INFO/MainProcess] mingle: searching for neighbors
[2017-03-17 15:10:28,303: DEBUG/MainProcess] using channel_id: 1
[2017-03-17 15:10:28,318: DEBUG/MainProcess] Channel open
[2017-03-17 15:10:28,470: WARNING/MainProcess] consumer: Connection to broker lost. Trying to re-establish the connection...
Traceback (most recent call last):
File "/usr/local/lib/python2.7/site-packages/celery/worker/consumer/consumer.py", line 318, in start
blueprint.start(self)
File "/usr/local/lib/python2.7/site-packages/celery/bootsteps.py", line 119, in start
step.start(parent)
File "/usr/local/lib/python2.7/site-packages/celery/worker/consumer/mingle.py", line 38, in start
self.sync(c)
File "/usr/local/lib/python2.7/site-packages/celery/worker/consumer/mingle.py", line 42, in sync
replies = self.send_hello(c)
File "/usr/local/lib/python2.7/site-packages/celery/worker/consumer/mingle.py", line 55, in send_hello
replies = inspect.hello(c.hostname, our_revoked._data) or {}
File "/usr/local/lib/python2.7/site-packages/celery/app/control.py", line 129, in hello
return self._request('hello', from_node=from_node, revoked=revoked)
File "/usr/local/lib/python2.7/site-packages/celery/app/control.py", line 81, in _request
timeout=self.timeout, reply=True,
File "/usr/local/lib/python2.7/site-packages/celery/app/control.py", line 436, in broadcast
limit, callback, channel=channel,
File "/usr/local/lib/python2.7/site-packages/kombu/pidbox.py", line 315, in _broadcast
serializer=serializer)
File "/usr/local/lib/python2.7/site-packages/kombu/pidbox.py", line 290, in _publish
serializer=serializer,
File "/usr/local/lib/python2.7/site-packages/kombu/messaging.py", line 181, in publish
exchange_name, declare,
File "/usr/local/lib/python2.7/site-packages/kombu/messaging.py", line 187, in _publish
channel = self.channel
File "/usr/local/lib/python2.7/site-packages/kombu/messaging.py", line 209, in _get_channel
channel = self._channel = channel()
File "/usr/local/lib/python2.7/site-packages/kombu/utils/functional.py", line 38, in __call__
value = self.__value__ = self.__contract__()
File "/usr/local/lib/python2.7/site-packages/kombu/messaging.py", line 224, in <lambda>
channel = ChannelPromise(lambda: connection.default_channel)
File "/usr/local/lib/python2.7/site-packages/kombu/connection.py", line 819, in default_channel
self.connection
File "/usr/local/lib/python2.7/site-packages/kombu/connection.py", line 802, in connection
self._connection = self._establish_connection()
File "/usr/local/lib/python2.7/site-packages/kombu/connection.py", line 757, in _establish_connection
conn = self.transport.establish_connection()
File "/usr/local/lib/python2.7/site-packages/kombu/transport/pyamqp.py", line 130, in establish_connection
conn.connect()
File "/usr/local/lib/python2.7/site-packages/amqp/connection.py", line 294, in connect
self.transport.connect()
File "/usr/local/lib/python2.7/site-packages/amqp/transport.py", line 120, in connect
self._connect(self.host, self.port, self.connect_timeout)
File "/usr/local/lib/python2.7/site-packages/amqp/transport.py", line 161, in _connect
self.sock.connect(sa)
File "/usr/local/lib/python2.7/socket.py", line 228, in meth
return getattr(self._sock,name)(*args)
error: [Errno 111] Connection refused
[2017-03-17 15:10:28,508: DEBUG/MainProcess] Closed channel #1
[2017-03-17 15:10:28,570: DEBUG/MainProcess] | Consumer: Restarting event loop...
[2017-03-17 15:10:28,572: DEBUG/MainProcess] | Consumer: Restarting Gossip...
[2017-03-17 15:10:28,575: DEBUG/MainProcess] | Consumer: Restarting Heart...
[2017-03-17 15:10:28,648: DEBUG/MainProcess] | Consumer: Restarting Control...
[2017-03-17 15:10:28,655: DEBUG/MainProcess] | Consumer: Restarting Tasks...
[2017-03-17 15:10:28,655: DEBUG/MainProcess] Canceling task consumer...
[2017-03-17 15:10:28,655: DEBUG/MainProcess] | Consumer: Restarting Mingle...
[2017-03-17 15:10:28,655: DEBUG/MainProcess] | Consumer: Restarting Events...
[2017-03-17 15:10:28,672: DEBUG/MainProcess] | Consumer: Restarting Connection...
[2017-03-17 15:10:28,673: DEBUG/MainProcess] | Consumer: Starting Connection
[2017-03-17 15:10:28,947: ERROR/MainProcess] consumer: Cannot connect to amqp://guest:**#rabbitmq1:5672//: [Errno 111] Connection refused.
Will retry using next failover.
[2017-03-17 15:10:29,345: DEBUG/MainProcess] Start from server, version: 0.9, properties: {'information': 'Licensed under the MPL. See http://www.rabbitmq.com/', 'product': 'RabbitMQ', 'copyright': 'Copyright (C) 2007-2016 Pivotal Software, Inc.', 'capabilities': {'exchange_exchange_bindings': True, 'connection.blocked': True, 'authentication_failure_close': True, 'direct_reply_to': True, 'basic.nack': True, 'per_consumer_qos': True, 'consumer_priorities': True, 'consumer_cancel_notify': True, 'publisher_confirms': True}, 'cluster_name': 'rabbit#rabbitmq1', 'platform': 'Erlang/OTP', 'version': '3.6.6'}, mechanisms: [u'PLAIN', u'AMQPLAIN'], locales: [u'en_US']
[2017-03-17 15:10:29,506: INFO/MainProcess] Connected to amqp://guest:**#rabbitmq2:5672//
[2017-03-17 15:10:29,535: DEBUG/MainProcess] ^-- substep ok
[2017-03-17 15:10:29,569: DEBUG/MainProcess] | Consumer: Starting Events
[2017-03-17 15:10:29,682: ERROR/MainProcess] consumer: Cannot connect to amqp://guest:**#rabbitmq1:5672//: [Errno 111] Connection refused.
Will retry using next failover.
[2017-03-17 15:10:29,740: DEBUG/MainProcess] Start from server, version: 0.9, properties: {'information': 'Licensed under the MPL. See http://www.rabbitmq.com/', 'product': 'RabbitMQ', 'copyright': 'Copyright (C) 2007-2016 Pivotal Software, Inc.', 'capabilities': {'exchange_exchange_bindings': True, 'connection.blocked': True, 'authentication_failure_close': True, 'direct_reply_to': True, 'basic.nack': True, 'per_consumer_qos': True, 'consumer_priorities': True, 'consumer_cancel_notify': True, 'publisher_confirms': True}, 'cluster_name': 'rabbit#rabbitmq1', 'platform': 'Erlang/OTP', 'version': '3.6.6'}, mechanisms: [u'PLAIN', u'AMQPLAIN'], locales: [u'en_US']
[2017-03-17 15:10:29,768: DEBUG/MainProcess] ^-- substep ok
[2017-03-17 15:10:29,770: DEBUG/MainProcess] | Consumer: Starting Mingle
[2017-03-17 15:10:29,770: INFO/MainProcess] mingle: searching for neighbors
[2017-03-17 15:10:29,771: DEBUG/MainProcess] using channel_id: 1
[2017-03-17 15:10:29,795: DEBUG/MainProcess] Channel open
[2017-03-17 15:10:29,874: WARNING/MainProcess] consumer: Connection to broker lost. Trying to re-establish the connection...
Traceback (most recent call last):
File "/usr/local/lib/python2.7/site-packages/celery/worker/consumer/consumer.py", line 318, in start
blueprint.start(self)
File "/usr/local/lib/python2.7/site-packages/celery/bootsteps.py", line 119, in start
step.start(parent)
File "/usr/local/lib/python2.7/site-packages/celery/worker/consumer/mingle.py", line 38, in start
self.sync(c)
File "/usr/local/lib/python2.7/site-packages/celery/worker/consumer/mingle.py", line 42, in sync
replies = self.send_hello(c)
File "/usr/local/lib/python2.7/site-packages/celery/worker/consumer/mingle.py", line 55, in send_hello
replies = inspect.hello(c.hostname, our_revoked._data) or {}
File "/usr/local/lib/python2.7/site-packages/celery/app/control.py", line 129, in hello
return self._request('hello', from_node=from_node, revoked=revoked)
File "/usr/local/lib/python2.7/site-packages/celery/app/control.py", line 81, in _request
timeout=self.timeout, reply=True,
File "/usr/local/lib/python2.7/site-packages/celery/app/control.py", line 436, in broadcast
limit, callback, channel=channel,
File "/usr/local/lib/python2.7/site-packages/kombu/pidbox.py", line 315, in _broadcast
serializer=serializer)
File "/usr/local/lib/python2.7/site-packages/kombu/pidbox.py", line 290, in _publish
serializer=serializer,
File "/usr/local/lib/python2.7/site-packages/kombu/messaging.py", line 181, in publish
exchange_name, declare,
File "/usr/local/lib/python2.7/site-packages/kombu/messaging.py", line 187, in _publish
channel = self.channel
File "/usr/local/lib/python2.7/site-packages/kombu/messaging.py", line 209, in _get_channel
channel = self._channel = channel()
File "/usr/local/lib/python2.7/site-packages/kombu/utils/functional.py", line 38, in __call__
value = self.__value__ = self.__contract__()
File "/usr/local/lib/python2.7/site-packages/kombu/messaging.py", line 224, in <lambda>
channel = ChannelPromise(lambda: connection.default_channel)
File "/usr/local/lib/python2.7/site-packages/kombu/connection.py", line 819, in default_channel
self.connection
File "/usr/local/lib/python2.7/site-packages/kombu/connection.py", line 802, in connection
self._connection = self._establish_connection()
File "/usr/local/lib/python2.7/site-packages/kombu/connection.py", line 757, in _establish_connection
conn = self.transport.establish_connection()
File "/usr/local/lib/python2.7/site-packages/kombu/transport/pyamqp.py", line 130, in establish_connection
conn.connect()
File "/usr/local/lib/python2.7/site-packages/amqp/connection.py", line 294, in connect
self.transport.connect()
File "/usr/local/lib/python2.7/site-packages/amqp/transport.py", line 120, in connect
self._connect(self.host, self.port, self.connect_timeout)
File "/usr/local/lib/python2.7/site-packages/amqp/transport.py", line 161, in _connect
self.sock.connect(sa)
File "/usr/local/lib/python2.7/socket.py", line 228, in meth
return getattr(self._sock,name)(*args)
error: [Errno 111] Connection refused
[2017-03-17 15:10:29,887: DEBUG/MainProcess] Closed channel #1
[2017-03-17 15:10:29,907: DEBUG/MainProcess] | Consumer: Restarting event loop...
[2017-03-17 15:10:29,908: DEBUG/MainProcess] | Consumer: Restarting Gossip...
[2017-03-17 15:10:29,908: DEBUG/MainProcess] | Consumer: Restarting Heart...
[2017-03-17 15:10:29,908: DEBUG/MainProcess] | Consumer: Restarting Control...
[2017-03-17 15:10:29,909: DEBUG/MainProcess] | Consumer: Restarting Tasks...
[2017-03-17 15:10:29,910: DEBUG/MainProcess] Canceling task consumer...
[2017-03-17 15:10:29,911: DEBUG/MainProcess] | Consumer: Restarting Mingle...
[2017-03-17 15:10:29,912: DEBUG/MainProcess] | Consumer: Restarting Events...
[2017-03-17 15:10:29,953: DEBUG/MainProcess] | Consumer: Restarting Connection...
[2017-03-17 15:10:29,954: DEBUG/MainProcess] | Consumer: Starting Connection
[2017-03-17 15:10:30,036: ERROR/MainProcess] consumer: Cannot connect to amqp://guest:**#rabbitmq1:5672//: [Errno 111] Connection refused.
Will retry using next failover.
Unfortunately, Celery documentation doesn't say much about failover topic.
Its definitely bug, I have created issue on GitHub: https://github.com/celery/celery/issues/3921
Thanks to George Psarakis I have managed to avoid bug using --without-mingle flag for Celery workers, eg:
celery worker -A app.tasks -l debug --without-mingle

SSL handshake fails after successfully exchanging both client and server certificates

My Java (1.7) client seems to be failing at the very end of the handshake process with the below exception.
I guess there is some issue with the client set up. How should I go about debugging this?
...
main, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished
verify_data: { 29, 85, 244, 219, 41, 146, 203, 174, 235, 86, 47, 92 }
***
main, WRITE: TLSv1 Handshake, length = 40
main, READ: TLSv1 Alert, length = 2
main, RECV TLSv1 ALERT: fatal, handshake_failure
%% Invalidated: [Session-1, SSL_RSA_WITH_3DES_EDE_CBC_SHA]
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
Exception in thread "main" AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
faultActor:
faultNode:
faultDetail:

JavaMail: "Remote host closed connection during handshake" while connecting with office365

I try to connect to office365 mail server with javaMail v1.5.3 (application is deployed on tomcat 6). Im running a thread on startup that is checking for new emails in a loop with one minute sleep. In most cases connection is successfully estabilished and everything works just fine but sometimes I get
"Remote host closed connection during handshake" error.
The error is caused by
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at sun.security.ssl.InputRecord.read(InputRecord.java:482)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934)
I have tried sulutions from:
How to make Java 6, which fails SSL connection with "SSL peer shut down incorrectly", succeed like Java 7?
and javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake :
adding -Dhttps.protocols=TLSv1,SSLv3 and -Dsun.security.ssl.allowUnsafeRenegotiation=true to my tomcat environment
but I didn't get any result. Still - randomly exception occurs.
I enabled debug mode on javax.net and on IMAP connection and get results:
when connection is not estabilishing correctly log looks like this :
DEBUG: setDebug: JavaMail version 1.5.3
DEBUG: getProvider() returning javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Oracle]
DEBUG IMAP: mail.imap.fetchsize: 16384
DEBUG IMAP: mail.imap.ignorebodystructuresize: false
DEBUG IMAP: mail.imap.statuscachetimeout: 1000
DEBUG IMAP: mail.imap.appendbuffersize: -1
DEBUG IMAP: mail.imap.minidletime: 10
DEBUG IMAP: closeFoldersOnStoreFailure
DEBUG IMAP: trying to connect to host "outlook.office365.com", port 993, isSSL true
Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
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
%% Client cached [Session-4, TLS_RSA_WITH_AES_128_CBC_SHA]
%% Try resuming [Session-4, TLS_RSA_WITH_AES_128_CBC_SHA] from port 51400
*** ClientHello, TLSv1
RandomCookie:
GMT: 1435130635
bytes = { , , , , , , , , , , , , , , , , , , , , , , , , , , }
Session ID: {66, 20, 0, 0, 123, 9, 142, 72, 150, 39, 215, 34, 63, 169, 129, 23, 25, 182, 88, 196, 86, 27, 216, 191, 117, 196, 37, 118, 229, 8, 9, 64}-
Cipher Suites: [TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]-
Compression Methods: { }
Extension server_name, server_name: [host_name: outlook.office365.com]
***-
[write] MD5 and SHA1 hashes: len = 125
46#CheckMailThread, WRITE: TLSv1 Handshake, length = 125
[Raw write]: length = 130
46#CheckMailThread, received EOFException: error
46#CheckMailThread, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
46#CheckMailThread, SEND TLSv1 ALERT: fatal, description = handshake_failure
46#CheckMailThread, WRITE: TLSv1 Alert, length = 2
[Raw write]: length = 7
46#CheckMailThread, called closeSocket()
and then exception occurs
javax.mail.MessagingException: Remote host closed connection during handshake;
nested exception is:
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:733)
at javax.mail.Service.connect(Service.java:364)
at javax.mail.Service.connect(Service.java:245)
(...)
Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:953)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343)
at com.sun.mail.util.SocketFetcher.configureSSLSocket(SocketFetcher.java:574)
at com.sun.mail.util.SocketFetcher.createSocket(SocketFetcher.java:369)
at com.sun.mail.util.SocketFetcher.getSocket(SocketFetcher.java:236)
at com.sun.mail.iap.Protocol.<init>(Protocol.java:117)
at com.sun.mail.imap.protocol.IMAPProtocol.<init>(IMAPProtocol.java:120)
at com.sun.mail.imap.IMAPStore.newIMAPProtocol(IMAPStore.java:753)
at com.sun.mail.imap.IMAPStore.protocolConnect(IMAPStore.java:696)
... 6 more
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at sun.security.ssl.InputRecord.read(InputRecord.java:482)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934)
... 16 more
In other hand in most cases thread is doing ok and the log looks like this:
DEBUG: setDebug: JavaMail version 1.5.3
DEBUG: getProvider() returning javax.mail.Provider[STORE,imap,com.sun.mail.imap.IMAPStore,Oracle]
DEBUG IMAP: mail.imap.fetchsize: 16384
DEBUG IMAP: mail.imap.ignorebodystructuresize: false
DEBUG IMAP: mail.imap.statuscachetimeout: 1000
DEBUG IMAP: mail.imap.appendbuffersize: -1
DEBUG IMAP: mail.imap.minidletime: 10
DEBUG IMAP: closeFoldersOnStoreFailure
DEBUG IMAP: trying to connect to host "outlook.office365.com", port 993, isSSL true
Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA
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
%% Client cached [Session-150, TLS_RSA_WITH_AES_128_CBC_SHA]
%% Try resuming [Session-150, TLS_RSA_WITH_AES_128_CBC_SHA] from port 59183
*** ClientHello, TLSv1
RandomCookie:
GMT: 1435076193
bytes = { , , , , , , , , , , , , , , , , , , , , , , , , , , , }
Session ID:
{241, 61, 0, 0, 224, 114, 43, 139, 255, 64, 232, 7, 209, 90, 5, 63, 63, 117, 33, 66, 215, 35, 48, 83, 131, 211, 38, 151, 73, 232, 6, 120}
Cipher Suites: [TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: {
}
Extension server_name, server_name: [host_name: outlook.office365.com]
***
[write] MD5 and SHA1 hashes: len = 125
46#CheckMailThread, WRITE: TLSv1 Handshake, length = 125
[Raw write]: length = 130
[Raw read]: length = 5
[Raw read]: length = 3532
46#CheckMailThread, READ: TLSv1 Handshake, length = 3532
*** ServerHello, TLSv1
RandomCookie:
GMT: 1435076194
Bytes = { , , , , , , , , , , , , , , , , , , , , , , , , , , , }
Session ID:
{112, 39, 0, 0, 59, 34, 200, 120, 31, 23, 110, 30, 10, 37, 236, 213, 46, 233, 201, 3, 253, 223, 81, 109, 188, 218, 33, 164, 33, 127, 27, 55}
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***
%% Initialized: [Session-151, TLS_RSA_WITH_AES_128_CBC_SHA]
** TLS_RSA_WITH_AES_128_CBC_SHA
[read] MD5 and SHA1 hashes: len = 81
*** Certificate chain (...)
And then goes the certificate etc
So I was wonderig what can cause such inconsistent behaviour.