Re: [openssl-users] OpenSSL Release Strategy and Blog
> For comparison, Microsoft I'm not quite sure how we should respond to any paragraph that begins with those words. :) > I respectfully disagree. We, the OpenSSL dev team, all do. The release strategy document is the strong consensus of the entire team. -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL Release Strategy and Blog
On 28/12/14 00:31, Jakob Bohm wrote: > On 24-12-2014 00:49, Matt Caswell wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> You will have noticed that the OpenSSL 1.0.0 End Of Life Announcement >> contained a link to the recently published OpenSSL Release Strategy that >> is available here: >> https://www.openssl.org/about/releasestrat.html >> >> I have put up a blog post on the thinking behind this strategy on the >> newly created OpenSSL Blog that you may (or may not!) find interesting. >> It can be found here: >> https://www.openssl.org/blog/blog/2014/12/23/the-new-release-strategy/ > > I am afraid that this is a somewhat rush decision, with insufficient > consideration for the impact on others: Not at all. This decision has been under consideration for some considerable period of time with much discussion of the impacts. > > 1. Because this was announced during the Xmas/New year holidays, many > parties will not see this until the beginning of 2015. > > 2. The decision that 1.0.0 and 1.0.1 should both be classed as a STS > releases seems new, and is unlikely to have been anticipated by many > "users". Many will have naturally assumed that 1.0.0 would last as > long as 0.9.8 lasted. > > So announcing the imminent death of 1.0.0 at the same time as 0.9.8 > is going to be a nasty surprise to anyone who already froze their > projects on the 1.0.0 series rather than the new and more unstable > 1.0.1 series. 1.0.0 will have been around for over 5.5 years by the time it is finally retired. That's quite a healthy lifetime for any product. We are giving a whole year of notice before it is withdrawn. We have committed to continue to support 1.0.1 for another 2 years - and it has already been out for over 2.5 years. Calling either of these STS releases seems quite unfair. > > 3. The 1.0.x binary compatibility promise seems to not have been > completely kept. As recently as just this December, As a practical > example: I had an OS upgrade partially fail due to the presence of > a self-compiled up to date 1.0.1* library that conflicted with an > OS supplied 1.0.x library that was frozen earlier while relying on > your promise. I'm not sure what you are referring to here. However as Kurt has pointed out the same options have to be applied for binary compatibility to work. > > Also the 1.0.1 changelog includes at least one change of binary > flag values to get a different compatibility behavior than > previous 1.0.1 releases, thus there is not even binary > compatibility within 1.0.1 . > > 4. LTS release periods have an absolute need to overlap, such that > at any given date, there is at least one active LTS release known > not to end within the next many years, otherwise the whole concept > is useless. On any given day of the year (except, perhaps, holidays), > a project somewhere is going to look at available tool and library > releases and decide which one is most likely to be supportable for > the next N years, then irreversibly freeze on that version. So if > OpenSSL has no active long term release with at least 3 to 5 years > left, then OpenSSL is not viable or projects will have to incur the > cost of having security-novices backport security fixes manually > to an unsupported version for the remainder of the needed N years. > > Accordingly the policy should be that there will always be at least > one LTS release which is at least one year old and has at least 5 > years left before security support ends. > For comparison, Microsoft > usually promises security fixes for 10 years after release, non- > critical fixes for only 5, and people still complain loudly when the > 10 year period is up for e.g. NT 4.0 and XP. We are simply unable to provide that level of support - we just don't have the resources to do it. We're not Microsoft or anything remotely like it in terms of resources. At the same time as we have a set of users demanding long term support, we also have other users demanding the latest functionality and releases much more frequently. No matter what we decide we are never going to please everyone. This is our best attempt at balancing all of the various demands. We were keenly aware of the impacts that it would have and these decisions have caused us much debate about how best to balance things. No decisions were taken lightly. > > Since you have already announced the upcoming end of 0.9.8, you > must choose one of the stabilized 1.0.x releases (1.0.0 or 1.0.1) > as the new LTS release, and you need to deal with the fact that > since the 0.9.8 end-of-life announcement, you have been unclear > which of the two existing 1.0.x releases would be LTS-security, > causing some projects (not mine, fortunately) to irreversibly > pick a different one than you did. > > 5. Since its original release as part of SSLeay, libcrypt has become > the dominant BSD-licensed library of raw crypto primitives for all > sorts of uses, s
[openssl-users] Problems verifying OCSP signatures
Hi All,
I'm trying to get some code to verify the signature of an OCSP response to
work properly and I'm hitting quite a few road blocks. I've also been
talking
to the curl developers who are having the same problems and I wondered if
anyone can help us.
I've tried 3 different ways of handling the verification and none of them
seem
to work reliably. All 3 work properly for checking the OCSP status of
www.google.com, but they all fail when testing revoked.grc.com and tn123.org
.
I'm sure I must be doing something wrong, but I've no idea what and there
seems to be very little documentation in this area. I've put the 3
approaches
I've tried below in case anyone has any ideas. Note that the reason all the
openssl symbols has a q_XXX prefix is just due to a dlopen shim and doesn't
change the behaviour of the functions at all.
If anyone has any suggestions of what I'm doing wrong then please let me
know.
Thanks
Rich.
/**
* This version takes the whole issuer chain, and adds them as
intermediates.
* It also sets up the CA store.
*/
bool QSslOcspReply::hasValidSignature1(const QList
&issuers) const
{
// Create the certificate store
X509_STORE *certStore = q_X509_STORE_new();
if (!certStore) {
qWarning() << "Unable to create certificate store";
return false;
}
// Build a stack to put the issuer in
STACK_OF(X509) *intermediates = 0;
intermediates = (STACK_OF(X509) *) q_sk_new_null();
if (!intermediates) {
q_X509_STORE_free(certStore);
return false;
}
#if OPENSSL_VERSION_NUMBER >= 0x1000L
foreach (const QSslCertificate &cert, issuers)
q_sk_push( (_STACK *)intermediates, reinterpret_cast(cert.handle()));
#else
foreach (const QSslCertificate &cert, issuers)
q_sk_push( (STACK *)intermediates, reinterpret_cast(cert.handle()));
#endif
foreach (const QSslCertificate &caCertificate,
QSslSocket::defaultCaCertificates())
q_X509_STORE_add_cert(certStore, (X509 *)caCertificate.handle());
int verifyResult = q_OCSP_basic_verify(d->basicresp, intermediates,
certStore, OCSP_TRUSTOTHER);
// A verify result is a failure if it is 0 or less
if (verifyResult <= 0) {
unsigned long errnum = q_ERR_get_error();
const char *error = q_ERR_error_string(errnum, 0);
qDebug() << "OCSP response verification failed" << verifyResult;
qDebug() << "Error was: " << error;
// ### TODO: Fix mem leak
return false;
}
qDebug() << "OCSP response verification good";
#if OPENSSL_VERSION_NUMBER >= 0x1000L
q_sk_free( (_STACK *) intermediates);
#else
q_sk_free( (STACK *) intermediates);
#endif
q_X509_STORE_free(certStore);
return true;
}
/**
* This version takes the whole issuer chain, and adds them as
intermediates.
* It does not set up any CAs.
*/
bool QSslOcspReply::hasValidSignature2(const QList
&issuers) const
{
// Create the certificate store
X509_STORE *certStore = q_X509_STORE_new();
if (!certStore) {
qWarning() << "Unable to create certificate store";
return false;
}
// Build a stack to put the issuer in
STACK_OF(X509) *intermediates = 0;
intermediates = (STACK_OF(X509) *) q_sk_new_null();
if (!intermediates) {
q_X509_STORE_free(certStore);
return false;
}
#if OPENSSL_VERSION_NUMBER >= 0x1000L
foreach (const QSslCertificate &cert, issuers)
q_sk_push( (_STACK *)intermediates, reinterpret_cast(cert.handle()));
#else
foreach (const QSslCertificate &cert, issuers)
q_sk_push( (STACK *)intermediates, reinterpret_cast(cert.handle()));
#endif
int verifyResult = q_OCSP_basic_verify(d->basicresp, intermediates,
certStore, OCSP_TRUSTOTHER);
// A verify result is a failure if it is 0 or less
if (verifyResult <= 0) {
unsigned long errnum = q_ERR_get_error();
const char *error = q_ERR_error_string(errnum, 0);
qDebug() << "OCSP response verification failed" << verifyResult;
qDebug() << "Error was: " << error;
// ### TODO: Fix mem leak
return false;
}
qDebug() << "OCSP response verification good";
#if OPENSSL_VERSION_NUMBER >= 0x1000L
q_sk_free( (_STACK *) intermediates);
#else
q_sk_free( (STACK *) intermediates);
#endif
q_X509_STORE_free(certStore);
return true;
}
/**
* This version takes the just the actual issuer, and adds it as an
intermediate.
* It does not set up any CAs.
*/
bool QSslOcspReply::hasValidSignature3(const QSslCertificate &issuer) const
{
// Create the certificate store
X509_STORE *certStore = q_X509_STORE_new();
if (!certStore) {
qWarning() << "Unable to create certificate store";
return false;
}
// Build a stack to put the issuer in
STACK_OF(X509) *intermediates = 0;
intermediates = (STACK_OF(X509) *) q_sk_new_null();
if (!intermediates) {
q_X509_STORE_free(certStore);
return fa
Re: [openssl-users] OpenSSL Release Strategy and Blog
On Sun, Dec 28, 2014 at 01:31:38AM +0100, Jakob Bohm wrote: > 3. The 1.0.x binary compatibility promise seems to not have been > completely kept. As recently as just this December, As a practical > example: I had an OS upgrade partially fail due to the presence of > a self-compiled up to date 1.0.1* library that conflicted with an > OS supplied 1.0.x library that was frozen earlier while relying on > your promise. Can you give more details about this? Please note the binary compatibility will only work if you used the same options to build the library. (This is one of the reasons to make more structures opaque.) > Also the 1.0.1 changelog includes at least one change of binary > flag values to get a different compatibility behavior than > previous 1.0.1 releases, thus there is not even binary > compatibility within 1.0.1 . I assume you're talking about SSL_OP_NO_TLSv1_1? It's unfortunate that SSL_OP_ALL already contained that in 1.0.0 while 1.0.0 doesn't even know anything about TLS 1.1. But that only affects people who compiled with 1.0.1 or 1.0.1a headers. > must choose one of the stabilized 1.0.x releases (1.0.0 or 1.0.1) > as the new LTS release, and you need to deal with the fact that > since the 0.9.8 end-of-life announcement, you have been unclear > which of the two existing 1.0.x releases would be LTS-security, > causing some projects (not mine, fortunately) to irreversibly > pick a different one than you did. I think people should stop using both 0.9.8 and 1.0.0 as soon as possible since they do not support TLS 1.2. You really want to use TLS 1.2. > The best you can do is to split libcrypt into two or tree well > defined layers, that can be mixed in applications but do not break > their layering internally. These could be: rawalgs (non-opaque > software primitives, bignums etc. with CPU acceleration but > nothing more fancy) I don't think we intend to remove functions like AES_* yet but might deprecate them in favour APIs that exist for a very long time. Please note that for instance using the AES functions you do not have AESNI acceleration but by using the EVP interfance you do. Kurt ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
