[openssl-dev] [openssl.org #4174] Support the TLS Feature (aka Must Staple) X.509v3 extension (RFC7633)
https://github.com/openssl/openssl/pull/495 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4043] monitoring software depending onopenssl not working on cloudflare ssl websites
Hi Horatiu. To connect to a site that uses CloudFlare Universal SSL [1], you need to specify the SNI (Server Name Indication) header. Modern browsers do this by default, but for s_client you need to do this... openssl s_client -connect :443 -servername This isn't an OpenSSL bug, so I suggest closing this ticket. [1] https://blog.cloudflare.com/introducing-universal-ssl/ On 15/09/15 15:33, Horatiu N via RT wrote: > Greetings, > > Using the nagios plugins (latest debian package for 8.1) to check > availability of https websites using cloudflare gives errors >> CRITICAL - Cannot make SSL connection. >> 139729452828304:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 >> alert internal error:s23_clnt.c:770: > > same goes if i attempt to run >> openssl s_client -connect :443 > > This basically makes monitoring impossible at this time, > Any idea how to remedy this situation ? > > i attached a textfile with sample domains as extracted from the > certificate's "Certificate Subject alt name" > it's reproducible on any target as long as it's online > > openssl version >> OpenSSL 1.0.1k 8 Jan 2015 > > > dpkg -l openssl >> ii openssl 1.0.1k-3+deb8u1amd64 Secure >> Sockets Layer toolkit - cryptographic utility > > tried also to compile the newest one from openssl.org and use it, same > problem. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3665] Bug report and a patch forOpenSSL 1.0.1l (and 1.0.1k)
On 19/01/15 14:47, Stephen Henson via RT wrote:
> On Mon Jan 19 14:40:32 2015, steve wrote:
>>
>> The problem is that the two fields containing the signature algorithm
>> do not match.
>
> The current 'x509' utility can't show this difference (I have an option I'm
> testing which will).
Steve, while you're there...
I've been caught out a few times in the past because the 'x509' utility
displays the "outer" signature algorithm in the place where it should
display the "inner" signature algorithm. This is fine when they match,
but it's rather unhelpful when they don't match!
Please consider this trivial patch. Thanks.
diff --git a/crypto/asn1/t_x509.c b/crypto/asn1/t_x509.c
index 89115c7..97abd51 100644
--- a/crypto/asn1/t_x509.c
+++ b/crypto/asn1/t_x509.c
@@ -168,7 +168,7 @@ int X509_print_ex(BIO *bp, X509 *x, unsigned long
nmflags, unsigned long cflag)
if(!(cflag & X509_FLAG_NO_SIGNAME))
{
- if(X509_signature_print(bp, x->sig_alg, NULL) <= 0)
+ if(X509_signature_print(bp, ci->signature, NULL) <= 0)
goto err;
#if 0
if (BIO_printf(bp,"%8sSignature Algorithm: ","") <= 0)
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl.org #2354] [PATCH] Increase Default RSA Key Size to 2048-bits
This can presumably be resolved as fixed, given the commit on #2626 just now. On 29/09/10 20:54, Rob Stradling via RT wrote: NIST (SP800-57 Part 1) recommends a minimum RSA key size of 2048-bits beyond 2010. From January 1st 2011, in order to comply with the current Microsoft[1] and Mozilla[2] CA Policies, Commercial CAs will no longer be permitted to issue certificates with RSA key sizes of <2048-bit. Please accept the attached patch, which increases the default RSA key size to 2048-bits for the "req", "genrsa" and "genpkey" apps. Thanks. [1] http://technet.microsoft.com/en-us/library/cc751157.aspx says: "we have advised Certificate Authorities...to transition their subordinate and end-certificates to 2048-bit RSA certificates, and to complete this transition for any root certificate distributed by the Program no later than December 31, 2010". [2] https://wiki.mozilla.org/CA:MD5and1024 says: "December 31, 2010 – CAs should stop issuing intermediate and end-entity certificates from roots with RSA key sizes smaller than 2048 bits. All CAs should stop issuing intermediate and end-entity certificates with RSA key size smaller than 2048 bits under any root". Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3516] OCSP Certificate Chain Response Handling
Duplicate of #2206 ? On 05/09/14 08:35, Mehner, Carl via RT wrote: OCSP response handling in /apps/ocsp.c -- 2014-06-25 The OCSP Documentation States https://www.openssl.org/docs/apps/ocsp.html "Otherwise the OCSP responder certificate's CA is checked against the issuing CA certificate in the request. If there is a match and the OCSPSigning extended key usage is present in the OCSP responder certificate then the OCSP verify succeeds." --Assumptions-- The flag '-issuer' in openSSL's ocsp application is what the responder's certificate's CA is checking against. The 'responder's certificate's CA' means the certificate authority that is issuer of the ocsp signing certificate. --What Happens-- When running the command: openssl ocsp -no_nonce -issuer -cert -CA -url http:// Validation of the OCSP responder certificate fails unless the issuer's cert is also in the file containing the root CA cert. The error messages are: Response Verify Failure 8604:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:.\crypto\ocsp\ocsp_vfy.c:126:Verify error:unable to get local issuer certificate However, if you specify a -CAfile that includes the same cert from the '-issuer' flag and the root CA cert that is the root of trust for the ocsp responder cert, you will get back a 'Response verify OK' --What Should Happen-- If the certificate provided in the '-issuer' flag matches the CA certificate referenced in the OCSP responder's issuer field, the OCSP verify should succeed. There should be no need to chain up to the root in this case as it would be a waste of time since that evaluation is already done on the issuer certificate provided with the '-issuer' flag when evaluating the chain of the certificate provided by the '-cert' flag outside of the OCSP validation process. If the leaf validation fails, there is no need to validate the OCSP chain, the connection will fail regardless. However, if the anyone feels that the full chain needs to be validated, the validation procedure should be able to bridge the cert included on the '-issuer' flag with a single root specified on the '-CA' flag. (It currently does not.) -cem -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3469] problem with commit 3009244da47b989c4cc59ba02cf81a4e9d8f8431 - global_mask needs to be more liberal
On 27/07/14 14:30, Stephen Henson via RT wrote: On Mon Jul 21 20:29:47 2014, v...@v13.gr wrote: I'm not sure whether this change is needed at all as there's no justification for it. The justification is in RFC3280 et al: "The UTF8String encoding [RFC 2279] is the preferred encoding, and all certificates issued after December 31, 2003 MUST use the UTF8String encoding of DirectoryString (except as noted below)." Steve, that requirement was removed when RFC5280 obsoleted RFC3280. RFC5280 Section 1 says: "This specification obsoletes [RFC3280]. Differences from RFC 3280 are summarized below: ... * Sections 4.1.2.4 and 4.1.2.6 incorporate the conditions for continued use of legacy text encoding schemes that were specified in [RFC4630]. Where in use by an established PKI, transition to UTF8String could cause denial of service based on name chaining failures or incorrect processing of name constraints." And Section 4.2.1.4 says that PrintableString and UTF8String are now equally preferred. Which of these RFCs does OpenSSL (cl)aim to be compliant with? So in that sense OpenSSL was a bit behind the times. The configuration files were set to use UTF8 only well before then but not the default in the source. The bug is in any software which relies on the DirectoryString being a PrintableString and not in OpenSSL. Steve. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On 01/05/14 12:26, Stephen Henson via RT wrote: On Thu May 01 12:29:58 2014, meiss...@suse.de wrote: Hi, SUSE has received a bugreport from a user, that the "padding" extension change breaks IronPort SMTP appliances. Ironically it was added as a workaround for another bug. The padding extension was believed to have no side effects... obviously that isn't true :-( If you use a smaller cipherstring it should also work without having to force SSLv3. Steve, have you considered trimming the DEFAULT cipher list? It's currently... #define SSL_DEFAULT_CIPHER_LIST "ALL:!aNULL:!eNULL:!SSLv2" I wonder how many of these ciphers are actually ever negotiated in real-world use. The padding extension is only used if the ClientHello would be between 256 and 511 bytes in length so if you reduce the number of ciphersuites it wont be used. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
See also this thread: http://www.ietf.org/mail-archive/web/tls/current/msg12143.html On 01/05/14 11:29, Marcus Meissner via RT wrote: Hi, SUSE has received a bugreport from a user, that the "padding" extension change breaks IronPort SMTP appliances. There might a RT on this already, not sure. https://bugzilla.novell.com/show_bug.cgi?id=875639 http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html Quoting from our openSUSE bugreport: Last upgrade to openssl-1.0.1g-11.36.1.x86_64 broke SSL connections to some services, e.g. Cisco Ironport SMTP appliances. 1.0.1g not only fixes the Heartbleed bug but also adds another change by adding: #define TLSEXT_TYPE_padding 21 This in turn breaks SSL connections to e.g. Ironports, probably others: SSL23_GET_SERVER_HELLO:tlsv1 alert decode error Workaround: Force protocol to SSLv3 or recompile without the define above. For details, please refer to: postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html Reproducible: Always Steps to Reproduce: 1. openssl s_client -connect some.ironport.com:25 -starttls smtp Note: Send me an email for a hostname of an Ironport SMTP appliance to test with. I don't want to disclose it here. Actual Results: CONNECTED(0003) 139718758192784:error:1407741A:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert decode error:s23_clnt.c:762: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 129 bytes and written 552 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- Expected Results: CONNECTED(0003) --- Certificate chain [...cut...] New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 [...cut..-] 250 STARTTLS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Questions on SSL_OP_SAFARI_ECDHE_ECDSA_BUG
On 09/12/13 23:34, Jeffrey Walton wrote: Reference: http://openssl.6102.n7.nabble.com/openssl-org-3068-PATCH-Safari-broken-ECDHE-ECDSA-workaround-td45432.html and http://openssl.6102.n7.nabble.com/Apple-are-apparently-dicks-td45512.html. BL > ...and don't intend to fix their broken ECDSA support in Safari. Apple really needs to fix their engineering process and broken implementation. (And hire some QA personnel while they are at it... This is something their lawyers can't fix with a change to their license agreements). Will the patch be applied to 0.9.8 and 1.0.1 branches? It has been applied on those branches already. http://git.openssl.org/gitweb/?p=openssl.git;a=shortlog;h=refs/heads/OpenSSL_0_9_8-stable Committed on 2013-10-04. http://git.openssl.org/gitweb/?p=openssl.git;a=shortlog;h=refs/heads/OpenSSL_1_0_0-stable Committed on 2013-09-10. http://git.openssl.org/gitweb/?p=openssl.git;a=shortlog;h=refs/heads/OpenSSL_1_0_1-stable Committed on 2013-09-16. If I can't wait for the patch in future stable releases (or don't want to use SSL_OP_SAFARI_ECDHE_ECDSA_BUG), what are the other options? Can I use a cipher_list to work around this? For example, can I prefer RSA and DSS ciphers over ECDSA: const char* const PREFERRED_CIPHERS = /* TLS 1.2 only */ "ECDHE-RSA-AES256-GCM-SHA384:" "ECDHE-RSA-AES128-GCM-SHA256:" /* TLS 1.2 only */ "DHE-DSS-AES256-GCM-SHA384:" "DHE-RSA-AES256-GCM-SHA384:" "DHE-DSS-AES128-GCM-SHA256:" "DHE-RSA-AES128-GCM-SHA256:" /* TLS 1.2, see SSL_OP_SAFARI_ECDHE_ECDSA_BUG */ "ECDHE-ECDSA-AES256-GCM-SHA384:" "ECDHE-ECDSA-AES128-GCM-SHA256:" The broken versions of Safari/OSX don't support GCM (or DSS, I think), so enabling and even preferring ECDHE-ECDSA-AES256-GCM-SHA384 and ECDHE-ECDSA-AES128-GCM-SHA256 on your server shouldn't cause any problems. If you can't wait for the patch, or don't want to use it, here are two workarounds that I think should work... 1. Ensure that these 4 ciphers are all disabled on your server (since these are the only ciphers that are affected by the Safari/OSX bug): ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-RC4-SHA ECDHE-ECDSA-DES-CBC3-SHA or 2. If you want to enable 1 or more of those 4 ECDHE-ECDSA ciphers, ensure that your server prefers at least 1 of the following ciphers (that Safari/OSX also offers) ahead of them: ECDH-RSA-AES128-SHA ECDH-RSA-AES256-SHA ECDH-RSA-RC4-SHA ECDH-RSA-DES-CBC3-SHA ECDHE-RSA-AES256-SHA ECDHE-RSA-AES128-SHA ECDHE-RSA-RC4-SHA ECDHE-RSA-DES-CBC3-SHA AES128-SHA RC4-SHA RC4-MD5 AES256-SHA DES-CBC3-SHA DHE-RSA-AES128-SHA DHE-RSA-AES256-SHA EDH-RSA-DES-CBC3-SHA (Obviously you'll need 2 server certificates, one with an RSA key and one with an ECC key). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3169] [PATCH] Additional "chain_cert" functions for 1.0.2-dev
This patch, which currently applies successfully against master and 1_0_2, adds the following functions: SSL_[CTX_]select_current_cert() - set the current certificate without disturbing the existing structure. SSL_[CTX_]get0_chain_certs() - get the current certificate's chain. SSL_[CTX_]clear_chain_certs() - clear the current certificate's chain. The patch also adds these functions to, and fixes some existing errors in, SSL_CTX_add1_chain_cert.pod. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online diff --git a/doc/ssl/SSL_CTX_add1_chain_cert.pod b/doc/ssl/SSL_CTX_add1_chain_cert.pod index 04f7526..2d2161a 100644 --- a/doc/ssl/SSL_CTX_add1_chain_cert.pod +++ b/doc/ssl/SSL_CTX_add1_chain_cert.pod @@ -3,9 +3,11 @@ =head1 NAME SSL_CTX_set0_chain, SSL_CTX_set1_chain, SSL_CTX_add0_chain_cert, -SSL_CTX_add1_chain_cert, SSL_set0_chain, SSL_set1_chain, -SSL_add0_chain_cert, SSL_add1_chain_cert, SSL_CTX_build_cert_chain, -SSL_build_cert_chain - extra chain certificate processing +SSL_CTX_add1_chain_cert, SSL_CTX_get0_chain_certs, SSL_CTX_clear_chain_certs, +SSL_set0_chain, SSL_set1_chain, SSL_add0_chain_cert, SSL_add1_chain_cert, +SSL_get0_chain_certs, SSL_clear_chain_certs, SSL_CTX_build_cert_chain, +SSL_build_cert_chain, SSL_CTX_select_current_cert, +SSL_select_current_cert - extra chain certificate processing =head1 SYNOPSIS @@ -13,36 +15,58 @@ SSL_build_cert_chain - extra chain certificate processing int SSL_CTX_set0_chain(SSL_CTX *ctx, STACK_OF(X509) *sk); int SSL_CTX_set1_chain(SSL_CTX *ctx, STACK_OF(X509) *sk); - int SSL_CTX_add0_chain_cert(SSL_CTX *ctx, STACK_OF(X509) *x509); + int SSL_CTX_add0_chain_cert(SSL_CTX *ctx, X509 *x509); int SSL_CTX_add1_chain_cert(SSL_CTX *ctx, X509 *x509); + int SSL_CTX_get0_chain_certs(SSL_CTX *ctx, STACK_OF(X509) **sk); + int SSL_CTX_clear_chain_certs(SSL_CTX *ctx); int SSL_set0_chain(SSL *ssl, STACK_OF(X509) *sk); int SSL_set1_chain(SSL *ssl, STACK_OF(X509) *sk); - int SSL_add0_chain_cert(SSL *ssl, STACK_OF(X509) *x509); + int SSL_add0_chain_cert(SSL *ssl, X509 *x509); int SSL_add1_chain_cert(SSL *ssl, X509 *x509); + int SSL_get0_chain_certs(SSL *ssl, STACK_OF(X509) **sk); + int SSL_clear_chain_certs(SSL *ssl); int SSL_CTX_build_cert_chain(SSL_CTX *ctx, flags); - int SSL_build_cert_chain(SSL_CTX *ctx, flags); + int SSL_build_cert_chain(SSL *ssl, flags); + + int SSL_CTX_select_current_cert(SSL_CTX *ctx, X509 *x509); + int SSL_select_current_cert(SSL *ssl, X509 *x509); =head1 DESCRIPTION SSL_CTX_set0_chain() and SSL_CTX_set1_chain() set the certificate chain -associated with the current certificate of B to B. If B is set -to B any existing chain is cleared. +associated with the current certificate of B to B. SSL_CTX_add0_chain_cert() and SSL_CTX_add1_chain_cert() append the single certificate B to the chain associated with the current certificate of B. +SSL_CTX_get0_chain_certs() retrieves the chain associated with the current +certificate of B. + +SSL_CTX_clear_chain_certs() clears any existing chain associated with the +current certificate of B. (This is implemented by calling +SSL_CTX_set0_chain() with B set to B). + SSL_CTX_build_cert_chain() builds the certificate chain for B using the chain store. Any existing chain certificates are used as untrusted CAs. If the function is successful the built chain will replace any existing chain. The B parameter can be set to B to omit the root CA from the built chain. -SSL_set0_chain(), SSL_set1_chain(), SSL_add0_chain_cert(), SSL_add0_chain_cert() -and SSL_build_cert_chain() are similar except they apply to SSL structure -B. +Each of these functions operates on the I end entity +(i.e. server or client) certificate. This is the last certificate loaded or +selected on the corresponding B structure. + +SSL_CTX_select_current_cert() selects B as the current end entity +certificate, but only if B has already been loaded into B using a +function such as SSL_CTX_use_certificate(). + +SSL_set0_chain(), SSL_set1_chain(), SSL_add0_chain_cert(), +SSL_add1_chain_cert(), SSL_get0_chain_certs(), SSL_clear_chain_certs(), +SSL_build_cert_chain() and SSL_select_current_cert() are similar except they +apply to SSL structure B. All these functions are implemented as macros. Those containing a B<1> increment the reference count of the supplied certificate or chain so it must @@ -56,10 +80,6 @@ The chains associate with an SSL_CTX structure are copied to any SSL structures when SSL_new() is called. SSL structures will not be affected by any chains subsequently changed in the parent SSL_CTX. -Each of these functions operates on the I end entity -(i.e. server or client) certificate. This is the last certificate set -on the corresponding B or B structure. - One chain can be set for each key type supported by a server. So, for example, an RSA and a DSA certificate can (and often will) have different chains. diff --git a/ssl/s3_
Re: Need get() and clear() functions for chain_certs in 1.0.2-dev
On 06/11/13 17:27, Dr. Stephen Henson wrote: On Wed, Nov 06, 2013, Rob Stradling wrote: These 2 #defines exist for SSL_CTX->extra_certs: SSL_CTX_add_extra_chain_cert SSL_CTX_get_extra_chain_certs SSL_CTX_clear_extra_chain_certs In 1.0.2-dev, the #defines such as SSL_CTX_add0_chain_cert allow me to specify different chains for different certificate types, but AFAICT there are no associated get() or clear() functions. I can't see a way to squeeze a standalone SSL_CTX_get_chain_certs function into SSL_CTX_ctrl(). There's only 1 pointer argument available, so I can't pass in an X509* (to indicate which cert I want the chain for) and get back a STACK_OF(X509)* (the chain). One option would be to have another SSL_CTX_ctrl #define called SSL_CTX_get_cert_type, which would accept an X509* and return the index of that cert (i.e. SSL_CTX->CERT->pkeys[index]->x509), or -1 if not found. That index could then be passed to SSL_CTX_get_chain_certs in the larg argument. However, since the SSL_PKEY_* #defines are private (in ssl_locl.h), I'm unsure whether exposing these values in the public APIs would be acceptable. The other option would be to write SSL_CTX_get_chain_certs() as a proper function (instead of a SSL_CTX_ctrl #define), but I'm unsure whether or not that would be better than the first option. Any preference? The index for certificates could change in future so I'd rather not expose it in a public API. Agreed. I can imagine some future version of OpenSSL being able to accommodate several ECC certs, each with a key on a different named curve, for example. OpenSSL has the concept of a "current certificate" which could be used here. This refers to the last certificate set. So you'd have (for example) a way to retrieve extra chain certificates for the current certificate. For that to work properly you'd also have to have a way to set the current certtificate, without the risk of disturbing the existing structure. So perhaps something like: int SSL_set_current_cert(SSL *ssl, X509 *x); Works for me. :-) I think the word "select" instead of "set" in that function name might help to make its purpose slightly clearer. (I can imagine someone who doesn't like reading man pages thinking this function will do the same thing as SSL_use_certificate() ). Which returns 1 and sets the current certificate to one containing 'x' if a match is found and returns 0 and does nothing if no match is found. Also with an SSL_CTX version. Does the attached patch (against the master branch) look acceptable? Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online diff --git a/doc/ssl/SSL_CTX_add1_chain_cert.pod b/doc/ssl/SSL_CTX_add1_chain_cert.pod index 04f7526..2d2161a 100644 --- a/doc/ssl/SSL_CTX_add1_chain_cert.pod +++ b/doc/ssl/SSL_CTX_add1_chain_cert.pod @@ -3,9 +3,11 @@ =head1 NAME SSL_CTX_set0_chain, SSL_CTX_set1_chain, SSL_CTX_add0_chain_cert, -SSL_CTX_add1_chain_cert, SSL_set0_chain, SSL_set1_chain, -SSL_add0_chain_cert, SSL_add1_chain_cert, SSL_CTX_build_cert_chain, -SSL_build_cert_chain - extra chain certificate processing +SSL_CTX_add1_chain_cert, SSL_CTX_get0_chain_certs, SSL_CTX_clear_chain_certs, +SSL_set0_chain, SSL_set1_chain, SSL_add0_chain_cert, SSL_add1_chain_cert, +SSL_get0_chain_certs, SSL_clear_chain_certs, SSL_CTX_build_cert_chain, +SSL_build_cert_chain, SSL_CTX_select_current_cert, +SSL_select_current_cert - extra chain certificate processing =head1 SYNOPSIS @@ -13,36 +15,58 @@ SSL_build_cert_chain - extra chain certificate processing int SSL_CTX_set0_chain(SSL_CTX *ctx, STACK_OF(X509) *sk); int SSL_CTX_set1_chain(SSL_CTX *ctx, STACK_OF(X509) *sk); - int SSL_CTX_add0_chain_cert(SSL_CTX *ctx, STACK_OF(X509) *x509); + int SSL_CTX_add0_chain_cert(SSL_CTX *ctx, X509 *x509); int SSL_CTX_add1_chain_cert(SSL_CTX *ctx, X509 *x509); + int SSL_CTX_get0_chain_certs(SSL_CTX *ctx, STACK_OF(X509) **sk); + int SSL_CTX_clear_chain_certs(SSL_CTX *ctx); int SSL_set0_chain(SSL *ssl, STACK_OF(X509) *sk); int SSL_set1_chain(SSL *ssl, STACK_OF(X509) *sk); - int SSL_add0_chain_cert(SSL *ssl, STACK_OF(X509) *x509); + int SSL_add0_chain_cert(SSL *ssl, X509 *x509); int SSL_add1_chain_cert(SSL *ssl, X509 *x509); + int SSL_get0_chain_certs(SSL *ssl, STACK_OF(X509) **sk); + int SSL_clear_chain_certs(SSL *ssl); int SSL_CTX_build_cert_chain(SSL_CTX *ctx, flags); - int SSL_build_cert_chain(SSL_CTX *ctx, flags); + int SSL_build_cert_chain(SSL *ssl, flags); + + int SSL_CTX_select_current_cert(SSL_CTX *ctx, X509 *x509); + int SSL_select_current_cert(SSL *ssl, X509 *x509); =head1 DESCRIPTION SSL_CTX_set0_chain() and SSL_CTX_set1_chain() set the certificate chain -associated with the current certificate of B to B. If B is set -to B any existing chain is cleared. +associated with the current certificate of B to B. SSL_CTX_add
Need get() and clear() functions for chain_certs in 1.0.2-dev
These 2 #defines exist for SSL_CTX->extra_certs: SSL_CTX_add_extra_chain_cert SSL_CTX_get_extra_chain_certs SSL_CTX_clear_extra_chain_certs In 1.0.2-dev, the #defines such as SSL_CTX_add0_chain_cert allow me to specify different chains for different certificate types, but AFAICT there are no associated get() or clear() functions. I can't see a way to squeeze a standalone SSL_CTX_get_chain_certs function into SSL_CTX_ctrl(). There's only 1 pointer argument available, so I can't pass in an X509* (to indicate which cert I want the chain for) and get back a STACK_OF(X509)* (the chain). One option would be to have another SSL_CTX_ctrl #define called SSL_CTX_get_cert_type, which would accept an X509* and return the index of that cert (i.e. SSL_CTX->CERT->pkeys[index]->x509), or -1 if not found. That index could then be passed to SSL_CTX_get_chain_certs in the larg argument. However, since the SSL_PKEY_* #defines are private (in ssl_locl.h), I'm unsure whether exposing these values in the public APIs would be acceptable. The other option would be to write SSL_CTX_get_chain_certs() as a proper function (instead of a SSL_CTX_ctrl #define), but I'm unsure whether or not that would be better than the first option. Any preference? Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
ECDHE problem with 1.0.2-dev
Hi. When I build the latest development version of httpd or nginx against the OpenSSL_1_0_2-stable branch, the ECDHE-RSA and ECDHE-ECDSA ciphers don't work. With both webservers, I can get these ciphers to work by either... 1. Deleting: SSL_CTX_set_options(ctx, SSL_OP_SINGLE_ECDH_USE); or 2. Adding: SSL_CTX_set_ecdh_auto(ctx, 1); Should it still be possible to manually configure ECDH keys using SSL_CTX_set_tmp_ecdh() in 1_0_2? If so, any ideas why it isn't working? Is there a bug in OpenSSL_1_0_2-stable? Or are both httpd and nginx doing something wrong? Or, is "SSL_CTX_set_ecdh_auto(ctx, 1);" the only supported way of doing it in 1_0_2? Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14/06/13 14:16, Ben Laurie wrote: On 14 June 2013 14:08, Rob Stradling wrote: Apparently the ECDHE-ECDSA bug is in SecureTransport, which is an integral component of OSX. https://developer.apple.com/library/mac/#documentation/security/Reference/secureTransportRef/Reference/reference.html seems to suggest it is a library. Ben, what else needs to happen before this patch is either committed or rejected? Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14/06/13 15:25, Florian Weimer wrote: On 06/14/2013 03:31 PM, Dr. Stephen Henson wrote: Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared libraries are updated to include the patch existing applications wont set it: they'd all need to be recompiled. That's a valid point. Possibly alternative is to reuse one of the existing *ancient* flags. Does anyone really care about compatibility with a bug in SSLeay 0.80 for example? Wouldn't it be better to reverse the meaning of the flag and not set it in SSL_OP_ALL? Just to complicate matters further, the 0x400 bit used to be set in SSL_OP_ALL, and has previously been used for at least 2 other purposes! http://cvs.openssl.org/chngview?cn=18974 http://cvs.openssl.org/chngview?cn=22501 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14/06/13 14:31, Dr. Stephen Henson wrote: The behavior change applies only if new option SSL_OP_SAFARI_ECDHE_ECDSA_BUG is used (part of SSL_OP_ALL), as is standard for interoperability bug workarounds, so while it is very unfortunate that we'd need to do this, I'm in favor of accepting this patch. Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared libraries are updated to include the patch existing applications wont set it: they'd all need to be recompiled. Yep, but 0x400 is the only currently unallocated bit. Possibly alternative is to reuse one of the existing *ancient* flags. Does anyone really care about compatibility with a bug in SSLeay 0.80 for example? I'd wondered about that. If you're happy to reallocate one of the ancient flags, please do! -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14/06/13 13:54, The Doctor wrote: On Thu, Jun 13, 2013 at 05:39:36PM +0100, Ben Laurie wrote: ...and don't intend to fix their broken ECDSA support in Safari. It is therefore suggested that I pull this patch: https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d What do people think? No keep the patch. I think you misunderstood what Ben meant by "pull". See "man git-pull" -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14/06/13 13:58, Ben Laurie wrote: On 14 June 2013 13:57, Rob Stradling wrote: Safari's User-Agent string reveals the OSX version that it is running on. A few weeks ago I analyzed some webserver logs to get an idea of historical OSX update rates. Based on that analysis, I forecast that the majority of OSX 10.8.x users will install the 10.8.4 update, but that a significant minority won't. I guess then we need to know why? And would they upgrade Safari alone? Apparently the ECDHE-ECDSA bug is in SecureTransport, which is an integral component of OSX. No server administrator will want to deploy ECDHE-ECDSA if it means breaking compatibility with even a small fraction of deployed browsers. Hence why this patch is, unfortunately, necessary. What is _necessary_ is that Apple accept responsibility for their errors :-) Agreed. Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA bugfix. Why are we chasing after them cleaning up their messes? Because we want ECDHE-ECDSA to be deployable. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14/06/13 12:31, Ben Laurie wrote: On 14 June 2013 12:25, Rob Stradling wrote: Ah, so you're criticizing Apple for not being willing to force all OSX 10.8.x users to update to 10.8.4. No. If OSX 10.8.x has a mechanism that allows Apple to force updates to be installed, then I agree. But my suspicion is that it doesn't, and if so, Apple's willingness isn't the key issue here. It has a mechanism to nag you endlessly until you do install updates. Which makes me wonder why you think people won't install the OS update? Safari's User-Agent string reveals the OSX version that it is running on. A few weeks ago I analyzed some webserver logs to get an idea of historical OSX update rates. Based on that analysis, I forecast that the majority of OSX 10.8.x users will install the 10.8.4 update, but that a significant minority won't. No server administrator will want to deploy ECDHE-ECDSA if it means breaking compatibility with even a small fraction of deployed browsers. Hence why this patch is, unfortunately, necessary. What is _necessary_ is that Apple accept responsibility for their errors :-) Agreed. Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA bugfix. Why are we chasing after them cleaning up their messes? Because we want ECDHE-ECDSA to be deployable. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14/06/13 10:20, Ben Laurie wrote: On 14 June 2013 09:39, Rob Stradling wrote: On 13/06/13 17:39, Ben Laurie wrote: ...and don't intend to fix their broken ECDSA support in Safari. Ben, you've got your wires a bit crossed there. The ECDHE-ECDSA ciphersuites are indeed broken in Safari on OSX 10.8 to 10.8.3, but they are _fixed_ in OSX 10.8.4 (released last week). It is therefore suggested that I pull this patch: https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d What do people think? The unfortunate reality is that significant numbers of OSX 10.8.x users won't upgrade to 10.8.4 anytime soon, even though the upgrade is free and easy to install. Precisely my point - so how were my wires crossed? Ah, so you're criticizing Apple for not being willing to force all OSX 10.8.x users to update to 10.8.4. If OSX 10.8.x has a mechanism that allows Apple to force updates to be installed, then I agree. But my suspicion is that it doesn't, and if so, Apple's willingness isn't the key issue here. No server administrator will want to deploy ECDHE-ECDSA if it means breaking compatibility with even a small fraction of deployed browsers. Hence why this patch is, unfortunately, necessary. What is _necessary_ is that Apple accept responsibility for their errors :-) Agreed. Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA bugfix. Why are we chasing after them cleaning up their messes? Because we want ECDHE-ECDSA to be deployable. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 13/06/13 17:39, Ben Laurie wrote: ...and don't intend to fix their broken ECDSA support in Safari. Ben, you've got your wires a bit crossed there. The ECDHE-ECDSA ciphersuites are indeed broken in Safari on OSX 10.8 to 10.8.3, but they are _fixed_ in OSX 10.8.4 (released last week). It is therefore suggested that I pull this patch: https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d What do people think? The unfortunate reality is that significant numbers of OSX 10.8.x users won't upgrade to 10.8.4 anytime soon, even though the upgrade is free and easy to install. No server administrator will want to deploy ECDHE-ECDSA if it means breaking compatibility with even a small fraction of deployed browsers. Hence why this patch is, unfortunately, necessary. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3068] [PATCH] Safari broken ECDHE-ECDSA workaround
The Safari browser on OSX versions 10.8 to 10.8.3 advertises support for
several ECDHE-ECDSA ciphers but fails to negotiate them.
When a Safari client connects to an OpenSSL-based server that has the
attached patch (against the "master" branch) applied, the server will
prefer other mutually supported ciphers above ECDHE-ECDSA ciphers.
This patch enables a webserver to have an ECC certificate together with
an RSA and/or DSA certificate, and to offer ECDHE-ECDSA ciphers without
fear of breaking compatibility with Safari clients.
The ssl_check_for_safari() function, which fingerprints Safari clients
based on the TLS Extensions used, was written by Adam Langley.
A representative from Apple has told me that the Safari bug will be
fixed in OSX 10.8.4. However, since OSX users won't be forced to
upgrade, I believe that a significant number of users will still be
using affected Safari versions a few years from now.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
index 7ad8a54..fff73eb 100644
--- a/ssl/s3_lib.c
+++ b/ssl/s3_lib.c
@@ -3076,7 +3076,10 @@ void ssl3_clear(SSL *s)
OPENSSL_free(s->s3->tlsext_authz_client_types);
s->s3->tlsext_authz_client_types = NULL;
}
-#endif
+#ifndef OPENSSL_NO_EC
+ s->s3->is_probably_safari = 0;
+#endif /* OPENSSL_NO_EC */
+#endif /* OPENSSL_NO_TLSEXT */
rp = s->s3->rbuf.buf;
wp = s->s3->wbuf.buf;
@@ -4145,8 +4148,15 @@ SSL_CIPHER *ssl3_choose_cipher(SSL *s, STACK_OF(SSL_CIPHER) *clnt,
ii=sk_SSL_CIPHER_find(allow,c);
if (ii >= 0)
{
- ret=sk_SSL_CIPHER_value(allow,ii);
- break;
+ if ((alg_k & SSL_kEECDH) && (alg_a & SSL_aECDSA) && s->s3->is_probably_safari)
+{
+if (!ret) ret=sk_SSL_CIPHER_value(allow,ii);
+}
+ else
+{
+ret=sk_SSL_CIPHER_value(allow,ii);
+break;
+}
}
}
return(ret);
diff --git a/ssl/ssl.h b/ssl/ssl.h
index e14a8d4..dd62578 100644
--- a/ssl/ssl.h
+++ b/ssl/ssl.h
@@ -568,6 +568,7 @@ struct ssl_session_st
#define SSL_OP_SSLEAY_080_CLIENT_DH_BUG 0x0080L
#define SSL_OP_TLS_D5_BUG0x0100L
#define SSL_OP_TLS_BLOCK_PADDING_BUG 0x0200L
+#define SSL_OP_SAFARI_ECDHE_ECDSA_BUG 0x0400L
/* Disable SSL 3.0/TLS 1.0 CBC vulnerability workaround that was added
* in OpenSSL 0.9.6d. Usually (depending on the application protocol)
@@ -578,7 +579,7 @@ struct ssl_session_st
/* SSL_OP_ALL: various bug workarounds that should be rather harmless.
* This used to be 0x000FL before 0.9.7. */
-#define SSL_OP_ALL 0x8BFFL
+#define SSL_OP_ALL 0x8FFFL
/* DTLS options */
#define SSL_OP_NO_QUERY_MTU 0x1000L
diff --git a/ssl/ssl3.h b/ssl/ssl3.h
index d8ed725..0b900b5 100644
--- a/ssl/ssl3.h
+++ b/ssl/ssl3.h
@@ -577,7 +577,14 @@ typedef struct ssl3_state_st
* server echoed our server_authz extension and therefore must send us
* a supplemental data handshake message. */
char tlsext_authz_server_promised;
-#endif
+
+#ifndef OPENSSL_NO_EC
+ /* This is set to true if we believe that this is a version of Safari
+ * running on OS X 10.6 .. 10.8. We wish to know this because Safari
+ * on 10.8 has broken ECDHE-ECDSA support. */
+ char is_probably_safari;
+#endif /* OPENSSL_NO_EC */
+#endif /* OPENSSL_NO_TLSEXT */
} SSL3_STATE;
#endif
diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c
index 31daa50..c5e2b85 100644
--- a/ssl/t1_lib.c
+++ b/ssl/t1_lib.c
@@ -1716,6 +1716,89 @@ unsigned char *ssl_add_serverhello_tlsext(SSL *s, unsigned char *p, unsigned cha
return ret;
}
+#ifndef OPENSSL_NO_EC
+/* ssl_check_for_safari attempts to fingerprint Safari using OS X
+ * SecureTransport using the TLS extension block in |d|, of length |n|.
+ * Safari, since 10.6, sends exactly these extensions, in this order:
+ * SNI,
+ * elliptic_curves
+ * ec_point_formats
+ *
+ * We wish to fingerprint Safari because they broke ECDHE-ECDSA support in 10.8,
+ * but they advertise support. So enabling ECDHE-ECDSA ciphers breaks them.
+ * Sadly we cannot differentiate 10.6 and 10.7 (which work), from 10.8 (which
+ * doesn't).
+ */
+static void ssl_check_for_safari(SSL *s, const unsigned char *data, const unsigned char *d, int n) {
+ unsigned short type, size;
+ static const unsigned char kSafariExtensionsBlock[] = {
+ 0x00, 0x0a, /* elliptic_curves extension */
+ 0x00, 0x08, /* 8 bytes */
+ 0x00, 0x06, /* 6 bytes of curve ids */
+ 0x00, 0x17, /* P-256 */
+ 0x00, 0x18, /* P-384 */
+ 0x00, 0x19, /* P-521 */
+
+ 0x00, 0x0b, /* ec_point_formats */
+ 0x00, 0x02, /* 2 bytes */
+ 0x01,/* 1 point format */
+ 0x00,/* uncompressed */
+ };
+
+ /* The following is only present in TLS 1.2 */
+ static const unsigned char kSafariTLS12ExtensionsBlock[] = {
+ 0x00, 0x0d, /* signature_algorithms */
+ 0x00, 0x0c, /* 12 bytes */
+ 0x00, 0x0a, /* 10 bytes */
+ 0x
Re: Ask for help-please help to response,thank you!
Hi xiaotu65217.
Are you saying that the coredump is occurring inside SSL_get_certificate() ?
Or is SSL_get_certificate() returning NULL, and is your application
coredumping because it's not expecting NULL ?
If you can provide more detail on what your application is doing, that
would help to diagnose this problem.
Thanks.
On 16/04/13 15:24, xiaotu65217 wrote:
Hello,my friend!
Today when I use the openssl 0.9.8y,I met a problem,please
help me.
The problem is : I upgrade the openssl form version 0.9.8w to
0.9.8y,a progress occured coredump.I finally found that the issue is:
/* Fix this function so that it takes an optional type
parameter */
X509 *SSL_get_certificate(const SSL *s)
{
* if (s->server)
return(ssl_get_server_send_cert(s));* //it changed here，and
add this two lines.
else if (s->cert != NULL)
return(s->cert->key->x509);
else
return(NULL);
}
So my question is :why you modiy this SSL_get_certificate
function?Did you modify the other codes at the same time or just this
two lines?
If I modify this function,and roll back,do I need to rolback other
code ?
Thank you very much!
The pciture is captured from the openssl0.9.8y,and the bugs and fixs
show like the following:
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
On 21/09/12 15:38, Rob Stradling via RT wrote: > On 21/09/12 15:12, Rob Stradling via RT wrote: >> On 21/09/12 15:04, Stephen Henson via RT wrote: > >>> Easiest solution is to also backport ssl_get_server_send_pkey see: >>> >>> http://cvs.openssl.org/chngview?cn=22840 >> >> I didn't think of that. Thanks! >> >> I'll prepare patches to backport 22840 to 1.0.0 and 0.9.8 (unless you or >> Ben get there first). > > http://cvs.openssl.org/patchset?cn=22840 applies cleanly (i.e. no failed > hunks) on top of my patches for 1.0.0 and 0.9.8. Steve, Ben committed my patch to the 1.0.0 branch yesterday: http://cvs.openssl.org/chngview?cn=22875 So, please would you now apply http://cvs.openssl.org/patchset?cn=22840 to the 1.0.0 branch? Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
On 21/09/12 15:12, Rob Stradling via RT wrote: On 21/09/12 15:04, Stephen Henson via RT wrote: Easiest solution is to also backport ssl_get_server_send_pkey see: http://cvs.openssl.org/chngview?cn=22840 I didn't think of that. Thanks! I'll prepare patches to backport 22840 to 1.0.0 and 0.9.8 (unless you or Ben get there first). http://cvs.openssl.org/patchset?cn=22840 applies cleanly (i.e. no failed hunks) on top of my patches for 1.0.0 and 0.9.8. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
On 21/09/12 15:04, Stephen Henson via RT wrote:
[rob.stradl...@comodo.com - Fri Sep 21 15:55:39 2012]:
Hi Steve.
I saw your update (to 1.0.2 and HEAD), and I did start looking at
backporting it into my 1.0.1/1.0.0/0.9.8 patches.
ssl_get_server_send_pkey() is not available in 1.0.1 and earlier, so the
t1_lib.c patch would have to be something like...
+ X509 *x;
+ x = ssl_get_server_send_cert)s);
+ /* If no certificate can't return certificate status */
+ if (x == NULL)
+ {
+ s->tlsext_status_expected = 0;
+ return 1;
+ }
+ /* Set current certificate to one we will use so
+* SSL_get_certificate et al can pick it up.
+*/
+ s->cert->key->x509 = x;
Is it OK to update s->cert->key->x509 like this?
No because you could end up with all sorts of bad things happening (keys
and certificates not matching, certificate types not matching and memory
leaks).
That's what I thought.
Easiest solution is to also backport ssl_get_server_send_pkey see:
http://cvs.openssl.org/chngview?cn=22840
I didn't think of that. Thanks!
I'll prepare patches to backport 22840 to 1.0.0 and 0.9.8 (unless you or
Ben get there first).
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
Hi Steve.
I saw your update (to 1.0.2 and HEAD), and I did start looking at
backporting it into my 1.0.1/1.0.0/0.9.8 patches.
ssl_get_server_send_pkey() is not available in 1.0.1 and earlier, so the
t1_lib.c patch would have to be something like...
+ X509 *x;
+ x = ssl_get_server_send_cert)s);
+ /* If no certificate can't return certificate status */
+ if (x == NULL)
+ {
+ s->tlsext_status_expected = 0;
+ return 1;
+ }
+ /* Set current certificate to one we will use so
+* SSL_get_certificate et al can pick it up.
+*/
+ s->cert->key->x509 = x;
Is it OK to update s->cert->key->x509 like this?
On 21/09/12 14:34, Stephen Henson via RT wrote:
[rob.stradl...@comodo.com - Fri Sep 21 15:02:54 2012]:
Attached are patches for 1.0.0 and 0.9.8.
Note, I updated the original change to retain compatibility with
existing behaviour as far as possible. See:
http://cvs.openssl.org/chngview?cn=22808
Steve.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
On 21/09/12 15:12, Rob Stradling via RT wrote: > On 21/09/12 15:04, Stephen Henson via RT wrote: >> Easiest solution is to also backport ssl_get_server_send_pkey see: >> >> http://cvs.openssl.org/chngview?cn=22840 > > I didn't think of that. Thanks! > > I'll prepare patches to backport 22840 to 1.0.0 and 0.9.8 (unless you or > Ben get there first). http://cvs.openssl.org/patchset?cn=22840 applies cleanly (i.e. no failed hunks) on top of my patches for 1.0.0 and 0.9.8. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
On 21/09/12 15:04, Stephen Henson via RT wrote:
>> [rob.stradl...@comodo.com - Fri Sep 21 15:55:39 2012]:
>>
>> Hi Steve.
>>
>> I saw your update (to 1.0.2 and HEAD), and I did start looking at
>> backporting it into my 1.0.1/1.0.0/0.9.8 patches.
>>
>> ssl_get_server_send_pkey() is not available in 1.0.1 and earlier, so the
>> t1_lib.c patch would have to be something like...
>>
>> +X509 *x;
>> +x = ssl_get_server_send_cert)s);
>> +/* If no certificate can't return certificate status */
>> +if (x == NULL)
>> +{
>> +s->tlsext_status_expected = 0;
>> +return 1;
>> +}
>> +/* Set current certificate to one we will use so
>> + * SSL_get_certificate et al can pick it up.
>> + */
>> +s->cert->key->x509 = x;
>>
>> Is it OK to update s->cert->key->x509 like this?
>>
>
> No because you could end up with all sorts of bad things happening (keys
> and certificates not matching, certificate types not matching and memory
> leaks).
That's what I thought.
> Easiest solution is to also backport ssl_get_server_send_pkey see:
>
> http://cvs.openssl.org/chngview?cn=22840
I didn't think of that. Thanks!
I'll prepare patches to backport 22840 to 1.0.0 and 0.9.8 (unless you or
Ben get there first).
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
Hi Steve.
I saw your update (to 1.0.2 and HEAD), and I did start looking at
backporting it into my 1.0.1/1.0.0/0.9.8 patches.
ssl_get_server_send_pkey() is not available in 1.0.1 and earlier, so the
t1_lib.c patch would have to be something like...
+ X509 *x;
+ x = ssl_get_server_send_cert)s);
+ /* If no certificate can't return certificate status */
+ if (x == NULL)
+ {
+ s->tlsext_status_expected = 0;
+ return 1;
+ }
+ /* Set current certificate to one we will use so
+* SSL_get_certificate et al can pick it up.
+*/
+ s->cert->key->x509 = x;
Is it OK to update s->cert->key->x509 like this?
On 21/09/12 14:34, Stephen Henson via RT wrote:
>> [rob.stradl...@comodo.com - Fri Sep 21 15:02:54 2012]:
>>
>> Attached are patches for 1.0.0 and 0.9.8.
>>
>>
>
> Note, I updated the original change to retain compatibility with
> existing behaviour as far as possible. See:
>
> http://cvs.openssl.org/chngview?cn=22808
>
> Steve.
>
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
Attached are patches for 1.0.0 and 0.9.8.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
Index: ssl/s3_srvr.c
===
RCS file: /v/openssl/cvs/openssl/ssl/s3_srvr.c,v
retrieving revision 1.126.2.42
diff -u -r1.126.2.42 s3_srvr.c
--- ssl/s3_srvr.c 16 Feb 2012 15:21:17 - 1.126.2.42
+++ ssl/s3_srvr.c 20 Sep 2012 14:40:41 -
@@ -1005,7 +1005,7 @@
goto f_err;
}
}
- if (ssl_check_clienthello_tlsext(s) <= 0) {
+ if (ssl_check_clienthello_tlsext_early(s) <= 0) {
SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_CLIENTHELLO_TLSEXT);
goto err;
}
@@ -1131,6 +1131,16 @@
* s->tmp.new_cipher- the new cipher to use.
*/
+ /* Handles TLS extensions that we couldn't check earlier */
+ if (s->version >= SSL3_VERSION)
+ {
+ if (ssl_check_clienthello_tlsext_late(s) <= 0)
+ {
+
SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_CLIENTHELLO_TLSEXT);
+ goto err;
+ }
+ }
+
if (ret < 0) ret=1;
if (0)
{
Index: ssl/ssl_lib.c
===
RCS file: /v/openssl/cvs/openssl/ssl/ssl_lib.c,v
retrieving revision 1.133.2.31
diff -u -r1.133.2.31 ssl_lib.c
--- ssl/ssl_lib.c 5 Jan 2012 10:21:49 - 1.133.2.31
+++ ssl/ssl_lib.c 20 Sep 2012 14:40:41 -
@@ -1943,7 +1943,7 @@
}
/* THIS NEEDS CLEANING UP */
-X509 *ssl_get_server_send_cert(SSL *s)
+X509 *ssl_get_server_send_cert(const SSL *s)
{
unsigned long alg,kalg;
CERT *c;
@@ -2420,7 +2420,9 @@
/* Fix this function so that it takes an optional type parameter */
X509 *SSL_get_certificate(const SSL *s)
{
- if (s->cert != NULL)
+ if (s->server)
+ return(ssl_get_server_send_cert(s));
+ else if (s->cert != NULL)
return(s->cert->key->x509);
else
return(NULL);
Index: ssl/ssl_locl.h
===
RCS file: /v/openssl/cvs/openssl/ssl/ssl_locl.h,v
retrieving revision 1.63.2.22
diff -u -r1.63.2.22 ssl_locl.h
--- ssl/ssl_locl.h 9 Mar 2012 15:51:56 - 1.63.2.22
+++ ssl/ssl_locl.h 20 Sep 2012 14:40:41 -
@@ -740,7 +740,7 @@
int ssl_undefined_function(SSL *s);
int ssl_undefined_void_function(void);
int ssl_undefined_const_function(const SSL *s);
-X509 *ssl_get_server_send_cert(SSL *);
+X509 *ssl_get_server_send_cert(const SSL *);
EVP_PKEY *ssl_get_sign_pkey(SSL *,SSL_CIPHER *);
int ssl_cert_type(X509 *x,EVP_PKEY *pkey);
void ssl_set_cert_masks(CERT *c, SSL_CIPHER *cipher);
@@ -979,7 +979,8 @@
int ssl_parse_serverhello_tlsext(SSL *s, unsigned char **data, unsigned char
*d, int n, int *al);
int ssl_prepare_clienthello_tlsext(SSL *s);
int ssl_prepare_serverhello_tlsext(SSL *s);
-int ssl_check_clienthello_tlsext(SSL *s);
+int ssl_check_clienthello_tlsext_early(SSL *s);
+int ssl_check_clienthello_tlsext_late(SSL *s);
int ssl_check_serverhello_tlsext(SSL *s);
#ifdef OPENSSL_NO_SHA256
Index: ssl/t1_lib.c
===
RCS file: /v/openssl/cvs/openssl/ssl/t1_lib.c,v
retrieving revision 1.13.2.30
diff -u -r1.13.2.30 t1_lib.c
--- ssl/t1_lib.c4 Jan 2012 14:25:10 - 1.13.2.30
+++ ssl/t1_lib.c20 Sep 2012 14:40:41 -
@@ -745,7 +745,7 @@
return 1;
}
-int ssl_check_clienthello_tlsext(SSL *s)
+int ssl_check_clienthello_tlsext_early(SSL *s)
{
int ret=SSL_TLSEXT_ERR_NOACK;
int al = SSL_AD_UNRECOGNIZED_NAME;
@@ -755,11 +755,34 @@
else if (s->initial_ctx != NULL &&
s->initial_ctx->tlsext_servername_callback != 0)
ret = s->initial_ctx->tlsext_servername_callback
Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
On 07/09/12 11:51, Rob Stradling wrote:
> Attached is an updated patch for CVS HEAD, plus a patch for the 1.0.2
> branch.
>
> Are you still accepting patches for 1.0.1?
Attached is a patch for 1.0.1.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Index: ssl/s3_srvr.c
===
RCS file: /v/openssl/cvs/openssl/ssl/s3_srvr.c,v
retrieving revision 1.171.2.21.2.26
diff -u -r1.171.2.21.2.26 s3_srvr.c
--- ssl/s3_srvr.c 8 Jun 2012 09:18:46 - 1.171.2.21.2.26
+++ ssl/s3_srvr.c 12 Sep 2012 15:45:12 -
@@ -1183,7 +1183,7 @@
goto f_err;
}
}
- if (ssl_check_clienthello_tlsext(s) <= 0) {
+ if (ssl_check_clienthello_tlsext_early(s) <= 0) {
SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_CLIENTHELLO_TLSEXT);
goto err;
}
@@ -1405,6 +1405,16 @@
* s->tmp.new_cipher- the new cipher to use.
*/
+ /* Handles TLS extensions that we couldn't check earlier */
+ if (s->version >= SSL3_VERSION)
+ {
+ if (ssl_check_clienthello_tlsext_late(s) <= 0)
+ {
+
SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_CLIENTHELLO_TLSEXT);
+ goto err;
+ }
+ }
+
if (ret < 0) ret=1;
if (0)
{
Index: ssl/ssl_lib.c
===
RCS file: /v/openssl/cvs/openssl/ssl/ssl_lib.c,v
retrieving revision 1.176.2.19.2.25
diff -u -r1.176.2.19.2.25 ssl_lib.c
--- ssl/ssl_lib.c 8 Jun 2012 09:18:46 - 1.176.2.19.2.25
+++ ssl/ssl_lib.c 12 Sep 2012 15:45:12 -
@@ -2287,7 +2287,7 @@
#endif
/* THIS NEEDS CLEANING UP */
-X509 *ssl_get_server_send_cert(SSL *s)
+X509 *ssl_get_server_send_cert(const SSL *s)
{
unsigned long alg_k,alg_a;
CERT *c;
@@ -2780,7 +2780,9 @@
/* Fix this function so that it takes an optional type parameter */
X509 *SSL_get_certificate(const SSL *s)
{
- if (s->cert != NULL)
+ if (s->server)
+ return(ssl_get_server_send_cert(s));
+ else if (s->cert != NULL)
return(s->cert->key->x509);
else
return(NULL);
Index: ssl/ssl_locl.h
===
RCS file: /v/openssl/cvs/openssl/ssl/ssl_locl.h,v
retrieving revision 1.100.2.10.2.17
diff -u -r1.100.2.10.2.17 ssl_locl.h
--- ssl/ssl_locl.h 9 Mar 2012 15:52:20 - 1.100.2.10.2.17
+++ ssl/ssl_locl.h 12 Sep 2012 15:45:12 -
@@ -830,7 +830,7 @@
int ssl_undefined_function(SSL *s);
int ssl_undefined_void_function(void);
int ssl_undefined_const_function(const SSL *s);
-X509 *ssl_get_server_send_cert(SSL *);
+X509 *ssl_get_server_send_cert(const SSL *);
EVP_PKEY *ssl_get_sign_pkey(SSL *s,const SSL_CIPHER *c, const EVP_MD **pmd);
int ssl_cert_type(X509 *x,EVP_PKEY *pkey);
void ssl_set_cert_masks(CERT *c, const SSL_CIPHER *cipher);
@@ -1088,7 +1088,8 @@
int ssl_parse_serverhello_tlsext(SSL *s, unsigned char **data, unsigned char
*d, int n, int *al);
int ssl_prepare_clienthello_tlsext(SSL *s);
int ssl_prepare_serverhello_tlsext(SSL *s);
-int ssl_check_clienthello_tlsext(SSL *s);
+int ssl_check_clienthello_tlsext_early(SSL *s);
+int ssl_check_clienthello_tlsext_late(SSL *s);
int ssl_check_serverhello_tlsext(SSL *s);
#ifndef OPENSSL_NO_HEARTBEATS
Index: ssl/t1_lib.c
===
RCS file: /v/openssl/cvs/openssl/ssl/t1_lib.c,v
retrieving revision 1.64.2.14.2.33
diff -u -r1.64.2.14.2.33 t1_lib.c
--- ssl/t1_lib.c27 Jun 2012 14:11:40 - 1.64.2.14.2.33
+++ ssl/t1_lib.c12 Sep 2012 15:45:12 -
@@ -1763,7 +1763,7 @@
return 1;
}
-int ssl_check_clienthello_tlsext(SSL *s)
+int ssl_check_clienthello_tlsext_early(SSL *s)
{
int ret=SSL_TLSEXT_ERR_NOACK;
int al = SSL_AD_UNRECOGNIZED_NAME;
@@ -1782,42 +1782,12 @@
else if (s->initial_ctx != NULL &&
s->initial_ctx->tlsext_servername_callback != 0)
ret = s->initial_ctx->tlsext_servername_callback(s, &al,
s->initial_ctx->tlsext_servername_arg);
- /* If status request then ask callback what to do.
-* Note: this must be called after servername callbacks in case
-* the certificate has changed.
-*/
- if ((s->tlsext_status_type != -1) && s->ctx && s->ctx->tlsext_status_cb)
- {
- int r;
- r = s->ctx->tlsext_status_cb(s, s->ctx->tlsext_status_arg);
- switch (r)
-
Re: [openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
Attached is an updated patch for CVS HEAD, plus a patch for the 1.0.2
branch.
Are you still accepting patches for 1.0.1?
Any chance of reviewing these patches soon?
Thanks.
On 19/06/12 21:15, Rob Stradling via RT wrote:
> The OCSP Stapling Callback function (s->ctx->tlsext_status_cb) is called
> during the parsing of the ClientHello message, before the server has
> decided which cipher to use. However, since the choice of cipher can
> influence which server certificate is sent, this means that the wrong
> OCSP Response may be sent in cases where multiple server certificates
> are configured.
>
> The attached patch against CVS HEAD makes the following changes:
> - Moves the s->ctx->tlsext_status_cb() call to just after the cipher
> has been chosen. This involves splitting ssl_check_clienthello_tlsext()
> into two functions: "early" and "late".
> - Updates SSL_get_certificate() so that it returns the server
> certificate that actually gets sent. (This is the function that Apache
> httpd's OCSP Stapling code calls in order to determine which OCSP
> Response to send).
>
> I've tested this patch successfully with an installation of httpd 2.4.2
> that has both an RSA cert and an ECC cert configured.
>
> If this patch is OK, I'd like to backport it to the OpenSSL 1.0.x branch
> as well.
>
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Index: ssl/s3_srvr.c
===
RCS file: /v/openssl/cvs/openssl/ssl/s3_srvr.c,v
retrieving revision 1.239
diff -u -r1.239 s3_srvr.c
--- ssl/s3_srvr.c 15 Aug 2012 15:15:05 - 1.239
+++ ssl/s3_srvr.c 7 Sep 2012 10:00:12 -
@@ -1432,6 +1432,16 @@
* s->tmp.new_cipher- the new cipher to use.
*/
+ /* Handles TLS extensions that we couldn't check earlier */
+ if (s->version >= SSL3_VERSION)
+ {
+ if (ssl_check_clienthello_tlsext_late(s) <= 0)
+ {
+
SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_CLIENTHELLO_TLSEXT);
+ goto err;
+ }
+ }
+
if (ret < 0) ret=1;
if (0)
{
Index: ssl/ssl_lib.c
===
RCS file: /v/openssl/cvs/openssl/ssl/ssl_lib.c,v
retrieving revision 1.242
diff -u -r1.242 ssl_lib.c
--- ssl/ssl_lib.c 31 Aug 2012 11:18:54 - 1.242
+++ ssl/ssl_lib.c 7 Sep 2012 10:00:12 -
@@ -2336,7 +2336,7 @@
#endif
-static int ssl_get_server_cert_index(SSL *s)
+static int ssl_get_server_cert_index(const SSL *s)
{
int idx;
idx = ssl_cipher_get_cert_index(s->s3->tmp.new_cipher);
@@ -2347,7 +2347,7 @@
return idx;
}
-CERT_PKEY *ssl_get_server_send_pkey(SSL *s)
+CERT_PKEY *ssl_get_server_send_pkey(const SSL *s)
{
CERT *c;
int i;
@@ -2833,6 +2833,14 @@
/* Fix this function so that it takes an optional type parameter */
X509 *SSL_get_certificate(const SSL *s)
{
+ if (s->server)
+ {
+ CERT_PKEY *certpkey;
+ certpkey = ssl_get_server_send_pkey(s);
+ if (certpkey && certpkey->x509)
+ return certpkey->x509;
+ }
+
if (s->cert != NULL)
return(s->cert->key->x509);
else
Index: ssl/ssl_locl.h
===
RCS file: /v/openssl/cvs/openssl/ssl/ssl_locl.h,v
retrieving revision 1.155
diff -u -r1.155 ssl_locl.h
--- ssl/ssl_locl.h 31 Aug 2012 11:18:54 - 1.155
+++ ssl/ssl_locl.h 7 Sep 2012 10:00:12 -
@@ -934,7 +934,7 @@
int ssl_undefined_function(SSL *s);
int ssl_undefined_void_function(void);
int ssl_undefined_const_function(const SSL *s);
-CERT_PKEY *ssl_get_server_send_pkey(SSL *);
+CERT_PKEY *ssl_get_server_send_pkey(const SSL *s);
unsigned char *ssl_get_authz_data(SSL *s, size_t *authz_length);
EVP_PKEY *ssl_get_sign_pkey(SSL *s,const SSL_CIPHER *c, const EVP_MD **pmd);
int ssl_cert_type(X509 *x,EVP_PKEY *pkey);
@@ -1201,6 +1201,7 @@
unsigned char *ssl_add_clienthello_tlsext(SSL *s, unsigned char *p, unsigned
char *limit);
unsigned char *ssl_add_serverhello_tlsext(SSL *s, unsigned char *p, unsigned
char *limit);
int ssl_parse_clienthello_tlsext(SSL *s, unsigned char **data, unsigned char
*d, int n);
+int ssl_check_clienthello_tlsext_late(SSL *s);
int ssl_parse_serverhello_tlsext(SSL *s, unsigned char **data, unsigned char
*d, int n);
int ssl_prepare_clienthello_tlsext(SSL *s);
int ssl_prepare_serverhello_tlsext(SSL *s);
Index: ssl/t1_lib.c
===
RCS file: /v/openssl/cvs/o
warning: ‘hash_nid’ may be used uninitialized in this function
Steve, I just noticed this warning whilst compiling CVS HEAD: t1_lib.c: In function ‘tls1_lookup_sigalg’: t1_lib.c::16: warning: ‘hash_nid’ may be used uninitialized in this function (Line number scrubbed 'cos I have local edits) The uninitialized use of hash_nid seems to be in the function's last if statement: if (sign_nid && hash_nid) I suggest: - int sign_nid, hash_nid; + int sign_nid, hash_nid = 0; -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2836] [PATCH] Staple the correct OCSP Response when multiple certs are configured
The OCSP Stapling Callback function (s->ctx->tlsext_status_cb) is called
during the parsing of the ClientHello message, before the server has
decided which cipher to use. However, since the choice of cipher can
influence which server certificate is sent, this means that the wrong
OCSP Response may be sent in cases where multiple server certificates
are configured.
The attached patch against CVS HEAD makes the following changes:
- Moves the s->ctx->tlsext_status_cb() call to just after the cipher
has been chosen. This involves splitting ssl_check_clienthello_tlsext()
into two functions: "early" and "late".
- Updates SSL_get_certificate() so that it returns the server
certificate that actually gets sent. (This is the function that Apache
httpd's OCSP Stapling code calls in order to determine which OCSP
Response to send).
I've tested this patch successfully with an installation of httpd 2.4.2
that has both an RSA cert and an ECC cert configured.
If this patch is OK, I'd like to backport it to the OpenSSL 1.0.x branch
as well.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Index: ssl/s3_srvr.c
===
RCS file: /v/openssl/cvs/openssl/ssl/s3_srvr.c,v
retrieving revision 1.233
diff -u -r1.233 s3_srvr.c
--- ssl/s3_srvr.c 6 Jun 2012 12:52:19 - 1.233
+++ ssl/s3_srvr.c 19 Jun 2012 10:59:34 -
@@ -1424,6 +1424,16 @@
* s->tmp.new_cipher- the new cipher to use.
*/
+ /* Handles TLS extensions that we couldn't check earlier */
+ if (s->version >= SSL3_VERSION)
+ {
+ if (!ssl_check_clienthello_tlsext_late(s))
+ {
+ SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_PARSE_TLSEXT);
+ goto err;
+ }
+ }
+
if (ret < 0) ret=1;
if (0)
{
Index: ssl/ssl_lib.c
===
RCS file: /v/openssl/cvs/openssl/ssl/ssl_lib.c,v
retrieving revision 1.234
diff -u -r1.234 ssl_lib.c
--- ssl/ssl_lib.c 18 Jun 2012 12:56:59 - 1.234
+++ ssl/ssl_lib.c 19 Jun 2012 10:59:34 -
@@ -2846,6 +2846,14 @@
/* Fix this function so that it takes an optional type parameter */
X509 *SSL_get_certificate(const SSL *s)
{
+ if (s->server)
+ {
+ CERT_PKEY *certpkey;
+ certpkey = ssl_get_server_send_pkey((SSL *)s);
+ if (certpkey && certpkey->x509)
+ return certpkey->x509;
+ }
+
if (s->cert != NULL)
return(s->cert->key->x509);
else
Index: ssl/ssl_locl.h
===
RCS file: /v/openssl/cvs/openssl/ssl/ssl_locl.h,v
retrieving revision 1.141
diff -u -r1.141 ssl_locl.h
--- ssl/ssl_locl.h 18 Jun 2012 12:56:59 - 1.141
+++ ssl/ssl_locl.h 19 Jun 2012 10:59:34 -
@@ -1132,6 +1132,7 @@
unsigned char *ssl_add_clienthello_tlsext(SSL *s, unsigned char *p, unsigned
char *limit);
unsigned char *ssl_add_serverhello_tlsext(SSL *s, unsigned char *p, unsigned
char *limit);
int ssl_parse_clienthello_tlsext(SSL *s, unsigned char **data, unsigned char
*d, int n);
+int ssl_check_clienthello_tlsext_late(SSL *s);
int ssl_parse_serverhello_tlsext(SSL *s, unsigned char **data, unsigned char
*d, int n);
int ssl_prepare_clienthello_tlsext(SSL *s);
int ssl_prepare_serverhello_tlsext(SSL *s);
Index: ssl/t1_lib.c
===
RCS file: /v/openssl/cvs/openssl/ssl/t1_lib.c,v
retrieving revision 1.123
diff -u -r1.123 t1_lib.c
--- ssl/t1_lib.c11 Jun 2012 09:23:55 - 1.123
+++ ssl/t1_lib.c19 Jun 2012 10:59:34 -
@@ -123,7 +123,7 @@
static int tls_decrypt_ticket(SSL *s, const unsigned char *tick, int ticklen,
const unsigned char *sess_id, int sesslen,
SSL_SESSION **psess);
-static int ssl_check_clienthello_tlsext(SSL *s);
+static int ssl_check_clienthello_tlsext_early(SSL *s);
int ssl_check_serverhello_tlsext(SSL *s);
#endif
@@ -1846,7 +1846,7 @@
return 0;
}
- if (ssl_check_clienthello_tlsext(s) <= 0)
+ if (ssl_check_clienthello_tlsext_early(s) <= 0)
{
SSLerr(SSL_F_SSL_PARSE_CLIENTHELLO_TLSEXT,SSL_R_CLIENTHELLO_TLSEXT);
return 0;
@@ -2247,7 +2247,7 @@
return 1;
}
-static int ssl_check_clienthello_tlsext(SSL *s)
+static int ssl_check_clienthello_tlsext_early(SSL *s)
{
int ret=SSL_TLSEXT_ERR_NOACK;
int al = SSL_AD_UNRECOGNIZED_NAME;
@@ -2266,42 +2266,11 @@
else if (s->
Re: OCSP Stapling bug with multiple certs (e.g. an RSA cert and an ECC cert)
On 18/06/12 11:40, Rob Stradling wrote: On 16/06/12 23:31, Dr. Stephen Henson wrote: Is there a way to patch httpd so that it can work around the limitations in the OpenSSL API and always send the correct OCSP Response? Possible changes to OpenSSL: Should the Stapling Callback function be called later in the handshake (perhaps in ssl_add_serverhello_tlsext()), after the cipher has been selected? Should ssl_get_server_send_cert() be made available for applications to call? Or should SSL_get_certificate() be updated so that it always returns the cert that the server will actually send? I can't immediately think of a clean solution to this problem. I think it makes sense for OpenSSL to return the server certificate actually used via SSL_get_certificate(). Agreed. This would avoid the need to implement a fix/workaround in the httpd code, and would presumably also mean that the OpenSSL 1.0.x branch can be fixed without breaking binary compatibility. See if adding: c->key = c->pkeys + i; to ssl_get_server_send_cert fixes this. Which it wont because the status callback is called too soon as you noted. Would moving the status callback to a sufficiently later point in the handshake work? Since it's now clear that the fix for this problem requires changing OpenSSL, I've just sent a request to the Request Tracker. I've also proposed a patch. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OCSP Stapling bug with multiple certs (e.g. an RSA cert and an ECC cert)
On 16/06/12 23:31, Dr. Stephen Henson wrote: Is there a way to patch httpd so that it can work around the limitations in the OpenSSL API and always send the correct OCSP Response? Possible changes to OpenSSL: Should the Stapling Callback function be called later in the handshake (perhaps in ssl_add_serverhello_tlsext()), after the cipher has been selected? Should ssl_get_server_send_cert() be made available for applications to call? Or should SSL_get_certificate() be updated so that it always returns the cert that the server will actually send? I can't immediately think of a clean solution to this problem. I think it makes sense for OpenSSL to return the server certificate actually used via SSL_get_certificate(). Agreed. This would avoid the need to implement a fix/workaround in the httpd code, and would presumably also mean that the OpenSSL 1.0.x branch can be fixed without breaking binary compatibility. See if adding: c->key = c->pkeys + i; to ssl_get_server_send_cert fixes this. Which it wont because the status callback is called too soon as you noted. Would moving the status callback to a sufficiently later point in the handshake work? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OCSP Stapling bug with multiple certs (e.g. an RSA cert and an ECC cert)
Using OpenSSL 1.x and Apache httpd 2.4.x, I've been trying to get OCSP Stapling to work with both an RSA cert and an ECC cert configured. The desired behaviour is (obviously) that httpd should staple the correct OCSP Response for whichever cert (RSA or ECC) it chooses to send to the client. However, I've found that it always staples the OCSP Response for the ECC cert, even when it sends the RSA cert. ssl_util_stapling.c in httpd 2.4.x calls SSL_get_certificate(), but this function appears to have no knowledge of which server cert will actually be sent to the client. I've been trying to work out how to fix the httpd code, but it doesn't look like the OpenSSL API provides a clean solution. The ssl_get_server_send_cert() function defined in ssl_lib.c would be ideal here, but since it's declared in ssl_locl.h it's not intended to be available to applications. But even if ssl_get_server_send_cert() was publicly accessible, I don't think it would actually work properly. The Stapling Callback function (s->ctx->tlsext_status_cb) is called when parsing the ClientHello message, which I believe takes place before the server has decided which cipher to use. And ssl_get_server_send_cert() needs to know which cipher has been selected. Is there a way to patch httpd so that it can work around the limitations in the OpenSSL API and always send the correct OCSP Response? Possible changes to OpenSSL: Should the Stapling Callback function be called later in the handshake (perhaps in ssl_add_serverhello_tlsext()), after the cipher has been selected? Should ssl_get_server_send_cert() be made available for applications to call? Or should SSL_get_certificate() be updated so that it always returns the cert that the server will actually send? Thanks. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2626] ENHANCEMENT: please update default_bits to 2048 in default openssl.cnf
Duplicate of ticket #2354. On Wednesday 19 Oct 2011 16:58:28 Daniel Kahn Gillmor via RT wrote: > The current default openssl.cnf appears to have default_bits = 1024: > > http://cvs.openssl.org/fileview?f=openssl/apps/openssl.cnf&v=1.23.4.6 > > however, NIST has recommended avoiding reliance on 1024-bit RSA keys > after 2010. > > See pages 63-66 of: > > http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_M > ar08-2007.pdf > > Please change default_bits in the stock openssl.cnf to 2048, or include > some clear justification for why the tool defaults to creating a > deprecated keysize. > > Thanks, > > --dkg > > __ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL Security Advisory: OCSP stapling vulnerability
Bodo, some comments inline... On Tuesday 08 Feb 2011 18:09:46 Bodo Moeller wrote: > OpenSSL Security Advisory [8 February 2011] > > OCSP stapling vulnerability in OpenSSL > Which applications are affected > --- > > Applications are only affected if they act as a server and call > SSL_CTX_set_tlsext_status_cb on the server's SSL_CTX. This includes > Apache httpd >= 2.3.3. In httpd >= 2.3.3, OCSP Stapling is currently disabled by default. To enable it, the "SSLUseStapling On" directive must be added to the config. Since SSL_CTX_set_tlsext_status_cb() is only called when OCSP Stapling has been enabled, I conclude that the default configuration is not vulnerable. A couple of months ago I proposed to httpd-dev that OCSP Stapling should be enabled by default. Steve Henson was cautiously sympathetic to the idea... "My personal opinion would be to, at least initially, require an explicit directive to enable it and leave the option in future to have it enabled by default." ...but Igor Galić replied with... "If we want to see more extensive testing in the field, then this is the right time to make 'On' the default." Maybe httpd should: 1. Check the version number of the OpenSSL runtime library. 2. Log a warning if a vulnerable OpenSSL version is detected. 3. Definitely avoid enabling Stapling by default if a vulnerable OpenSSL version is detected. (Sorry, I guess I've drifted a bit off-topic for this list). > OCSP stapling is defined in RFC 2560. RFC 2560 defines OCSP, but not OCSP Stapling. OCSP Stapling is the popular term for the Certificate Status Request TLS Extension defined most recently by RFC 6066 (previous versions: RFC 4366, RFC 3546). Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2354] [PATCH] Increase Default RSA Key Size to 2048-bits
NIST (SP800-57 Part 1) recommends a minimum RSA key size of 2048-bits beyond
2010. From January 1st 2011, in order to comply with the current Microsoft[1]
and Mozilla[2] CA Policies, Commercial CAs will no longer be permitted to
issue certificates with RSA key sizes of <2048-bit.
Please accept the attached patch, which increases the default RSA key size to
2048-bits for the "req", "genrsa" and "genpkey" apps.
Thanks.
[1] http://technet.microsoft.com/en-us/library/cc751157.aspx says:
"we have advised Certificate Authorities...to transition their subordinate and
end-certificates to 2048-bit RSA certificates, and to complete this transition
for any root certificate distributed by the Program no later than December 31,
2010".
[2] https://wiki.mozilla.org/CA:MD5and1024 says:
"December 31, 2010 – CAs should stop issuing intermediate and end-entity
certificates from roots with RSA key sizes smaller than 2048 bits. All CAs
should stop issuing intermediate and end-entity certificates with RSA key size
smaller than 2048 bits under any root".
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
Index: apps/genrsa.c
===
RCS file: /v/openssl/cvs/openssl/apps/genrsa.c,v
retrieving revision 1.40
diff -U 5 -r1.40 genrsa.c
--- apps/genrsa.c 1 Mar 2010 14:22:21 - 1.40
+++ apps/genrsa.c 28 Sep 2010 14:44:44 -
@@ -76,11 +76,11 @@
#include
#include
#include
#include
-#define DEFBITS 512
+#define DEFBITS 2048
#undef PROG
#define PROG genrsa_main
static int MS_CALLBACK genrsa_cb(int p, int n, BN_GENCB *cb);
Index: apps/openssl-vms.cnf
===
RCS file: /v/openssl/cvs/openssl/apps/openssl-vms.cnf,v
retrieving revision 1.11
diff -U 5 -r1.11 openssl-vms.cnf
--- apps/openssl-vms.cnf 23 Apr 2009 16:32:37 - 1.11
+++ apps/openssl-vms.cnf 28 Sep 2010 14:44:44 -
@@ -101,11 +101,11 @@
commonName = supplied
emailAddress = optional
[ req ]
-default_bits = 1024
+default_bits = 2048
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
Index: apps/openssl.cnf
===
RCS file: /v/openssl/cvs/openssl/apps/openssl.cnf,v
retrieving revision 1.32
diff -U 5 -r1.32 openssl.cnf
--- apps/openssl.cnf 4 Apr 2009 19:54:02 - 1.32
+++ apps/openssl.cnf 28 Sep 2010 14:44:44 -
@@ -101,11 +101,11 @@
commonName = supplied
emailAddress = optional
[ req ]
-default_bits = 1024
+default_bits = 2048
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
Index: apps/req.c
===
RCS file: /v/openssl/cvs/openssl/apps/req.c,v
retrieving revision 1.146
diff -U 5 -r1.146 req.c
--- apps/req.c 14 Mar 2010 12:54:45 - 1.146
+++ apps/req.c 28 Sep 2010 14:44:44 -
@@ -97,11 +97,11 @@
#define V3_EXTENSIONS "x509_extensions"
#define REQ_EXTENSIONS "req_extensions"
#define STRING_MASK "string_mask"
#define UTF8_IN "utf8"
-#define DEFAULT_KEY_LENGTH 512
+#define DEFAULT_KEY_LENGTH 2048
#define MIN_KEY_LENGTH 384
#undef PROG
#define PROG req_main
Index: crypto/rsa/rsa_pmeth.c
===
RCS file: /v/openssl/cvs/openssl/crypto/rsa/rsa_pmeth.c,v
retrieving revision 1.39
diff -U 5 -r1.39 rsa_pmeth.c
--- crypto/rsa/rsa_pmeth.c 1 Jun 2010 14:39:01 - 1.39
+++ crypto/rsa/rsa_pmeth.c 28 Sep 2010 14:44:44 -
@@ -91,11 +91,11 @@
{
RSA_PKEY_CTX *rctx;
rctx = OPENSSL_malloc(sizeof(RSA_PKEY_CTX));
if (!rctx)
return 0;
- rctx->nbits = 1024;
+ rctx->nbits = 2048;
rctx->pub_exp = NULL;
rctx->
[openssl.org #2206] [PATCH] Implicitly support non-delegated OCSP response signing
it would typically require giving a public responder access to a > > > > CA key: increasing the risk of compromise especially if the private > > > > key itself is placed on the server. > > > > > > Steve, I think it's entirely unfair to label the non-delegated model as > > > "not recommended for security reasons" just because *some > > > implementations* might give "a public responder access to a CA key". > > > > > Yes sorry I should've qualified that statement. I was attempting to keep > > this simple and that always includes the risk of oversimplification. > > Steve, thanks for explaining. > > > > > Though of course the delegated trust model can also support pre-produced > > OCSP responses. > > That's true. > > By the way Steve, I'd like to propose a small change to "openssl ocsp" to > support the non-delegated model more seamlessly. I've always been > surprised and slightly confused that you have to specify both "-issuer > ca.pem" and "- VAfile ca.pem" to verify the signature on a non-delegated > OCSP Response. Why doesn't "-issuer ca.pem" cause ca.pem to be treated as > a candidate OCSP Response signer certificate? > > When, a couple of weeks ago, a colleague independently made the same > observation and asked me that same question, it spurred me to write a > patch. > > Would you be happy with this change in behaviour? If so, I'll submit my > patch to the Request Tracker. > > > Steve. > > -- > > Dr Stephen N. Henson. OpenSSL project core developer. > > Commercial tech support now available see: http://www.openssl.org > > __ > > OpenSSL Project http://www.openssl.org > > User Support Mailing Listopenssl-us...@openssl.org > > Automated List Manager majord...@openssl.org > > Rob Stradling > Senior Research & Development Scientist > C·O·M·O·D·O - Creating Trust Online > Office Tel: +44.(0)1274.730505 > Office Fax: +44.(0)1274.730909 > www.comodo.com > > Comodo CA Limited, Registered in England No. 04058690 > Registered Office: > 3rd Floor, 26 Office Village, Exchange Quay, > Trafford Road, Salford, Manchester M5 3EQ > > This e-mail and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the sender by > replying to the e-mail containing this attachment. Replies to this email > may be monitored by Comodo for operational or business reasons. Whilst > every endeavour is taken to ensure that e-mails are free from viruses, no > liability can be accepted and the recipient is requested to use their own > virus checking software. > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-us...@openssl.org > Automated List Manager majord...@openssl.org Rob Stradling Senior Research & Development Scientist C·O·M·O·D·O - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. --- openssl-0.9.8n/apps/ocsp.c 2008-11-05 18:36:35.0 + +++ openssl-0.9.8n-modified/apps/ocsp.c 2010-03-26 09:22:30.0 + @@ -118,7 +118,7 @@ long nsec = MAX_VALIDITY_PERIOD, maxage = -1; char *CAfile = NULL, *CApath = NULL; X509_STORE *store = NULL; - STACK_OF(X509) *sign_other = NULL, *verify_other = NULL, *rother = NULL; + STACK_OF(X509) *sign_other = NULL, *verify_other = NULL, *rother = NULL, *issuer_st = NULL; char *sign_certfile = NULL, *verify_certfile = NULL, *rcertfile = NULL; unsigned long sign_flags = 0, verify_flags = 0, rflags = 0; int ret = 1; @@ -389,6 +389,8 @@ issuer = load_cert(bio
