Re: What does cache field in X509_STORE struct do?
On 2009.10.13 at 18:20:12 +0200, Dr. Stephen Henson wrote: > > There is some additional logic for CRLs though. In by_dir.c it stores the last > suffix value of a CRL so if you have CRL links: This logic have to be clearly documented in the X509_LOOKUP_hash_dir manual page. I'd write what I've learned from this letter, but I hope, you'll read and improve it. Because it is critically important information for utilities which update hashed directory - that new CRL should be added, rather than replace outdating ones. Of course, keeping history in the hashed directory makes some sense. > It notes that "r3" is the last CRL looked up if now a new one is added: > > 12345678.r4 > > it only looks for r4 and doesn't reload all the (potentially large) previous > CRLs. The logic is that CRLs change far more regularly than certificates. > > Though in certificates the likelihood of matching hash values is far less. This is place I've not got complete understanding from the code reading. In our case we need to perform root certificate rollover each year. But I'm not sure yet, that if new root certificate would be issued with same DN (but, of course, different subjectKeyIdentifier) certificate chains would be constructed properly. Idea is that root certificate is issued with validity period of two years, but is changed year after. And client certificates are issued with validity period 1 year. So root certificate expires same day as last certificate possible signed by it is expired. Of course, it is possible to add something to DN of new root certificate, such as serialNumber or UID, and increment this field each time new certificate is issued. I also have an idea of issuing certificate for old CA key signed by new CA key, so new client which joined system after rollover have to manually install only one, current, CA certificate (manually install means - compare fingerprint with some printed document), and older certificates are verified with chain of length 2. But this is just marginal usablity improvement. So, if chain of two certificates with identical DN cannot be built, it is not a big problem. __ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
Re: What does cache field in X509_STORE struct do?
On Tue, Oct 13, 2009, Victor B. Wagner wrote:
> --- x509_lu.c.orig 2009-10-13 17:23:48.0 +0400
> +++ x509_lu.c 2009-10-13 17:24:15.0 +0400
> @@ -290,7 +290,7 @@
>
> tmp=X509_OBJECT_retrieve_by_subject(ctx->objs,type,name);
>
> - if (tmp == NULL || type == X509_LU_CRL)
> + if (!cache || tmp == NULL || type == X509_LU_CRL)
> {
> for
> (i=vs->current_method;
>
> iget_cert_methods);
>
> i++)
>
> {
>
> This solution has drawback that it doesn't save memory used by cache,
> but it would make X509_STORE repeat search in the hashed directory each
> time if cache is disabled.
>
> And it still allow examining cache for additional matches. after search
>
> I've now noticed that three years ago you've already commited fix
> that makes search for CRLs each time.
>
There is some additional logic for CRLs though. In by_dir.c it stores the last
suffix value of a CRL so if you have CRL links:
12345678.r0
12345678.r1
12345678.r2
12345678.r3
It notes that "r3" is the last CRL looked up if now a new one is added:
12345678.r4
it only looks for r4 and doesn't reload all the (potentially large) previous
CRLs. The logic is that CRLs change far more regularly than certificates.
Though in certificates the likelihood of matching hash values is far less.
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
Development Mailing List [email protected]
Automated List Manager [email protected]
Re: What does cache field in X509_STORE struct do?
On 2009.10.13 at 14:30:50 +0200, Dr. Stephen Henson wrote:
> On Mon, Oct 12, 2009, Victor B. Wagner wrote:
>
> >
> > 2. Make X509_LOOKUP_hash_dir lookup method honour cache field in the
> > X509_STORE structure. (I think that it is better to make this field
> > a bit mask and interpret constants X509_LU_CERT and X509_LU_CRL as
> > bit flags, but it would conflict with X509_LU_PKEY constant, which
> > seems to be unused anyway. But for first time handle this field as
> > boolean flag is better than nothing)
> >
>
> Ah I just remembered something about how this works which makes disabling
> caching more complex.
>
> The X509_LOOKUP API retrieves one matching object: that's a limitation of the
> API. It however populates the cache with all matching objects. The API
> limitation can be worked around by examining the cache after a lookup.
>
> If you disable the cache without having something equivalent to retrieve
> multiple matching objects you can stop verificaion working properly in some
> cases, for example:
>
> 1. CRLs with only partial scope (deltas and partitioned ones).
> 2. Certificates with different AKID but same subject names.
> 3. Historical checks on chains using certificates and/or CRLs that are not
> current.
>
> Admittedly #3 isn't likely to be used much but in the case of #1 and #2 some
> paths will just fail to verify. We'd at least need to document that: in many
> cases such features wont be used so it wont matter.
>
This can be solved by just one-line patch
--- x509_lu.c.orig 2009-10-13 17:23:48.0 +0400
+++ x509_lu.c 2009-10-13 17:24:15.0 +0400
@@ -290,7 +290,7 @@
tmp=X509_OBJECT_retrieve_by_subject(ctx->objs,type,name);
- if (tmp == NULL || type == X509_LU_CRL)
+ if (!cache || tmp == NULL || type == X509_LU_CRL)
{
for
(i=vs->current_method;
iget_cert_methods);
i++)
{
This solution has drawback that it doesn't save memory used by cache,
but it would make X509_STORE repeat search in the hashed directory each
time if cache is disabled.
And it still allow examining cache for additional matches. after search
I've now noticed that three years ago you've already commited fix
that makes search for CRLs each time.
__
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
Re: What does cache field in X509_STORE struct do?
On Tue, Oct 13, 2009, Victor B. Wagner wrote: > > > In that vein we'd need to document X509_STORE_CTX, X509_verify_cert() and > > X509_VERIFY_PARAM (and related functions). Some of this could just copy and > > paste or point to some existing documentation for the verify utility. > > Now I'm attaching a pod file which documents parts of X509_STORE API > which is needed to initialize X509_STORE for verifying PKCS7/CMS/TS_response > and altering behavoir of SSL_CTX certificate validation, because I've > already written it. > > X509_STORE_CTX, X509_VERIFY_PARAM and X509_LOOKUP_hash_dir/X509_LOOKUP_file > documents would follow. OK thanks. I'll have a look at that. I'll add some documentation for X509_VERIFY_PARAM myself when I have time (I'm more familiar with it having written the stuff). 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 Development Mailing List [email protected] Automated List Manager [email protected]
Re: What does cache field in X509_STORE struct do?
On 2009.10.13 at 14:12:22 +0200, Dr. Stephen Henson wrote: > On Tue, Oct 13, 2009, Victor B. Wagner wrote: > > > On 2009.10.12 at 19:00:30 +0200, Dr. Stephen Henson wrote: > > > > > > > > Well we are in the middle of a beta relase cycle so making incompatible > > > changes and/or major new functionality isn't an option. > > > > Is this (#2) a major new functionality, given that cache field in > > X509_CTX is already here and applications rely on it? > > > > If it breaks existing applications yes, if it is a bugfix no. I think in this > case it is arguably "fixing" something which is broken so it could come under > that. It shouldn't break existing applications, which do not care about cache field, because X509_STORE_new initializes it to 1 (may be change it to 0xfff for future use of bitfield just now). It would probably fix stunnel, which sets cache for CRL store to 0 and expects CRLs to be reloaded. > I'd suggest using a bitfield in this case but you need rather more flags than > just each type of object. For example some application which need to verify > certificates at times in the past might want to keep expired objects around. So, we have at least two flags for each type of object 1 << X509_LU_whaterver and X509_LU_KEEP_EXPIRED << X509_LU_whatever > Although applications don't use X509_STORE_CTX directly they do use it and > related APIs indirectly and some understading of how these structures interact > would help. Of course. > In that vein we'd need to document X509_STORE_CTX, X509_verify_cert() and > X509_VERIFY_PARAM (and related functions). Some of this could just copy and > paste or point to some existing documentation for the verify utility. Now I'm attaching a pod file which documents parts of X509_STORE API which is needed to initialize X509_STORE for verifying PKCS7/CMS/TS_response and altering behavoir of SSL_CTX certificate validation, because I've already written it. X509_STORE_CTX, X509_VERIFY_PARAM and X509_LOOKUP_hash_dir/X509_LOOKUP_file documents would follow. =pod =head1 NAME X509_STORE_new, X509_STORE_free, X509_STORE_load_locations, X509_STORE_set_default_paths, X509_STORE_add_cert, X509_STORE_add_crl, X509_verify_cert, X509_STORE_add_lookup, X509_STORE_set_flags, X509_STORE_set_purpose, X509_STORE_set_depth, X509_STORE_set1_param X509_STORE_set_verify_cb_func, X509_STORE_set_trust - manipulate trusted certificate store =head1 SYNOPSIS #include X509_STORE *X509_STORE_new(); void X509_STORE_free(X509_STORE *store); int X509_STORE_load_locations (X509_STORE *store, const char *file, const char *dir); int X509_store_set_default_paths(X509_STORE *store); int X509_STORE_add_cert(X509_STORE *store, X509 *cert); X509_LOOKUP *X509_STORE_add_lookup(X509_STORE *store, X509_LOOKUP_METHOD *m); int X509_STORE_add_crl(X509_STORE *store, X509_CRL *crl); int X509_STORE_set1_param(X509_STORE *store, X509_VERIFY_PARAM *param); int X509_STORE_set_flags(X509_STORE *store, unsigned long flags); int X509_STORE_set_purpose(X509_STORE *store, int purpose); int X509_STORE_set_trust(X509_STORE *store, int trust); int X509_STORE_set_depth(X509_STORE *store, int depth); X509_STORE_set_verify_cb_func(X509_STORE *store, int (*verify_cb)(int ok, X509_STORE_CTX *ctx)) =head1 DESCRIPTION B structure holds information, neccessary for certificate verification process. This information include set of trusted CA certificates and corresponding CRLs, various flags modifying verification process and additional information such as required certificate purpose and policy. This structure can be passed to L and L functions. When SSL_CTX is created, it creates B internally. This store can be obtained using L function and its behavoir modified by setting flags and other verification parameters. It is also possible to replace internally created B by custom one using L. B doesn't neccessary hold all trusted certificates and CRLs in itself. There is flexible mechanism of B which allows to implement own certificate storage, for example with relational database backend or LDAP. OpenSSL implements two simple lookup methods: L and L. Users typically don't need to create instances of these lookup methods explicitely. They are created in the B (or L). Actual certificate verification, lookup and chain building is performed by B object, which is created based on B object. Unless application need to check certificates and CRLs by its own, it doesn't need to create B, it would be created internally by SSL or PKCS7/CMS API functions. =head2 CREATING X509_STORE AND SETTING LOCATIONS AND CALLBACKS Typically SSL applications do not create B explicitely, because it is created implicitely by libssl, and libssl provides own API to do basic initialization of B. But applications which use L or L have to do it manually, because these functions expect to receive ready to use B. Function B creates new empty certificate store. Before this store can
Re: What does cache field in X509_STORE struct do?
On Tue, Oct 13, 2009, Victor B. Wagner wrote: > On 2009.10.12 at 19:00:30 +0200, Dr. Stephen Henson wrote: > > > > > Well we are in the middle of a beta relase cycle so making incompatible > > changes and/or major new functionality isn't an option. > > Is this (#2) a major new functionality, given that cache field in > X509_CTX is already here and applications rely on it? > If it breaks existing applications yes, if it is a bugfix no. I think in this case it is arguably "fixing" something which is broken so it could come under that. > > Handling multi-megabyte CRLs is problematical in any cases. OpenSSL > > typically > > trebles the size of them at least when storing in memory for example. > > Servers > > which use fork() and are not multithreaded will suffer big perormance hits > > reloading such CRLs. > > This is why I suggest this feature be controllable using cache field of > X509_STORE. Application writer can than decide what is worse for him - > performance hit from reloading of CRLs or interrupt of service, required > when reload of server needed each time CRL is issued. > I'd suggest using a bitfield in this case but you need rather more flags than just each type of object. For example some application which need to verify certificates at times in the past might want to keep expired objects around. Since cache is unused it could (for example) use (1 << X509_LU_WHATEVER) for flags which avoids clashes with X509_LU_PKEY, though as you note that is currently unused. > > > Documentation I think should really concentrate on the verification > > mechanism > > and X509_STORE_CTX. X509_STORE is badly broken and was supposed to have been > > replaced long ago but that hasn't happened for various reasongs. > > Documentation should concentrate on how to do the right thing. > > For most purposes the right thing is to point OpenSSL to the trusted store > directory/file, set neccessary X509_V_FLAGs and let it care about the > rest. > > With current API typical application writer never sees X509_STORE_CTX. > > 1. SSL_CTX allows him to get pointer to X509_STORE, not X509_STORE_CTX > in order to set flags or may be cache field. > > Locations, callbacks and such is set using SSL_CTX API. > > 2. PKCS7_verify and CMS_verify receive X509_STORE, not X509_STORE_CTX. > > These two cases cover about 99% of use of the trusted certificate store > in the applications. > > Rest would be probably attempts to implement application-specific lookup > method, say store trusted certificates and CRLs in the SQL database. > > Only application where I myself had to create X509_STORE_CTX in my code > was PKI Client application which handles certificates and CRLs received > from CA and put it into the right place (doing some checks). There I > have to use X509_STORE_CTX to manually check certificates and manually > lookup CRLs (because there is no CRL validation function analougue to > X509_verify_cert). > > I think that describing life cycle of CA certificates and CRLs is much > more imporaint than details of X509_STORE_CTX API. Although details of > verification process are, of course, important. > > But this process is already documented in the verify(1) man page. > Only reference to this page can be made in the X509_verify_cert(3) man > page. Some flags can be described just as reference to corresponding > verify(1) option. But some flags, such as X509_V_FLAG_USE_CHECK_TIME do > not have corresponding command line option in the verify command,. > And some (such as X509_V_FLAG_CB_ISSUER_CHECK and > X509_V_FLAG_NOTIFY_POLICY) have quite different semantic on API level > than on command-line level. > Although applications don't use X509_STORE_CTX directly they do use it and related APIs indirectly and some understading of how these structures interact would help. In that vein we'd need to document X509_STORE_CTX, X509_verify_cert() and X509_VERIFY_PARAM (and related functions). Some of this could just copy and paste or point to some existing documentation for the verify utility. 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 Development Mailing List [email protected] Automated List Manager [email protected]
Re: What does cache field in X509_STORE struct do?
On Mon, Oct 12, 2009, Victor B. Wagner wrote: > > 2. Make X509_LOOKUP_hash_dir lookup method honour cache field in the > X509_STORE structure. (I think that it is better to make this field > a bit mask and interpret constants X509_LU_CERT and X509_LU_CRL as > bit flags, but it would conflict with X509_LU_PKEY constant, which > seems to be unused anyway. But for first time handle this field as > boolean flag is better than nothing) > Ah I just remembered something about how this works which makes disabling caching more complex. The X509_LOOKUP API retrieves one matching object: that's a limitation of the API. It however populates the cache with all matching objects. The API limitation can be worked around by examining the cache after a lookup. If you disable the cache without having something equivalent to retrieve multiple matching objects you can stop verificaion working properly in some cases, for example: 1. CRLs with only partial scope (deltas and partitioned ones). 2. Certificates with different AKID but same subject names. 3. Historical checks on chains using certificates and/or CRLs that are not current. Admittedly #3 isn't likely to be used much but in the case of #1 and #2 some paths will just fail to verify. We'd at least need to document that: in many cases such features wont be used so it wont matter. 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 Development Mailing List [email protected] Automated List Manager [email protected]
Re: What does cache field in X509_STORE struct do?
On 2009.10.12 at 19:00:30 +0200, Dr. Stephen Henson wrote: > > Well we are in the middle of a beta relase cycle so making incompatible > changes and/or major new functionality isn't an option. Is this (#2) a major new functionality, given that cache field in X509_CTX is already here and applications rely on it? > Handling multi-megabyte CRLs is problematical in any cases. OpenSSL typically > trebles the size of them at least when storing in memory for example. Servers > which use fork() and are not multithreaded will suffer big perormance hits > reloading such CRLs. This is why I suggest this feature be controllable using cache field of X509_STORE. Application writer can than decide what is worse for him - performance hit from reloading of CRLs or interrupt of service, required when reload of server needed each time CRL is issued. > Documentation I think should really concentrate on the verification mechanism > and X509_STORE_CTX. X509_STORE is badly broken and was supposed to have been > replaced long ago but that hasn't happened for various reasongs. Documentation should concentrate on how to do the right thing. For most purposes the right thing is to point OpenSSL to the trusted store directory/file, set neccessary X509_V_FLAGs and let it care about the rest. With current API typical application writer never sees X509_STORE_CTX. 1. SSL_CTX allows him to get pointer to X509_STORE, not X509_STORE_CTX in order to set flags or may be cache field. Locations, callbacks and such is set using SSL_CTX API. 2. PKCS7_verify and CMS_verify receive X509_STORE, not X509_STORE_CTX. These two cases cover about 99% of use of the trusted certificate store in the applications. Rest would be probably attempts to implement application-specific lookup method, say store trusted certificates and CRLs in the SQL database. Only application where I myself had to create X509_STORE_CTX in my code was PKI Client application which handles certificates and CRLs received from CA and put it into the right place (doing some checks). There I have to use X509_STORE_CTX to manually check certificates and manually lookup CRLs (because there is no CRL validation function analougue to X509_verify_cert). I think that describing life cycle of CA certificates and CRLs is much more imporaint than details of X509_STORE_CTX API. Although details of verification process are, of course, important. But this process is already documented in the verify(1) man page. Only reference to this page can be made in the X509_verify_cert(3) man page. Some flags can be described just as reference to corresponding verify(1) option. But some flags, such as X509_V_FLAG_USE_CHECK_TIME do not have corresponding command line option in the verify command,. And some (such as X509_V_FLAG_CB_ISSUER_CHECK and X509_V_FLAG_NOTIFY_POLICY) have quite different semantic on API level than on command-line level. > 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 > Development Mailing List [email protected] > Automated List Manager [email protected] > __ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
Re: What does cache field in X509_STORE struct do?
On Mon, Oct 12, 2009, Victor B. Wagner wrote: > On 2009.10.12 at 14:49:23 +0200, Dr. Stephen Henson wrote: > > > On Mon, Oct 12, 2009, Victor B. Wagner wrote: > > > > > > > > BTW, it seems that most applications which actualy use CRLs, such as > > > Apache, openvpn and stunnel, do implement lookup of certicate in the CRL > > > in its own code, not relying on X509_V_FLAG_CRL_CHECK in X509_STORE. > > > > > > > > > > In some cases CRL lookup is done manually because the code originates from a > > time when OpenSSL didn't perform its own CRL lookup. > > I can provide in some reasonable timeframe (say, this week) a patch with > following functionality: > > 1. Somehow document X509_STORE object. It would require proofreading, > because I do not have experience with big certification authorities with > multimegabyte CRLs and multilevel secondary CA hierarchy (where security > problems you mention are applicable). But I'm sure it is better than > nothing > > 2. Make X509_LOOKUP_hash_dir lookup method honour cache field in the > X509_STORE structure. (I think that it is better to make this field > a bit mask and interpret constants X509_LU_CERT and X509_LU_CRL as > bit flags, but it would conflict with X509_LU_PKEY constant, which > seems to be unused anyway. But for first time handle this field as > boolean flag is better than nothing) > > 3. Make X509_LOOKUP_hash_dir check notAfter field of certificate and > nextUpdate field of CRL and attempt to reload CRL/certificate from > disk if cached copy in the memory have been expired. > > Does this plan seems to be acceptable intermediate solution? > Well we are in the middle of a beta relase cycle so making incompatible changes and/or major new functionality isn't an option. The functionality for #3 should already be in 1.0.0. Though it permits CRLs to coexist with different dates. Handling multi-megabyte CRLs is problematical in any cases. OpenSSL typically trebles the size of them at least when storing in memory for example. Servers which use fork() and are not multithreaded will suffer big perormance hits reloading such CRLs. Documentation I think should really concentrate on the verification mechanism and X509_STORE_CTX. X509_STORE is badly broken and was supposed to have been replaced long ago but that hasn't happened for various reasongs. 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 Development Mailing List [email protected] Automated List Manager [email protected]
Re: What does cache field in X509_STORE struct do?
On 2009.10.12 at 14:49:23 +0200, Dr. Stephen Henson wrote: > On Mon, Oct 12, 2009, Victor B. Wagner wrote: > > > > > BTW, it seems that most applications which actualy use CRLs, such as > > Apache, openvpn and stunnel, do implement lookup of certicate in the CRL > > in its own code, not relying on X509_V_FLAG_CRL_CHECK in X509_STORE. > > > > > > In some cases CRL lookup is done manually because the code originates from a > time when OpenSSL didn't perform its own CRL lookup. I can provide in some reasonable timeframe (say, this week) a patch with following functionality: 1. Somehow document X509_STORE object. It would require proofreading, because I do not have experience with big certification authorities with multimegabyte CRLs and multilevel secondary CA hierarchy (where security problems you mention are applicable). But I'm sure it is better than nothing 2. Make X509_LOOKUP_hash_dir lookup method honour cache field in the X509_STORE structure. (I think that it is better to make this field a bit mask and interpret constants X509_LU_CERT and X509_LU_CRL as bit flags, but it would conflict with X509_LU_PKEY constant, which seems to be unused anyway. But for first time handle this field as boolean flag is better than nothing) 3. Make X509_LOOKUP_hash_dir check notAfter field of certificate and nextUpdate field of CRL and attempt to reload CRL/certificate from disk if cached copy in the memory have been expired. Does this plan seems to be acceptable intermediate solution? __ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
Re: What does cache field in X509_STORE struct do?
On 2009.10.12 at 14:49:23 +0200, Dr. Stephen Henson wrote: > On Mon, Oct 12, 2009, Victor B. Wagner wrote: > > > > > BTW, it seems that most applications which actualy use CRLs, such as > > Apache, openvpn and stunnel, do implement lookup of certicate in the CRL > > in its own code, not relying on X509_V_FLAG_CRL_CHECK in X509_STORE. > > > > > > In some cases CRL lookup is done manually because the code originates from a > time when OpenSSL didn't perform its own CRL lookup. > Some of this mishandles CRLs and doesn't reject CRLs containing unhandled > critical extensions. This raises security concerns: for example it would be > possible to substitue CRLs of limited scope and fool such applications into > thinking revoked certificates were valid. Of course, application-level handling of such important thing as CRL lookup would raise security problems. Authors of crypto library should know better about such problems, then authors of application. But there are serious problems with X509_STORE object and default lookup methods in OpenSSL just now. I think that we should fix this problems first, and then urge authors of applications to use OpenSSL code rather than to reinvent the wheel. First of all, X509_STORE working is not documented at all. Authors of applications just have no source of information how to handle certificate verification except the source code of verify utility. (which is not well suited for server authors, because it is not intended to run for weeks without restart). Second, there is problem with aggressive caching and unused cache field, which I've mentioned in previous letter. Third, there should be guidelines for implementors of custom lookup method. At least such as there exist for implemetors of UI_METHODS which are quite verbose comments in the header file. Fourth, I've spend hours studying of X509_STORE source code and cannot realize how it would handle CA certificate rollover. I.e. is setting of subjectKeyIdentifier and authorityKeyIdentifier sufficient to recognize difference between old and new CA certificate or when I'm issuing new CA certificate I have to make its DN unique. If we want application writers to use OpenSSL code securely, we should somehow provide them clear understanding which security threats we care of, and how we handle them. > 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 > Development Mailing List [email protected] > Automated List Manager [email protected] > __ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
Re: What does cache field in X509_STORE struct do?
On Mon, Oct 12, 2009, Victor B. Wagner wrote: > > BTW, it seems that most applications which actualy use CRLs, such as > Apache, openvpn and stunnel, do implement lookup of certicate in the CRL > in its own code, not relying on X509_V_FLAG_CRL_CHECK in X509_STORE. > > In some cases CRL lookup is done manually because the code originates from a time when OpenSSL didn't perform its own CRL lookup. Some of this mishandles CRLs and doesn't reject CRLs containing unhandled critical extensions. This raises security concerns: for example it would be possible to substitue CRLs of limited scope and fool such applications into thinking revoked certificates were valid. 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 Development Mailing List [email protected] Automated List Manager [email protected]
