RE: Multithreading problem

[David Schwartz]

> This problem was raised on this mailing list many times, but the 
> clear solution (in my opinion) was not given. From OpenSSL FAQ: 
> ...an SSL connection may not concurrently be used by multiple 
> threads... This means that I can't have 2 threads, one reading 
> and one writing at the same time from the same socket. My 
> application is basic Jabber communicator (messager) I should to 
> constantly listen on socket for incoming messages and at the same 
> time send messages written by me.(this is not communication model 
> like for example in http: request,response,request,response.etc.) 
> If I use simple TCP connection I create 2 threads one reading, 
> one writing. This is simple,fast and correct.(reding and writing 
> are blocking).

Actually, it's extremely complicated. For example, what do you do if you call 
'write' and it doesn't return in a reasonable amount of time?

> But when have to SSL connection this is much more 
> complicated. I'm using Delphi and Indy components. There are 
> sugesstion on mailing list that concurrent socket usage can be 
> avoided by creating non-blocking socket and mutex, which is 
> locked when any thread is using socket. But non-blocking socket 
> is more complex to implement and forces me to not use Indy 
> component, since Indy components are desined to work only in 
> blocking mode (for TCP sockets this is correct design, I've read 
> that Indy 10 has an option in core to work in non-blocking mode 
> but I don't known if this option is exposed to user the same way 
> as in socet API (maybe it was added to other purposes), but I 
> have Indy 9 and don't want to upgrade). So using nonblocking 
> sockets forces me to implement everything in native socket API, 
> using  OpenSSL API (currently Indy does it internally) and deal 
> with additional complexivity of nonblocking sockets.

Doesn't this kind of prove that your assumption (that non-blocking sockets are 
more complicated) is wrong? Look at all the craziness you have to go through to 
get blocking sockets to work right.
 
> Is there any OpenSSL function similar to socket API 'select' 
> (SSL_select)  If yes, then I can use blocking sockets. One 
> thread is waiting in blocking SSL_select for incoming messages, 
> If massage will come then this thread will try to acquire mutex 
> and then carry out blocking SSL_read which will not block because 
> there is message on 
> socket. I can't do this with socket API 'select' because it 
> signals any data on socket not exactly data on which SSL_read 
> will not block. (TLS renogotiation or something like this). I 
> hope you known what I mean.
> (I have tried with SSL_pending but it return 0 even if there are 
> data on socket)

You cannot use 'select' with blocking sockets. If you do, and your 'write' 
blocks (say because only a few bytes could be written at that instant), you 
won't be able to call 'read'.

> Any suggestions? Can someone help me with this?

If you want to use blocking sockets, you can. Just use BIO pairs. You would 
then have one thread that asks OpenSSL if it has any data that needs to be 
written, if so, you grab it from OpenSSL (using non-blocking operations), then 
block on the socket while you write it. You can keep a thread blocked on 'read' 
and when you get any data from the socket, you hand if to OpenSSL. Protect the 
whole BIO pair assembly with a mutex, which you only hold while you enter the 
non-blocking OpenSSL logic.

So it works like this:

1) When you want to write plaintext data to the SSL layer, grab the SSL mutex, 
call a non-blocking write function. If you don't write it all, release the 
mutex and block on the SSL conditition variable. If you make any forward 
progress, broadcast the condition variable.

2) When you want to read plaintext data from the SSL layer, grab the SSL mutex, 
call a non-blocking read function. If you get no data, release the mutex and 
block on the condition variable. If you make any forward progress, broadcast 
the condition variable.

3) In your read thread, when you get data from the socket, grab the SSL mutex, 
give the data to a non-blocking write function on the SSL BIO. If you wrote it 
all, release the mutex and signal the condition variable. If not, block on the 
condition variable until you write it all.

4) In your write thread, grab the mutex and block on the condition variable. 
When woken, get any data from the SSL BIO. Release the mutex, signal the 
condition variable, and write it to the socket. When you can no longer make 
forward progress, block on the condition variable (implicitly releasing the 
condition variable).

I wrote this quickly and unfortunately have to go before I have a chance to 
proofread it, but it should give you the idea.

DS


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager  

Re: BN_bin2bn problem

[Olga Kornievskaia]

Nils Larsch wrote:

Olga Kornievskaia wrote:
Hi, can anyone tell me how to fix the leading zero in BIGNUM. I have 
the following code:


