From 2a03823606b2d7e73e5dc890c3202e186511151f Mon Sep 17 00:00:00 2001 From: Richard Levitte Date: Sat, 23 Nov 2019 10:36:16 +0100 Subject: [PATCH] doc/man7/proxy-certificates.pod: New guide for proxy certificates This replaces doc/HOWTO/proxy_certificates.txt Reviewed-by: Paul Dale (Merged from https://github.com/openssl/openssl/pull/10507) --- doc/HOWTO/proxy_certificates.txt | 319 --------------------------- doc/man7/proxy-certificates.pod | 363 +++++++++++++++++++++++++++++++ 2 files changed, 363 insertions(+), 319 deletions(-) delete mode 100644 doc/HOWTO/proxy_certificates.txt create mode 100644 doc/man7/proxy-certificates.pod diff --git a/doc/HOWTO/proxy_certificates.txt b/doc/HOWTO/proxy_certificates.txt deleted file mode 100644 index f6f754cc34..0000000000 --- a/doc/HOWTO/proxy_certificates.txt +++ /dev/null @@ -1,319 +0,0 @@ - HOWTO proxy certificates - -0. WARNING - -NONE OF THE CODE PRESENTED HERE HAS BEEN CHECKED! The code is just examples to -show you how things could be done. There might be typos or type conflicts, and -you will have to resolve them. - -1. Introduction - -Proxy certificates are defined in RFC 3820. They are really usual certificates -with the mandatory extension proxyCertInfo. - -Proxy certificates are issued by an End Entity (typically a user), either -directly with the EE certificate as issuing certificate, or by extension through -an already issued proxy certificate. Proxy certificates are used to extend -rights to some other entity (a computer process, typically, or sometimes to the -user itself). This allows the entity to perform operations on behalf of the -owner of the EE certificate. - -See https://www.ietf.org/rfc/rfc3820.txt for more information. - - -2. A warning about proxy certificates - -No one seems to have tested proxy certificates with security in mind. To this -date, it seems that proxy certificates have only been used in a context highly -aware of them. - -Existing applications might misbehave when trying to validate a chain of -certificates which use a proxy certificate. They might incorrectly consider the -leaf to be the certificate to check for authorisation data, which is controlled -by the EE certificate owner. - -subjectAltName and issuerAltName are forbidden in proxy certificates, and this -is enforced in OpenSSL. The subject must be the same as the issuer, with one -commonName added on. - -Possible threats we can think of at this time include: - - - impersonation through commonName (think server certificates). - - use of additional extensions, possibly non-standard ones used in certain - environments, that would grant extra or different authorisation rights. - -For these reasons, OpenSSL requires that the use of proxy certificates be -explicitly allowed. Currently, this can be done using the following methods: - - - if the application directly calls X509_verify_cert(), it can first call: - - X509_STORE_CTX_set_flags(ctx, X509_V_FLAG_ALLOW_PROXY_CERTS); - - Where ctx is the pointer which then gets passed to X509_verify_cert(). - - - proxy certificate validation can be enabled before starting the application - by setting the environment variable OPENSSL_ALLOW_PROXY_CERTS. - -In the future, it might be possible to enable proxy certificates by editing -openssl.cnf. - - -3. How to create proxy certificates - -Creating proxy certificates is quite easy, by taking advantage of a lack of -checks in the 'openssl x509' application (*ahem*). You must first create a -configuration section that contains a definition of the proxyCertInfo extension, -for example: - - [ v3_proxy ] - # A proxy certificate MUST NEVER be a CA certificate. - basicConstraints=CA:FALSE - - # Usual authority key ID - authorityKeyIdentifier=keyid,issuer:always - - # The extension which marks this certificate as a proxy - proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:1,policy:text:AB - -It's also possible to specify the proxy extension in a separate section: - - proxyCertInfo=critical,@proxy_ext - - [ proxy_ext ] - language=id-ppl-anyLanguage - pathlen=0 - policy=text:BC - -The policy value has a specific syntax, {syntag}:{string}, where the syntag -determines what will be done with the string. The following syntags are -recognised: - - text indicates that the string is simply bytes, without any encoding: - - policy=text:räksmörgås - - Previous versions of this design had a specific tag for UTF-8 text. - However, since the bytes are copied as-is anyway, there is no need for - such a specific tag. - - hex indicates the string is encoded in hex, with colons between each byte - (every second hex digit): - - policy=hex:72:E4:6B:73:6D:F6:72:67:E5:73 - - Previous versions of this design had a tag to insert a complete DER - blob. However, the only legal use for this would be to surround the - bytes that would go with the hex: tag with whatever is needed to - construct a correct OCTET STRING. The DER tag therefore felt - superfluous, and was removed. - - file indicates that the text of the policy should really be taken from a - file. The string is then really a filename. This is useful for - policies that are large (more than a few lines, e.g. XML documents). - -The 'policy' setting can be split up in multiple lines like this: - - 0.policy=This is - 1.policy= a multi- - 2.policy=line policy. - -NOTE: the proxy policy value is the part which determines the rights granted to -the process using the proxy certificate. The value is completely dependent on -the application reading and interpreting it! - -Now that you have created an extension section for your proxy certificate, you -can easily create a proxy certificate by doing: - - openssl req -new -config openssl.cnf -out proxy.req -keyout proxy.key - openssl x509 -req -CAcreateserial -in proxy.req -days 7 -out proxy.crt \ - -CA user.crt -CAkey user.key -extfile openssl.cnf -extensions v3_proxy - -You can also create a proxy certificate using another proxy certificate as -issuer (note: I'm using a different configuration section for it): - - openssl req -new -config openssl.cnf -out proxy2.req -keyout proxy2.key - openssl x509 -req -CAcreateserial -in proxy2.req -days 7 -out proxy2.crt \ - -CA proxy.crt -CAkey proxy.key -extfile openssl.cnf -extensions v3_proxy2 - - -4. How to have your application interpret the policy? - -The basic way to interpret proxy policies is to start with some default rights, -then compute the resulting rights by checking the proxy certificate against -the chain of proxy certificates, user certificate and CA certificates. You then -use the final computed rights. Sounds easy, huh? It almost is. - -The slightly complicated part is figuring out how to pass data between your -application and the certificate validation procedure. - -You need the following ingredients: - - - a callback function that will be called for every certificate being - validated. The callback be called several times for each certificate, - so you must be careful to do the proxy policy interpretation at the right - time. You also need to fill in the defaults when the EE certificate is - checked. - - - a data structure that is shared between your application code and the - callback. - - - a wrapper function that sets it all up. - - - an ex_data index function that creates an index into the generic ex_data - store that is attached to an X509 validation context. - -Here is some skeleton code you can fill in: - - #include - #include - #include - #include - - #define total_rights 25 - - /* - * In this example, I will use a view of granted rights as a bit - * array, one bit for each possible right. - */ - typedef struct your_rights { - unsigned char rights[(total_rights + 7) / 8]; - } YOUR_RIGHTS; - - /* - * The following procedure will create an index for the ex_data - * store in the X509 validation context the first time it's called. - * Subsequent calls will return the same index. */ - static int get_proxy_auth_ex_data_idx(X509_STORE_CTX *ctx) - { - static volatile int idx = -1; - if (idx < 0) { - X509_STORE_lock(X509_STORE_CTX_get0_store(ctx)); - if (idx < 0) { - idx = X509_STORE_CTX_get_ex_new_index(0, - "for verify callback", - NULL,NULL,NULL); - } - X509_STORE_unlock(X509_STORE_CTX_get0_store(ctx)); - } - return idx; - } - - /* Callback to be given to the X509 validation procedure. */ - static int verify_callback(int ok, X509_STORE_CTX *ctx) - { - if (ok == 1) { - /* - * It's REALLY important you keep the proxy policy - * check within this section. It's important to know - * that when ok is 1, the certificates are checked - * from top to bottom. You get the CA root first, - * followed by the possible chain of intermediate - * CAs, followed by the EE certificate, followed by - * the possible proxy certificates. - */ - X509 *xs = X509_STORE_CTX_get_current_cert(ctx); - - if (X509_get_extension_flags(xs) & EXFLAG_PROXY) { - YOUR_RIGHTS *rights = - (YOUR_RIGHTS *)X509_STORE_CTX_get_ex_data(ctx, - get_proxy_auth_ex_data_idx(ctx)); - PROXY_CERT_INFO_EXTENSION *pci = - X509_get_ext_d2i(xs, NID_proxyCertInfo, NULL, NULL); - - switch (OBJ_obj2nid(pci->proxyPolicy->policyLanguage)) { - case NID_Independent: - /* - * Do whatever you need to grant explicit rights to - * this particular proxy certificate, usually by - * pulling them from some database. If there are none - * to be found, clear all rights (making this and any - * subsequent proxy certificate void of any rights). - */ - memset(rights->rights, 0, sizeof(rights->rights)); - break; - case NID_id_ppl_inheritAll: - /* - * This is basically a NOP, we simply let the current - * rights stand as they are. - */ - break; - default: - /* This is usually the most complex section of code. - * You really do whatever you want as long as you - * follow RFC 3820. In the example we use here, the - * simplest thing to do is to build another, temporary - * bit array and fill it with the rights granted by - * the current proxy certificate, then use it as a - * mask on the accumulated rights bit array, and - * voilà, you now have a new accumulated rights bit - * array. - */ - { - int i; - YOUR_RIGHTS tmp_rights; - memset(tmp_rights.rights, 0, sizeof(tmp_rights.rights)); - - /* - * process_rights() is supposed to be a procedure - * that takes a string and its length, interprets - * it and sets the bits in the YOUR_RIGHTS pointed - * at by the third argument. - */ - process_rights((char *) pci->proxyPolicy->policy->data, - pci->proxyPolicy->policy->length, - &tmp_rights); - - for(i = 0; i < total_rights / 8; i++) - rights->rights[i] &= tmp_rights.rights[i]; - } - break; - } - PROXY_CERT_INFO_EXTENSION_free(pci); - } else if (!(X509_get_extension_flags(xs) & EXFLAG_CA)) { - /* We have an EE certificate, let's use it to set default! */ - YOUR_RIGHTS *rights = - (YOUR_RIGHTS *)X509_STORE_CTX_get_ex_data(ctx, - get_proxy_auth_ex_data_idx(ctx)); - - /* The following procedure finds out what rights the owner - * of the current certificate has, and sets them in the - * YOUR_RIGHTS structure pointed at by the second - * argument. - */ - set_default_rights(xs, rights); - } - } - return ok; - } - - static int my_X509_verify_cert(X509_STORE_CTX *ctx, - YOUR_RIGHTS *needed_rights) - { - int ok; - int (*save_verify_cb)(int ok,X509_STORE_CTX *ctx) = - X509_STORE_CTX_get_verify_cb(ctx); - YOUR_RIGHTS rights; - - X509_STORE_CTX_set_verify_cb(ctx, verify_callback); - X509_STORE_CTX_set_ex_data(ctx, get_proxy_auth_ex_data_idx(ctx), &rights); - X509_STORE_CTX_set_flags(ctx, X509_V_FLAG_ALLOW_PROXY_CERTS); - ok = X509_verify_cert(ctx); - - if (ok == 1) { - ok = check_needed_rights(rights, needed_rights); - } - - X509_STORE_CTX_set_verify_cb(ctx, save_verify_cb); - - return ok; - } - - -If you use SSL or TLS, you can easily set up a callback to have the -certificates checked properly, using the code above: - - SSL_CTX_set_cert_verify_callback(s_ctx, my_X509_verify_cert, &needed_rights); - - --- -Richard Levitte diff --git a/doc/man7/proxy-certificates.pod b/doc/man7/proxy-certificates.pod new file mode 100644 index 0000000000..df5ee1b4b5 --- /dev/null +++ b/doc/man7/proxy-certificates.pod @@ -0,0 +1,363 @@ +=pod + +=encoding UTF-8 + +=head1 NAME + +proxy-certificates - Proxy certificates in OpenSSL + +=head1 DESCRIPTION + +Proxy certificates are defined in RFC 3820. They are used to +extend rights to some other entity (a computer process, typically, or +sometimes to the user itself). This allows the entity to perform +operations on behalf of the owner of the EE (End Entity) certificate. + +The requirements for a valid proxy certificate are: + +=over 4 + +=item * + +They are issued by an End Entity, either a normal EE certificate, or +another proxy certificate. + +=item * + +They must not have the B or B +extensions. + +=item * + +They must have the B extension. + +=item * + +They must have the subject of their issuer, with one B +added. + +=back + +=head2 Enabling proxy certificate verification + +OpenSSL expects applications that want to use proxy certificates to be +specially aware of them, and make that explicit. This is done by +setting an X509 verification flag: + + X509_STORE_CTX_set_flags(ctx, X509_V_FLAG_ALLOW_PROXY_CERTS); + +or + + X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_ALLOW_PROXY_CERTS); + +See L for a discussion on this requirement. + +=head2 Creating proxy certificates + +Creating proxy certificates can be done using the L +command, with some extra extensions: + + [ v3_proxy ] + # A proxy certificate MUST NEVER be a CA certificate. + basicConstraints=CA:FALSE + + # Usual authority key ID + authorityKeyIdentifier=keyid,issuer:always + + # The extension which marks this certificate as a proxy + proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:1,policy:text:AB + +It's also possible to specify the proxy extension in a separate section: + + proxyCertInfo=critical,@proxy_ext + + [ proxy_ext ] + language=id-ppl-anyLanguage + pathlen=0 + policy=text:BC + +The policy value has a specific syntax, I:I, where the +I determines what will be done with the string. The following +Is are recognised: + +=over 4 + +=item B + +indicates that the string is a byte sequence, without any encoding: + + policy=text:räksmörgås + +=item B + +indicates the string is encoded hexadecimal encoded binary data, with +colons between each byte (every second hex digit): + + policy=hex:72:E4:6B:73:6D:F6:72:67:E5:73 + +=item B + +indicates that the text of the policy should be taken from a file. +The string is then a filename. This is useful for policies that are +large (more than a few lines, e.g. XML documents). + +=back + +I + +With a proxy extension, creating a proxy certificate is a matter of +two commands: + + openssl req -new -config proxy.cnf \ + -out proxy.req -keyout proxy.key \ + -subj "/DC=org/DC=openssl/DC=users/CN=proxy 1" + + openssl x509 -req -CAcreateserial -in proxy.req -out proxy.crt \ + -CA user.crt -CAkey user.key -days 7 \ + -extfile proxy.cnf -extensions v3_proxy1 + +You can also create a proxy certificate using another proxy +certificate as issuer (note: using a different configuration +section for the proxy extensions): + + openssl req -new -config proxy.cnf \ + -out proxy2.req -keyout proxy2.key \ + -subj "/DC=org/DC=openssl/DC=users/CN=proxy 1/CN=proxy 2" + + openssl x509 -req -CAcreateserial -in proxy2.req -out proxy2.crt \ + -CA proxy.crt -CAkey proxy.key -days 7 \ + -extfile proxy.cnf -extensions v3_proxy2 + +=head2 Using proxy certs in applications + +To interpret proxy policies, the application would normally start with +some default rights (perhaps none at all), then compute the resulting +rights by checking the rights against the chain of proxy certificates, +user certificate and CA certificates. + +The complicated part is figuring out how to pass data between your +application and the certificate validation procedure. + +The following ingredients are needed for such processing: + +=over 4 + +=item * + +a callback function that will be called for every certificate being +validated. The callback is called several times for each certificate, +so you must be careful to do the proxy policy interpretation at the +right time. You also need to fill in the defaults when the EE +certificate is checked. + +=item * + +a data structure that is shared between your application code and the +callback. + +=item * + +a wrapper function that sets it all up. + +=item * + +an ex_data index function that creates an index into the generic +ex_data store that is attached to an X509 validation context. + +=back + +The following skeleton code can be used as a starting point: + + #include + #include + #include + #include + + #define total_rights 25 + + /* + * In this example, I will use a view of granted rights as a bit + * array, one bit for each possible right. + */ + typedef struct your_rights { + unsigned char rights[(total_rights + 7) / 8]; + } YOUR_RIGHTS; + + /* + * The following procedure will create an index for the ex_data + * store in the X509 validation context the first time it's + * called. Subsequent calls will return the same index. + */ + static int get_proxy_auth_ex_data_idx(X509_STORE_CTX *ctx) + { + static volatile int idx = -1; + + if (idx < 0) { + X509_STORE_lock(X509_STORE_CTX_get0_store(ctx)); + if (idx < 0) { + idx = X509_STORE_CTX_get_ex_new_index(0, + "for verify callback", + NULL,NULL,NULL); + } + X509_STORE_unlock(X509_STORE_CTX_get0_store(ctx)); + } + return idx; + } + + /* Callback to be given to the X509 validation procedure. */ + static int verify_callback(int ok, X509_STORE_CTX *ctx) + { + if (ok == 1) { + /* + * It's REALLY important you keep the proxy policy check + * within this section. It's important to know that when + * ok is 1, the certificates are checked from top to + * bottom. You get the CA root first, followed by the + * possible chain of intermediate CAs, followed by the EE + * certificate, followed by the possible proxy + * certificates. + */ + X509 *xs = X509_STORE_CTX_get_current_cert(ctx); + + if (X509_get_extension_flags(xs) & EXFLAG_PROXY) { + YOUR_RIGHTS *rights = + (YOUR_RIGHTS *)X509_STORE_CTX_get_ex_data(ctx, + get_proxy_auth_ex_data_idx(ctx)); + PROXY_CERT_INFO_EXTENSION *pci = + X509_get_ext_d2i(xs, NID_proxyCertInfo, NULL, NULL); + + switch (OBJ_obj2nid(pci->proxyPolicy->policyLanguage)) { + case NID_Independent: + /* + * Do whatever you need to grant explicit rights + * to this particular proxy certificate, usually + * by pulling them from some database. If there + * are none to be found, clear all rights (making + * this and any subsequent proxy certificate void + * of any rights). + */ + memset(rights->rights, 0, sizeof(rights->rights)); + break; + case NID_id_ppl_inheritAll: + /* + * This is basically a NOP, we simply let the + * current rights stand as they are. + */ + break; + default: + /* + * This is usually the most complex section of + * code. You really do whatever you want as long + * as you follow RFC 3820. In the example we use + * here, the simplest thing to do is to build + * another, temporary bit array and fill it with + * the rights granted by the current proxy + * certificate, then use it as a mask on the + * accumulated rights bit array, and voilà, you + * now have a new accumulated rights bit array. + */ + { + int i; + YOUR_RIGHTS tmp_rights; + memset(tmp_rights.rights, 0, + sizeof(tmp_rights.rights)); + + /* + * process_rights() is supposed to be a + * procedure that takes a string and its + * length, interprets it and sets the bits + * in the YOUR_RIGHTS pointed at by the + * third argument. + */ + process_rights((char *) pci->proxyPolicy->policy->data, + pci->proxyPolicy->policy->length, + &tmp_rights); + + for(i = 0; i < total_rights / 8; i++) + rights->rights[i] &= tmp_rights.rights[i]; + } + break; + } + PROXY_CERT_INFO_EXTENSION_free(pci); + } else if (!(X509_get_extension_flags(xs) & EXFLAG_CA)) { + /* We have an EE certificate, let's use it to set default! */ + YOUR_RIGHTS *rights = + (YOUR_RIGHTS *)X509_STORE_CTX_get_ex_data(ctx, + get_proxy_auth_ex_data_idx(ctx)); + + /* + * The following procedure finds out what rights the + * owner of the current certificate has, and sets them + * in the YOUR_RIGHTS structure pointed at by the + * second argument. + */ + set_default_rights(xs, rights); + } + } + return ok; + } + + static int my_X509_verify_cert(X509_STORE_CTX *ctx, + YOUR_RIGHTS *needed_rights) + { + int ok; + int (*save_verify_cb)(int ok,X509_STORE_CTX *ctx) = + X509_STORE_CTX_get_verify_cb(ctx); + YOUR_RIGHTS rights; + + X509_STORE_CTX_set_verify_cb(ctx, verify_callback); + X509_STORE_CTX_set_ex_data(ctx, get_proxy_auth_ex_data_idx(ctx), + &rights); + X509_STORE_CTX_set_flags(ctx, X509_V_FLAG_ALLOW_PROXY_CERTS); + ok = X509_verify_cert(ctx); + + if (ok == 1) { + ok = check_needed_rights(rights, needed_rights); + } + + X509_STORE_CTX_set_verify_cb(ctx, save_verify_cb); + + return ok; + } + +If you use SSL or TLS, you can easily set up a callback to have the +certificates checked properly, using the code above: + + SSL_CTX_set_cert_verify_callback(s_ctx, my_X509_verify_cert, + &needed_rights); + +=head1 NOTES + +To this date, it seems that proxy certificates have only been used in +environments that are aware of them, and no one seems to have +investigated how they can be used or misused outside of such an +environment. + +For that reason, OpenSSL requires that applications aware of proxy +certificates must also make that explicit. + +B and B are forbidden in proxy +certificates, and this is enforced in OpenSSL. The subject must be +the same as the issuer, with one commonName added on. + +=head1 SEE ALSO + +L, +L, +L, +L, +L, L, +L + +=head1 COPYRIGHT + +Copyright 2019 The OpenSSL Project Authors. All Rights Reserved. + +Licensed under the Apache License 2.0 (the "License"). You may not use +this file except in compliance with the License. You can obtain a copy +in the file LICENSE in the source distribution or at +L. + +=cut -- 2.25.1