Re: Resend: SSL portability and Coyote

[Eric Rescorla]

"Bill Barker" <[EMAIL PROTECTED]> writes:
> From: "Eric Rescorla" <[EMAIL PROTECTED]>
> > "Bill Barker" <[EMAIL PROTECTED]> writes:
> > > Also, somebody in o.a.c.tomcat4 needs to fire the
> ACTION_REQ_SSL_ATTRIBUTE
> > > action.  That's the Coyote replacement for CertificateValve.
> > Ah. Can you give me the 10,000 overview on how ATTRIBUTES work (or
> > point me to the right location)?
> 
> I assume you mean actions.  They are defined in o.a.c.ActionCode, and
> processed by somebody implementing o.a.c.ActionHook (both under the "coyote"
> directory).  For the HTTP/1.1 connector, this is
> o.a.c.http11.Http11Processor (under the "http11" directory).  The usual way
> to fire them is to call o.a.c.Response.action (which is conventionally named
> "coyoteResponse").  For the SSL action, the second parameter is the
> o.a.c.Request.
Hmm I arranged to call this hook in
o.a.c.tomcat4.CoyoteAdapter.postParseRequest, but none of the values
seem to be getting propagated to the servlets. I've verified that
setAttribute call is made, the variables just don't show up.

I'm not really excited about debugging this since it seems to require
first figuring out how Coyote and Cataline move attributes around,
which I assume someone already knows how to do. If that someone has a
working example of setting any such attribute using an action that
would be a greatly appreciated. At that point, I should be able to
adapt it to set the SSL attributes. Even a fixed string would be fine.

Anyone?

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Resend: SSL portability and Coyote

[Larry Isaacs]

The current implementation is available in the jakarta-tomcat
tree under proposals/PasswordPrompter.

Cheers,
Larry

