Sean Walker schrieb:
>
> new key on the connection. We have other means of identifying the client, we don't
> need to use a specific key to identify them. We just need to be sure that the data
> in transit is "secure".
using auth with client certs is a nice field to play with...
> Thanks for t
> > > Perhaps you should ask for a better definition of "session based" first.
> > >
> > > > I believe that I would have to
> > > > disable key caching on the server, correct?
> > >
> > > You have to disable *session* caching on the server. Thus for every new
> > > connect a full SSL handshake is
Ben Laurie schrieb:
>
> Holger Reif wrote:
> > Sean Walker schrieb:
> > > We are writing both client and server applications
> > > and so have complete control over the design. What would be a good means
> > > of generating a "session based" key?
> >
> > Perhaps you should ask for a better defini
Holger Reif wrote:
> Sean Walker schrieb:
> > We are writing both client and server applications
> > and so have complete control over the design. What would be a good means
> > of generating a "session based" key?
>
> Perhaps you should ask for a better definition of "session based" first.
>
>
Sean Walker schrieb:
>
> I am doing some work with a government agency who is requiring 128
> "bite" (a direct quote, by the way) SSL encryption in order to
> communicate their information over the Internet. We have a direct line
> to their office to get the information and then we relay that to
I am doing some work with a government agency who is requiring 128
"bite" (a direct quote, by the way) SSL encryption in order to
communicate their information over the Internet. We have a direct line
to their office to get the information and then we relay that to our
customers via the Internet.
