JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
bug_report_small.png
CLOSED  Bug report JPPF-186  -  SSL services unable to distinguish between client and node certificates
Posted Sep 10, 2013 - updated Sep 13, 2013
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Bug report
  • Status
     
    Closed
  • Assigned to
     lolo4j
  • Progress
       
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
     lolo4j
  • Owned by
    Not owned by anyone
  • Category
    Security
  • Resolution
    RESOLVED
  • Priority
    Normal
  • Reproducability
    Always
  • Severity
    Critical
  • Targetted for
    icon_milestones.png JPPF 3.3.6
Issue description
Here is the relevant use case from this forum thread:

I would supply nodes for everyone to download for constructing my own grid computing. In this situation, the directory of "config/ssl" of nodes will expose for everyone.

I do experiment:

I generate two trust store for clients and nodes, respectively, then:
  1. Delete the files "keystores.ks" and "truststore.ks" of "config/ssl" in clients
  2. Download the nodes which I supplied.
  3. Copy the files "keystores.ks" and "truststore.ks" of nodes into the clients.
Basically, our implementation of the handling of SSL mutual authentication does not permit this.
Steps to reproduce this issue
  • generate two trust stores and key stores for clients and nodes, respectively, then:
  • Delete the files "keystores.ks" and "truststore.ks" of "config/ssl" in clients
  • Download the nodes which I supplied.
  • Copy the files "keystores.ks" and "truststore.ks" of nodes into any client.
  • ==> the client can authenticate



#4
Comment posted by
 lolo4j
Sep 10, 10:58
As suggested in the forum thread, a fix would be to enable, in the driver's configuration, to specify whether to use separate trust stores for nodes and clients that connect to the server. So, we will add a boolean property to specify this, plus additional properties to specify the nodes and clients trust stores sources, along with their corresponding password sources. When the boolean property is set to false (the default), then the server will perform as in earlier versions (same trust store for nodes and clients).
#5
Comment posted by
 lolo4j
Sep 11, 08:47
After some more research, I came to the conclusion that we'll have to modify the connection flow with regards to how the SSL handshake is done. Currently what we have is like this:
  1. Acceptor server accepts an incoming connection
  2. if accepted from an SSL port, initiate SSL handshake
  3. read the connection type identifyer
  4. dispatch the channel to the server determined by the identifier
Instead, what we need is more like this:
  1. Acceptor server accepts an incoming connection
  2. read the connection type identifyer
  3. dispatch the channel to the server determined by the identifier
  4. corresponding server initiates SSL handshake, using SSL parameters (including the trust store) for the type of channel: client or non-client
What this means is we need to identify the channel before the SSL handshake takes place. It also means that remote peers (nodes, clients and other servers) will have to send the connection identifier before the SSL handshake.

#6
Comment posted by
 lolo4j
Sep 13, 20:11
Fixed. Changes committed to SVN:

The issue was updated with the following change(s):
  • This issue has been closed
  • The status has been updated, from Confirmed to Closed.
  • This issue's progression has been updated to 100 percent completed.
  • The resolution has been updated, from Not determined to RESOLVED.
  • Information about the user working on this issue has been changed, from lolo4j to Not being worked on.