Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 333947

Summary: Net4j TLS/SSL support
Product: [Modeling] EMF Reporter: Karel Gardas <karel.gardas>
Component: cdo.net4jAssignee: Eike Stepper <stepper>
Status: CLOSED DUPLICATE QA Contact: Eike Stepper <stepper>
Severity: enhancement    
Priority: P3 CC: caspar_d, saulius.tvarijonas, stepper
Version: 3.0   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on: 332248    
Bug Blocks:    
Attachments:
Description Flags
Patch v3 - copied from bug 332248
none
Patch v4
none
Patch v5 none

Description Karel Gardas CLA 2011-01-11 03:21:36 EST
Build Identifier: I20100608-0911

Hello,
it would be great if Net4j support TLS as a transport layer. This will definitely increase a security of the transfered data.
Thanks! Karel

Reproducible: Always
Comment 1 Eike Stepper CLA 2011-01-11 03:42:35 EST
Created attachment 186464 [details]
Patch v3 - copied from bug 332248
Comment 2 Eike Stepper CLA 2011-01-11 04:33:32 EST
Karel, I have the feeling that the SSLContext is the entity we should inject into the connector. If you agree I can add this mechanism.
Comment 3 Karel Gardas CLA 2011-01-11 04:44:42 EST
Yes, I hope I understand your "inject" correctly here. SSLContext is configuration detail or well something heavily dependent on configuration which is not changed later -- at least for now. So please inject it into SSLConnector. :-) Thanks.
Comment 4 Eike Stepper CLA 2011-01-11 05:06:26 EST
I've tried to create the keystores:

cd C:\Program Files\Java\jdk1.5.0_22\bin

keytool -keystore C:\develop\ws\cdo-3.0\plugins\org.eclipse.net4j.tests\security\keystore -storepass keystore -genkey -v -keyalg RSA -alias cdotest -keypass cdotest -dname "CN=Eike Stepper, OU=CDO, O=Eclipse.org, L=Unknown, ST=Unknown, C=Unknown"

keytool -keystore C:\develop\ws\cdo-3.0\plugins\org.eclipse.net4j.tests\security\keystore -storepass keystore -export -alias cdotest -file C:\develop\ws\cdo-3.0\plugins\org.eclipse.net4j.tests\security\cdotest.cer

keytool -keystore C:\develop\ws\cdo-3.0\plugins\org.eclipse.net4j.tests\security\truststore -storepass truststore -import -v -trustcacerts -alias cdotest -keypass cdotest -file C:\develop\ws\cdo-3.0\plugins\org.eclipse.net4j.tests\security\cdotest.cer

And changed the init code to:

  private void initSSLEngine() throws KeyStoreException, IOException, NoSuchAlgorithmException, CertificateException,
      FileNotFoundException, UnrecoverableKeyException, KeyManagementException
  {
    // First initialize the key and trust material.
    KeyStore ks = KeyStore.getInstance("JKS");
    ks.load(new FileInputStream("C:\\develop\\ws\\cdo-3.0\\plugins\\org.eclipse.net4j.tests\\security\\keystore"),
        "keystore".toCharArray());

    KeyStore ksTrust = KeyStore.getInstance("JKS");
    ks.load(new FileInputStream("C:\\develop\\ws\\cdo-3.0\\plugins\\org.eclipse.net4j.tests\\security\\truststore"),
        "truststore".toCharArray());

    // KeyManager decides which key material to use.
    KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
    kmf.init(ks, "cdotest".toCharArray());

    // TrustManager decides whether to allow connections.
    TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509");
    tmf.init(ksTrust);

    SSLContext sslContext = SSLContext.getInstance("SSL");
    sslContext.init(kmf.getKeyManagers(), null, null);

    // We're ready for the engine.
    engine = sslContext.createSSLEngine("localhost", 2037);
  }

