a handful of performance related patches
I am writing to advertise three performance related openssl patches: handshake_cutthrough.patch Enables SSL3+ clients to send application data immediately following the Finished message even when negotiating full-handshakes. With this patch, clients can negotiate SSL connections in 1-RTT even when performing full-handshakes. rsaasync.patch Enable RSA private decrypt operations to be non-blocking, thus allowing RSA private decrypt operations to be carried out in other threads or processes. small_records.patch Reduce OpenSSL memory consumption. SSL records may be as large as 16K, but are typically 2K. In addition, a historic bug in Windows allowed records to be as large 32K. OpenSSL statically allocates read and write buffers (34K and 18K respectively) used for processing records. With this patch, OpenSSL statically allocates 4K + 4K buffers, with the option of dynamically growing buffers to 34K + 4K, which is a saving of 44K per connection for the typical case. The patches are available here: http://bazaar.launchpad.net/~nagendra/openssl-patches/trunk/files __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS OpenSSL0.9.8a, assertion with mutual auth.
He told me that this patch must be in the upstream openssl cvs. Why is this patch not an official release or directly applied to the cvs? Manuel, you're right. This patch missed the last release. I'm in the process of submitting some patches to openssl-cvs and will include this patch. I'll send mail once the patches have been accepted, most likely within the following week. nagendra __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[PATCH] bug in crypto/pqueue/pqueue.c
diff -u -r1.5 pqueue.c --- crypto/pqueue/pqueue.c 7 Jun 2005 22:21:14 - 1.5 +++ crypto/pqueue/pqueue.c 20 Dec 2005 01:48:27 - @@ -184,7 +184,7 @@ } /* check the one last node */ - if ( memcpy(next-priority, prio64be,8) ==0) + if ( memcmp(next-priority, prio64be,8) ==0) found = next; if ( ! found) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
inconsistent behaviour on openssl ciphers
With OpenSSL 0.9.8a: $ openssl version OpenSSL 0.9.8a 11 Oct 2005 $ openssl ciphers 'RSA+DSS+AES+3DES+SHA1' Error in cipher list 15676:error:144020B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl_lib.c:1176: With OpenSSL 0.9.7d: $ openssl version OpenSSL 0.9.7d 17 Mar 2004 $ openssl ciphers 'RSA+DSS+AES+3DES+SHA1' AES256-SHA:AES128-SHA:DES-CBC3-SHA Did the cipherspec format change between 0.9.7 and 0.9.8? Thanks, nagendra __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1105] DTLS HelloVerifyRequest PATCH
It turns out that the Version field was omitted from the
HelloVerify message in the internet draft. The document
will be corrected.
nagendra
* nagendra modadugu [EMAIL PROTECTED] [2005-06-08 17:09:40 -0700]:
I think you might have found a bug in the draft document. I'll get back
to you soon. Thanks,
nagendra
* Tigran Gevorgyan via RT [EMAIL PROTECTED] [2005-06-08 22:00:58 +0200]:
Hello,
I apologize if this message appears multiple times.
This is a proposed patch for openssl-0.9.8-beta for all platforms.
I tested it with openssl-0.9.8beta2 however I think it is applicable to
all openssl-0.9.8 trees.
I think the current implementation of DTLS is not compliant with the
draft. According to
http://www.ietf.org/internet-drafts/draft-rescorla-dtls-04.txt Section
4.3 the HelloVerifyRequest is defined like this:
struct {
Cookie cookie0..32;
} HelloVerifyRequest;
The 0.9.8-beta2 implementation has two additional octets which specify
the protocol version. Is this according to a newer version of the DTLS
draft or is it an error?
Attached is a patch that removes the code that parses and generates this
additional octets.
Thanks
Tigran Gevorgyan
This e-mail message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.
Thank you.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl/ FAQ
Apologies for the delayed joining of the discussion. I chose to use BN to implement 64-bit numbers because (1) it was little code, (2) the abstraction was clean, (3) BN works on all supported platforms, (4) the places where emulated 64-bit numbers are used are not performance critical, and (5) no changes were required outside of pqueue and DTLS code. appro 1. I'm reluctant to include bn.h to non-bn code, because it's appronothing but counterintuitive [and is not good in long run]. appro 2. My standpoint is [still] that pqueue/dtls1 should not have approdependancy on bh.h either. I don't quite follow this point. Is it that pqueue is not self-contained? (There are already a number of cross-dependancies in libcrypto, including on bn.h) appro 3. Using BIGNUM for DTLS purposes is *total* overkill. To back approthis up I'm going to suggest alternative, 64-bit neutral pq approcode shortly:-) That works for me. Though, I'll add that neither pqueue nor DTLS do anything heavy with PQ_64BIT--the performance gain for the few platforms that do need the specialized code will be minimal. nagendra __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1105] DTLS HelloVerifyRequest PATCH
I think you might have found a bug in the draft document. I'll get back
to you soon. Thanks,
nagendra
* Tigran Gevorgyan via RT [EMAIL PROTECTED] [2005-06-08 22:00:58 +0200]:
Hello,
I apologize if this message appears multiple times.
This is a proposed patch for openssl-0.9.8-beta for all platforms.
I tested it with openssl-0.9.8beta2 however I think it is applicable to
all openssl-0.9.8 trees.
I think the current implementation of DTLS is not compliant with the
draft. According to
http://www.ietf.org/internet-drafts/draft-rescorla-dtls-04.txt Section
4.3 the HelloVerifyRequest is defined like this:
struct {
Cookie cookie0..32;
} HelloVerifyRequest;
The 0.9.8-beta2 implementation has two additional octets which specify
the protocol version. Is this according to a newer version of the DTLS
draft or is it an error?
Attached is a patch that removes the code that parses and generates this
additional octets.
Thanks
Tigran Gevorgyan
This e-mail message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient, please contact the sender
by reply e-mail and destroy all copies of the original message. Thank you.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: DTLS OpenSsl9.7g, assertion with mutual auth.
I was able to replicate the bug and have attached an
incremental patch--mutual auth should work now. Let me know
how it goes. Thanks,
nagendra
* Prashant Kumar [EMAIL PROTECTED] [2005-05-09 14:03:21 -0700]:
Hello Nagendra,
I tried your DTLS patch with Openssl9.7g on a vxworks platform. Everything
works except mutual certificate authentication. When I enable mutual
certificate authentication, DTLS fails with the following assertion:
d1_both.c(1054): OpenSSL internal error, assertion failed:
s-d1-w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH == s-init_num
I tried the same thing on a Linux platform and got the same error.
Here is the debug info for the lengths:
s-init_num = 19
w_msg_hdr.msg_len = 393
Thank you so much for your help.
Regards,
Prashant.
Prashant Kumar [EMAIL PROTECTED] wrote:Hello Nagendra,
I had one question on the timer management and retransmission. I see that
there is a new BIO type in the file bss_dgram.c. My question is if the
application does not use the dgram BIO type and use the memory BIO instead,
does the application has to take the responsibility of timer management and
retransmission ?
Thanks you,
Prashant Kumar.
nagendra modadugu [EMAIL PROTECTED] wrote:
Datagram TLS (DTLS) source is now part of the OpenSSL
repository (CVS main branch). Also, I have seperately released
patches against openssl-0.9.7g.
This is the link to the main DTLS page (including links
to further information about the protocol, and patches):
http://crypto.stanford.edu/~nagendra/projects/dtls/
I am in the process of putting together an FAQ, so any
questions/comments you may have will be much appreciated.
Thanks,
nagendra
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.c om
-
Yahoo! Mail
Stay connected, organized, and protected. Take the tour
--- openssl-0.9.7g/ssl/d1_srvr.c2005-05-10 00:32:27.0 -0700
+++ openssl-0.9.7g-bugfixing/ssl/d1_srvr.c 2005-05-10 00:27:21.0
-0700
@@ -1018,6 +1018,7 @@
STACK_OF(X509_NAME) *sk=NULL;
X509_NAME *name;
BUF_MEM *buf;
+ unsigned int msg_len;
if (s-state == SSL3_ST_SW_CERT_REQ_A)
{
@@ -1094,7 +1095,10 @@
s-init_num += 4;
#endif
- /* XDTLS: set message header ? */
+ msg_len = s-init_num - DTLS1_HM_HEADER_LENGTH;
+ dtls1_set_message_header(s, s-init_buf-data,
+ SSL3_MT_CERTIFICATE_REQUEST, msg_len, 0, msg_len);
+
/* buffer the message to handle re-xmits */
dtls1_buffer_message(s, 0);
Re: pqueue needs some rethinking...
Ah, I see. The reason pqueue uses 64-bit integers as the priority type is that record sequence numbers are 64-bits. I can easily change the code to make use of a pair of 32-bit integers (given that this really isn't performance critical code). nagendra * Richard Levitte - VMS Whacker [EMAIL PROTECTED] [2005-04-30 15:16:26 +0200]: Hi, We need to rethink pqueue a little bit. The trouble with it right now is that it uses BN_ULLONG in the published API. Unfortunately, BN_ULLONG doesn't work on all platforms we (pretend to?) support. In the BIGNUM code, all uses of BN_LLONG and BN_ULLONG are wrapped in a check for BN_LLONG. This macro is undefined on VMS (see the beginning of bn.h) for a very good reason; On VMS for VAX, there is no (or has not been until very recently) 64-bit integer type that's easily reachable from C (see http://h71000.www7.hp.com/commercial/c/docs/6180p006.html#integral_types_sec). This is actually rather silly, since the VAX does have the quad type, but apparently that was nothing for C... Anyway, this means that pqueue very simply breaks on VMS for VAX, because the definition of BN_ULLONG becomes 'unsigned long long', which isn't a supported type. I know next to nothing about DTLS, so I'm not sure if the priority field really has to be such a large number. Can it be easily changed? Either way, this will be a show stopper for the upcoming release of OpenSSL 0.9.8 (see http://www.oenssl.org/news/state.html). Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Datagram TLS source
* Prashant Kumar [EMAIL PROTECTED] [2005-04-28 06:11:38 -0700]: I had one question on the timer management and retransmission. I see that there is a new BIO type in the file bss_dgram.c. My question is if the application does not use the dgram BIO type and use the memory BIO instead, does the application has to take the responsibility of timer management and retransmission ? If you are using a memory BIO for doing I/O, then you are also using DTLS in non-blocking mode -- in this case, the application is responsible for managing timeouts. When a timer expires, the application calls SSL_read() / SSL_write(), and the DTLS layer will take care of retransmitting. You may want to look at resiprocate/sip/resiprocate/DtlsTransport.cxx for an implementation of something very similar to the scenario you describe. On a high level, reSIProcate does the following: 1) many DTLS sessions use the same file descriptor for network I/O. 2) after data is read from the network, data is passed to the appropriate DTLS session (based on remote IP address port number) through a mem BIO. nagendra __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Datagram TLS source
Datagram TLS (DTLS) source is now part of the OpenSSL repository (CVS main branch). Also, I have seperately released patches against openssl-0.9.7g. This is the link to the main DTLS page (including links to further information about the protocol, and patches): http://crypto.stanford.edu/~nagendra/projects/dtls/ I am in the process of putting together an FAQ, so any questions/comments you may have will be much appreciated. Thanks, nagendra __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: rsync://dev.openssl.org busy?
Please try again now. It should be available again. Thanks for looking into it, works now. nagendra __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
rsync://dev.openssl.org busy?
I've been trying to access the OpenSSL CVS repository for the past couple of days (including odd hours), with no success: $ rsync rsync://dev.openssl.org/openssl-cvs @ERROR: max connections (20) reached - try again later rsync: connection unexpectedly closed (0 bytes received so far) [receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(359) Any thoughts? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
rsync://dev.openssl.org unavailable?
Is rsync access to the OpenSSL repository unavailable? $ rsync://dev.openssl.org/ rsync: failed to connect to dev.openssl.org: Connection refused rsync error: error in socket IO (code 10) at /SourceCache/rsync/rsync-14/rsync/clientserver.c(93) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
minor bug in ssl3_send_client_verify()
In function ssl3_send_client_verify(), the state is never switched to SSL3_ST_CW_CERT_VRFY_B after the handshake message is serialized. It's a fairly minor bug: *(d++)=SSL3_MT_CERTIFICATE_VERIFY; l2n3(n,d); s-init_num=(int)n+4; s-init_off=0; s-state=SSL3_ST_CW_CERT_VRFY_B; } return(ssl3_do_write(s,SSL3_RT_HANDSHAKE)); err: return(-1); } __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
minor bug in ssl3_send_certificate_request()
In function ssl3_send_certificate_request(), the state is never switched to SSL3_ST_SW_CERT_REQ_B after the handshake message is serialized. It's a fairly minor bug, with a simple fix: #ifdef NETSCAPE_HANG_BUG p=(unsigned char *)s-init_buf-data + s-init_num; /* do the header */ *(p++)=SSL3_MT_SERVER_DONE; *(p++)=0; *(p++)=0; *(p++)=0; s-init_num += 4; #endif s-state = SSL3_ST_SW_CERT_REQ_B; } /* SSL3_ST_SW_CERT_REQ_B */ return(ssl3_do_write(s,SSL3_RT_HANDSHAKE)); err: return(-1); } __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: How to port for Palm
Ian Goldberg did some work as part of TopGun (this is a rather outdated port though): http://www.isaac.cs.berkeley.edu/pilot/ Also, Palm OS 5.0 is supposed to ship with an SSL library. nagendra * mohanraj venkatesh kumar [EMAIL PROTECTED] [2002-11-27 16:27:54 +]: Dear Sir, Iam trying to port OpenSSL to Palm. Iam trying to develop a client side application that would use SSL. Could someone please guide me as what are the common files that I would need to take as-is and what are the files that need to be ported for a particular OS(Palm OS). Thanks in advance. Venkatesh _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
info regarding SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER
I've looked around the web and openssl-dev archives, but am unable to find information about SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER and the related Microsoft bug that results in jumbo SSL records. Does anyone have pointers / information about this bug ? Thanks. nagendra -=-=-=-=-=-=-=-=-=-=-=-= Nagendra Modadugu nagendra @ cs.stanford.edu __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
bug in ssl3_get_key_exchange
SSLv3 clients call ssl3_get_key_exchange regardless of whether this message is required for the chosen cipher. As a result, ssl3_get_message called from ssl3_get_key_exchange ends up reading the certificate request message (when doing client auth and the key exchange message is absent): n=ssl3_get_message(s, SSL3_ST_CR_KEY_EXCH_A, SSL3_ST_CR_KEY_EXCH_B, -1, 1024*8, /* ?? */ ok); This results in a limit of 8K for the certificate request list, whereas the limit should be 100K. This bug manifests itself when using s_client to connect to apache-modssl. Apache sends all the CA's listed in ca-bundle.crt, which exceeds the 8K limit and causes the client to barf: 28537:error:1408E098:SSL routines:SSL3_GET_MESSAGE:excessive message size:s3_both.c:418: Nagendra Modadugu [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: iis certificate renewal woes
I've appended the PKCS#7 request generated by IIS to the end of this email. IIS creates the header "BEGIN NEW CERTIFICATE REQUEST", which is interpreted as an old X509 request (see pem.h). Changing the header to "BEGIN PKCS7" makes things work. It's not obvious what the solution should be since there is a name collision here. Does anyone use the old X509 req format? If it is not used, then the header file can be updated to map PKCS7 to the iis generated header. On Sat, 30 Sep 2000, Dr S N Henson wrote: nagendra wrote: Hi, We're generating a CSR on IIS (win2k). When a certificate is already installed on IIS, it generates a PKCS#7 certificate renewal request rather than a PKCS#10 CSR. Furthermore the PEM header in the request is an invalid PKCS#7 header. As a result none of the openssl utilities can parse the request. Does anyone know why IIS generates a PKCS#7 request rather than PKCS#10? At any rate, openssl should know how to parse PKCS#7 requests created by IIS. Can anyone shed some light on the problem? Thanks, What's in the PKCS#7 header? If you just get a complaint of no start line then you can try editing the header and footer and see if OpenSSL will tolerate it then. If you get an ASN1 error of some sort then please send me the file and I'll see if I can see what the problem is. Steve. -BEGIN NEW CERTIFICATE REQUEST- MIIOVQYJKoZIhvcNAQcCoIIORjCCDkICAQExCzAJBgUrDgMCGgUAMIIHZQYJKoZI hvcNAQcBoIIHVgSCB1IwggdOMIIGtwIBADCBgjESMBAGA1UEAxMJcHVibGlzaGVy MRkwFwYDVQQLExBTdWN0aW9uIFNlcnZpY2VzMRgwFgYDVQQKEw9NaWNyb3NvZnQg Q29ycC4xFTATBgNVBAcTDFJlZHdvb2QgQ2l0eTETMBEGA1UECBMKQ2FsaWZvcm5p YTELMAkGA1UEBhMCVVMwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMxYnDYe LZen72tLXktOb9pzdIB5o7WM+2eUVAMUjRhvKYMHKppQDoiQs6mdyIHAiXRsaH1x fQOO2ybnJ4eWEdE4mDixUmFgTjAjkxtNolRWDGIqzNnhl6l41FeYdOP4b4qUQhL9 +GF2xXsouRfvUel3OsPoVA5ybMGywgPVmMkxAgMBAAGgggWJMBoGCisGAQQBgjcN AgMxDBYKNS4wLjIxOTUuMjA1BgorBgEEAYI3AgEOMScwJTAOBgNVHQ8BAf8EBAMC BPAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwgf0GCisGAQQBgjcNAgIxge4wgesCAQEe WgBNAGkAYwByAG8AcwBvAGYAdAAgAFIAUwBBACAAUwBDAGgAYQBuAG4AZQBsACAA QwByAHkAcAB0AG8AZwByAGEAcABoAGkAYwAgAFAAcgBvAHYAaQBkAGUAcgOBiQAg dwtIPabCtPlfjfzHtSbBt/b6Jwj0AXTsDaesxyUjwlNxcENEoBaREDcuhxJ+/SNA jK1Pd6vR4dU0LXdmFOpVh0Lp16yHMrZgBVY4YmzV+g6dXuNVo3NjeIpScstRhbLO vOnHWbdhj+stOCO+Pzr5Ftln/Z3s1KzKxEjNjz+AdQAAMIIEMgYJKwYB BAGCNw0BMYIEIzCCBB8wggN4oAMCAQICAQMwDQYJKoZIhvcNAQEEBQAwcjELMAkG A1UEBhMCVVMxDTALBgNVBAgTBHRlc3QxDTALBgNVBAcTBHRlc3QxDTALBgNVBAoT BHRlc3QxDTALBgNVBAsTBHRlc3QxDTALBgNVBAMTBHRlc3QxGDAWBgkqhkiG9w0B CQEWCXRlc3RAdGVzdDAeFw0wMDA5MjkxMDA0MzRaFw0wMTA5MzAxMDA0MzRaMIGC MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEVMBMGA1UEBxMMUmVk d29vZCBDaXR5MRgwFgYDVQQKEw9NaWNyb3NvZnQgQ29ycC4xGTAXBgNVBAsTEFN1 Y3Rpb24gU2VydmljZXMxEjAQBgNVBAMTCXB1Ymxpc2hlcjCCAiIwDQYJKoZIhvcN AQEBBQADggIPADCCAgoCggIBANjsTUm7uaHGwQ9nOHU3e8432PvrGUl0N4VHBf11 v299rM3pej1wVj0PeiJHK6cm96dTkIe6hs8Xma0bYLnsmpcbAtJXEoTnRCUw6t/3 TLs9UknyLy4VM5d6EnXXuaZJuV9yNRDQ1cyAYGs4uP7Si571cD/eW7a748hBq7Ql CmOpvOsVaAlDQdzWJpUeI6fBz1Oz5PO7DDHwypWkMoNLcmB4Ad4xfSZnK8SWZ+/j ppEk8TDerUJuFyTjvcOKLV02qznQrQg6yrLfcV+8vNHW7rYrf/6gGYnki1WhnLe+ sWWZvlteXFrN6C+aANmt1RY3tdnkaq0QglcL2N1V3HyxKKv8wiV1Z34LLOSD6jSY eL6VMgJYECADlsXH457bY9hmDhWqhV2bqkGzXYiBaHhHHx/xPWGjnDhIm/LTDwFL Slr3pk+NcuuP6fZghcel3KOnlpbC8HUccB3BPKFgURKfc3AAkx6yVU4JOO7OIkw7 34FqYK2HuKrPWCYYwC3Crc10AjTg4XS6070lNGy8zrd2FM18ApydlV8FSRkANKKq Iuk93p09aOvLlCbNBrEsMy9534vu/aYAxBSkYtwyhMv3l7AsA1uYhj6sCf5DWXQY hWHXFXFrOdt+pQa4dHUOuDk3IC5rE/LKwBp5ypdXYancLHheOBKYnjl509/rvvIW MhVFAgMBAAGjIDAeMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgZAMA0GCSqG SIb3DQEBBAUAA4GRAITv75waRGvTveeyRBJaGPqsxnAoyCm24+atQajmB+IIRsuU bTLl1MPP3g/yaXmZw5B6YE5vJhk05b51NS0Hbhj1Wk9HuWmKuABu1xuU7vU2CNA2 3ARK728gGEEfXtjPtdlhPWJu9LB+zJszlbV3q5bLtQPq9ajPfc/CTTsFC1xNtRs9 FEChzQgN9tSOQ1eY1TANBgkqhkiG9w0BAQUFAAOBgQBziGhKvIveQQMkUpvYFrqC 7WDX/MXj8okAKV8Ai94nJ1kqLzNGxIjJIWA+oRBSMys9QFKbRP0YRQkmtgIZ9X72 bDIKTyMst1EK1nS4VHvXItq9gJRB/j2rLCh2+MoOWf0ECTanem9DeHJ6Q+7IALpq XyOStTK0OoroVDCfAF3H7aCCBCMwggQfMIIDeKADAgECAgEDMA0GCSqGSIb3DQEB BAUAMHIxCzAJBgNVBAYTAlVTMQ0wCwYDVQQIEwR0ZXN0MQ0wCwYDVQQHEwR0ZXN0 MQ0wCwYDVQQKEwR0ZXN0MQ0wCwYDVQQLEwR0ZXN0MQ0wCwYDVQQDEwR0ZXN0MRgw FgYJKoZIhvcNAQkBFgl0ZXN0QHRlc3QwHhcNMDAwOTI5MTAwNDM0WhcNMDEwOTMw MTAwNDM0WjCBgjELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFTAT BgNVBAcTDFJlZHdvb2QgQ2l0eTEYMBYGA1UEChMPTWljcm9zb2Z0IENvcnAuMRkw FwYDVQQLExBTdWN0aW9uIFNlcnZpY2VzMRIwEAYDVQQDEwlwdWJsaXNoZXIwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDY7E1Ju7mhxsEPZzh1N3vON9j7 6xlJdDeFRwX9db9vfazN6Xo9cFY9D3oiRyunJvenU5CHuobPF5mtG2C57JqXGwLS VxKE50QlMOrf90y7PVJJ8i8uFTOXehJ117mmSblfcjUQ0NXMgGBrOLj+0oue9XA/ 3lu2u+PIQau0JQpjqbzrFWgJQ0Hc1iaVHiOnwc9Ts+Tzuwwx8MqVpDKDS3JgeAHe MX0mZyvElmfv46aRJPEw3q1Cbhck473Dii1dNqs50K0IOsqy33FfvLzR1u62K3/+ oBmJ5ItVoZy3vrFlmb5bXlxazegvmgDZrdUWN7XZ5GqtEIJXC9jdVdx8sSir/MIl dWd+Cyzkg+o0mHi+lTICWBAgA5bFx+Oe22PYZg4VqoVdm6pBs12IgWh4Rx8f8T1h o5w4SJvy0w8BS0pa96ZPjXLrj+n2YIXHpdyjp5aWwvB1
iis certificate renewal woes
Hi, We're generating a CSR on IIS (win2k). When a certificate is already installed on IIS, it generates a PKCS#7 certificate renewal request rather than a PKCS#10 CSR. Furthermore the PEM header in the request is an invalid PKCS#7 header. As a result none of the openssl utilities can parse the request. Does anyone know why IIS generates a PKCS#7 request rather than PKCS#10? At any rate, openssl should know how to parse PKCS#7 requests created by IIS. Can anyone shed some light on the problem? Thanks, Nagendra __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
EVP_EncryptFinal, EVP_DecryptFinal
As the code is, EVP_EncryptFinal and EVP_DecryptFinal, do not reset ctx-buf_len to 0 once done (there is an internal buffer to EVP_CIPHER_CTX, that is used to hold on to trailing bytes that do not complete a block). This means that encrypting two sets of data with the same CTX will require EVP_(Encrypt|Decrypt)Init to be called in between. This is wasteful, so I have modified EVP_EncryptFinal and EVP_DecryptFinal to reset the value of ctx-buf_len to zero. Nagendra diff -urN openssl-0.9.5a/crypto/evp/evp_enc.c openssl-0.9.5a-work/crypto/evp/evp_enc.c --- openssl-0.9.5a/crypto/evp/evp_enc.c Fri Apr 23 15:10:20 1999 +++ openssl-0.9.5a-work/crypto/evp/evp_enc.cThu Jul 20 09:41:05 2000 @@ -173,6 +173,7 @@ ctx-buf[i]=n; ctx-cipher-do_cipher(ctx,out,ctx-buf,b); *outl=b; + ctx-buf_len=0; } void EVP_DecryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl, @@ -255,6 +256,7 @@ for (i=0; in; i++) out[i]=ctx-buf[i]; *outl=n; + ctx-buf_len=0; } else *outl=0;
[PATCH]: session_cache_mode
This is a patch to openssl-0.9.5a that makes sure that the
session_cache_mode is used to determine whether a session is resumed or
renegotiated. Previously clients always attempted a session resume if the
session id was non NULL.
So now SSL_CTX_new sets the cache mode to client or server depending on
whether the method is client or server. Also client_hello from s2_clnt.c
and s3_clnt hello only attempt a session resume if the
SSL_SESS_CACHE_CLIENT is set.
nagendra
diff -urN openssl-0.9.5a/ssl/s2_clnt.c openssl-0.9.5a-work/ssl/s2_clnt.c
--- openssl-0.9.5a/ssl/s2_clnt.cThu Feb 3 15:23:22 2000
+++ openssl-0.9.5a-work/ssl/s2_clnt.c Tue Jun 20 18:07:57 2000
@@ -473,7 +473,8 @@
if (s-state == SSL2_ST_SEND_CLIENT_HELLO_A)
{
if ((s-session == NULL) ||
- (s-session-ssl_version != s-version))
+ (s-session-ssl_version != s-version) ||
+ !(s-ctx-session_cache_mode SSL_SESS_CACHE_CLIENT))
{
if (!ssl_get_new_session(s,0))
{
diff -urN openssl-0.9.5a/ssl/s3_clnt.c openssl-0.9.5a-work/ssl/s3_clnt.c
--- openssl-0.9.5a/ssl/s3_clnt.cMon Mar 27 13:28:27 2000
+++ openssl-0.9.5a-work/ssl/s3_clnt.c Tue Jun 20 16:49:52 2000
@@ -456,7 +456,8 @@
{
if ((s-session == NULL) ||
(s-session-ssl_version != s-version) ||
- (s-session-not_resumable))
+ (s-session-not_resumable) ||
+ !(s-ctx-session_cache_mode SSL_SESS_CACHE_CLIENT))
{
if (!ssl_get_new_session(s,0))
goto err;
diff -urN openssl-0.9.5a/ssl/ssl_lib.c openssl-0.9.5a-work/ssl/ssl_lib.c
--- openssl-0.9.5a/ssl/ssl_lib.cMon Mar 27 13:28:28 2000
+++ openssl-0.9.5a-work/ssl/ssl_lib.c Tue Jun 20 16:53:22 2000
@@ -1108,7 +1108,12 @@
ret-method=meth;
ret-cert_store=NULL;
- ret-session_cache_mode=SSL_SESS_CACHE_SERVER;
+
+ if(meth-ssl_accept == ssl_undefined_function)
+ ret-session_cache_mode=SSL_SESS_CACHE_CLIENT;
+ else
+ ret-session_cache_mode=SSL_SESS_CACHE_SERVER;
+
ret-session_cache_size=SSL_SESSION_CACHE_MAX_SIZE_DEFAULT;
ret-session_cache_head=NULL;
ret-session_cache_tail=NULL;
