SSL_renegotiate broken in non-blocking mode with PARTIAL_WRITE?
I have a server application which uses OpenSSL (0.9.9-current as of about four months ago) in nonblocking mode. As a test, I added an option to call SSL_renegotiate every 100 successful SSL_read or SSL_write calls. I am seeing very strange behavior and I wonder if SSL_renegotiate actually works in non-blocking mode. My application normally uses SSL_MODE_ENABLE_PARTIAL_WRITE to avoid pointless trips around its select loop (the application can generate 32K of data at a time, so without PARTIAL_WRITE, I end up selecting twice and calling SSL_write twice for every write, since it always rejects a write of 32K the first time). If I turn it off, the problem described below goes away. Essentially, I get SSL_ERROR_SSL back from an SSL_read() call which should have successfully finished the negotiation and returned 0 (because the client sends me one request and never generates more payload, while the server responds then closes the connection). The pattern is like this: 1) I have data to write, and the SSL session's descriptor selects as ready-to-write. 2) I call SSL_renegotiate. I do understand that in a server application this merely sends the client a request to do a new handshake, which the client can ignore. 3) I generate more data and several more SSL_writes() complete normally. 4) Eventualy the SSL session's file descriptor selects as ready-to-read. 5) I call SSL_read with a 4096-byte buffer. SSL_read returns -1 and error is SSL_ERROR_WANT_READ. 6) I set a flag to ensure I do not call SSL_write() (it isn't clear to me this is necessary -- the documentation is vague) and select on the SSL session's descriptor for read. 7) The SSL session's file descriptor selects as ready for read, I call SSL with the same 4096 byte buffer at the same address, and SSL_read returns -1 and error is SSL_ERROR_SSL. I cannot understand why #7 occurs. Is SSL_MODE_ENABLE_PARTIAL_WRITE just incompatible with non-blocking mode and renegotiations? Thor __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Can we expect debug version libraries of Openssl code to vs2005?
Hi Development Team, How can we get debug version libraries of Openssl code? VS2005 is giving follow linker error while compiling lib-curl code with openssl library files in debug mode. 1-- Build started: Project: curl-7.15.5, Configuration: Debug Win32 -- 1Linking... 1LIBCMT.lib(calloc.obj) : error LNK2005: _calloc already defined in LIBCMTD.lib(dbgheap.obj) 1LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library 1Debug\curl-7.15.5.exe : fatal error LNK1169: one or more multiply defined symbols found 1Build log was saved at file://f:\source\VS2005\Agent\thirdparty\Copy (2) of curl-7.15.5\Debug\BuildLog.htm 1curl-7.15.5 - 2 error(s), 1 warning(s) == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped == VS2005 is building lib-curl code successfully with openssl library files. However that executable failed to write (curl_write) in https – post method. Is there any issue to compile openssl lib with vs2005? Thanks, Satya. -- Confidentiality And Disclaimer Notice Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. ……www.netenrich.com -
Re: Can we expect debug version libraries of Openssl code to vs2005?
The pre-built OpenSSL library is provided by someone else. If you want to get debug libraries for OpenSSL, you can compile them yourself. Please see the FAQ, however; there are a couple of gotchas on Windows systems which need to be addressed within your environment during the compilation and test cycles. -Kyle H On Thu, May 21, 2009 at 5:54 AM, satyanarayana.va...@netenrich.com wrote: Hi Development Team, How can we get debug version libraries of Openssl code? VS2005 is giving follow linker error while compiling lib-curl code with openssl library files in debug mode. 1-- Build started: Project: curl-7.15.5, Configuration: Debug Win32 -- 1Linking... 1LIBCMT.lib(calloc.obj) : error LNK2005: _calloc already defined in LIBCMTD.lib(dbgheap.obj) 1LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library 1Debug\curl-7.15.5.exe : fatal error LNK1169: one or more multiply defined symbols found 1Build log was saved at file://f:\source\VS2005\Agent\thirdparty\Copy (2) of curl-7.15.5\Debug\BuildLog.htm 1curl-7.15.5 - 2 error(s), 1 warning(s) == Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped == VS2005 is building lib-curl code successfully with openssl library files. However that executable failed to write (curl_write) in https – post method. Is there any issue to compile openssl lib with vs2005? Thanks, Satya. -- Confidentiality And Disclaimer Notice Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. ……www.netenrich.com - __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_renegotiate broken in non-blocking mode with PARTIAL_WRITE?
Replies below v Thor Lancelot Simon wrote: The pattern is like this: 1) I have data to write, and the SSL session's descriptor selects as ready-to-write. 2) I call SSL_renegotiate. I do understand that in a server application this merely sends the client a request to do a new handshake, which the client can ignore. 3) I generate more data and several more SSL_writes() complete normally. 4) Eventualy the SSL session's file descriptor selects as ready-to-read. 5) I call SSL_read with a 4096-byte buffer. SSL_read returns -1 and error is SSL_ERROR_WANT_READ. 6) I set a flag to ensure I do not call SSL_write() (it isn't clear to me this is necessary -- the documentation is vague) and select on the SSL session's descriptor for read. It should not be, the OpenSSL API should gracefully handle a SSL_write() it doesn't want just yet. 7) The SSL session's file descriptor selects as ready for read, I call SSL with the same 4096 byte buffer at the same address, and SSL_read returns -1 and error is SSL_ERROR_SSL. SSL_ERROR_SSL as I'm sure you know is for a protocol level error this should never happen (no matter how hard you attempt abuse the application level APIs). Presumptions aside (such as both ends support and can agree on exactly which encryption/MAC and other things they will both use). It should only report this problem when the other end violates the protocol specification. Since both ends are OpenSSL this there is a bug somewhere in OpenSSL. I cannot understand why #7 occurs. Is SSL_MODE_ENABLE_PARTIAL_WRITE just incompatible with non-blocking mode and renegotiations? It is possible it relies on the behavior as if SSL_MODE_ENABLE_PARTIAL_WRITE was not set. SSL_MODE_ENABLE_PARTIAL_WRITE was probably added as an after thought to the behavior without. Do you have a minimal testcase application that can be started up as either the A or B end and with and without the PARTIAL_WRITE options in use. Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
X.509 certificates with RSASSA-PSS signatures
Dear all,
I'm working on support for X.509 certificates with RSASSA-PSS signatures
according to PKCS1 #2.1 and RFC 4055. As I would like to come up with
something that can be included in the main tree, I'm sending this
mail to ask for your advice and to make sure I'm heading in the right
direction.
My first step is to support verification of X.509 certificates with a
PSS signature that uses the default PSS parameters.
Low-level routines for PSS signatures have been present for a long time.
The signature type (PKCS1.5 or PSS) can be set for an EVP_PKEY_CTX
object.
X.509 signature verification is based on EVP_MD_CTX.
EVP_VerifyInit_ex(), EVP_VerifyUpdate() and EVP_VerifyFinal() are called
on the EVP_MD_CTX.
EVP_VerifyFinal() uses a local EVP_PKEY_CTX object that is configured
according to the EVP_MD_CTX' flags.
I thought of different approaches
- add a new flag similar to EVP_MD_FLAG_PKEY_METHOD_SIGNATURE
This would require a new sha1_md which in turn would require a new
NID_sha1Pss (or so) to have a unique match in obj_xref.txt
- looks like this will end up in a mess
- base the signature verification on EVP_PKEY_CTX rather than EVP_MD_CTX
- I understand that EVP_VerifyInit/Update/Final() is the most
abstract API for this and should be used for X.509 signature
verification
- therefore, my proposal is to use the pctx field of EVP_MD_CTX to set
up the PSS-related parameters in ASN1_item_verify(). EVP_VerifyFinal()
is changed to set up the local EVP_PKEY_CTX only if the EVP_MD_CTX' pctx
field is unset.
I attach a simple patch against 1.0.0-beta2 that outlines the basic
idea. It is far from ready (e.g. PSS parameters are not checked) but it
should be sufficient for discussing the approach.
I would very much appreciate your comments.
Best regards,
Martin
diff --git a/crypto/asn1/a_verify.c b/crypto/asn1/a_verify.c
index cecdb13..9094937 100644
--- a/crypto/asn1/a_verify.c
+++ b/crypto/asn1/a_verify.c
@@ -72,6 +72,7 @@
#include openssl/buffer.h
#include openssl/evp.h
+
#ifndef NO_ASN1_OLD
int ASN1_verify(i2d_of_void *i2d, X509_ALGOR *a, ASN1_BIT_STRING *signature,
@@ -150,6 +151,17 @@ int ASN1_item_verify(const ASN1_ITEM *it, X509_ALGOR *a, ASN1_BIT_STRING *signat
ASN1err(ASN1_F_ASN1_ITEM_VERIFY,ASN1_R_UNKNOWN_MESSAGE_DIGEST_ALGORITHM);
goto err;
}
+ if (OBJ_obj2nid(a-algorithm) == NID_rsaSsaPss)
+ {
+ if ((ctx.pctx = EVP_PKEY_CTX_new(pkey, NULL)) == NULL)
+ goto err;
+ if (EVP_PKEY_verify_init(ctx.pctx) = 0)
+ goto err;
+ if (EVP_PKEY_CTX_set_signature_md(ctx.pctx, ctx.digest) = 0)
+ goto err;
+ if (EVP_PKEY_CTX_set_rsa_padding(ctx.pctx, RSA_PKCS1_PSS_PADDING) = 0)
+ goto err;
+ }
/* Check public key OID matches public key type */
if (EVP_PKEY_type(pknid) != pkey-ameth-pkey_id)
diff --git a/crypto/evp/p_verify.c b/crypto/evp/p_verify.c
index 8db4641..4e406e5 100644
--- a/crypto/evp/p_verify.c
+++ b/crypto/evp/p_verify.c
@@ -77,21 +77,30 @@ int EVP_VerifyFinal(EVP_MD_CTX *ctx, const unsigned char *sigbuf,
if (ctx-digest-flags EVP_MD_FLAG_PKEY_METHOD_SIGNATURE)
{
- EVP_PKEY_CTX *pkctx = NULL;
- i = -1;
- pkctx = EVP_PKEY_CTX_new(pkey, NULL);
- if (!pkctx)
- goto err;
- if (EVP_PKEY_verify_init(pkctx) = 0)
- goto err;
- if (EVP_PKEY_CTX_set_signature_md(pkctx, ctx-digest) = 0)
- goto err;
- i = EVP_PKEY_verify(pkctx, sigbuf, siglen, m, m_len);
- err:
- EVP_PKEY_CTX_free(pkctx);
- return i;
- }
-
+ if (!ctx-pctx)
+ {
+ EVP_PKEY_CTX *pkctx = NULL;
+ i = -1;
+ pkctx = EVP_PKEY_CTX_new(pkey, NULL);
+ if (!pkctx)
+goto err;
+ if (EVP_PKEY_verify_init(pkctx) = 0)
+goto err;
+ if (EVP_PKEY_CTX_set_signature_md(pkctx, ctx-digest) = 0)
+goto err;
+ i = EVP_PKEY_verify(pkctx, sigbuf, siglen, m, m_len);
+ err:
+ EVP_PKEY_CTX_free(pkctx);
+ return i;
+ }
+ else
+ {
+ /* pctx must have been prepared completely before calling
+ * EVP_VerifyFinal() */
+ i = EVP_PKEY_verify(ctx-pctx, sigbuf, siglen, m, m_len);
+ return i;
+ }
+ }
for (i=0; i4; i++)
{
v=ctx-digest-required_pkey_type[i];
diff --git a/crypto/objects/obj_xref.txt b/crypto/objects/obj_xref.txt
index e45b3d3..ef6f48f 100644
--- a/crypto/objects/obj_xref.txt
+++ b/crypto/objects/obj_xref.txt
@@ -6,6 +6,7 @@ md2WithRSAEncryption md2 rsaEncryption
md5WithRSAEncryption md5 rsaEncryption
shaWithRSAEncryption sha rsaEncryption
sha1WithRSAEncryption sha1 rsaEncryption
+rsaSsaPss sha1 rsaEncryption
md4WithRSAEncryption md4 rsaEncryption
sha256WithRSAEncryption sha256 rsaEncryption
sha384WithRSAEncryption sha384 rsaEncryption
diff --git a/crypto/objects/objects.txt b/crypto/objects/objects.txt
index 52ac0a6..82fa188 100644
--- a/crypto/objects/objects.txt
+++ b/crypto/objects/objects.txt
@@ -166,6 +166,8 @@ pkcs1 3 : RSA-MD4
Re: [openssl.org #1934] Enhancement request: openssl-0.9.8k Solaris CC flags
c^ via RT wrote: Hi all ./Configure solaris64-sparcv9-cc builtin provides the CFLAGS -xtarget=ultra -xarch=v9 This is deprecated in Sun Studio12 and warns a lot. Suggest: -xtarget=ultra2 -m64 -xarch=sparc The -m64 flag doesn't work with Sun Studio 10 compilers, so it will simply break in this case. I came to the same problem and the solution was to patch the Configure and replace those fixed directives with something like \$(CC_ARCH_FLAGS) and then use CC_ARCH_FLAGS=-m64 make ... for SunStudio11+ and CC_ARCH_FLAGS=-xtarget=ultra -xarch=v9 make ... for SunStudio10 The proper solution would be to check the CC version and set those flags accordingly. I somehow doubt this is wise thing to do, cause who knows what SunCC will break in the next release ;) Regards -- ^(TM) __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: SSL_renegotiate broken in non-blocking mode with PARTIAL_WRITE?
Thor Lancelot Simon wrote: 1) I have data to write, and the SSL session's descriptor selects as ready-to-write. This already scares me. You have data to write on the unencrypted stream to the SSL connection. The SSL session's descriptor write is for the encrypted stream between SSL implementations. Why would you check one when you want to write to the other? You should only be calling 'select' to see if a descriptor is ready-to-write if you know you need to write on that descriptor. Since SSL_write did not return 'WANT_WRITE', you had no way to know OpenSSL needed to write on the socket. 2) I call SSL_renegotiate. I do understand that in a server application this merely sends the client a request to do a new handshake, which the client can ignore. 3) I generate more data and several more SSL_writes() complete normally. 4) Eventualy the SSL session's file descriptor selects as ready-to-read. Did an SSL_read return WANT_READ? If not, why were you selecting on the file descriptor for read? What you are doing makes failure scenarios possible. Consider: 1) You call SSL_write. Since a renegotiation is in progress, it tries to read the data to complete the rengotiation. 2) It reads the renegotiation data, and some application data. It completes the write. 3) You select on the socket for 'read', but you don't get a hit because the data has already been read. So why were you waiting for the SSL session's file descriptor to select as ready-to-read? An SSL connection has *ONE* *STATE*. When SSL_write completes normally, its state is everything is fine. It's state is *NOT* want read, which seems to be what you were assuming. 5) I call SSL_read with a 4096-byte buffer. SSL_read returns -1 and error is SSL_ERROR_WANT_READ. So now you know that a read hit from select is needed (or other forward progress must be made) before SSL_read can succeed. 6) I set a flag to ensure I do not call SSL_write() (it isn't clear to me this is necessary -- the documentation is vague) and select on the SSL session's descriptor for read. Why would you avoid writing? It's possible the other side will not send any application data. 7) The SSL session's file descriptor selects as ready for read, I call SSL with the same 4096 byte buffer at the same address, and SSL_read returns -1 and error is SSL_ERROR_SSL. I cannot understand why #7 occurs. Is SSL_MODE_ENABLE_PARTIAL_WRITE just incompatible with non-blocking mode and renegotiations? Perhaps the other side gave up waiting for you and closed the connection down abruptly? What does the other side show when this happens? DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_renegotiate broken in non-blocking mode with PARTIAL_WRITE?
On Fri, May 22, 2009 at 03:14:46PM -0700, David Schwartz wrote: Thor Lancelot Simon wrote: 1) I have data to write, and the SSL session's descriptor selects as ready-to-write. This already scares me. You have data to write on the unencrypted stream to the SSL connection. The SSL session's descriptor write is for the encrypted stream between SSL implementations. Why would you check one when you want to write to the other? I'm sorry, what are you talking about? I have data to write on the SSL *. I'm not interested in doing two system calls for every logical write operation. If OpenSSL wants to tell me WANT_WRITE -- or WANT_READ -- after I issue an SSL_write(), it's certainly free to do that; but on what rational grounds ought I not issue an SSL_write() if I know the file descriptor underlying the SSL * is write-ready? What you are doing makes failure scenarios possible. Consider: 1) You call SSL_write. Since a renegotiation is in progress, it tries to read the data to complete the rengotiation. 2) It reads the renegotiation data, and some application data. It completes the write. 3) You select on the socket for 'read', but you don't get a hit because the data has already been read. My code will never select on the socket underlying the SSL * for read unless it has drained all data previously requested for that direction using SSL_read(). You seem to believe some kind of desynchronization is possible here which I am not seeing. So why were you waiting for the SSL session's file descriptor to select as ready-to-read? Because all data I ever actually requested via SSL_read() has been handed to me already by OpenSSL. If a renegotiation causes the socket to spuriously select as ready-for-read, the worst that can happen, as far as I can tell, is that I generate a call to SSL_read() which returns WANT_READ. What is the harm in this? An SSL connection has *ONE* *STATE*. When SSL_write completes normally, its state is everything is fine. It's state is *NOT* want read, which seems to be what you were assuming. I think you are jumping to conclusions. An SSL connection has two directions of data flow. Many applications which run OpenSSL in non-blocking mode appear to treat the entire SSL connection as half-duplex, but there is nothing about the SSL protocol itself which mandates half-duplex operation, and I can't see anything in the OpenSSL documentation which states that full-duplex operation is required. My application has two -- interlocking, necessarily, since there is global state of the SSL session -- state machines for interacting with OpenSSL, one for read and one for write. When SSL_read() or SSL_write() return WANT_X for some X, this is an event which forces synchronization of the state machines -- since, in the case in which X is the direction expected for normal operation, e.g. WANT_READ from a call to SSL_read() I can't tell whether that was caused by a normal I/O drain, or by a renegotation which will require pausing the other direction to complete (because of the very odd next call must be _exactly the same API function, with the same buffer and length rule of the API which is semi-documented in various manual pages). So I go to some lengths to avoid causing this kind of synchronization by causing the API to return to me WANT_READ or WANT_WRITE. You seem to be arguing that I should never select() on the SSL session's file descriptor for ready-to-read unless SSL_read() or SSL_write() has already returned to me ready-for-read. But select() will never cause me to call (for example) SSL_read() when I would not have called it if I did *not* select() first: it can only cause me _not_ to call SSL_read() in cases where I would have called it and received WANT_READ in return, if I followed what appears to be your proposed heuristic of always try the I/O first, then sleep on I/O if nothing is ready. So if I had this wrong, I would _stall waiting for I/O which never appeared_ -- which is not what happens. 5) I call SSL_read with a 4096-byte buffer. SSL_read returns -1 and error is SSL_ERROR_WANT_READ. So now you know that a read hit from select is needed (or other forward progress must be made) before SSL_read can succeed. Sure. 6) I set a flag to ensure I do not call SSL_write() (it isn't clear to me this is necessary -- the documentation is vague) and select on the SSL session's descriptor for read. Why would you avoid writing? It's possible the other side will not send any application data. Because the documentation appears in several places to state that when I receive WANT_X from _any_ OpenSSL API operation in non-blocking mode, the next API operation I issue on that SSL * must be the exact same API operation, with the same parameters. We've also seen OpenSSL developers say as much on this mailing list in the past -- and in testing, I have in fact seen misbehavior with previous versions of
