The one time I was looking at SSL performance, I noticed that new SSL sessions were 
being created quite frequently, even though the requests were being made from a single 
app.  There was not a new session created for every single connection, but it varied 
from 3 to 8 SSL sessions used per 10 connections.  (I was getting the "new session" 
information from jsse debug).  This continued even when I whittled the test down to a 
simple app that did little other than get the default factory, create a (SSL) socket, 
connect, and close.  I did not pursue the issue further.

Scott Nichol

Do not send e-mail directly to this e-mail address,
because it is filtered to accept only mail from
specific mail lists.
----- Original Message ----- 
From: "Sinha, Madhukar [IT]" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 10, 2004 5:38 PM
Subject: RE: apache 2.3.1 and SSL



Thanks a lot Scott-

I was planning to change the Apache source "SSLUtils.java" for myself, but then I was 
provided with a good certificate and calls started flowing through :). I can post as 
update to Apache users and it can be reused later.

Another question -  i would think that if a servlet is making multiple SSL/SOAP calls 
using apache soap , it should not have to verify cert each time. Its doing that right 
now, and think that is also because SSLContext is getting lost after each call and 
every calls starts a new SSLContext. I am re-usign session cookie (same sesssion ) 
(between soap client servlet and server) and still then verification is happnening 
again and again. It has made calls quiet slow.

any suggestion?

thanks
Madhukar

-----Original Message-----
From: Scott Nichol [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 10, 2004 2:28 PM
To: [EMAIL PROTECTED]
Subject: Re: apache 2.3.1 and SSL


I wish I could be of help to you, but I have very little experience with SSL.

Apache SOAP uses an SSLSocket from SSLSocketFactory.getDefault().createSocket(host, 
port).  Your code below that does

       HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());

will thus have no effect on Apache SOAP.  The J2SE 1.4.2 docs (which is what I have on 
my machine) for SSLSocketFactory#getDefault say that you change the behavior by 
setting the ssl.SocketFactory.provider security property (in the Java security 
properties file) to the desired class.  This class does not appear to have a 
programmatic approach, e.g. a setDefault method.

Scott Nichol

Do not send e-mail directly to this e-mail address,
because it is filtered to accept only mail from
specific mail lists.
----- Original Message ----- 
From: "Sinha, Madhukar [IT]" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 10, 2004 1:35 PM
Subject: RE: apache 2.3.1 and SSL



Scott -

Please help - The trusting all does not work as apache SOAP overides the SSLContext i 
am setting up. Hence by the time SOAP call is made the new Trustmanager has been 
initialized and hence my "trust all doesnt work" . My plain HTTPS calls go fine (trust 
all works with HttpsUrlConnection calls) but apache SOAP calls fail as my TRUST ALL is 
not taking effect. 

Is there a setting in apache soap or any ENV setting by which i could tell APACHE soap 
to "trust all" . 

Please help
Regards
Madhukar


-----Original Message-----
From: Sinha, Madhukar [IT] 
Sent: Thursday, June 10, 2004 10:25 AM
To: [EMAIL PROTECTED]
Subject: RE: apache 2.3.1 and SSL



Daniel /group 

i am using jsse 1.0.2 and am using trustmanager to trust all certs but i am still 
getting "Could not find trusted cert in chain." , Looks like JSSE is still trying to 
trust my certificate (which on our server is dummy expired cert from verisign ..for 
now).

I saw somewhere on internet that - it could be a bug for JSSE when used with JRE 1.3.1 
. Please let me know if this is true and/or if there is anyway round it. 

I am using following code to trust all -

##############################


                       Security.addProvider(new 
com.sun.net.ssl.internal.ssl.Provider());
                       
System.setProperty("java.protocol.handler.pkgs","com.sun.net.ssl.internal.www.protocol");
//FOR JSSE 1.0.3       
System.setProperty("java.protocol.handler.pkgs","javax.net.ssl");
/*
        Provider [] provs = Security.getProviders();
        for (int i = 0 ; i < provs.length; i++) {
            System.out.println("");
            System.out.println(provs[i].getName());
            System.out.println(provs[i].getInfo());
            provs[i].list(System.out);
        }

*/
//
// Create a trust manager that does not validate certificate chains

TrustManager[] trustAllCerts = new TrustManager[]{
         new X509TrustManager() {
             public java.security.cert.X509Certificate[]
 getAcceptedIssuers() {
                 return null;
             }
             public void checkClientTrusted(
                 java.security.cert.X509Certificate[] certs, String authType) {
             }
             public void checkServerTrusted(
                 java.security.cert.X509Certificate[] certs, String authType) {
             }

      public boolean isServerTrusted(java.security.cert.X509Certificate[] certs){
          return true;
      }
      public boolean isClientTrusted(java.security.cert.X509Certificate[] certs){
          return true;
     }
         }
     };

// to Install the all-trusting trust manager

  try{
   SSLContext sc = SSLContext.getInstance("SSL");
   sc.init(null, trustAllCerts, new java.security.SecureRandom());
   HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
      } catch (Exception e) {
   e.printStackTrace();
  }
//followed by SOAP calls. 


                        URL url = null;
                        url = new URL(endpoint);
                        Call call = new Call();
                        SOAPHTTPConnection shc = new SOAPHTTPConnection ();
                        shc.setMaintainSession (true);
                        shc.setCookieHeader(smCookies);
                        call.setSOAPTransport (shc);
                        call.setSOAPMappingRegistry(smr);
                        call.setTargetObjectURI(targetObjURI);
                        call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);
                        call.setMethodName("construct_query");
                        call.setParams(params);

                        Response resp = call.invoke ( url, "" );

###########################################################

ALSO attached is the DEBUG TRACE when i have SSL DEBUG turned on for JRUN JVM 

<file attached>

ANy help will be really useful.

thanks
MS


-----Original Message-----
From: Daniel Zhang [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 03, 2004 2:04 PM
To: [EMAIL PROTECTED]
Subject: Re: apache 2.3.1 and SSL


A good reference page for Tomcat -  
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/ssl-howto.html
Sun's  JSSE page for J2SDK 1.2.x and 1.3.x - 
http://java.sun.com/products/jsse/index-103.html
A page for JRUN - 
http://teaching.cs.uml.edu/~heines/tools/JRun4/docs/html/Programmers_Guide/wssecurity4.html

You need SSL certificates say from Verisign, Thawte or whatever(for 
testing, you can make self-signed certificates). You have to put 
certificates into keystores (or programmatically get that).  Also you 
need to configure your servers. Finally change SOAP calls from HTTP to 
HTTPs.

Daniel


Sinha, Madhukar [IT] wrote:

> I have JSSE 1.0.2 , does apache SOAP have a minimum requirement of 
> JSSE 1.0.3? we are using J2SE 1.3.0 here
>  
> thanks
> madhukar
>  
>
>     -----Original Message-----
>     *From:* Sinha, Madhukar [IT]
>     *Sent:* Thursday, June 03, 2004 1:38 PM
>     *To:* [EMAIL PROTECTED]
>     *Subject:* apache 2.3.1 and SSL
>
>     Hello
>      
>     I have SOAP webservices running under JRUN . Our server is moving
>     to SSL.  I understand that no changes need to be done on server side.
>      
>     but if i have java WEBservice clients - can someone suggest me
>     examples or how/what change will be needed . I saw that we need
>     JSSE 1.2.1 or higher. Please help with some information.
>      
>     Please help
>      
>     Thanks
>     MS
>
>          
>



Reply via email to