unsigned char pkinit_1024_dhprime[128] = {
   0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
   0xC9, 0x0F, 0xDA, 0xA2, 0x21, 0x68, 0xC2, 0x34,
   0xC4, 0xC6, 0x62, 0x8B, 0x80, 0xDC, 0x1C, 0xD1,
   0x29, 0x02, 0x4E, 0x08, 0x8A, 0x67, 0xCC, 0x74,
   0x02, 0x0B, 0xBE, 0xA6, 0x3B, 0x13, 0x9B, 0x22,
   0x51, 0x4A, 0x08, 0x79, 0x8E, 0x34, 0x04, 0xDD,
   0xEF, 0x95, 0x19, 0xB3, 0xCD, 0x3A, 0x43, 0x1B,
   0x30, 0x2B, 0x0A, 0x6D, 0xF2, 0x5F, 0x14, 0x37,
   0x4F, 0xE1, 0x35, 0x6D, 0x6D, 0x51, 0xC2, 0x45,
   0xE4, 0x85, 0xB5, 0x76, 0x62, 0x5E, 0x7E, 0xC6,
   0xF4, 0x4C, 0x42, 0xE9, 0xA6, 0x37, 0xED, 0x6B,
   0x0B, 0xFF, 0x5C, 0xB6, 0xF4, 0x06, 0xB7, 0xED,
   0xEE, 0x38, 0x6B, 0xFB, 0x5A, 0x89, 0x9F, 0xA5,
   0xAE, 0x9F, 0x24, 0x11, 0x7C, 0x4B, 0x1F, 0xE6,
   0x49, 0x28, 0x66, 0x51, 0xEC, 0xE6, 0x53, 0x81,
   0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
};

BIGNUM *p;
p = BN_bin2bn(pkinit_1024_dhprime, sizeof(pkinit_1024_dhprime), NULL);

When I print the big number is comes out with a leading zero:
   00:ff:ff:ff:ff:ff:ff:ff:ff:c9:0f:da:a2:21:68:
   c2:34:c4:c6:62:8b:80:dc:1c:d1:29:02:4e:08:8a:
   67:cc:74:02:0b:be:a6:3b:13:9b:22:51:4a:08:79:
   8e:34:04:dd:ef:95:19:b3:cd:3a:43:1b:30:2b:0a:
   6d:f2:5f:14:37:4f:e1:35:6d:6d:51:c2:45:e4:85:
   b5:76:62:5e:7e:c6:f4:4c:42:e9:a6:37:ed:6b:0b:
   ff:5c:b6:f4:06:b7:ed:ee:38:6b:fb:5a:89:9f:a5:
   ae:9f:24:11:7c:4b:1f:e6:49:28:66:51:ec:e6:53:
   81:ff:ff:ff:ff:ff:ff:ff:ff

In crypto/bn/bn.h, I read comments about "Bignum consistency macros" 
and I tried to add bn_fix_top(p) after calling BN_bin2bn() but it 
didn't fix the leading zero problem.


Any suggestions would be appreciated.


the bignum library doesn't add a leading zero byte. The leading zero byte
is normally added when you DER encode an integer to indicate that the
number is positive.

Ok. Thanks. I was hoping that a leading zero was the answer to my real 
problem which is. I'm using the above "p" and a generator "g" = 2 (both 
are well-known group 2 DH parameters described in the  RFC 2412).  I 
initialize the DH structure with them and the then call DH_check() which 
returns with an error code of 8 which is  "the g value is not a 
generator". I'm puzzled as to why the library doesn't like the 
well-known DH parameters.

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: BN_bin2bn problem

[Nils Larsch]

Olga Kornievskaia wrote:
Hi, can anyone tell me how to fix the leading zero in BIGNUM. I have the 
following code:


