David Taylor wrote:
> If you give a client hello with an existing session id, the client and
> server random values will change, but the master secret won't because
> the short version of the handshake doesn't do the key exchange.
Changing the client and server random values does change the mast
> I'm trying to avoid doing the whole handshake again - I just want to
> change the bulk cipher keys/IVs in use by the connection every now and
> again and the SSL and TLS specs say this is done by using the client
> hello message with the same session ID as the connection is already
> using (see
> OTOH, wouldn't renegotiation change the session ID and thus avoid the
> problem? (I'm saying this without checking, but it seems the obvious
> thing to do).
Not always! This is the point I'm trying to figure out.
I had a cursory look at the OpenSSL code last night and all I could see
was that
Ben Laurie wrote:
> > It's unfortunate that makedepend insists on tracking down every
> > dependency. A flag to say "don't go there" as in -X/usr/include,
> > would be a big win.
>
> Yeah.
Before someone points it out, of course, there is one (-Y) but what I,
and, I presume, Rich, meant was "go
[EMAIL PROTECTED] wrote:
>
> (Garg, why does the mailing list set reply-to?)
>
> >what I actually did was to use makedepend to generate dependencies, and
> >then hack it with perl to remove the OS headers. The "depend" target
> >does this. If anyone wants OS headers too, they can damn well inven
(Garg, why does the mailing list set reply-to?)
>what I actually did was to use makedepend to generate dependencies, and
>then hack it with perl to remove the OS headers. The "depend" target
>does this. If anyone wants OS headers too, they can damn well invent
>their own target.
Actually, if som
Rich Salz wrote:
>
> On Sun, 17 Jan 1999, Ben Laurie wrote:
> > I'm being driven slowly mad by the number of files that have to be in
> > the CVS tree but also get modified by code. Most of them I can deal
> > with
>
> I assume/hope that you'll do the "foo.in --> foo" kind of transform.
>
> > I
> I am responsible for the server that currently distributes the SSLeay mailing
> lists. I believe that these lists should and will die, and interested parties
> should move across to openssl lists. Before suggesting this to ssl-users,
> I'd like to poll the feeling over here for automatically r
[EMAIL PROTECTED] wrote:
>
> I don't understand why US people can't be given access to the source
> tree.
I didn't understand that, either, but it didn't seem worth quibbling,
because there are other reasons, anyway...
> Is it because of a desire to "prove" that nobody from the US exported
> so
sameer wrote:
>
> So the other thing which I was reminded to make sure was
> happening was the required legal CYA that's needed, imo, for an open
> source project. Namely the bits saying that if you submit something
> you're granting a license (including right to sublicense), warranting
>
sameer wrote:
>
> So, I'm lame, and I haven't been paying too much attention to
> this list. I realized today, however, that it would be legit for me to
> work on documentation for OpenSSL. So what's the status on
> documentation? I'm thinking it would be appropriate to setup another
> CV
I don't understand why US people can't be given access to the source
tree.
Is it because of a desire to "prove" that nobody from the US exported
source code? Surely that's (a) too big a hammer (we can, e.g., con-
tribute to the ASN1 engine); (b) probably not sufficient proof; and
(c) starting do
Clifford Heath wrote:
>
> Folk,
>
> I am responsible for the server that currently distributes the SSLeay mailing
> lists. I believe that these lists should and will die, and interested parties
> should move across to openssl lists. Before suggesting this to ssl-users,
> I'd like to poll the f
Folk,
I am responsible for the server that currently distributes the SSLeay mailing
lists. I believe that these lists should and will die, and interested parties
should move across to openssl lists. Before suggesting this to ssl-users,
I'd like to poll the feeling over here for automatically re
[EMAIL PROTECTED] wrote:
>
> Gentlefolk,
>
> Here's a few problems I've encountered so far with openssl.
>
> (1)
>
> In bn_lcl.h, definitions of BN_MULL_SIZE_NORMAL, etc.
> My AIX C compiler is not happy with the double slashes.
> Are these supposed to be C++ comments? That's what I
> told my
I've found some fun bug in OpenSSL that I'll work through later. This only
seems to be happening in SSLeay 0.9.1b and anything onwards although I've
not yet tried earlier versions yet apart from 0.8.0d (which works).
./openssl s_client -connect www.ukweb.com:443 -CAfile cacert.pem
15929:error:
David Taylor wrote:
>
> I have a question about session param negotiation when there are a
> number of connections attached to the session.
>
> If the cipher suite stays the same, I imagine everything works fine as
> the new session params really only generate connection state (bulk
> cipher key
> > In my last question I mentioned existing connections on a session that
> > has had it's master secret changed must continue to use the values
> > generated from the old master secret. Is this true or does OpenSSL get
> > all the connections to change their bulk cipher keys and IVs?
>
> The w
> (2)
> In s_server.c, the call to SSL_load_client_CA_file uses
> the wrong file. It works a lot better if CAfile is used
> instead of the client's certificate (s_cert_file).
Oops, meant server's certificate.
Eric Norman
University of Wisconsin
> In my last question I mentioned existing connections on a session that
> has had it's master secret changed must continue to use the values
> generated from the old master secret. Is this true or does OpenSSL get
> all the connections to change their bulk cipher keys and IVs?
The way I read the
Gentlefolk,
Here's a few problems I've encountered so far with openssl.
(1)
In bn_lcl.h, definitions of BN_MULL_SIZE_NORMAL, etc.
My AIX C compiler is not happy with the double slashes.
Are these supposed to be C++ comments? That's what I
told my C compiler they were (AIX option), but maybe I
21 matches
Mail list logo
