Radovan Semancik wrote:
>
> And what about the certificate serial number. It will be changed or
> stays same?
> User will download a renewed certificate just as a "original" one? Won't
> Netscape complaint about duplicate certificate?
No, the serial number is different. Netscape will correctly i
May I humbly request that in future updates of the library, the following
line (and all others like them) be changed back from:
#include
#include
to the original:
#include
#include
I think the latter is friendlier, but this is just IMHO. I had to make a
bunch of changes to my usage to get
Title: OpenSSL configuration
Hi All:
I've used OpenSSL to develop a client/server app. (Thanks for the open source!)
I have things working when my client and server are on the same machine. I get the dreaded no shared cipher when I move my server application from my development machine
From: Taral <[EMAIL PROTECTED]>
taral> If you're talking about adding threading support to OpenSSL,
taral> I'd be happy to help.
I'm talking about adding more fine-grained locking. It horifies me
(perhaps unjustly) that all X.509 operations may be locked out just
because on instance of a X.509
From: Taral <[EMAIL PROTECTED]>
taral> By the way, what's all the code in crypto/threads for?
Testing and examples on how to deal with threads with OpenSSL. I use
it whenever I wanna check that locking still works as intended.
--
Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chair
DSA * d2i_DSAPublicKey(DSA **a, unsigned char **pp, long length);
DSA * d2i_DSAPrivateKey(DSA **a, unsigned char **pp, long length);
These two functions do not seem to be working. It doesn't initalize
the DSA structure from pp containing the DER encoded keys.
For example:
void main(int argc,
On 27 Jun, Richard Levitte - VMS Whacker wrote:
> I see what you mean. True, we have then entered another level of
> difficulty. I think that demands waiting for the overhaul that I'm
> thinking of doing...
If you're talking about adding threading support to OpenSSL, I'd be
happy to help.
Tar
I tried to word my reply so that it would be obvious that I didn't want
to spend the time to look it up. Oh well. Cf SSL_pending().
__
OpenSSL Project http://www.openssl.org
User Support Mailing L
From: Bill Rebey <[EMAIL PROTECTED]>
Bill.Rebey> If I understand you correctly, you are suggesting that I
Bill.Rebey> put wrappers around SSL_write and SSL_read that make them
Bill.Rebey> exclusive operations.
Uhmm, not quite, just per-SSL structure...
Bill.Rebey> This effectively makes the thi
Rich Salz <[EMAIL PROTECTED]> writes:
> > Any ideas?
> >
> > More importantly, do you know why this limitation exists at all? I would
> > rather fix the problem than run from it.
>
> The limit exists because the context depends on state derived from each
> half of the duplex connection. (Myth
On 27 Jun, Rich Salz wrote:
> You should be able to rewrite your server to use select instead of
> threads. Be aware that SSL can do read-ahead write-behind, so you
> can't just trust select but have to call some API or other as well.
Which API is this? licq uses select currently, and I need to
Date: Tue, 27 Jun 2000 14:54:04 -0400
From: Bill Rebey <[EMAIL PROTECTED]>
Thanks, Lenny.
The product is a poor man's software VPN. A Server (the thing I'm writing)
accepts local, clear connections, consults a routing table that is part of
that Server's configuration, se
> Any ideas?
>
> More importantly, do you know why this limitation exists at all? I would
> rather fix the problem than run from it.
The limit exists because the context depends on state derived from each
half of the duplex connection. (Mythical example, for explanation: SSL
periodically sends
On 27 Jun, Lenny Foner wrote:
> If I understand you correctly, you are suggesting that I put wrappers around
> SSL_write and SSL_read that make them exclusive operations. This
> effectively makes the thing single-threaded again. I need to have blocking
> [you mean, "nonblocking"?]
>
On 27 Jun, Bill Rebey wrote:
> Each server has two threads per connection, one doing a blocking read on the
> local port, the other doing a blocking read on the SSL port. When data
> shows up at one, it is written to the other. It's very efficient and very
> compact, involves no polling, maximi
Albert
How about using an HTTPS PUT operation?
Best
Harry
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Albert Serra
Sent: Tuesday, June 27, 2000 2:51 AM
To: [EMAIL PROTECTED]
Subject: string - file
Hello again,
another question,
if I want to tran
Thanks, Lenny.
The product is a poor man's software VPN. A Server (the thing I'm writing)
accepts local, clear connections, consults a routing table that is part of
that Server's configuration, sets up an SSL connection with another Server
as indicated in the routing table, and requests that the
Yea, that's the way I interpreted it, I just reiterated it unclearly.
That's the problem - I can't serialize the access to a single SSL - I need
two threads to access it, one blocking on an SSL_read and another issuing
SSL_write calls as data from an outside source becomes available for writing
ac
On 27 Jun, Lenny Foner wrote:
> If I understand you correctly, you are suggesting that I put wrappers around
> SSL_write and SSL_read that make them exclusive operations. This
> effectively makes the thing single-threaded again. I need to have blocking
> [you mean, "nonblocking"?]
>
On 27 Jun, Lenny Foner wrote:
> If I understand you correctly, you are suggesting that I put wrappers around
> SSL_write and SSL_read that make them exclusive operations. This
> effectively makes the thing single-threaded again. I need to have blocking
> [you mean, "nonblocking"?]
>
Date: Tue, 27 Jun 2000 13:47:25 -0400
From: Bill Rebey <[EMAIL PROTECTED]>
Richard,
Thanks for the reply.
If I understand you correctly, you are suggesting that I put wrappers around
SSL_write and SSL_read that make them exclusive operations. This
effectively makes
Richard,
Thanks for the reply.
If I understand you correctly, you are suggesting that I put wrappers around
SSL_write and SSL_read that make them exclusive operations. This
effectively makes the thing single-threaded again. I need to have blocking
Reads in effect all the time on one thread whi
I received the following error when I did the make
certificate after compiling apache:
4038:error:24064064:random number
generator:SSLEAY_RAND_BYTES:PRNG not
seeded:md_rand.c:538:
4038:error:0A06B003::lib(10) :DSA_sign_setup:BN
lib:dsa_ossl.c:214:
4038:error:0A070003::lib(10) :DSA_do_sign:BN
lib:
On Tue, 27 Jun 2000, Tewari, Vijay wrote:
> Thanks. I was not interested in any particular cipher suite. Actually
> we are trying to run some experinments to determine the impact on tput
> on going from 40 to 128 bit ciphers. I am assuming that EXP-RC4-MD5 is 40
> bit
> while RC4-MD5 is 128 bit .
From: "Erik" <[EMAIL PROTECTED]>
nolke> Do these thread problems also occur when sharing the same SSL
nolke> context but not the same SSL object?
No. The SSL_CTX structure basically acts as a template for the SSL
structures you create, so they don't really carry any semantics that
are thread-se
On 27 Jun, Tewari, Vijay wrote:
> Hi,
> How would I support 40 bit encryption in
> an SSL application built using OpenSSL.
It's already supported by default.
Taral
__
OpenSSL Project http://www.
Do these thread problems also occur when sharing the same SSL context but
not the same SSL object?
thanks,
-erik
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Richard Levitte -
VMS Whacker
Sent: Tuesday, June 27, 2000 9:16 AM
To: [EMAIL PROTECTED]; [EM
Thanks. I was not interested in any particular cipher suite. Actually
we are trying to run some experinments to determine the impact on tput
on going from 40 to 128 bit ciphers. I am assuming that EXP-RC4-MD5 is 40
bit
while RC4-MD5 is 128 bit .
Thanks
Regards
Vijay
-Original Message-
You need to be a little more specific. Is there some specific cipher you
require, or are you just trying to comply with export control regulations?
Probably the easiest approach, if the latter is true, is to do something
like this:
SSL_CTX *sslctx;
.
.
.
/* figure out your SSL_METHOD a
On Tue, Jun 27, 2000 at 05:34:57PM +0100, [EMAIL PROTECTED] wrote:
> >Are you using non-blocking sockets?
> >Lutz
>
> No, I am using blocking sockets...
[Source code deleted.]
I run out of ideas at this point.
The error message you posted is only printed
if (SSL_in_init(s) &&
>Are you using non-blocking sockets?
> Lutz
No, I am using blocking sockets...
Ragnar
---
int ClientConnectionType::connectToHost()
{
int err = 0;
struct sockaddr_in sa;
X509* server_cert;
char* str
Yes.
Is all included in the sources.
In the directory demos/ssl
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Anastasios Angelidis
Sent: Tuesday, June 27, 2000 9:59 AM
To: [EMAIL PROTECTED]
Subject: Beginning
Hi, I am currently working on a application
On Tue, Jun 27, 2000 at 08:36:59AM -0700, Tewari, Vijay wrote:
> How would I support 40 bit encryption in
> an SSL application built using OpenSSL.
Use an export cipher.
Type "openssl ciphers". The cipher EXP-RC4-MD5 is a 40-bit cipher.
Which particular cipher you use depends on whether you c
On Tue, Jun 27, 2000 at 04:48:56PM +0100, [EMAIL PROTECTED] wrote:
> Thank you Lutz, your response gave me an idea i.e. I used "meth =
> TLSv1_client_method();" instead of "meth = SSLv3_client_method();"
>
> My SSL alert number 10 vanished... now I can connect without receiving
> this error.
Douglas,
Sorry - I didn't bookmark any of the Web pages discussing hardware Entropy
sources, as I wasn't really interested in them. If you go to Googl.com or
your favorite search engine and search for "Entropy", "Entropy Source", or
"Hardware Entropy", you'll have more reading material than you
From: Bill Rebey <[EMAIL PROTECTED]>
Bill.Rebey> I based my product on OpenSSL with the understanding that
Bill.Rebey> OpenSSL was multi-thread safe. It has since been brought
Bill.Rebey> to my attention that OpenSSL in fact NOT thread safe and
Bill.Rebey> can not read and write the same SSL fro
Thank you Lutz, your response gave me an idea i.e. I used "meth = TLSv1_client_method();" instead of "meth = SSLv3_client_method();"
My SSL alert number 10 vanished... now I can connect without receiving this error.
This seems to work A.OK with the JCSI server, at least no worse :)
Now all
First, thanks to all of you who have helped me over the past couple of weeks
- without your help I would be bald and have no product at all. At least
now I have some hair left and a product that doesn't work. Better than
nothing.
I based my product on OpenSSL with the understanding that OpenSSL
Hi,
How would I support 40 bit encryption in
an SSL application built using OpenSSL.
Regards
Vijay
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL P
On Tue, Jun 27, 2000 at 04:18:55PM +0100, [EMAIL PROTECTED] wrote:
> >If you are talking about any other peer software, please be more specific
> >and give enough data (IP-address?), so that other people can experiment
> >themselves.
>
> Thank you for the info Lutz :)
>
> My peer software is a s
>If you are talking about any other peer software, please be more specific
>and give enough data (IP-address?), so that other people can experiment
>themselves.
Thank you for the info Lutz :)
My peer software is a server which I wrote myself in Java using the JCSI library from DTSC. Literatur
41 matches
Mail list logo