unsigned char pkinit_1024_dhprime[128] = {
   0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
   0xC9, 0x0F, 0xDA, 0xA2, 0x21, 0x68, 0xC2, 0x34,
   0xC4, 0xC6, 0x62, 0x8B, 0x80, 0xDC, 0x1C, 0xD1,
   0x29, 0x02, 0x4E, 0x08, 0x8A, 0x67, 0xCC, 0x74,
   0x02, 0x0B, 0xBE, 0xA6, 0x3B, 0x13, 0x9B, 0x22,
   0x51, 0x4A, 0x08, 0x79, 0x8E, 0x34, 0x04, 0xDD,
   0xEF, 0x95, 0x19, 0xB3, 0xCD, 0x3A, 0x43, 0x1B,
   0x30, 0x2B, 0x0A, 0x6D, 0xF2, 0x5F, 0x14, 0x37,
   0x4F, 0xE1, 0x35, 0x6D, 0x6D, 0x51, 0xC2, 0x45,
   0xE4, 0x85, 0xB5, 0x76, 0x62, 0x5E, 0x7E, 0xC6,
   0xF4, 0x4C, 0x42, 0xE9, 0xA6, 0x37, 0xED, 0x6B,
   0x0B, 0xFF, 0x5C, 0xB6, 0xF4, 0x06, 0xB7, 0xED,
   0xEE, 0x38, 0x6B, 0xFB, 0x5A, 0x89, 0x9F, 0xA5,
   0xAE, 0x9F, 0x24, 0x11, 0x7C, 0x4B, 0x1F, 0xE6,
   0x49, 0x28, 0x66, 0x51, 0xEC, 0xE6, 0x53, 0x81,
   0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
};

BIGNUM *p;
p = BN_bin2bn(pkinit_1024_dhprime, sizeof(pkinit_1024_dhprime), NULL);

When I print the big number is comes out with a leading zero:
   00:ff:ff:ff:ff:ff:ff:ff:ff:c9:0f:da:a2:21:68:
   c2:34:c4:c6:62:8b:80:dc:1c:d1:29:02:4e:08:8a:
   67:cc:74:02:0b:be:a6:3b:13:9b:22:51:4a:08:79:
   8e:34:04:dd:ef:95:19:b3:cd:3a:43:1b:30:2b:0a:
   6d:f2:5f:14:37:4f:e1:35:6d:6d:51:c2:45:e4:85:
   b5:76:62:5e:7e:c6:f4:4c:42:e9:a6:37:ed:6b:0b:
   ff:5c:b6:f4:06:b7:ed:ee:38:6b:fb:5a:89:9f:a5:
   ae:9f:24:11:7c:4b:1f:e6:49:28:66:51:ec:e6:53:
   81:ff:ff:ff:ff:ff:ff:ff:ff

In crypto/bn/bn.h, I read comments about "Bignum consistency macros" and 
I tried to add bn_fix_top(p) after calling BN_bin2bn() but it didn't fix 
the leading zero problem.


Any suggestions would be appreciated.


the bignum library doesn't add a leading zero byte. The leading zero byte
is normally added when you DER encode an integer to indicate that the
number is positive.

Cheers,
Nils
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: sslv3 alert handshake failure

[IT Professional]

Great, 

I finally don't see the error.

Is there any other way to disable ECDHE other than from command line?

I couldn't find any command to disable ECDHE in the generation of the ECC cert.

I also tried editing SSLCipherSuite to 
ALL:!ADH:!EXPORT56:RC4+RSA:-kEECDH:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

or
ALL:!ADH:!EXPORT56:RC4+RSA:-kECDHe:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
where I expected -kEECDH or -kECDHE or to disable ECDHE.
Unfortunately, it didn't worked out.

Many thanks!


- Original Message 

From: Marek Marcola <[EMAIL PROTECTED]>

To: openssl-users@openssl.org

Sent: Thursday, 19 October 2006 7:06:48 PM

Subject: Re: sslv3 alert handshake failure



Hello,

> Like to clarify one point, am I right to say the peer (client) we are

> referring to here is the browser?

Browser or any other SSL client.



> I'm using Firefox 2 Beta 1 which I know has ECC support. I had

> performed a test at tls.secg.org to verify this.

According to Firefox documetation ECC support is presently limited

to curves of 256, 384, and 521 bits.

But after creating ECC secp521r1 I was unable to connect

with Firefox too, but now I had error -8092 

which means SEC_ERROR_KEYGEN_FAIL. After looking at source

code of Firefox there was place in

mozilla/security/nss/lib/ssl/ssl3ecc.c where ephemeral keys are

generated from ECC and probably this cause error.

After running "openssl s_server ..." with "-no_ecdhe" I was

able to establish connection with ECC ciphers.



>Another point I'm puzzled is that the openssl ciphersuites shown only

>ciphers with SSLv3 protocol when I execute openssl cipher -v ECCdraft.

>But I thought openssl 0.9.8b already provide support for TLSv1 too, so

>why don't I see any ciphers with TLSv1 protocol? Or have I

>misunderstood the readme file in 0.9.8b?

This is only name problem, SSL3 and TLS1 are very close so sometimes

some names/variables are used interchangeably.





Best regards,



-- 

Marek Marcola <[EMAIL PROTECTED]>



__

OpenSSL Project http://www.openssl.org

User Support Mailing Listopenssl-users@openssl.org

Automated List Manager   [EMAIL PROTECTED]

















__ 
What is the internet to you? 
Contribute to the Yahoo! Time Capsule and be a part of internet history. 
http://timecapsule.yahoo.com/capsule.php?intl=sg
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

ecdsa certificates and sha256

[Max Pritikin]

Folks,

This questions is regarding the demo openssl-0.9.8-stable- 
SNAP-20061004/demos/ssltest-ecc, and in particular the ECCCcertgen.sh  
script. What I've done is attempt to specify the hash digest like so:


#earlier in the script i set the digest I want
TEST_DIGEST="sha256"

# and here I've modified to specify the digest:

# Sign the certificate request in $TEST_CA_FILE.req.pem using the
# private key in $TEST_CA_FILE.key.pem and include the CA extension.
# Make the certificate valid for 1500 days from the time of signing.
# The certificate is written into $TEST_CA_FILE.cert.pem
$OPENSSL_CMD x509 -req -days $DAYS \
-in $CERTS_DIR/$TEST_CA_FILE.req.pem \
-extfile $OPENSSL_DIR/apps/openssl.cnf \
-extensions v3_ca \
-signkey $KEYS_DIR/$TEST_CA_FILE.key.pem \
-out $CERTS_DIR/$TEST_CA_FILE.cert.pem -$TEST_DIGEST

What I find though is that the resulting certificates are still  
created with:

Signature Algorithm: ecdsa-with-SHA1

I'm looking for some advice/thoughts on the following three questions:

1) Perhaps I'm just using the CLI incorrectly. Does my method look  
correct?


2) Perhaps openssl doesn't yet support ecdsa with SHA256?
If so I'd expect an error when I specify -sha256 (as it does if I  
provide a bogus digest name). Looking through the code though there  
doesn't appear to be an 'ecdsa-with-SHA256' or similar defined/used.  
If this is true I guess I'll move over to openssl-dev and see if I  
can help fix things.


3) Perhaps ecdsa is limited to sha-1?
This seems unlikely and the www.x9.org abstract for X9.62 (ecdsa)  
seems to claim "The hash functions Approved at the time of  
publication of this document are SHA-1 (see NOTE), SHA-224, SHA-256,  
SHA-384 and SHA-512." But I don't have access to the entire document  
and don't see the 'NOTE' and thus could very well be wrong on this  
point.


Any responses appreciated. Thanks,

- max

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Solaris installation: Text relocation remains...

[Laurent Blume]

I've seen you fixed your issue, glad I could help.
PATH issues are common on Solaris, where there are many commonly
installed tools. That's why I always keep a very simple one when
building, to be sure what's used for a given source tarball, SunCC, GCC,
make, gmake, and so on.

Marc Girod a écrit :
>> export LD_OPTIONS="-R${PREFIX}/lib"
> 
> Er... What is that?
> 
> -R   Build runtime search path list into executable
> 
> I don't believe it should affect... not do I want it in fact.
> Anyway, I try...

LD_OPTIONS is used by Solaris ld, it's like its contents are put as
parameters. I add this because at some point, the -R option was not used
in OpenSSL to build the tools, and they couldn't find the libs are runtime.
It doesn't hurt to have it set this way, it's redundant to the -R given
to configure.

And -R is used just for that, so the binaries look there at runtime for
the libs, without the need to set LD_LIBRARY_PATH (which is never a good
solution), or crle (which is not too good either, and tricky).

Laurent
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: SSL_read()

[Mark]

Hi Carlo, 

> I have a single threaded application where a SSL_read() is 
> returning a return code of 0.  The openSSL doc suggests that 
> this is due to a socket shutdown by the peer.  Upon this 
> error, is there anything that I can do to recover the 
> connection and/or data or do I just need to start over? Thank you.

Call SSL_get_error() to find out the reason.

Regards,
Mark
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Solaris installation: Text relocation remains...

[Marc Girod]

Marc Girod <[EMAIL PROTECTED]> writes:

> I'll try to see what exactly affects.

It seems that the discriminating factor in my case,
i.e. what broke my build,
what gmake.

In my first attempt, I had GNU make in my path, preempting /usr/ccs/bin/make.
If I take it away, my build works...
I found that I had to install it in order to build expat (needed for
subversion), which won't build as such with Solaris make:

 cat ~/tmp/foo.mk
FOO=bar

ifndef FOO
FOO=foo
endif

all:
echo $(FOO)
# Linux/GNU make:
$ type make
make is /usr/bin/make
$ make -f foo.mk
echo bar
bar
# pdsunfire:
$ type make
make is hashed (/usr/ccs/bin/make)
$ make -f ~/tmp/foo.mk
make: Fatal error in reader: /home/mgirod/tmp/foo.mk, line 4: Unexpected end of
line seen

Marc

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: sslv3 alert handshake failure

[Marek Marcola]

Hello,
> Like to clarify one point, am I right to say the peer (client) we are
> referring to here is the browser?
Browser or any other SSL client.

> I'm using Firefox 2 Beta 1 which I know has ECC support. I had
> performed a test at tls.secg.org to verify this.
According to Firefox documetation ECC support is presently limited
to curves of 256, 384, and 521 bits.
But after creating ECC secp521r1 I was unable to connect
with Firefox too, but now I had error -8092 
which means SEC_ERROR_KEYGEN_FAIL. After looking at source
code of Firefox there was place in
mozilla/security/nss/lib/ssl/ssl3ecc.c where ephemeral keys are
generated from ECC and probably this cause error.
After running "openssl s_server ..." with "-no_ecdhe" I was
able to establish connection with ECC ciphers.

>Another point I'm puzzled is that the openssl ciphersuites shown only
>ciphers with SSLv3 protocol when I execute openssl cipher -v ECCdraft.
>But I thought openssl 0.9.8b already provide support for TLSv1 too, so
>why don't I see any ciphers with TLSv1 protocol? Or have I
>misunderstood the readme file in 0.9.8b?
This is only name problem, SSL3 and TLS1 are very close so sometimes
some names/variables are used interchangeably.


Best regards,

-- 
Marek Marcola <[EMAIL PROTECTED]>

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: base64 encode of sha1

[Kaushalye Kapuruge]

Kaushalye Kapuruge wrote:

Witek wrote:

Kaushalye Kapuruge wrote:


Hi,
I tried to get the base64 encoded result of a SHA1 digest. But the 
result is not compatible with the same operation in Java. Also I 
tried to use a javascript function. It is matching with the result 
of the Java implementation but not with the openssl result. So I 
guess there is something wrong with openssl implementation.

Here I'll write my approaches.

(A) Openssl

echo "abcde" | openssl dgst -sha1 -binary | openssl base64


(B) Java implementation.
--
   MessageDigest md = MessageDigest.getInstance("SHA1");
   md.reset();
   md.update("abcde".getBytes());
   System.out.println(Base64.encode(md.digest()));


(C) Javascript

var res= b64_sha1("abcde");
[Have to include the script file src="http://pajhome.org.uk/crypt/md5/sha1.js";>]


Also I tried this with SHA1() function in openssl/sha1 and it 
produces another result.(Let's say approach D)


If I summarize the results.
Approach A,B produces the same result. (A95sVwv+JL/DKMzXyka3bq2vQzQ=)
Approach C,D produces different results.

Thanks,
Kaushalye


__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]



Hi,

Try this:
echo -n "abcde" | openssl dgst -sha1 -binary | openssl base64

Witek

Great.. I forgot abt the end-line character.
But wonder how I do SHA1 in the code level. There is SHA1(input, 
length, result) function. Also I can use SHA1_Init(), Update(), 
final() approach. Anyone has some examples?

Rgds,
Kaushalye
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


I found the way to go...
If anybody needs, this is how its gonna be...

   SHA_CTX c;
   unsigned char md[SHA_DIGEST_LENGTH];
   SHA1_Init(&c);
   SHA1_Update(&c,"abcde",5);
   SHA1_Final(md,&c);
   printf("\nmd =%s", md);

Rgds,
Kau

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]