As discussed on the list previously, I'm working on changing the SSL
interfaces in Tomcat to make them more portable to various SSL
toolkits, in particular PureTLS. In the process I've run into some
issues that I wanted to run by the list.
1. I don't see how to make the switch-hit via a
jean-frederic clere [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
As discussed on the list previously, I'm working on changing the SSL
interfaces in Tomcat to make them more portable to various SSL
toolkits, in particular PureTLS. In the process I've run into some
issues that I
.)
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jean-frederic clere [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
[EMAIL PROTECTED] writes:
One simple workaround could be to abstract acceptSocket() too ( i.e. make
it a method in ServerSocketFactory or SSLSupport).
Yes, we could do that. It's a little ugly but it avoids having
of the code it's not clear to me what would
be most consistent with traditional practice. Do people have
opinions?
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
Author of SSL and TLS: Designing and Building Secure Systems
http://www.rtfm.com
jean-frederic clere [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
A few issues remain:
(I) Is portability to JDK 1.1.x desirable/a requirement? Both the
existing JSSE code and my new code rely upon java.security.cert.*
which was introduced in JDK 1.2. Both JSSE and PureTLS provide more
William Barker [EMAIL PROTECTED] writes:
jean-frederic clere [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
A few issues remain:
(I) Is portability to JDK 1.1.x desirable/a requirement? Both the
existing JSSE code and my new code rely upon java.security.cert.*
which
,
though, I agree that it belongs in Http10Interceptor.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
can get ssldump from http://www.rtfm.com/ssldump). You'll
want to use the -A and -N flags.
Once we know what's happening we can try to figure out why.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
Author of SSL and TLS: Designing and Building Secure Systems
I'd finished adding portable SSL support to Tomcat and was
testing it when I ran into an interesting snag. Roughly,
the way things work is as follows (spread out over a number
of classes)
Socket s=accept();
PushbackInputStream is=new PushbackInputStream
mailed to the list I'm happy to do so.
Note: These changes only work properly with the latest PureTLS snapshot:
20011130 (though they should work fine if you're compiling without
PureTLS at all as well).
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
Author of SSL
so if someone just pings me when it's ready to be adapted :)
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Bill Barker [EMAIL PROTECTED] writes:
Since no one else responded, I've gone ahead and checked in Eric's changes.
I haven't actually tried to build against PureTLS, but I assume that Eric
has.
I did, but I'll check it out myself and make sure that it works.
You did check that it works in the
in?
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
session. Clients and servers can flush the
session cache at any time.
Session IDs aren't really a complete substitute for cookies.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
Author of SSL and TLS: Designing and Building Secure Systems
http
(Bootstrap.java:243)
Is there any answer?
I'd guess that this is a password problem.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto
the same abstraction for both with a control
flag to indicate which ones to support.
Just one question - are tls socket factories available for tomcat?
Yes. The PureTLS and JSSE socket factories support SSLv3 and TLS.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED
to 4.0. If someone else
wants to do it, I'll be happy to advise. Otherwise I'll shoot
for sometime in March.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional
more than a rush job--always a dangerous practice on
security critical code. I'll be happy to offer advice and review
if someone else wants to take a shot at it. Alternately, if someone
can commit to giving my code a thorough review, I'll take a crack
at it myself.
-Ekr
--
[Eric Rescorla
Nick Betteridge [EMAIL PROTECTED] writes:
I've written the TLS socket but haven't been able to get around to
testing it yet - swamped.
I know how that is.
The socket also has a certificate factory to enable certificates to be
read from a variety of sources.
This seems like a nice addition.
files say?
You might try using ssldump (http://www.rtfm.com/ssldump) to
see what's going on.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail
).
I'm not sure about it, but it doesn't look like client-cert would work with
PureTLS.
Hmm... I need to dig into this. Why do you think it wouldn't?
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail
it work.
Yes, it sounds like the calling code will have to change. How bad
will that be?
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL
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: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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
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
someone
objects.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
somewhere?
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Eric Rescorla [EMAIL PROTECTED] writes:
Bill Barker [EMAIL PROTECTED] writes:
What I'm suggesting is to change o.a.c.tc4.CoyoteRequest.getAttribute to
something like:
code
public Object getAttribute(String name) {
return coyoteRequest.getAttribute(name);
}
/code
, but it would be nice
if someone could test them or look them over or something before we call
them soup :)
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e
).
The release of Coyote 1.0 may be delayed, as it is not the connector used by
default.
Well, I didn't intentionally break anything, but I don't have a complete
regression harness either. (Incidentally, does someone have such a thing
that can be run before checkin?)
-Ekr
--
[Eric Rescorla
these classes would get used.
In any case, the future we're moving toward will be all Coyote
in which case you won't need these classes at all. Is that your
understanding as well?
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com
automatically translates
from the underlying implementation to a vector j.s.c.X509Certificate.
The actual translators live in o.a.t.u.net.{JSSE,PureTLS}Support.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail
Tomcat 4.x repositories (4.0.4-b3, 4.0.x, 4.1.x, 4.0.3), and if the build
was ../build, I'd have lots of nasty conflicts between the different copies.
I agree with Remy here.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com
number of SSL/TLS implementations
do not support anonymous DH (e.g. almost no browsers do.)
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto
is vanishing. (E.g. with a 16-byte
session ID, you'd have to generate 2^60 session IDs to have
a reasonable chance of collision.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED
Bill Barker [EMAIL PROTECTED] writes:
As far as I can tell, ManagerBase could really use your expertise on this.
The current algorithm is really bad :-(
Ok. I've read the current code, which, as you say, is rather complicated.
As far as I can tell, here's how it works:
INITIALIZATION
(1)
decrease the
quality of the randomness to any interesting degree.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Dirk-Willem van Gulik [EMAIL PROTECTED] writes:
On 9 Jan 2003, Eric Rescorla wrote:
Remy Maucherat [EMAIL PROTECTED] writes:
- A MD5 hash occurs after getting the SecureRandom. This looks like a
mistake, and decreases the quality of the random a lot, but given the
quality of MD5
that all of our security mechanisms absolutely
depend on statistical uniqueness of randomly generated large
numbers.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional
Jim Jagielski [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
Glenn Olander [EMAIL PROTECTED] writes:
5) The strength of the PRNG is largely irrelevant
As a user, I wouldn't trust any solution which lacks a check for
duplicate session id's, regardless of the strength of the PRNG
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
that
there is no need to explicitly check for uniqueness.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Costin Manolache [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
Jim Jagielski [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
Glenn Olander [EMAIL PROTECTED] writes:
5) The strength of the PRNG is largely irrelevant
As a user, I wouldn't trust any solution which lacks
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
maybe I should wear a helmet at all times
because a meteor might drop on my head. Sure, it could happen,
btu it's not the thing I'd worry about.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto
--
[Eric Rescorla [EMAIL PROTECTED]]
http://www.rtfm.com/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Costin Manolache [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
Dirk-Willem van Gulik [EMAIL PROTECTED] writes:
ID provides a statistical probability of collision so low that
there is no need to explicitly check for uniqueness.
Or just add a syncronized i++ to make sure.
Yes
Remy Maucherat [EMAIL PROTECTED] writes:
Eric Rescorla wrote:
If PureTLS isn't compatible with IBM JVM, then fine, but I can't see
its usefulness.
It shouldn't be incompatible. What's going on here is a provider
conflict.
You need to ensure that Cryptix is ahead of whatever IBM provider
51 matches
Mail list logo