Now I can start the tests without exceptions but they die after 10 seconds of blocking somewhere ;-(
Comment 5 Eike Stepper CLA 2011-01-11 05:10:09 EST
Created attachment 186471 [details]
Patch v4
Comment 6 Karel Gardas CLA 2011-01-26 12:30:17 EST
(In reply to comment #4)
> Now I can start the tests without exceptions but they die after 10 seconds of
> blocking somewhere ;-(

Hi Eike,

have you also set your system preferences as needed? If not, please set:
-Djavax.net.ssl.trustStore=C:\\develop\\ws\\cdo-3.0\\plugins\\org.eclipse.net4j.tests\\security\\truststore
-Dsun.security.ssl.allowUnsafeRenegotiation=true

and let me know if this is working or not. As I said, this init code is broken so well. first task to fix it. :-)
Thanks! Karel
Comment 7 Eike Stepper CLA 2011-01-26 13:36:39 EST
(In reply to comment #6)
> have you also set your system preferences as needed? If not, please set:
> -Djavax.net.ssl.trustStore=C:\\develop\\ws\\cdo-3.0\\plugins\\org.eclipse.net4j.tests\\security\\truststore
> -Dsun.security.ssl.allowUnsafeRenegotiation=true

Yes, I'm pretty sure I adjusted the launch config arguments accordingly. Can the fact that no (visible) exceptions occured proof that I did set them?

It was more kind of a freeze...
Comment 8 Karel Gardas CLA 2011-01-26 13:44:35 EST
(In reply to comment #7)
> (In reply to comment #6)
> > have you also set your system preferences as needed? If not, please set:
> > -Djavax.net.ssl.trustStore=C:\\develop\\ws\\cdo-3.0\\plugins\\org.eclipse.net4j.tests\\security\\truststore
> > -Dsun.security.ssl.allowUnsafeRenegotiation=true
> 
> Yes, I'm pretty sure I adjusted the launch config arguments accordingly. Can
> the fact that no (visible) exceptions occured proof that I did set them?
> 
> It was more kind of a freeze...

Strange, then please go to TLSConnector (or TCPConnector in your case) and switch verbose_debug variable to true and if you like you can uncomment in performHandshake System.setProperty("javax.net.debug", "all"); to see even more details. BTW: what was your test exactly? If not closed/proprietary then please send me debug output to my email address for investigation. Thanks!
Comment 9 Eike Stepper CLA 2011-01-26 14:34:09 EST
(In reply to comment #8)
> Strange, then please go to TLSConnector (or TCPConnector in your case) and
> switch verbose_debug variable to true and if you like you can uncomment in
> performHandshake System.setProperty("javax.net.debug", "all"); to see even more
> details. 

Okay, maybe you can already include that in your new version? In the end there may not be any System.out/err usages anymore.

We distinguish between tracing and logging. The former can be controlled on a fine granule (see OSGi/PDE tracing options). The mandatory idiom is:

  private static final ContextTracer TRACER = 
          new ContextTracer(OM.DEBUG, TCPConnector.class);

  if (TRACER.isEnabled())
  {
    TRACER.trace("print this");
    TRACER.format("print that: {0}", that);
  }

Unhandled exceptions and infos that are of interest for an operator should be logged:

  OM.LOG.error(ex);
  OM.LOG.info("Authentication failed for user " + userID);

Use logging carefully as it may flood the Error Log view ;-)


> BTW: what was your test exactly? If not closed/proprietary then please
> send me debug output to my email address for investigation. Thanks!

I executed the normal CDO test suite for TCP transport. Go to org.eclipse.emf.cdo.tests.AllTests and comment out all scenarios except the last one.
Comment 10 Karel Gardas CLA 2011-02-08 14:14:39 EST
Created attachment 188542 [details]
Patch v5
Comment 11 Karel Gardas CLA 2011-02-08 15:06:44 EST
I've attached my current stage as a patch v5. It nearly passes all the CDO test which Eike enabled for it. Currently one issue is with handshake on server side where it for some tests fails due to missing one byte in the handshake sequence.
Also I've fixed initSSLEngine code so feel free to modify it to include your own cert keystore and truststore. This is working now and you don't need to use -D for it. For now also rehandshake support is completely switched off by commenting it out.
Comment 12 Eike Stepper CLA 2011-04-04 11:03:38 EDT
Hi Karel,

As I've stated before, I appreciate very much your engagement in the development of this cool feature and I'm kind of sad that there has not been much communication between the two different implementors of this same functionality (see bug 340108). I still hope that you can live with the the implementation in bug 340108 and we'd be happy if you could review/test it with your valuable knowledge in that area. The IP clearance process of the other implementation is progressing now and I hope that it's okay for you that we close this bugzilla as a duplicate. Thank you very much!!!

Cheers
/Eike

*** This bug has been marked as a duplicate of bug 340108 ***