> -Original Message-
> From: Eric Rescorla [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, April 29, 2002 10:21 AM
> To: Tomcat Developers List
> Subject: Re: Resend: SSL portability and Coyote
> 
> 
> "GOMEZ Henri" <[EMAIL PROTECTED]> writes:
> > I even like to have server cert and key in differents
> > files (à la mod_ssl), and even use the code from Bojan 
> > 'PasswordPrompter' when the key is protected by password
> I like prompting for the password too. Is the code
> for this already in Tomcat somewhere?
> 
> -Ekr
> 
> -- 
> [Eric Rescorla   [EMAIL PROTECTED]]
> http://www.rtfm.com/
> 
> --
> To unsubscribe, e-mail:   
> <mailto:tomcat-dev-> [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: <mailto:[EMAIL PROTECTED]>
> 

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Resend: SSL portability and Coyote

[Eric Rescorla]

"GOMEZ Henri" <[EMAIL PROTECTED]> writes:
> I even like to have server cert and key in differents
> files (à la mod_ssl), and even use the code from Bojan 
> 'PasswordPrompter' when the key is protected by password
I like prompting for the password too. Is the code
for this already in Tomcat somewhere?

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Resend: SSL portability and Coyote

[GOMEZ Henri]

>(2) JSSE uses one keyfile (the keystore). PureTLS uses three, the
>keyfile, the CA file, and the random file. I need to add new
>directives to ServerSocketFactory to propagate those.

I couldn't tell you how many questions I've got after releasing
my SSL documentation for tomcat 3.2/3.3.

The recurrent question was about how to create CA/CERTS.

Since mod_ssl for Apache HTTPD server use the same files
organisation/format (PEM) than  PureTLS, and now there is
tools (http://www.openca.org/) to create a complete PKI,
having tomcat using such standard will help people use
tomcat in SSL.


A big +1 so for the PureTLS Cert/Key pem.

I even like to have server cert and key in differents
files (à la mod_ssl), and even use the code from Bojan 
'PasswordPrompter' when the key is protected by password



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Resend: SSL portability and Coyote

[Nick Betteridge]

Erik

This is what I'm currently using for Catalina as  a
SSLServerSocketFactory - some of it may look familiar!

rgds



import java.io.InputStream;
import java.io.IOException;
import java.net.InetAddress;
import java.net.ServerSocket;
import java.net.Socket;

import COM.claymoresystems.ptls.SSLContext;
import COM.claymoresystems.ptls.SSLContext;
import COM.claymoresystems.ptls.SSLSocket;
import COM.claymoresystems.ptls.SSLServerSocket;
import COM.claymoresystems.sslg.SSLPolicyInt;

/**
 * SSL server socket factory--wraps PureTLS
 *
 * @author Eric Rescorla
 *
 * some sections of this file cribbed from SSLSocketFactory
 * (the JSSE socket factory)
 *
 */

 
public class PureTLSSocketFactory 
implements org.apache.catalina.net.ServerSocketFactory
{
static String defaultProtocol = "TLS";
static boolean defaultClientAuth = false;
static String pureTLSCertificateFactoryName =
"com.syntactics.server.net.PureTLSCertificateFactory";
private PureTLSCertificateFactoryInterface pureTLSCertificateFactory
= null;

private SSLContext context=null;

public PureTLSSocketFactory() {
}

/**
 * Should we require client authentication?
 */
private boolean clientAuth = false;

public boolean getClientAuth() {
return (this.clientAuth);
}

public void setClientAuth(boolean clientAuth) {
this.clientAuth = clientAuth;
}

public String getPureTLSCertificateFactory() {
return pureTLSCertificateFactoryName;
}

public void setPureTLSCertificateFactory(String
pureTLSCertificateFactory) {
this.pureTLSCertificateFactoryName = pureTLSCertificateFactory;
}

public ServerSocket createSocket(int port)
throws IOException
{
init();
return new SSLServerSocket(context,port);
}

public ServerSocket createSocket(int port, int backlog)
throws IOException
{
init();
ServerSocket tmp;

try {
tmp=new SSLServerSocket(context,port,backlog);
}
catch (IOException e){
throw e;
}
return tmp;
}

public ServerSocket createSocket(int port, int backlog,
 InetAddress ifAddress)
throws IOException
{
init();
return new SSLServerSocket(context,port,backlog,ifAddress);
}

private void init()
throws IOException//, ClassNotFoundException, IllegalAccessException,
InstantiationException
{
try {
pureTLSCertificateFactory =
(PureTLSCertificateFactoryInterface)Class.forName(pureTLSCertificateFactoryName).newInstance();
} catch (ClassNotFoundException cnfe) {
throw new
IOException(cnfe.getMessage());//ClassNotFoundException(cnfe.getMessage());
} catch (IllegalAccessException iae) {
throw new
IOException(iae.getMessage());//IllegalAccessException(iae.getMessage());
} catch (InstantiationException ie) {
throw new
IOException(ie.getMessage());//InstantiationException(ie.getMessage());
}

if(context!=null)
return;

try {
String keyStoreFile=null;
if(keyStoreFile==null)
keyStoreFile=pureTLSCertificateFactory.getKeyStoreFile();
InputStream keyStoreStream =
pureTLSCertificateFactory.getKeyStoreStream();

String keyPass=null;
if(keyPass==null)
keyPass=pureTLSCertificateFactory.getKeyPassword();

String rootFile=null;
if(rootFile==null)
rootFile=pureTLSCertificateFactory.getRootFile();
InputStream rootStream =
pureTLSCertificateFactory.getRootStream();

String randomFile=null;
if(randomFile==null)
randomFile=pureTLSCertificateFactory.getRandomFile();

String protocol=defaultProtocol;

SSLContext tmpContext=new SSLContext();
if(clientAuth){
if (rootStream == null)
tmpContext.loadRootCertificates(rootFile);
else
tmpContext.loadRootCertificates(rootStream);
}
if (keyStoreStream == null)
tmpContext.loadEAYKeyFile(keyStoreFile,keyPass);
else
tmpContext.loadEAYKeyFile(keyStoreStream,keyPass);
tmpContext.useRandomnessFile(randomFile,keyPass);

if (rootStream!=null) rootStream.close();
if (keyStoreStream!=null) keyStoreStream.close();

SSLPolicyInt policy=new SSLPolicyInt();
policy.requireClientAuth(clientAuth);
policy.handshakeOnConnect(false);
policy.waitOnClose(false);
tmpContext.setPolicy(policy);
context=tmpContext;
} catch (Exception e){
throw new IOException(e.getMessage());
}
}

public void handshake(Socket sock)
  

Re: Resend: SSL portability and Coyote

[Nick Betteridge]

Eric Rescorla wrote:
> 
> Nick Betteridge <[EMAIL PROTECTED]> writes:
> > Eric Rescorla wrote:
> > >
> > > This didn't make it out the first time so I'm resending...
> > >
> > > I'm looking at what needs to be done to make the 3.3 SSL portablity
> > > stuff work properly with Coyote. For the most part, this work has been
> > > done--if you set the SSLImplementation appropriately and the correct
> > > factory gets invoked. However, there appear to be some issues with
> > > CoyoteServerSocketFactory and it's handling of configuration
> > > directives:
> > >
> > > (1) CoyoteServerSocketFactory appears to be willing to handle a
> > > "socketFactoryName". AFAICT, this is supplanted by SSLImplementation
> > > and none of the other code does anything with it. Any reason not to
> > > remove support for this directive entirely?
> > >
> > > (2) JSSE uses one keyfile (the keystore). PureTLS uses three, the
> > > keyfile, the CA file, and the random file. I need to add new
> > > directives to ServerSocketFactory to propagate those.
> > >
> >
> > Erik - any chance of implementing this with a generic certificate/key
> > factory so that the SocketFactory doesn't just rely on the default
> > keystore?
> I'm not sure exactly what you're looking for here. Can you provide
> an example of how you'd like things to look?
> 

I'm currently using a simple factory to get around having to rely on the
keystore file - all of my certificates are held in a jdo repository -
below is the interface I'm using - if you need more, please mail and
I'll send it on

Rgds Nick

public interface PureTLSCertificateFactoryInterface {


public String getKeyAlias();
public void setKeyAlias(String alias);

public String getKeyPassword();
public void setKeyPassword(String password);

// Keys from files

public String getKeyStoreFile();
public void setKeyStoreFile(String keyStoreFile);

public String getRootFile();
public void setRootFile(String rootFile);

public String getRandomFile();
public void setRandomFile(String randomFile);

// Keys from streams

public InputStream getKeyStoreStream();
public void setKeyStoreStream(InputStream keyStoreFile);

public InputStream getRootStream();
public void setRootStream(InputStream rootFile);

}

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Resend: SSL portability and Coyote

[Eric Rescorla]

"Bill Barker" <[EMAIL PROTECTED]> writes:
> > I can arrange for this to get called, but I'm not even sure where
> > to look to arrange it.
> >
> 
> I'm not sure either, which is why I'm talking about it instead of doing it
> :).  My guess would be o.a.c.tomcat4.CoyoteAdapter.postParseRequest.
> However, the current Catalina code is doing it much much later.  I'm pretty
> sure that you can't get the 3.3.x behavior of "only when asked for" without
> a lot of changes in Catalina (this is more a reflection of spec changes
> between 2.2 & 2.3 than design).
I tend to agree. I'll put it in postParseRequest unless someone
objects.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Resend: SSL portability and Coyote

[Eric Rescorla]

"Bill Barker" <[EMAIL PROTECTED]> writes:
> From: "Eric Rescorla" <[EMAIL PROTECTED]>
> I assume you mean actions.  They are defined in o.a.c.ActionCode, and
> processed by somebody implementing o.a.c.ActionHook (both under the "coyote"
> directory).  For the HTTP/1.1 connector, this is
> o.a.c.http11.Http11Processor (under the "http11" directory).  The usual way
> to fire them is to call o.a.c.Response.action (which is conventionally named
> "coyoteResponse").  For the SSL action, the second parameter is the
> o.a.c.Request.
> 
> This is mostly working, except that I couldn't find how to get the keySize
> for PureTLS (so PureTLSSupport is currently returning null).
It's still not clear to me what "keysize" means. Is it supposed
to be the symmetric key size? If so, you just use the same kind of
table as in CertificateValve. Email to Sun to get this question answered
haven't been returned. It could also be the asymmetric key size.

> > I can arrange for this to get called, but I'm not even sure where
> > to look to arrange it.
> >
> 
> I'm not sure either, which is why I'm talking about it instead of doing it
> :).  My guess would be o.a.c.tomcat4.CoyoteAdapter.postParseRequest.
> However, the current Catalina code is doing it much much later.  I'm pretty
> sure that you can't get the 3.3.x behavior of "only when asked for" without
> a lot of changes in Catalina (this is more a reflection of spec changes
> between 2.2 & 2.3 than design).
Yeah. Who here understands this part of Catalina well enough to have
an opinion?

-Ekr
-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Resend: SSL portability and Coyote

[Eric Rescorla]

Nick Betteridge <[EMAIL PROTECTED]> writes:
> Eric Rescorla wrote:
> > 
> > This didn't make it out the first time so I'm resending...
> > 
> > I'm looking at what needs to be done to make the 3.3 SSL portablity
> > stuff work properly with Coyote. For the most part, this work has been
> > done--if you set the SSLImplementation appropriately and the correct
> > factory gets invoked. However, there appear to be some issues with
> > CoyoteServerSocketFactory and it's handling of configuration
> > directives:
> > 
> > (1) CoyoteServerSocketFactory appears to be willing to handle a
> > "socketFactoryName". AFAICT, this is supplanted by SSLImplementation
> > and none of the other code does anything with it. Any reason not to
> > remove support for this directive entirely?
> > 
> > (2) JSSE uses one keyfile (the keystore). PureTLS uses three, the
> > keyfile, the CA file, and the random file. I need to add new
> > directives to ServerSocketFactory to propagate those.
> > 
> 
> Erik - any chance of implementing this with a generic certificate/key
> factory so that the SocketFactory doesn't just rely on the default
> keystore?
I'm not sure exactly what you're looking for here. Can you provide
an example of how you'd like things to look?

-Ekr


-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Resend: SSL portability and Coyote

[Nick Betteridge]

Eric Rescorla wrote:
> 
> This didn't make it out the first time so I'm resending...
> 
> I'm looking at what needs to be done to make the 3.3 SSL portablity
> stuff work properly with Coyote. For the most part, this work has been
> done--if you set the SSLImplementation appropriately and the correct
> factory gets invoked. However, there appear to be some issues with
> CoyoteServerSocketFactory and it's handling of configuration
> directives:
> 
> (1) CoyoteServerSocketFactory appears to be willing to handle a
> "socketFactoryName". AFAICT, this is supplanted by SSLImplementation
> and none of the other code does anything with it. Any reason not to
> remove support for this directive entirely?
> 
> (2) JSSE uses one keyfile (the keystore). PureTLS uses three, the
> keyfile, the CA file, and the random file. I need to add new
> directives to ServerSocketFactory to propagate those.
> 

Erik - any chance of implementing this with a generic certificate/key
factory so that the SocketFactory doesn't just rely on the default
keystore?

> Does anyone object to these changes?
> 
> -Ekr
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Resend: SSL portability and Coyote

[Bill Barker]

- Original Message -
From: "Eric Rescorla" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, April 26, 2002 5:38 PM
Subject: Re: Resend: SSL portability and Coyote


> "Bill Barker" <[EMAIL PROTECTED]> writes:
> > Also, somebody in o.a.c.tomcat4 needs to fire the
ACTION_REQ_SSL_ATTRIBUTE
> > action.  That's the Coyote replacement for CertificateValve.
> Ah. Can you give me the 10,000 overview on how ATTRIBUTES work (or
> point me to the right location)?

I assume you mean actions.  They are defined in o.a.c.ActionCode, and
processed by somebody implementing o.a.c.ActionHook (both under the "coyote"
directory).  For the HTTP/1.1 connector, this is
o.a.c.http11.Http11Processor (under the "http11" directory).  The usual way
to fire them is to call o.a.c.Response.action (which is conventionally named
"coyoteResponse").  For the SSL action, the second parameter is the
o.a.c.Request.

This is mostly working, except that I couldn't find how to get the keySize
for PureTLS (so PureTLSSupport is currently returning null).

>
> I can arrange for this to get called, but I'm not even sure where
> to look to arrange it.
>

I'm not sure either, which is why I'm talking about it instead of doing it
:).  My guess would be o.a.c.tomcat4.CoyoteAdapter.postParseRequest.
However, the current Catalina code is doing it much much later.  I'm pretty
sure that you can't get the 3.3.x behavior of "only when asked for" without
a lot of changes in Catalina (this is more a reflection of spec changes
between 2.2 & 2.3 than design).

> -Ekr
>
> --
> [Eric Rescorla   [EMAIL PROTECTED]]
> http://www.rtfm.com/
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Resend: SSL portability and Coyote

[Eric Rescorla]

"Bill Barker" <[EMAIL PROTECTED]> writes:
> Also, somebody in o.a.c.tomcat4 needs to fire the ACTION_REQ_SSL_ATTRIBUTE
> action.  That's the Coyote replacement for CertificateValve.
Ah. Can you give me the 10,000 overview on how ATTRIBUTES work (or
point me to the right location)?

I can arrange for this to get called, but I'm not even sure where
to look to arrange it.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]]
http://www.rtfm.com/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Resend: SSL portability and Coyote

