Pre Master Secret Regarding
Hi all, During SSL/TLS handshake,a pre master secret is sent from client to the server by encrypting pre master secret with server's public key.From that both client and server derive master secret and finally one symmetric key.My doubt is, why both cannot use pre master secret itself as a symmetric key ? Thanks in advance, Aravind.
RE: Pre Master Secret Regarding
Aravinda babu wrote: During SSL/TLS handshake,a pre master secret is sent from client to the server by encrypting pre master secret with server's public key. From that both client and server derive master secret and finally one symmetric key. My doubt is, why both cannot use pre master secret itself as a symmetric key ? The minor reasons: 1) The scheme used to identify the server may not support encrypting data large enough to be used as the symmetric key. 2) The client's random number generation may not be sufficiently secure, so having the server participate in generating the symmetric key provides greater protection from passive attacks. 3) Using this approach, you would need a phase where the server proves it can decrypt the symmetric key anyway. The major reason: If you did that, you would have no protection against replay attacks. Nothing would stop an attacker from intercepting the SSL session and playing it back to the server. Consider a secure web application that receives commands from a command center to disarm the safe alarm every business morning and then one to arm it every day at close of business. If an attacker intercepts the disarm the safe session, he could play it back any time he wanted and disarm the safe alarm at 2AM on a Sunday morning. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Session reuse causes slowdown for large payloads
Hi all, I'm trying to debug a weird performance artifact: for large payloads, session reuse appears to slow things down significantly relative to creating new sessions. I'm using an apache (2.2.14) + openssl server and openssl s_time to benchmark, e.g., openssl s_time -connect server -www /1.bytes -cipher HIGH -time 5 With small payloads (10,000 random bytes), session reuse dramatically outperforms new sessions (3999 completed connections vs. 247 completed connections). This is also true at 100,000 bytes. But, if I try a larger file (1,000,000 random bytes), session reuse is much worse! (with session reuse: 89 completed connections vs. no reuse: 149 completed connections). I've seen this between separate server/bench machines in the same rack. But, it's easy to replicate even on a single system. Run httpd -X (single threaded mode) and then use s_time as described (I generated the random files with dd if=/dev/urandom) In an interesting twist, if I change the protocol to -ssl2, -reuse outperforms -new, as expected, (81 completed vs. 77 completed). For such large transfer volumes, I wouldn't expect a large penalty from session negotiation in the first place, but it certainly shouldn't be worse. This is basically the same problem as described in the previous post linked below, with the possible tweak that it only manifests for me at large file sizes. But, I didn't find a resolution in the archives... http://www.mail-archive.com/openssl-users@openssl.org/msg33604.html I've seen the problem on x86-Linux and OS X 10.6.3. Any tips would be appreciated, thanks! -M __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: pkcs7 cert loading, why this code doesn't work?
Hi, There are two bugs in your code: First, you only need calls to BIO_read not BIO_write, and in order to avoid the crash you have to pass a pointer equal to inbuf instead of inbuf directly because d2i_PKCS7 increment the pointer internally. So, a more correct version of the code will be : BIO *bio, *b64; char inbuf[4096]; int inlen = strlen(a); char* ptr = inbuf[0]; b64 = BIO_new(BIO_f_base64()); BIO_set_flags(b64, BIO_FLAGS_BASE64_NO_NL); bio=BIO_new_mem_buf(a, -1); bio = BIO_push(b64, bio); inlen=BIO_read(bio, inbuf, 4096); p7 = d2i_PKCS7(NULL, ptr, inlen); I hope this will help. -- Mounir IDRASSI IDRIX http://www.idrix.fr On 4/3/2010 3:06 AM, sean wang wrote: Hello, I have a pkcs7 encoded cert which i want to load. the following code block works fine: ( I am doing a base64 decoding first, will explain the reason in the second half): BIO *bio, *b64; PKCS7 * p7; b64 = BIO_new(BIO_f_base64()); BIO_set_flags(b64, BIO_FLAGS_BASE64_NO_NL); bio=BIO_new_mem_buf(a, -1); bio_out= BIO_new_fp(stderr, BIO_NOCLOSE); bio = BIO_push(b64, bio); p7 = d2i_PKCS7_bio(bio, NULL); However, for some interface reasons, I need to pass pass in a base64 decoded blob to a legacy function, so i tried the following code: BIO *bio, *b64, *bio_out; char inbuf[4096]; int inlen = strlen(a); b64 = BIO_new(BIO_f_base64()); BIO_set_flags(b64, BIO_FLAGS_BASE64_NO_NL); bio=BIO_new_mem_buf(a, -1); bio_out= BIO_new_fp(stderr, BIO_NOCLOSE); bio = BIO_push(b64, bio); while((inlen=BIO_read(bio, inbuf, 4096))0) BIO_write(bio_out, inbuf, inlen); p7 = d2i_PKCS7(NULL,inbuf, inlen); now this code fails with a segment fault. So my question is, if i really need to get the based64 decoded blob of a pkcs 7 cert, what is the right way? (because the first code worked, I assume the base64 decoding worked fine, but I can't pull the data out of 'bio' variable, appears there the data is still base64 encoded. how can i get the correct decoded blob?) test cert I used: char cert[] = MIIDCgYJKoZIhvcNAQcCoIIC+zCCAvcCAQExADALBgkqhkiG9w0BBwGgggLdMIIC\ 2TCCAkKgAwIBAgIJAILcTFTXHeLsMA0GCSqGSIb3DQEBBQUAMGcxCzAJBgNVBAYT\ AlVTMQswCQYDVQQIEwJXQTELMAkGA1UEChMCT00xCzAJBgNVBAsTAk9NMQ0wCwYD\ VQQDEwRzZWFuMSIwIAYJKoZIhvcNAQkBFhNzd2FuZzU0QGhvdG1haWwuY29tMB4X\ DTEwMDMyMjIxMTkzN1oXDTExMDMyMjIxMTkzN1oweTELMAkGA1UEBhMCVVMxCzAJ\ BgNVBAgTAldBMRAwDgYDVQQHEwdyZWRtb25kMQswCQYDVQQKEwJPTTELMAkGA1UE\ CxMCT00xDTALBgNVBAMTBHNlYW4xIjAgBgkqhkiG9w0BCQEWE3N3YW5nNTRAaG90\ bWFpbC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALKS/aKF9VjvokJZ\ dW4xkuqYFaRnNSYHNnmi4pIvbvf26QMnj9SerMw/c53LJTre1uQ/t1iAARY1LX4D\ wUCAijg/RN6zuW5NBcnJpgIYL6ZHciaL2qiDWIb6aoKy5hh0fb7psPI2n4/VO7pq\ 9fhjsiCosJvEUehezhEOWkCDEyw7AgMBAAGjezB5MAkGA1UdEwQCMAAwLAYJYIZI\ AYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1UdDgQW\ BBScenB4QwEq0x5n/oSRa8CuW+TifzAfBgNVHSMEGDAWgBSEddm7LRw5ylO1uAkY\ ZPvI6WnNqjANBgkqhkiG9w0BAQUFAAOBgQCmxtc5DV9wA8U3GW8ZVy5wO9Kzmhpz\ aRMLsKXjmgR5T0x9AQnf3W4Y5JmHtpXeOpvYEUiKiLOb/aNya+Km3S/7LJv8ufjn\ kHIiE6bsus/3NgAkLLmdodfJXFve/1viBzibwDZm4FyTHFjEnsFL57eAH+w0ZGna\ OUP4KRvWhjC/AKEAMQA=; _ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendarocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
