Re: The new subject hash algorithm
On Mon, Apr 22, 2013, Krzysztof Benedyczak wrote: Hi Openssl Developers, Since openssl 1.0.0 a new subject hash is used, i.e. the output of the openssl x509 -subject_hash ... has changed. The old one was quite easy to decipher and commonly known (part of the MD5 hash of the bin form of the subject name). Now AFAIU MD5 has been changed do SHA1, but it seems that there are also other modifications (some normalization? or?). Is it possible to get a precise information how openssl generate the the aforementioned subject hash? I can try to infer it from source of course, but having an algorithm description would be of great help. I was trying to find some information on the topic but no luck. The reason for the question is that in Java software I need to support openssl-like certificates trust store. It's a bit complex and you need to be able to decode and reencode the Name structure to duplicate this. The function x509_name_canon performs the reencoding this is in crypto/asn1/x_name.c: /* This function generates the canonical encoding of the Name structure. * In it all strings are converted to UTF8, leading, trailing and * multiple spaces collapsed, converted to lower case and the leading * SEQUENCE header removed. * This encoding is then used to perform the hash using SHA1 in a similar way to the old algorithm (see X509_NAME_hash function in crypto/x509/x509_cmp.c). 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 openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Problems compiling 1.0.1e with no-tlsext
I can't get the 1.0.1e SSL library to build when I specify the following config options: shared no-ec2m no-idea no-krb5 no-mdc2 no-rc5 no-tlsext -DOPENSSL_IA32_SSE2 First I get warnings: s3_srvr.c: warning: implicit declaration of function 'ssl_check_clienthello_tlsext_late' s3_srvr.c: warning: implicit declaration of function 'tls12_get_sigandhash' s3_srvr.c: warning: implicit declaration of function 'tls12_get_sigid' s3_srvr.c: warning: implicit declaration of function 'tls12_get_hash' s3_clnt.c: warning: implicit declaration of function 'tls12_get_sigid' s3_clnt.c: warning: implicit declaration of function 'tls12_get_hash' Then the build fails altogether when compiling d1_srtp.c: d1_srtp.c: error: 'SSL_CTX' has no member named 'srtp_profiles' d1_srtp.c: error: 'SSL' has no member named 'srtp_profiles' If I rerun the config adding the 'no-srtp' option, I still get the 'implicit declaration' warnings and libssl is missing the following functions: ssl_check_clienthello_tlsext_late tls1_process_sigalgs tls12_get_req_sig_algs tls12_get_sigid tls12_get_hash tls12_get_sigandhash It looks like the fixes associated with PR: 2979 would resolve the 'ssl_check_clienthello_tlsext_late' warnings/errors. TLS extensions aren't REQUIRED for TLS 1.2 functionality, right? My reading of the RFC leads me to think that TLS 1.2 can function fine without extensions - albeit without support for some useful functionality (e.g. secure renegotiation). Thanks.
Re: MD5 in openSSL internals
-Original Message- From: Venkataragavan Narayanaswamy v...@brocade.com Sender: owner-openssl-us...@openssl.org Date: Tue, 23 Apr 2013 00:29:17 To: openssl-dev@openssl.orgopenssl-dev@openssl.org; openssl-us...@openssl.orgopenssl-us...@openssl.org Reply-To: openssl-us...@openssl.org Subject: MD5 in openSSL internals Hi, We are currently analyzing and understanding the security strength of the openSSL internal implementation to certify the products. In version 0.9.8d, TLSv1.0 alone is supported. Can you please answer the following or provide me with the documentation reference 1. Does openSSL library use MD5 internally for any operation? 2. Can we have SHA256 in the ciphersuite with TLSv1.0? Thanks, Venkat
Re: The new subject hash algorithm
Hi, W dniu 24.04.2013 17:36, Dr. Stephen Henson pisze: On Mon, Apr 22, 2013, Krzysztof Benedyczak wrote: Hi Openssl Developers, Since openssl 1.0.0 a new subject hash is used, i.e. the output of the openssl x509 -subject_hash ... has changed. The old one was quite easy to decipher and commonly known (part of the MD5 hash of the bin form of the subject name). Now AFAIU MD5 has been changed do SHA1, but it seems that there are also other modifications (some normalization? or?). Is it possible to get a precise information how openssl generate the the aforementioned subject hash? I can try to infer it from source of course, but having an algorithm description would be of great help. I was trying to find some information on the topic but no luck. The reason for the question is that in Java software I need to support openssl-like certificates trust store. It's a bit complex and you need to be able to decode and reencode the Name structure to duplicate this. The function x509_name_canon performs the reencoding this is in crypto/asn1/x_name.c: /* This function generates the canonical encoding of the Name structure. * In it all strings are converted to UTF8, leading, trailing and * multiple spaces collapsed, converted to lower case and the leading * SEQUENCE header removed. * This encoding is then used to perform the hash using SHA1 in a similar way to the old algorithm (see X509_NAME_hash function in crypto/x509/x509_cmp.c). Thanks a lot for the answer. I've tried it on a simple DN and I was able to reproduce the same hash as is outputted by Openssl. However I have some general doubts regarding the algorithm: -) what about multi-valued RDNs? According to RFC their order is irrelevant. Do you somehow sort them for the c19 form? -) what is the definition of the 'string' above? TeletexString, PrintableString, UTF8String, BMPString? More or less? Thanks again, Krzysztof __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Bug in call to an Engine during PKCS7_sign? (or not?)
On Wed, Apr 24, 2013, Alan Kozlay wrote: OpenSSL Team, Compiled for Android: OpenSSL 1.0.1e FIPS Module 2.0.3. I've created an Engine for PKCS#11 to perform RSA operations. It works when OpenSSL is used for TLS/SSL in both FIPS and non-FIPS mode. It works when OpenSSL is used for PKCS_sign in non-FIPS mode but not in FIPS mode. I see something occurring which I am not expecting and I'm wondering if it's a mistake in OpenSSL or intended. When I run with FIPS mode disabled, I see: [OpenSSL] PKCS7_sign [ENGINE] - pkcs11_rsa_sign [PKCS#11] - C_SignInit ?. When I run the test with fips mode enabled, the call stack looks like: [OpenSSL] PKCS7_sign [ENGINE] - pkcs11_rsa_encrypt [PKCS#11] - C_EncryptInit [PKCS#11] !!! crash with SIGSEGV !!! The crash is likely something in my PKCS11 code but should I be expecting PKCS7_sign to perform encryption like this? If so, what is it attempting to encrypt? Are you replacing the default RSA method or just the method for that specific private key? If it's the default method you might be messing with the FIPS POST. If you just replace that one key then can you provide a full stack trace? 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 openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OCSP_basic_verify
I am using OCSP software which pre-signs all certificate information.
Therefor if a nonce check is requested, my responders are not able to
provide the nonce back.
Knowing this I grabbed apache 2.4.4 from source and modified
/usr/local/src/httpd-2.4.4/modules/ssl/ssl_engine_ocsp.c
I commented out the following function:
if (rc == V_OCSP_CERTSTATUS_GOOD) {
if (OCSP_check_nonce(request, basicResponse) != 1) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, APLOGNO(01924)
Bad OCSP responder answer (bad nonce));
rc = V_OCSP_CERTSTATUS_UNKNOWN;
}
}
and I feel that it successfully resolved that problem.
The current issue i have is that my apache logs still say:
[ssl:error] [pid 24782:tid 140511052035840] AH01925: failed to verify the
OCSP response
[ssl:error] [pid 24782:tid 140511052035840] SSL Library Error:
error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error
(Verify error:unable to get local issuer certificate
I was able to resolve this by commenting out the following function:
if (rc == V_OCSP_CERTSTATUS_GOOD) {
/* TODO: allow flags configuration. */
if (OCSP_basic_verify(basicResponse, NULL, ctx-ctx, 0) != 1) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, APLOGNO(01925)
failed to verify the OCSP response);
ssl_log_ssl_error(SSLLOG_MARK, APLOG_ERR, s);
rc = V_OCSP_CERTSTATUS_UNKNOWN;
}
}
I don't fully understand why it works. Can anyone here comment on what risks
I am taking by doing these 2 modification, or comment on a better solution
to allow apache 2.4.4 work with my OCSP system.
--
View this message in context:
http://openssl.6102.n7.nabble.com/OCSP-basic-verify-tp44881.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
OCSP_basic_verify
I am using OCSP software which pre-signs all certificate information.
Therefor if a nonce check is requested, my responders are not able to
provide the nonce back.
Knowing this I grabbed apache 2.4.4 from source and modified
/usr/local/src/httpd-2.4.4/modules/ssl/ssl_engine_ocsp.c
I commented out the following function:
if (rc == V_OCSP_CERTSTATUS_GOOD) {
if (OCSP_check_nonce(request, basicResponse) != 1) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, APLOGNO(01924)
Bad OCSP responder answer (bad nonce));
rc = V_OCSP_CERTSTATUS_UNKNOWN;
}
}
and I feel that it successfully resolved that problem.
The current issue i have is that my apache logs still say:
[ssl:error] [pid 24782:tid 140511052035840] AH01925: failed to verify the
OCSP response
[ssl:error] [pid 24782:tid 140511052035840] SSL Library Error:
error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error
(Verify error:unable to get local issuer certificate
I was able to resolve this by commenting out the following function:
if (rc == V_OCSP_CERTSTATUS_GOOD) {
/* TODO: allow flags configuration. */
if (OCSP_basic_verify(basicResponse, NULL, ctx-ctx, 0) != 1) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, APLOGNO(01925)
failed to verify the OCSP response);
ssl_log_ssl_error(SSLLOG_MARK, APLOG_ERR, s);
rc = V_OCSP_CERTSTATUS_UNKNOWN;
}
}
I don't fully understand why it works. Can anyone here comment on what risks
I am taking by doing these 2 modification, or comment on a better solution
to allow apache 2.4.4 work with my OCSP system.
--
View this message in context:
http://openssl.6102.n7.nabble.com/OCSP-basic-verify-tp44882.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