[Bill Barker]

Also, somebody in o.a.c.tomcat4 needs to fire the ACTION_REQ_SSL_ATTRIBUTE
action.  That's the Coyote replacement for CertificateValve.
- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, April 26, 2002 2:50 PM
Subject: Re: Resend: SSL portability and Coyote


> > This didn't make it out the first time so I'm resending...
> >
> > I'm looking at what needs to be done to make the 3.3 SSL portablity
> > stuff work properly with Coyote. For the most part, this work has been
> > done--if you set the SSLImplementation appropriately and the correct
> > factory gets invoked. However, there appear to be some issues with
> > CoyoteServerSocketFactory and it's handling of configuration
> > directives:
> >
> > (1) CoyoteServerSocketFactory appears to be willing to handle a
> > "socketFactoryName". AFAICT, this is supplanted by SSLImplementation
> > and none of the other code does anything with it. Any reason not to
> > remove support for this directive entirely?
>
> I had no idea what was useful.
>
> > (2) JSSE uses one keyfile (the keystore). PureTLS uses three, the
> > keyfile, the CA file, and the random file. I need to add new
> > directives to ServerSocketFactory to propagate those.
>
> +1.
>
> Remy
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Resend: SSL portability and Coyote

[Remy Maucherat]

> This didn't make it out the first time so I'm resending...
> 
> I'm looking at what needs to be done to make the 3.3 SSL portablity
> stuff work properly with Coyote. For the most part, this work has been
> done--if you set the SSLImplementation appropriately and the correct
> factory gets invoked. However, there appear to be some issues with
> CoyoteServerSocketFactory and it's handling of configuration
> directives:
> 
> (1) CoyoteServerSocketFactory appears to be willing to handle a
> "socketFactoryName". AFAICT, this is supplanted by SSLImplementation
> and none of the other code does anything with it. Any reason not to
> remove support for this directive entirely?

I had no idea what was useful.

> (2) JSSE uses one keyfile (the keystore). PureTLS uses three, the
> keyfile, the CA file, and the random file. I need to add new
> directives to ServerSocketFactory to propagate those.

+1.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Resend: SSL portability and Coyote

[costinm]

On Fri, 26 Apr 2002, Eric Rescorla wrote:

> (1) CoyoteServerSocketFactory appears to be willing to handle a
> "socketFactoryName". AFAICT, this is supplanted by SSLImplementation
> and none of the other code does anything with it. Any reason not to
> remove support for this directive entirely?
> 
> (2) JSSE uses one keyfile (the keystore). PureTLS uses three, the
> keyfile, the CA file, and the random file. I need to add new
> directives to ServerSocketFactory to propagate those.
> 
> Does anyone object to these changes?

+1

BTW, I just got pureTLS to work with axis - jsse has a stupid bug
and couldn't find any solution or fix. It works _great_.

( and policy.acceptUnverifiableCertificates(true) instread of 
fake trust factories and ugly hacks  is amazing )

Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: