RE: Generation of the Finished message
On Mon, 10 Dec 2007, Marek Marcola wrote: Hello, Your description seems like on Certificate Verify message? I was talking about Finished message. Finished message is build with two hashes: dgst1=md1(hs_msgs+label+master_secret+48*0x36) dgst1=md1(master_secret+48*0x5c+dgst1) dgst2=md2(hs_msgs+label+master_secret+40*0x36) dgst2=md2(master_secret+40*0x5c+dgst2) where md1=MD5 (for RSA) and md2=SHA1 (for RSA and DSA) label=CLNT for client, label=SRVR for server. This two digests is then encrypted with negotiated symmetric algorithm (with padding for block ciphers) and sent to peer. Peer decrypts SSL packet, calculates your own digests and compares (peer drops connection if digests differs). Looks like the hash generation technique is same for finished and the client verify message, except the contents fed to the hash differs. Best regards, This email message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential, proprietary and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and destroy all copies of the original message. Thank you. Intoto Inc. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Generation of the Finished message
Yes, if the negotiated algorithm is RSA, then the hash is a combinatin of
MD5 and SHA-1 (16+20 = 36) which is further encrypted using the public key
of the server/client depending on who is sending the finished message,
using the RSA algorithm, and the padding ensures that the message is an
integral multiple of the block size.
For DH the finsihed message will contain only the MD5 hash, I guess this
information is available in the rfc.
Thanks
--Gayathri
On Thu, 6 Dec 2007, Xiaoyu Ruan wrote:
Hello All,
According to RFC 2246 or 4346, the Finished message should be
struct {
opaque verify_data[12];
} Finished;
verify_data
PRF(master_secret, finished_label, MD5(handshake_messages) +
SHA-1(handshake_messages)) [0..11];
In addition to this there are Handshake type (1 byte) and message length (3
bytes). Then the Finished message should be 16 bytes. However, OpenSSL s_server
and s_client are sending out 40-bytes or 48-bytes Finished messages. This
implies that the 16-byte data has been encrypted or undergoing some other
processing. Can anyone please let me know what is done here and what the
corresponding RFC reference is?
Thanks,
Xiaoyu
This email message (including any attachments) is for the sole use of the intended recipient(s)
and may contain confidential, proprietary and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended recipient,
please immediately notify the sender by reply email and destroy all copies of the original message.
Thank you.
Intoto Inc.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: cyphers and keys
On Tue, 30 Oct 2007, [EMAIL PROTECTED] wrote: Hi I have one worrying question... I have generated my keys and ca and all with easy-rsa package and he has generated 1024 bit rsa keys... but as far as I have seen openvpn is using blowfish... blowfish in a symetric encription cypher and rsa is an asymetrical one... shouldn't match keys and cypher types?? or else... how this works? I mean it takes parts of the whole 1024 size key in pieces or 128 bits (for blowfish) or how does this work? I guess you have no idea about SSL, blowfish would be used for the bulk encryption (application data records) and rsa would be used for public key encryption to securely exchange the pre master secret. I suggest you read the TLS standard from ietf. When you do a openvpn --show-cyphers you see all symetryc cipher systems am I wrong? Thanks a lot mates!! waiting anxious you're answers __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] This email message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential, proprietary and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and destroy all copies of the original message. Thank you. Intoto Inc. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Segmentation fault in application creating too many threads.
The stack trace showing a null sha1 transform kindof caught my attention
here, I wouldnt go by the the GDB call trace coz its obviously a memory
leak and the gdb stack could have been corrupted, many a times I see 0x0
in the frames but when you actually try to print the ctx address it would
be valid. CTX is definitely valid here,
prabhu, earlier I was assuming you are using the linux sha1 in the kernel
which is a loadable module, and I realise your just using plain openssl
from userspace and linking with libcrypto. Linux sha1 has a limitation on
the sha1_tfm structure, perhaps libcrypto sha1 is also the same way?
Its obvious that you have ran out of sha1_tfms which is why when you
actually sleep it helps as other threads would have released theirs.
If you dont mind sending ur client code snipped, I could debug..
my email id would be [EMAIL PROTECTED]
Thanks
--Gayathri
Even reducing the thread stack size didn't help.
I observe that the thread creation as such is not a problem. I create
about 1000 threads , delay in each thread the SSL_connect for about 10
sec.
Once the delay expires and each client make connections to the server
the seg fault occurs.
You know, looking back at your original trace, it seems I may have jumped
to conclusions. It's hard to be sure because I don't know what OpenSSL
version you are using, so the line numbers don't tell me anything, but
check this
out:
#0 SHA1_Init (c=0x0) at sha_locl.h:150
#1 0x405b2bb0 in init (ctx=0x0) at m_sha1.c:72
#2 0x405afc91 in EVP_DigestInit_ex (ctx=0x4d606230, type=0x4061f620,
impl=0x0) at digest.c:207
#3 0x405ac08e in ssleay_rand_add (buf=0x0, num=0, add=
2.5863007356866632e-306) at md_rand.c:263
#4 0x405ace6e in RAND_add (buf=0x8a269f8, num=144861688, entropy=0)
at rand_lib.c:151
I'm guessing frame #2 is this:
return ctx-digest-init(ctx);
Which calls this:
static int init(EVP_MD_CTX *ctx)
{ return SHA1_Init(ctx-md_data); }
Notice that 'init' was called with a NULL context. But the context
cannot have been NULL in frame 2 because if it was ctx-digest would have
faulted.
So it looks like the stack in frame #2 cannot have lead to the stack in
frame #1.
This is not a memory exhaustion issue or a failure to check for
NULL. It looks like stack corruption. The real puzzle is why stack
corruption would only occur with a large number of threads.
I'm thinking perhaps there's some concurrency issue with
ssleay_rand_add, but I've been over it twice and I don't see any issue.
The md context would be unique for each thread, so it should be safe.
Maybe someone will read this and it will resonate with something
they know?
If you can, please tell us what version of OpenSSL this was. This will
allow people to understand the line numbers better and make sure they're
not looking at code that has whatever bit you already fixed.
DS
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
This email message (including any attachments) is for the sole use of the intended recipient(s)
and may contain confidential, proprietary and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended recipient,
please immediately notify the sender by reply email and destroy all copies of the original message.
Thank you.
Intoto Inc.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Segmentation fault in application creating too many threads.
Hi Prabhu, Can you check the sha1 usage count in the lsmod? I am thinking you have not freed the sha tfm and eventually run out of it. I hit a similar issue when making use of linux sha1. Thanks --Gayathri On Mon, 15 Oct 2007, Prabhu S wrote: Hi, The SSL enabled client application seg faults when too many threads are created. Each thread is a SSL client attempting a connection with Server. The application sets the static call back functions.: static void locking_function(int mode, int n, const char * file, int line) static unsigned long id_function(void) The application creates about 800 threads in a Linux 2.6 Kernel. #0 SHA1_Init (c=0x0) at sha_locl.h:150 #1 0x405b2bb0 in init (ctx=0x0) at m_sha1.c:72 #2 0x405afc91 in EVP_DigestInit_ex (ctx=0x4d606230, type=0x4061f620, impl=0x0) at digest.c:207 #3 0x405ac08e in ssleay_rand_add (buf=0x0, num=0, add= 2.5863007356866632e-306) at md_rand.c:263 #4 0x405ace6e in RAND_add (buf=0x8a269f8, num=144861688, entropy=0) at rand_lib.c:151 #5 0x08a269f8 in ?? () #6 0x08a269f8 in ?? () #7 0x in ?? () When less number of threads are created I don't see the issue. How do we use CRYPTO_set_idptr_callback()? OpenSSL document reads - There is still the issue of platforms where pthread_self() returns something other than an integer. It is for cases like this that CRYPTO_set_idptr_callback() comes in handy Regards, Prabhu. S This email message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential, proprietary and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and destroy all copies of the original message. Thank you. Intoto Inc. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
