Weird SSL/TLS negotiation problems with REST BC

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Weird SSL/TLS negotiation problems with REST BC

Stefan Müller-Wilken
Dear all,

I'm currently testing HTTPS encrypted message exchange with REST BC and run into weird problems. Whenever doing HTTP GET through browsers (I tried Chrome, Firefox, curl and wget), I get an SSL handshake error like the following output in server.log:

...
*** ServerHelloDone
Grizzly-9698(18), WRITE: TLSv1.2 Handshake, length = 14442
Grizzly-9698(18), READ: TLSv1.2 Handshake, length = 7
*** Certificate chain
***
Grizzly-9698(18), fatal error: 42: null cert chain
javax.net.ssl.SSLHandshakeException: null cert chain
%% Invalidated:  [Session-17, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
Grizzly-9698(18), SEND TLSv1.2 ALERT:  fatal, description = bad_certificate
Grizzly-9698(18), WRITE: TLSv1.2 Alert, length = 2
Grizzly-9698(18), fatal: engine already closed.  Rethrowing javax.net.ssl.SSLHandshakeException: null cert chain

When I try the same through a Jersey 1.9.1 handcrafted client, the same call works:

*** ServerHelloDone
Grizzly-9698(19), WRITE: TLSv1.2 Handshake, length = 14442
Grizzly-9698(19), READ: TLSv1.2 Handshake, length = 1070
*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: ...
...
Grizzly-9698(19), WRITE: TLSv1.2 Handshake, length = 80
%% Cached server session: [Session-18, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
2017-02-21T10:57:15.814+0000 FINEST [com.sun.jbi.restbc.jbiadapter.inbound.JerseyRootResource] (Grizzly-9698(19))ClassName=com.sun.jbi.restbc.jbiadapter.inbound.JerseyRootResource;MethodName=delegate; RESTBC-1101: Inbound Request:
  URI: ...
...
  Method: GET
  Status: 200  Headers: {Content-Type=[application/json], X-Content-Length=[69]}

Grizzly-9698(19), WRITE: TLSv1.2 Application Data, length = 251
Grizzly-9698(19), WRITE: TLSv1.2 Application Data, length = 5
Grizzly-9698(20), called closeInbound()
Grizzly-9698(20), fatal error: 80: Inbound closed before receiving peer's close_notify: possible truncation attack?
javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
%% Invalidated:  [Session-18, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
Grizzly-9698(20), SEND TLSv1.2 ALERT:  fatal, description = internal_error
Grizzly-9698(20), WRITE: TLSv1.2 Alert, length = 64

Again, this is not completely okay but at least the communication works. Searching the net for similar problems, the 'null cert chain' usually hints at mutual authentication (i.e. client cert) problems but unless I have unknowingly switched on client certificate auth in the RESTBC, this must be missleading.

Using HTTPBC with the same set of certificates / keys, encrypted communication via HTTPS works without problems, so it does not seem to be a problem with the key- and truststores.

Anyone an idea?

Cheers
 Stefan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Weird SSL/TLS negotiation problems with REST BC

param.singh
This post has NOT been accepted by the mailing list yet.
Your client (browser) received the bad certificate error. The problem lies with the certificates your client ( your browser) is sending, not the validation of the server certificates. 

I suggest you run openssl s_client -connect yourserver:443
it should send you a list of acceptable CAs and chain, Validate it, may be possible you get some clue. 


Param
-------- Original Message --------
Subject: Weird SSL/TLS negotiation problems with REST BC
From: Stefan_Müller-Wilken_[via_OpenESB_Community_Forum]
<[hidden email]>
Date: Tue, February 21, 2017 4:04 am
To: "param.singh" <[hidden email]>

Dear all,

I'm currently testing HTTPS encrypted message exchange with REST BC and run into weird problems. Whenever doing HTTP GET through browsers (I tried Chrome, Firefox, curl and wget), I get an SSL handshake error like the following output in server.log:

...
*** ServerHelloDone
Grizzly-9698(18), WRITE: TLSv1.2 Handshake, length = 14442
Grizzly-9698(18), READ: TLSv1.2 Handshake, length = 7
*** Certificate chain
***
Grizzly-9698(18), fatal error: 42: null cert chain
javax.net.ssl.SSLHandshakeException: null cert chain
%% Invalidated:  [Session-17, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
Grizzly-9698(18), SEND TLSv1.2 ALERT:  fatal, description = bad_certificate
Grizzly-9698(18), WRITE: TLSv1.2 Alert, length = 2
Grizzly-9698(18), fatal: engine already closed.  Rethrowing javax.net.ssl.SSLHandshakeException: null cert chain

When I try the same through a Jersey 1.9.1 handcrafted client, the same call works:

*** ServerHelloDone
Grizzly-9698(19), WRITE: TLSv1.2 Handshake, length = 14442
Grizzly-9698(19), READ: TLSv1.2 Handshake, length = 1070
*** Certificate chain
chain [0] = [
[
  Version: V3
  Subject: ...
...
Grizzly-9698(19), WRITE: TLSv1.2 Handshake, length = 80
%% Cached server session: [Session-18, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
2017-02-21T10:57:15.814+0000 FINEST [com.sun.jbi.restbc.jbiadapter.inbound.JerseyRootResource] (Grizzly-9698(19))ClassName=com.sun.jbi.restbc.jbiadapter.inbound.JerseyRootResource;MethodName=delegate; RESTBC-1101: Inbound Request:
  URI: ...
...
  Method: GET
  Status: 200  Headers: {Content-Type=[application/json], X-Content-Length=[69]}

Grizzly-9698(19), WRITE: TLSv1.2 Application Data, length = 251
Grizzly-9698(19), WRITE: TLSv1.2 Application Data, length = 5
Grizzly-9698(20), called closeInbound()
Grizzly-9698(20), fatal error: 80: Inbound closed before receiving peer's close_notify: possible truncation attack?
javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
%% Invalidated:  [Session-18, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
Grizzly-9698(20), SEND TLSv1.2 ALERT:  fatal, description = internal_error
Grizzly-9698(20), WRITE: TLSv1.2 Alert, length = 64

Again, this is not completely okay but at least the communication works. Searching the net for similar problems, the 'null cert chain' usually hints at mutual authentication (i.e. client cert) problems but unless I have unknowingly switched on client certificate auth in the RESTBC, this must be missleading.

Using HTTPBC with the same set of certificates / keys, encrypted communication via HTTPS works without problems, so it does not seem to be a problem with the key- and truststores.

Anyone an idea?

Cheers
 Stefan


If you reply to this email, your message will be added to the discussion below:
http://openesb-community-forum.794670.n2.nabble.com/Weird-SSL-TLS-negotiation-problems-with-REST-BC-tp7581506.html
To start a new topic under OpenESB Community Forum, email [hidden email]
To unsubscribe from OpenESB Community Forum, click here.
NAML
Param
Logicoy Inc.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Weird SSL/TLS negotiation problems with REST BC

Stefan Müller-Wilken
Thanks for your take on this,

but what surprises me is the fact that the server requests a client cert in the first place:

$ openssl s_client -state -connect hostname:9698 -state 2>&1 | grep 'server certificate request'
SSL_connect:SSLv3 read server certificate request A

$

Why does it do that and where Do I switch the feature on or off in REST BC??

Cheers
 Stefan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Weird SSL/TLS negotiation problems with REST BC

vishnu.piskala
Hi

This was a bug in REST BC. Please try with the latest one.

Thanks
Vishnu
www.logicoy.com


-----Original Message-----
From: Stefan Müller-Wilken [mailto:[hidden email]]
Sent: Tuesday, February 21, 2017 6:19 PM
To: [hidden email]
Subject: RE: Weird SSL/TLS negotiation problems with REST BC

Thanks for your take on this,

but what surprises me is the fact that the server requests a client cert in
the first place:



Why does it do that and where Do I switch the feature on or off in REST BC??

Cheers
 Stefan




--
View this message in context:
http://openesb-community-forum.794670.n2.nabble.com/Weird-SSL-TLS-negotiatio
n-problems-with-REST-BC-tp7581506p7581510.html
Sent from the OpenESB Community Forum mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Weird SSL/TLS negotiation problems with REST BC

Stefan Müller-Wilken
Ah, that kind of explains it. Only: what is the definition of 'latest' and what change set was the fix in? The REST BC I'm using is result of a fairly recent 'git pull'...

Cheers
 Stefan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Weird SSL/TLS negotiation problems with REST BC

vishnu.piskala
Hi Stephan

These are the exact fixes :
https://bitbucket.org/openesb/openesb-restbc/commits/476223480ac84f4a7e79900
2f8b0acf93b7596de?at=master
And
https://bitbucket.org/openesb/openesb-restbc/commits/dae0645b35f05c6daa7441a
95db8a0d70f61206b?at=master

Regards
Vishnu
www.logicoy.com


-----Original Message-----
From: Stefan Müller-Wilken [mailto:[hidden email]]
Sent: Tuesday, February 21, 2017 7:31 PM
To: [hidden email]
Subject: RE: Weird SSL/TLS negotiation problems with REST BC

Ah, that kind of explains it. Only: what is the definition of 'latest' and
what change set was the fix in? The REST BC I'm using is result of a fairly
recent 'git pull'...

Cheers
 Stefan



--
View this message in context:
http://openesb-community-forum.794670.n2.nabble.com/Weird-SSL-TLS-negotiatio
n-problems-with-REST-BC-tp7581506p7581512.html
Sent from the OpenESB Community Forum mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Weird SSL/TLS negotiation problems with REST BC

Stefan Müller-Wilken
Now that is strange! The version under https://bitbucket.org/openesb/openesb-components.git seems to be significantly different from the one coming from https://bitbucket.org/openesb/openesb-restbc which  you referenced.

For reference: this is what openesb-components/restbc's HTTPS listener looks like around line 522:

       // truststore password
        String truststorePassword = null;
        String truststorePasswordSysProp = System.getProperty(TRUSTSTORE_PASS_PROP);
        if (truststorePasswordSysProp == null || truststorePasswordSysProp.length() == 0) {
            truststorePassword = runtimeConfig.getTruststorePassword();
        } else {
            truststorePassword = truststorePasswordSysProp;
        }

        SSLConfig sslConfig = new SSLConfig();
        sslConfig.setKeyStoreFile(keystoreFile.getAbsolutePath());
        sslConfig.setKeyStorePass(keystorePassword);
        sslConfig.setTrustStoreFile(truststoreFile.getAbsolutePath());
        sslConfig.setTrustStorePass(truststorePassword);

        InboundHttpListener defaultHttpsListener = new InboundHttpListener(InboundHttpListener.DEFAULT_LISTENER_SSL,
                runtimeConfig.getDefaultHttpsListenerPort(), runtimeConfig.getDefaultHttpsListenerThreads(), sslConfig);

Apparently the main difference seems to be that 'your' REST BC is using org.glassfish.grizzly.ssl.SSLEngineConfigurator while 'mine' depends on com.sun.grizzly.SSLConfig. How comes that and which is the more recent / relevant one?

Cheers
 Stefan.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Weird SSL/TLS negotiation problems with REST BC

vishnu.piskala
Hi Stephan

https://bitbucket.org/openesb/openesb-restbc is the latest one we use for
GFv4 and OpenESB SE editions. The other one we use in 2.3.1 version. I don’t
think this bug is present in 2.3.1 version.

Regards
Vishnu
www.logicoy.com



-----Original Message-----
From: Stefan Müller-Wilken [mailto:[hidden email]]
Sent: Tuesday, February 21, 2017 10:46 PM
To: [hidden email]
Subject: RE: Weird SSL/TLS negotiation problems with REST BC

Now that is strange! The version under
https://bitbucket.org/openesb/openesb-components.git
<https://bitbucket.org/openesb/openesb-components.git>   seems to be
significantly different from the one coming from
https://bitbucket.org/openesb/openesb-restbc
<https://bitbucket.org/openesb/openesb-restbc>   which  you referenced.

For reference: this is what openesb-components/restbc's HTTPS listener looks
like around line 522:



Apparently the main difference seems to be that 'your' REST BC is using
org.glassfish.grizzly.ssl.SSLEngineConfigurator while 'mine' depends on
com.sun.grizzly.SSLConfig. How comes that and which is the more recent /
relevant one?

Cheers
 Stefan.




--
View this message in context:
http://openesb-community-forum.794670.n2.nabble.com/Weird-SSL-TLS-negotiatio
n-problems-with-REST-BC-tp7581506p7581514.html
Sent from the OpenESB Community Forum mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Weird SSL/TLS negotiation problems with REST BC

Stefan Müller-Wilken
Well, wouldn't it then be better to keep the sources consolidated to prevent errors like this one in the future. The documentation explaining binding component compilation  under https://openesb.atlassian.net/wiki/display/ESBCOMP/Building+OpenESB+Components explicitly references openesb-components and from my perspective it certainly makes sense to keep http-bc and rest-bc under the umbrella of that sub-project. Or what would you think?

Cheers
 Stefan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Weird SSL/TLS negotiation problems with REST BC

vishnu.piskala
Hi Stefan, going forward the plan is to have separate source code / project
for each jbi component rather than everything under openesb-components. This
is work in progress.

Regards
Vishnu
www.logicoy.com

-----Original Message-----
From: Stefan Müller-Wilken [mailto:[hidden email]]
Sent: Wednesday, February 22, 2017 2:17 PM
To: [hidden email]
Subject: RE: Weird SSL/TLS negotiation problems with REST BC

Well, wouldn't it then be better to keep the sources consolidated to prevent
errors like this one in the future. The documentation explaining binding
component compilation  under
https://openesb.atlassian.net/wiki/display/ESBCOMP/Building+OpenESB+Componen
ts
<https://openesb.atlassian.net/wiki/display/ESBCOMP/Building+OpenESB+Compone
nts>
explicitly references  openesb-components
<https://bitbucket.org/openesb/openesb-components>   and from my perspective
it certainly makes sense to keep http-bc and rest-bc under the umbrella of
that sub-project. Or what would you think?

Cheers
 Stefan



--
View this message in context:
http://openesb-community-forum.794670.n2.nabble.com/Weird-SSL-TLS-negotiatio
n-problems-with-REST-BC-tp7581506p7581517.html
Sent from the OpenESB Community Forum mailing list archive at Nabble.com.

Loading...