Re: [openssl-users] Using FIPS mode and modifying apps
On 01/26/2015 06:21 PM, jone...@teksavvy.com wrote: On Fri, 16 Jan 2015 10:16:48 -0500 Steve Marquess marqu...@openssl.com wrote: On 01/15/2015 05:52 AM, Marcus Meissner wrote: On Linux usually triggered by /proc/sys/crypto/fips_enabled containing 1 or the environment variable OPENSSL_FORCE_FIPS_MODE=1 (at least for the certs done by SUSE and Redhat, which do not use the container blob). That is (presumably) true for the proprietary RH and SUSE distros, not so for the open source based OpenSSL FIPS Object Module or other Linux distros. I'm afraid it does not come across clear to me. So, maybe the following pondering is relevant - or not. Basically, I'm looking at how to integrate a FIPS-enabled OpenSSL that will be used by some common Open Sources applications, as well as a 3rd party application (with source code provided). Tom Francis nailed the answer to this one. We did design the FIPS module + FIPS capable OpenSSL combination to make it possible to have a system wide FIPS mode capability, but that presumes that the system maintainer (i.e. OS distribution maintainer) has done the review and modification of each application that uses cryptography to make sure it is compatible with the many restrictions of FIPS mode. So, does your comment mean that the paying versions of Red Hat and SuSE (proprietary) have open source applications modified to at least include the FIPS_mode_set() call ? Why would these releases be different in FIPS SSL 'power-up' POST checks when compared to regular free releases ? That is indeed the assumption: that commercial versions of RH and SuSE have modified all impacted OSS applications to operate in FIPS mode. If they haven't they are deceiving their customers and the U.S. government. Note that such modifications are non-trivial for some applications, for instance OpenSSH. If I compare with GnuTLS that our product also uses, and with which it will also go to certification, its FIPS mode is completly transparent, with FIPS checks done on library load. Can't help you there as I know nothing of GnuTLS. But, applications using GnuTLS will face exactly the same problem; if they were not designed or modified to operate in FIPS mode you're probably going to have undesirable outcomes. Based on the discussion in 'The I.G. 9.5 Issue', I took a look at 'Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program', January 15 2015 release. In section 9.10 it states:... Please read the first two sentences on that web page, right at the top. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Intermediate certificates
On Tue, Jan 27, 2015 at 10:21:01PM +0300, Serj wrote: Some web-sites don't send all intermediate certs during SSL Handshake. Indeed some websites are misconfigured. For example, www.verisign.com sends only server's cert but doesn't send next intermediate cert: But www.verisign.com is not among them: $ sleep 2 | openssl s_client -showcerts -connect www.verisign.com:443 21 | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs -noout subject=/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=Private Organization/serialNumber=2158113/C=US/postalCode=94043/ST=California/L=Mountain View/street=350 Ellis Street/O=Symantec Corporation/OU=Infrastructure Operations /CN=www.verisign.com issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA subject=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 subject=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 issuer=/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority So, I need to set a list of intermediate certs for my SSL connections. How to do this? With SSL_CTX_load_verify_locations() I can set only trusted root certs, but not intermediate certs. This is not needed for properly configured servers, such as www.verisign.com. While providing additional untrusted (intermediate) certificates is possible, it is complex and the right solution is for the broken sites to fix their certificate chain configuration. It is unfortunate that browsers lend a helping hand to such sites. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Intermediate certificates
Browsers have too many work arounds for broken sites which results in those sites not actually getting fixed. Because if the site doesn't work, the user will blame the browser and switch. :( ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On 01/26/2015 06:21 PM, jone...@teksavvy.com wrote: On Fri, 16 Jan 2015 10:16:48 -0500 Steve Marquess marqu...@openssl.com wrote: On 01/15/2015 05:52 AM, Marcus Meissner wrote: On Linux usually triggered by /proc/sys/crypto/fips_enabled containing 1 or the environment variable OPENSSL_FORCE_FIPS_MODE=1 (at least for the certs done by SUSE and Redhat, which do not use the container blob). That is (presumably) true for the proprietary RH and SUSE distros, not so for the open source based OpenSSL FIPS Object Module or other Linux distros. I'm afraid it does not come across clear to me. So, maybe the following pondering is relevant - or not. Basically, I'm looking at how to integrate a FIPS-enabled OpenSSL that will be used by some common Open Sources applications, as well as a 3rd party application (with source code provided). Tom Francis nailed the answer to this one. We did design the FIPS module + FIPS capable OpenSSL combination to make it possible to have a system wide FIPS mode capability, but that presumes that the system maintainer (i.e. OS distribution maintainer) has done the review and modification of each application that uses cryptography to make sure it is compatible with the many restrictions of FIPS mode. So, does your comment mean that the paying versions of Red Hat and SuSE (proprietary) have open source applications modified to at least include the FIPS_mode_set() call ? Why would these releases be different in FIPS SSL 'power-up' POST checks when compared to regular free releases ? That is indeed the assumption: that commercial versions of RH and SuSE have modified all impacted OSS applications to operate in FIPS mode. If they haven't they are deceiving their customers and the U.S. government. Note that such modifications are non-trivial for some applications, for instance OpenSSH. If I compare with GnuTLS that our product also uses, and with which it will also go to certification, its FIPS mode is completly transparent, with FIPS checks done on library load. Can't help you there as I know nothing of GnuTLS. But, applications using GnuTLS will face exactly the same problem; if they were not designed or modified to operate in FIPS mode you're probably going to have undesirable outcomes. Based on the discussion in 'The I.G. 9.5 Issue', I took a look at 'Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program', January 15 2015 release. In section 9.10 it states:... Please read the first two sentences on that web page, right at the top. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Hostname validation
Hi, Viktor. I have some questions. I didn't find docs on such functions as SSL_get0_param Why there is no corresponding functions as SSL_set0_param in your code? Where can I found documentation on functions operating with params? I found only this code: X509_VERIFY_PARAM *param; param = X509_VERIFY_PARAM_new(); X509_VERIFY_PARAM_set_flags(param, X509_V_FLAG_CRL_CHECK); SSL_CTX_set1_param(ctx, param); X509_VERIFY_PARAM_free(param); here: https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_hostflags.html But there is no any description how SSL_CTX_set1_param works! Does it clear all previous flags on CTX or ORing with them? And there are no any docs on GET params functions! For example, like docs on SSL_CTX_set_options,SSL_CTX_get_option,SSL_set_options,SSL_get_options. -- Best Regards, Serj 25.01.2015, 20:59, Viktor Dukhovni openssl-us...@dukhovni.org: On Sun, Jan 25, 2015 at 07:43:14PM +0300, Serj wrote: What is the best way to make hostname validation? 1. http://wiki.openssl.org/index.php/Hostname_validation 2. X509_check_host that was added in OpenSSL 1.1.0. The X509_check_host() interface is also available in OpenSSL 1.0.2 released a few days ago https://www.openssl.org/docs/crypto/X509_check_host.html (the documentation should be updated to note the earlier availability). Starting with 1.0.2, you can also ask OpenSSL to automatically perform hostname checks during the SSL handshake on the application's behalf: https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_hostflags.html https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set1_host.html https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_add1_host.html https://www.openssl.org/docs/ssl/SSL_set_verify.html Sadly, we're still lacking documentation of SSL_get0_param() which is needed for a complete SSL hostname check recipe: const char *servername; SSL *ssl; X509_VERIFY_PARAM *param; servername = www.example.com; ssl = SSL_new(...); param = SSL_get0_param(ssl); /* Enable automatic hostname checks */ X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); X509_VERIFY_PARAM_set1_host(param, servername, 0); /* Configure a non-zero callback if desired */ SSL_set_verify(ssl, SSL_VERIFY_PEER, 0); /* * Establish SSL connection, hostname should be checked * automatically test with a hostname that should not match, * the connection will fail (unless you specify a callback * that returns despite the verification failure. In that * case SSL_get_verify_status() can expose the problem after * connection completion. */ ... I don't know does the first one support wildcards or no! Seems to be: how does Curl_cert_hostcheck work - is the answer, but I don't know how it works. Wildcard support is configured via the flags documented for X509_check_host(), the two most frequently useful are: X509_CHECK_FLAG_NO_WILDCARDS X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
Steve Marquess marqu...@openssl.comwrote on 01/27/15 09:18: Thank you (and Tom) for your comments - much appreciated. Tom Francis nailed the answer to this one. We did design the FIPS module + FIPS capable OpenSSL combination to make it possible to have a system wide FIPS mode capability, but that presumes that the system maintainer (i.e. OS distribution maintainer) has done the review and modification of each application that uses cryptography to make sure it is compatible with the many restrictions of FIPS mode. Yes, I understand the concern. Does this mean that the FIPS checks will be done today on OpenSSL library startup w/o the need for an application to use FIPS_mode_set() ? I'm asking since the OpenSSL FIPS User Guide 2.0 only mentions using FIPS_mode_set() (and FIPS_selftest()). Might have to do with your comment below. That is indeed the assumption: that commercial versions of RH and SuSE have modified all impacted OSS applications to operate in FIPS mode. If they haven't they are deceiving their customers and the U.S. government. I see. There is a set of SuSE OpenSSH FIPS patches from 9 months ago, though. Please read the first two sentences on that web page, right at the top. OK! Regarding the second sentence :) ... what is the current status ? Is OpenSSL transparently executing FIPS checks when in FIPS mode ? And, why would there be any validation (as opposed to functional tests) to be done since these checks are the same as they were before I presume, just done automatically this time around. Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Hostname validation
On Tue, Jan 27, 2015 at 04:18:49PM +0300, Serj wrote: I didn't find docs on such functions as SSL_get0_param As I mentioned, this function should be documented, but is not yet. Why there is no corresponding functions as SSL_set0_param in your code? Where can I found documentation on functions operating with params? The documentation for these functions is not yet written. The way I would set SSL verification parameters is to obtain the parameter handle via SSL_get0_param() or where appropriate SSL_CTX_get0_param(), and use the various X509_VERIFY_PARAM_mumble() functions to tweak the parameter object in place. Parameters that apply to all connections should be set at the SSL_CTX level, when the context is created. Specifics like hostnames, ... should be set for each connection via the SSL object. But there is no any description how SSL_CTX_set1_param works! Does it clear all previous flags on CTX or ORing with them? And there are no any docs on GET params functions! Yes, these need (more) documentation. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using FIPS mode and modifying apps
On 01/27/2015 11:09 AM, jonetsu wrote: Steve Marquess marqu...@openssl.comwrote on 01/27/15 09:18: Thank you (and Tom) for your comments - much appreciated. Tom Francis nailed the answer to this one. We did design the FIPS module + FIPS capable OpenSSL combination to make it possible to have a system wide FIPS mode capability, but that presumes that the system maintainer (i.e. OS distribution maintainer) has done the review and modification of each application that uses cryptography to make sure it is compatible with the many restrictions of FIPS mode. Yes, I understand the concern. Does this mean that the FIPS checks will be done today on OpenSSL library startup w/o the need for an application to use FIPS_mode_set() ? I'm asking since the OpenSSL FIPS User Guide 2.0 only mentions using FIPS_mode_set() (and FIPS_selftest()). Might have to do with your comment below. The user guide documents that correctly. For the OpenSSL FIPS Object Module 2.0 (#1747) the FIPS mode of operation is enabled with FIPS_mode_set(). There is no library startup; you keep confusing past validations with new ones. Note that we would update that existing module to comply with the new I.G. 9.10 guidance, but that falls in the class of changes that are not permitted under the change letter update process (similarly, we weren't allowed to update the module to address security vulnerabilities such as Lucky 13). That is indeed the assumption: that commercial versions of RH and SuSE have modified all impacted OSS applications to operate in FIPS mode. If they haven't they are deceiving their customers and the U.S. government. I see. There is a set of SuSE OpenSSH FIPS patches from 9 months ago, though. Please read the first two sentences on that web page, right at the top. OK! Regarding the second sentence :) ... what is the current status ? We have not done any validations that satisfy the various new requirements introduced in late 2013 and early 2014. New validations are very expensive, in dollars, time, and grief, and we don't have the necessary financial backing. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com marqu...@openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] TSLEXT_TYPE_opaque_prf_input
This is an implementation of an IETF draft that expired seven years ago. Is anyone using it? -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Hostname validation
On Tue, Jan 27, 2015 at 10:09:38PM +0300, Serj wrote: 27.01.2015, 20:23, Viktor Dukhovni openssl-us...@dukhovni.org: I would set SSL verification parameters is to obtain the parameter handle via SSL_get0_param() or where appropriate SSL_CTX_get0_param(), and use the various X509_VERIFY_PARAM_mumble() functions to tweak the parameter object in place. Why are not there any X509_VERIFY_PARAM_mumble() functions in your code? So your code is not complete? It is complete enough. The word mumble is not meant to be taken literally. The phrase: various X509_VERIFY_PARAM_mumble() functions means any of: X509_VERIFY_PARAM_set_hostflags() X509_VERIFY_PARAM_set1_host() ... As I mentioned, this function should be documented, but is not yet. The documentation for these functions is not yet written. ?The way Yes, these need (more) documentation. That's why maybe it is better to use X509_check_host() in post conection checks now? No, it is better to use the parameter functions, and also to document the missing SSL_get0_param(). NOTES Applications are encouraged to use X509_VERIFY_PARAM_set1_host() rather than explicitly calling X509_check_host(3). Host name checks are out of scope with the DANE-EE(3) certificate usage, and the internal checks will be suppressed as appropriate when DANE support is added to OpenSSL. -- and no any documentation on how to set properly params for SSL or CTX! Example code should likely be added to that document. Maybe this code is right, while there is no full documentation yet: char servername[]=www.openssl.org\x0; X509_VERIFY_PARAM *param; param = X509_VERIFY_PARAM_new(); //enable automatic hostname checks X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); X509_VERIFY_PARAM_set1_host(param, servername,0); SSL_CTX_set1_param(ctx, param); //is right if combined by a bitwise 'OR' operation //free param X509_VERIFY_PARAM_free(param); No, use the code example I provided. The above sets the hostname in the global context, where it does not belong. My original message is below: On Sun, Jan 25, 2015 at 05:57:06PM +, Viktor Dukhovni wrote: On Sun, Jan 25, 2015 at 07:43:14PM +0300, Serj wrote: What is the best way to make hostname validation? 1. http://wiki.openssl.org/index.php/Hostname_validation 2. X509_check_host that was added in OpenSSL 1.1.0. The X509_check_host() interface is also available in OpenSSL 1.0.2 released a few days ago https://www.openssl.org/docs/crypto/X509_check_host.html (the documentation should be updated to note the earlier availability). Starting with 1.0.2, you can also ask OpenSSL to automatically perform hostname checks during the SSL handshake on the application's behalf: https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_hostflags.html https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set1_host.html https://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_add1_host.html https://www.openssl.org/docs/ssl/SSL_set_verify.html Sadly, we're still lacking documentation of SSL_get0_param() which is needed for a complete SSL hostname check recipe: const char *servername; SSL *ssl; X509_VERIFY_PARAM *param; servername = www.example.com; ssl = SSL_new(...); param = SSL_get0_param(ssl); /* Enable automatic hostname checks */ X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); X509_VERIFY_PARAM_set1_host(param, servername, 0); /* Configure a non-zero callback if desired */ SSL_set_verify(ssl, SSL_VERIFY_PEER, 0); /* * Establish SSL connection, hostname should be checked * automatically test with a hostname that should not match, * the connection will fail (unless you specify a callback * that returns despite the verification failure. In that * case SSL_get_verify_status() can expose the problem after * connection completion. */ ... I don't know does the first one support wildcards or no! Seems to be: how does Curl_cert_hostcheck work - is the answer, but I don't know how it works. Wildcard support is configured via the flags documented for X509_check_host(), the two most frequently useful are: X509_CHECK_FLAG_NO_WILDCARDS X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Intermediate certificates
On Tue, Jan 27, 2015 at 10:21:01PM +0300, Serj wrote: Some web-sites don't send all intermediate certs during SSL Handshake. Indeed some websites are misconfigured. For example, www.verisign.com sends only server's cert but doesn't send next intermediate cert: But www.verisign.com is not among them: $ sleep 2 | openssl s_client -showcerts -connect www.verisign.com:443 21 | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs -noout subject=/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=Private Organization/serialNumber=2158113/C=US/postalCode=94043/ST=California/L=Mountain View/street=350 Ellis Street/O=Symantec Corporation/OU=Infrastructure Operations /CN=www.verisign.com issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA subject=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 subject=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 issuer=/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority So, I need to set a list of intermediate certs for my SSL connections. How to do this? With SSL_CTX_load_verify_locations() I can set only trusted root certs, but not intermediate certs. This is not needed for properly configured servers, such as www.verisign.com. While providing additional untrusted (intermediate) certificates is possible, it is complex and the right solution is for the broken sites to fix their certificate chain configuration. It is unfortunate that browsers lend a helping hand to such sites. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Hostname validation
Hi, Viktor. 27.01.2015, 20:23, Viktor Dukhovni openssl-us...@dukhovni.org: I would set SSL verification parameters is to obtain the parameter handle via SSL_get0_param() or where appropriate SSL_CTX_get0_param(), and use the various X509_VERIFY_PARAM_mumble() functions to tweak the parameter object in place. Why are not there any X509_VERIFY_PARAM_mumble() functions in your code? So your code is not complete? And if so why it was already added to wiki here: http://wiki.openssl.org/index.php/Hostname_validation As I mentioned, this function should be documented, but is not yet. The documentation for these functions is not yet written. The way Yes, these need (more) documentation. That's why maybe it is better to use X509_check_host() in post conection checks now? It's strangely, why I read in documentaion: -- Applications are strongly advised to use this interface in preference to explicitly calling X509_check_host(3), hostname checks are out of scope with the DANE-EE(3) certificate usage, and the internal check will be suppressed as appropriate when DANE support is added to OpenSSL. and no any documentation on how to set properly params for SSL or CTX! NOTES Applications are encouraged to use X509_VERIFY_PARAM_set1_host() rather than explicitly calling X509_check_host(3). Host name checks are out of scope with the DANE-EE(3) certificate usage, and the internal checks will be suppressed as appropriate when DANE support is added to OpenSSL. -- and no any documentation on how to set properly params for SSL or CTX! Maybe this code is right, while there is no full documentation yet: char servername[]=www.openssl.org\x0; X509_VERIFY_PARAM *param; param = X509_VERIFY_PARAM_new(); //enable automatic hostname checks X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); X509_VERIFY_PARAM_set1_host(param, servername,0); SSL_CTX_set1_param(ctx, param); //is right if combined by a bitwise 'OR' operation //free param X509_VERIFY_PARAM_free(param); -- Best Regards, Serj ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Intermediate certificates
Hello. Some web-sites don't send all intermediate certs during SSL Handshake. For example, www.verisign.com sends only server's cert but doesn't send next intermediate cert: s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 So, I need to set a list of intermediate certs for my SSL connections. How to do this? With SSL_CTX_load_verify_locations() I can set only trusted root certs, but not intermediate certs. -- Best Regards, Serj ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Hostname validation
On Tue, Jan 27, 2015, Serj wrote: Hi, Viktor. 27.01.2015, 23:07, Viktor Dukhovni openssl-us...@dukhovni.org: It is complete enough. The word mumble is not meant to be taken You full code from wiki is: const char *servername; SSL *ssl; X509_VERIFY_PARAM *param; servername = www.example.com; ssl = SSL_new(...); param = SSL_get0_param(ssl); /* Enable automatic hostname checks */ X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); X509_VERIFY_PARAM_set1_host(param, servername, 0); /* Configure a non-zero callback if desired */ SSL_set_verify(ssl, SSL_VERIFY_PEER, 0); /* * Establish SSL connection, hostname should be checked * automatically test with a hostname that should not match, * the connection will fail (unless you specify a callback * that returns despite the verification failure. In that * case SSL_get_verify_status() can expose the problem after * connection completion. */ ... You set here only param: X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); X509_VERIFY_PARAM_set1_host(param, servername, 0); But how this variable is associated with ssl object or ctx object? I don't understand really! Please explain more in detail. It's this: param = SSL_get0_param(ssl); Because SSL_get0_param retrieves the internal pointer to parameters used by ssl: so if you modify those parameters the modified versions will be used by ssl. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Hostname validation
Hi, Viktor. 27.01.2015, 23:07, Viktor Dukhovni openssl-us...@dukhovni.org: It is complete enough. The word mumble is not meant to be taken You full code from wiki is: const char *servername; SSL *ssl; X509_VERIFY_PARAM *param; servername = www.example.com; ssl = SSL_new(...); param = SSL_get0_param(ssl); /* Enable automatic hostname checks */ X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); X509_VERIFY_PARAM_set1_host(param, servername, 0); /* Configure a non-zero callback if desired */ SSL_set_verify(ssl, SSL_VERIFY_PEER, 0); /* * Establish SSL connection, hostname should be checked * automatically test with a hostname that should not match, * the connection will fail (unless you specify a callback * that returns despite the verification failure. In that * case SSL_get_verify_status() can expose the problem after * connection completion. */ ... You set here only param: X509_VERIFY_PARAM_set_hostflags(param, X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS); X509_VERIFY_PARAM_set1_host(param, servername, 0); But how this variable is associated with ssl object or ctx object? I don't understand really! Please explain more in detail. I know this function only SSL_CTX_set1_param() that associates param with context ctx. -- Best Regards, Serj ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Hostname validation
28.01.2015, 00:04, Dr. Stephen Henson st...@openssl.org: It's this: param = SSL_get0_param(ssl); Because SSL_get0_param retrieves the internal pointer to parameters used by ssl: so if you modify those parameters the modified versions will be used by ssl. Thanks, Stephen. Now it's clear. -- Best Regards, Serj ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Intermediate certificates
On Tue, Jan 27, 2015 at 11:42:51PM +0300, Serj wrote: It is unfortunate that browsers lend a helping hand to such sites. So, you want to say that browsers trust connections that don't provide intermediate certs during SSL handhake? As I know most browsers have also intermediate certs in their stores as builtin objects and also as received during handshakes. That's why any documentation how to set intermediate certificates for my SSL connections will be very needed. What browsers do is cache the intermediate certificates. If a sites fails to send them, the browser can still find it in it's cache and use those cached intermediate certificates to do the validation. If the missing intermediate certificate is not cached the site will not work in the browser. But if you then visit a site that has the same intermediate certificate that does send it, and then go back to the broken site it will suddenly work. Browsers have too many work arounds for broken sites which results in those sites not actually getting fixed. Kurt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Intermediate certificates
Browsers have too many work arounds for broken sites which results in those sites not actually getting fixed. Because if the site doesn't work, the user will blame the browser and switch. :( ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Intermediate certificates
From: openssl-users On Behalf Of Kurt Roeckx Sent: Tuesday, January 27, 2015 17:14 On Tue, Jan 27, 2015 at 11:42:51PM +0300, Serj wrote: snip What browsers do is cache the intermediate certificates. snip That's one possibility. Another is that it uses AuthorityInfoAccess to fetch the cert automatically, which OpenSSL currently does not (unless you figure out a custom X509_LOOKUP to do so). ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
