Optional validation of time in OpenSSL Reg.
Hi, I see that the openSSL certificate verify utility uses the X509_verify_cert() in x509_vfy.c for certificate validation. Based on the manual pages for verify, I understand that the order for verification is as follows: 1. Firstly a certificate chain is built up starting from the supplied certificate and ending in the root CA. 2. The second operation is to check every untrusted certificate's extensions for consistency with the supplied purpose. 3. The third operation is to check the trust settings on the root CA. 4. The final operation is to check the validity of the certificate chain. The validity period is checked against the current system time and the notBefore and notAfter dates in the certificate. The certificate signatures are also checked at this point. What would be the best way to make the time check optional? One way as seen from the code could be to make this call optional based on some environmental variable. Eg: if(TIME_CHECK_ON) check_cert_time(ctx, xs); else don't check time; Is there any alternative way to achieve this? I understand that by passing a custom time using void X509_STORE_CTX_set_time(X509_STORE_CTX *ctx, unsigned long flags, time_t t); and by setting this flag --X509_V_FLAG_USE_CHECK_TIME, I can make the verify code use the time I provide, but whatever time I provide through the time_t variable, will it be used as notBefore or notAfter time? (since time_t t represents the number of seconds since the start of the Unix epoch). I would need this optional time checking since I cannot count on my system time to be stable all the time :) Regds, Ashok
Re: Optional validation of time in OpenSSL Reg.
On 1/12/2012 2:48 PM, Ashok C wrote: Hi, I see that the openSSL certificate verify utility uses the X509_verify_cert() in x509_vfy.c for certificate validation. Based on the manual pages for verify, I understand that the order for verification is as follows: 1. Firstly a certificate chain is built up starting from the supplied certificate and ending in the root CA. 2. The second operation is to check every untrusted certificate's extensions for consistency with the supplied purpose. 3. The third operation is to check the trust settings on the root CA. 4. The final operation is to check the validity of the certificate chain. The validity period is checked against the current system time and the notBefore and notAfter dates in the certificate. The certificate signatures are also checked at this point. What would be the best way to make the time check optional? One way as seen from the code could be to make this call optional based on some environmental variable. Eg: if(TIME_CHECK_ON) check_cert_time(ctx, xs); else don't check time; Is there any alternative way to achieve this? I understand that by passing a custom time using void X509_STORE_CTX_set_time(X509_STORE_CTX *ctx, unsigned long flags, time_t t); and by setting this flag --X509_V_FLAG_USE_CHECK_TIME, I can make the verify code use the time I provide, but whatever time I provide through the time_t variable, will it be used as notBefore or notAfter time? (since time_t t represents the number of seconds since the start of the Unix epoch). It will be used in place of the *current* system time, so now it will check that the certificates were valid at the time you specify, not the time the computer thinks is now. Specifically it will check that t is not before any NotBefore time in certificates and t is not after any NotAfter times in certificates. I would need this optional time checking since I cannot count on my system time to be stable all the time :) Regds, Ashok __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
java to openssl
I am new to this so go easy on me. I had this dropped in my lap and have limited info but here is what I have. I was sent 2 files and a partial java code that another company uses to decrypt. import java.io.InputStream; import javax.crypto.Cipher; import javax.crypto.SecretKey; import javax.crypto.spec.IvParameterSpec; import javax.crypto.spec.SecretKeySpec; byte[] encryptedData = (byte[])msg.getBody().get(); byte[] decryptionKey = readFileContents(/keyfile_3des); final SecretKey key = new SecretKeySpec(decryptionKey, DESede); _log.debug(Creating Cipher ...); final IvParameterSpec iv = new IvParameterSpec(new byte[8]); final Cipher decipher = Cipher.getInstance(DESede/CBC/PKCS5Padding); decipher.init(Cipher.DECRYPT_MODE, key, iv); _log.debug(Performing Decryption ...); final byte[] decryptedData = decipher.doFinal(encryptedData); I am trying to get the same result with decrypting in openssl $ openssl enc -d -kfile keyfile_3des.txt -in encrypt.20120109.16.txt -out test1.txt -des-ede-cbc -nosalt I thought that the default padding for openssl was pkcs5 but I get what seems to me to be a padding error bad decrypt 140735237683644:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:467: It will run without error if I use -nopad but does not decrypt the file. Also no error with -des-ede-cfb. I am not all that familiar with java and don't know how to finish the partial jumbled code that I was sent either. I would greatly appreciate any help with openssl or the partial java code. Philip Landreth plandr...@cdsxrx.com philip.landr...@gmail.com
Re: Optional validation of time in OpenSSL Reg.
On Thu, Jan 12, 2012, Ashok C wrote: Hi, I see that the openSSL certificate verify utility uses the X509_verify_cert() in x509_vfy.c for certificate validation. Based on the manual pages for verify, I understand that the order for verification is as follows: 1. Firstly a certificate chain is built up starting from the supplied certificate and ending in the root CA. 2. The second operation is to check every untrusted certificate's extensions for consistency with the supplied purpose. 3. The third operation is to check the trust settings on the root CA. 4. The final operation is to check the validity of the certificate chain. The validity period is checked against the current system time and the notBefore and notAfter dates in the certificate. The certificate signatures are also checked at this point. What would be the best way to make the time check optional? Is there any alternative way to achieve this? I understand that by passing a custom time using void X509_STORE_CTX_set_time(X509_STORE_CTX *ctx, unsigned long flags, time_t t); and by setting this flag --X509_V_FLAG_USE_CHECK_TIME, I can make the verify code use the time I provide, but whatever time I provide through the time_t variable, will it be used as notBefore or notAfter time? (since time_t t represents the number of seconds since the start of the Unix epoch). Yes it will. This can also be set in the X509_VERIFY_PARAM structure. I would need this optional time checking since I cannot count on my system time to be stable all the time :) Validity time errors in the chain also produce the two errors X509_V_ERR_CERT_NOT_YET_VALID and X509_V_ERR_CERT_HAS_EXPIRED which can be overridden in the verify callback. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Verify intermediate certificate
Hello group, I have a question regarding the verify method of OpenSSL: If I have a certificate chain Root - A - B - Leaf where Leaf is the certificate of a webserver (https) and Root is a self-signed certificate. In this scenario, is it valid for the webserver to provide only A/B/Leaf and omit Root during the SSL handshake? I'm seeing strange errors and noticed that a webserver of ours is configured in that manner (and it seems odd to me). Also, when I have certificates A + B and do: $ openssl verify -CApath /sys -CAfile certA.crt certB.crt certB.crt: /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 error 2 at 1 depth lookup:unable to get issuer certificate (I'm only using /sys to make openssl not pull in /etc/ssl/certs) The verify fails. Why is that? The immediate signature is valid, does the verify command expect to always terminate at a self-signed certificate? Or, in other words: Let's assume I have a ultimate root (self-signed) Root and a branched CA X. I would like to trust X and all it's children, but not Root. Is this not possible? Best regards, Johannes __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify intermediate certificate
On Thu January 12 2012, Johannes Bauer wrote: Hello group, I have a question regarding the verify method of OpenSSL: If I have a certificate chain Root - A - B - Leaf where Leaf is the certificate of a webserver (https) and Root is a self-signed certificate. In this scenario, is it valid for the webserver to provide only A/B/Leaf and omit Root during the SSL handshake? I'm seeing strange errors and noticed that a webserver of ours is configured in that manner (and it seems odd to me). It is a third party verification system that is used. How could you trust the server to tell you itself who it is? Thus, the need for obtaining the root certificate some way other than having it sent by the server in question. And yes, 'root' certificates are self-signed, signed by an 'independent' third party in the business of being trusted for that purpose. Which in this post, the 'trusted third party' seems to be your own network admin (which may be yourself ;-) ) Mike Also, when I have certificates A + B and do: $ openssl verify -CApath /sys -CAfile certA.crt certB.crt certB.crt: /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 error 2 at 1 depth lookup:unable to get issuer certificate (I'm only using /sys to make openssl not pull in /etc/ssl/certs) The verify fails. Why is that? The immediate signature is valid, does the verify command expect to always terminate at a self-signed certificate? Or, in other words: Let's assume I have a ultimate root (self-signed) Root and a branched CA X. I would like to trust X and all it's children, but not Root. Is this not possible? Best regards, Johannes __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
DSA_verify(...) method FIPS compliant?
Hey all, I'm currently using FIPS capable OpenSSL 0.9.8r w/FOM 1.2.2 and I noticed that the DSA_verify() method returns 0 in FIPS mode because it fails the DSA_FLAG_NON_FIPS_ALLOW flag check. The documentation for DSA_FLAG_FIPS_METHOD in dsa.h states: /* If this flag is set the operations normally disabled in FIPS mode are * permitted it is then the applications responsibility to ensure that the * usage is compliant. */ I'm a little confused as to what ...applications responsiblilty to ensure that the usage is compliant. means exactly. Does this mean DSA_verify() is not FIPS compliant? If so, will moving to FOM 1.2.3 help? Cheers, -Chang Lee
Re: AES-Assembler for Powerpc
I'd suggest to move the discussion to openss-dev, as I unfortunately
don't have time to follow openssl-users.
I tried using the AES-assembler code for my PowerPC EABI, but
everytime I start speed aes my OS crashes. The 32Bit OS is a custom
one.
OS crashes? Not application, but OS?
The first problem was the usage of r13. On Page 3 of the PowerPC EABI
spec [1], the r13 register is described as a dedicated register. So
the usage of such a register is delicate.
Other ABI specs are not as categorical about r2 and r13. I was told by
IBM that r2 is used as TLS pointer in 32-bit OSes and r13 in 64-bit
ones. As signal handler is allowed to reference TLS pointer, these
registers were left alone. Referred specification says that *both* r2
and r13 can be dereferenced in signal/exception handler...
I could not use it because it is forbidden in our startup code. But
at Line 101 of crypto/aes/asm/aes-ppc.pl I found a workaround for
the 64 bit case, which replaces r13 with r0.
# stay away from TLS pointer
if ($SIZE_T==8) { die if ($t1 ne r13); $t1=r0; }
else { die if ($Tbl3 ne r2); $Tbl3=$t0; $t0=r0; }
So in the aes-ppc Perl source I replaced r13 with r0 at line 77,
which made the line 538
lwz $t1,4($key)
execute smoothly.
Presumably this is circumstantial. In sense that it worked solely
because exceptions didn't happed to dereference r2 at times subroutine
in question was executing. In other words, replacing r13 with r0 is not
sufficient, and the only right thing to do is to leave alone *both* r2
and r13. One can off-load $out to stack and use r4 instead of r13.
The second and much more delicate problem was the LAES_Te symbol:
why do we need this piece of code?
LAES_T[ed] returns pointer to the S-box in position-independent manner
that is not OS-specific. Position-independence is a must for shared
libraries, and OS independence was easier to implement than to make
multiple all 6 OS flavors work and maintain.
Would it be safe to leave it
aside? I'm asking because this code (in my case) overwrites r3,
therefore leaving me without access to the first argument of the
whole function. Because the value of the link register is saved in
r3,
Why is r3 concern for *you*? I mean why would you insist on having
access to original value of first argument? By the time it's overwritten
it's used up (input is loaded into registers) and you don't need the
value anymore.
the out argument
out argument is r4, not r3.
will point to the .text section,
It's conscious decision. Normally you'd put S-box into a read-only
section such as .const, but .text is as good. Moreover, some compilers
do this all by themselves.
and thus the
whole code will crash if the MMU prohibits accesses to this section.
Is it possible to program PPC MMU so that it would allow execution but
prohibit read access? At the very least having S-box in .text segment
was proven to work on all 6 supported OS flavors. If it's possible *and*
if your OS actually does it, then S-box should be placed elsewhere and
pulling its address should be different in your case.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Reworking OpenSSL code from using files to reading keys from memory
From: owner-openssl-us...@openssl.org On Behalf Of Wojciech Kocjan Sent: Wednesday, 11 January, 2012 14:47 I am working on reworking existing code that uses several OpenSSL APIs from using files to store keys, certificates and CAs to passing this directly from memory (so that it can be retrieved from memory, read from encrypted storage among other things). This is my first post here, so if this is not the correct group and/or anything below seems obvious/completely incorrect, please feel free to correct me. Our code currently uses the following APIs: - SSL_CTX_use_certificate_file and SSL_CTX_use_PrivateKey_file This part seems easier. From what I understand, I can use BIO_s_mem and pass it key/certificate data from memory. I could then use PEM to get EVP_PKEY or X509. For PEM files yes. For DER files (which OpenSSL also supports here) use d2i_*_bio on BIO_s_mem or d2i_* directly on memory. Then I could just invoke SSL_CTX_use_certificate() and SSL_CTX_use_PrivateKey() directly. In practice it may be a bit more complex, but at least I know the solution. - SSL_CTX_load_verify_locations and SSL_CTX_set_client_CA_lis This part is the harder one. I was not able to find any APIs to do this. _set_client_CA_list already takes STACK_OF(X509). Instead of getting that stack from SSL_load_client_CA_file, construct it yourself with sk_X509_new etc. Or use SSL_add_client_CA instead. _load_verify_ is the hard one. The builtin X509_STORE/X509_LOOKUP mechanism only does PEM files. It *is* pluggable -- you can substitute your own LOOKUP's -- but it appears to me you have to reimplement quite a bit, and I haven't made the attempt. Another alternative I was wondering about is whether I can provide another way for OpenSSL to access the keys - i.e. so that I can tell that filename is something like mystorage://key1.pem and OpenSSL would use my BIO (or create BIO_s_mem and preload it with data) instead of BIO_s_file. AFAIK not at the OpenSSL level for _load_verify_. If your OS has any kind of virtual files or filesystems, you could use those. Most(?) nowadays have at least something for remote files, like NFS or NetBIOS/SMB, that you can use/fake with enough effort. AIUI at least Windows and Linux have ways to install your own driver, which could do this sort of thing, but those aren't simple to write. This is dependent on your OS of course, and often requires 'root' or 'admin' which an SSL (and OpenSSL) app doesn't otherwise need. Similarly, your C library's fopen *could* have a capability like this. But I haven't seen it in any commonly used ones. I've heard a rumor Plan9 does, but I doubt you (or your users) use Plan9. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: java to openssl
From: owner-openssl-us...@openssl.org On Behalf Of Philip R. Landreth Sent: Thursday, 12 January, 2012 09:33 I was sent 2 files and a partial java code that another company uses to decrypt. snip and realigned byte[] encryptedData = (byte[])msg.getBody().get(); byte[] decryptionKey = readFileContents(/keyfile_3des); final SecretKey key = new SecretKeySpec(decryptionKey, DESede); _log.debug(Creating Cipher ...); final IvParameterSpec iv = new IvParameterSpec(new byte[8]); final Cipher decipher = Cipher.getInstance(DESede/CBC/PKCS5Padding); decipher.init(Cipher.DECRYPT_MODE, key, iv); _log.debug(Performing Decryption ...); final byte[] decryptedData = decipher.doFinal(encryptedData); I am trying to get the same result with decrypting in openssl $ openssl enc -d -kfile keyfile_3des.txt -in encrypt.20120109.16.txt -out test1.txt -des-ede-cbc -nosalt I thought that the default padding for openssl was pkcs5 but I get what seems to me to be a padding error bad decrypt 140735237683644:error:06065064:digital envelope routines: EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:467: The 'enc' utility normally does *password based encryption* which derives the actual cipher key by a complicated hashing process. -kfile takes the *password* from a file, not the actual key. The only option that takes an actual key is -K and it doesn't read from a file, so you'll have to get the key bytes, convert to hex, and pass them to -K. Which may be insecure on an OS where other processes can see process args, if anyone else can run programs. With -K you must give -iv explicitly, also in hex; that Java code is using 8 bytes of zero for the IV (which substantially reduces the security benefit the IV is intended to provide) so you must also. Alternatively write your own code which just calls the DES_ routines directly or the EVP_Decrypt* routines with cipher=EVP_des_ede3_cbc(). It's probably about 20-40 lines as a standalone program (depending on what options you need/want) or less as a function you integrate into an existing program that uses the result if there is such. PKCS5 is indeed the default for EVP_ and 'enc'; for DES_ you have to code it yourself, but it's only a few lines even at most careful. This shows up as a padding error because the raw decrypt operation with the wrong key produces effectively random garbage, and the first thing that looks at that data is the remove-padding operation which says hey, this is garbage, I can't do squat with it. With -nopad you should still get garbage, it just isn't detected as such. I'm also concerned that your filename is .txt. If it is readable (e.g. all or nearly all alphanumeric) then it is (with overwhelming probability) not the actual ciphertext, rather an 'armoring' such as commonly used base64 or hex. If it is (only) base64 the 'enc' utility can handle that with -a and maybe -A; for hex or other you must decode it yourself before passing in (which you can do on standard input); and for your own program you need to do either or whatever. If the data is actually binary and you just named it .txt it *might* be just the ciphertext, or it might be some other format that *includes* the ciphertext, such as PKCS7/CMS DER. Or HTTP-kindof-MIME. Or XML. Or who knows. msg.getBody().get() suggests to me that there is some logic involved in getting the ciphertext out of the message, but you'll have to find out what that consists of. The cast also worries me; AFAICS the only other Java type than can be cast to byte[] is Object, and an API for .get() that does that would be pretty weird. (Array-of-object types can be elementally-upcast, but not array-of-primitive which are implemented differently and have no up, or vice versa.) If you find out this cast is not redundant and useless, I'd be curious. You also have .txt on the keyfile and readFileContents(keyfile) might be doing something other than just reading the bytes, although here the name is not so suggestive to me. If it is, you need to do whatever that reading process is in the argument to enc -K, or in your own code. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Verify intermediate certificate
From: owner-openssl-us...@openssl.org On Behalf Of Michael S. Zick Sent: Thursday, 12 January, 2012 13:24 On Thu January 12 2012, Johannes Bauer wrote: Hello group, I have a question regarding the verify method of OpenSSL: If I have a certificate chain: Root - A - B - Leaf [...] is it valid for the webserver to provide only A/B/Leaf and omit Root during the SSL handshake? [...] It is a third party verification system that is used. How could you trust the server to tell you itself who it is? Thus, the need for obtaining the root certificate some way other than having it sent by the server in question. Exactly. Which in OpenSSL is usually 'CAfile' or 'CApath'. And yes, 'root' certificates are self-signed, signed by an 'independent' third party in the business of being trusted for that purpose. Nit: not necessarily in the 'business' of being trusted. Just some party which IS trusted. For example some part(s?) of the US DoD issue certs for employees and contractors. The DoD's 'business' is preparing to do and doing military actions directed by the elected government (which should do so in the interests of the country, but that's a different issue and offtopic here). Issuing certs is a minor sideline. Most(?) of the well-known public CAs were created solely to be CAs, but many(?) of them have been acquired by businesses which have other functions as well. Which in this post, the 'trusted third party' seems to be your own network admin (which may be yourself ;-) ) Exactly. This is similarly a sideline. Mike Also, when I have certificates A + B and do: $ openssl verify -CApath /sys -CAfile certA.crt certB.crt certB.crt: /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 error 2 at 1 depth lookup:unable to get issuer certificate (I'm only using /sys to make openssl not pull in /etc/ssl/certs) The verify fails. Why is that? The immediate signature is valid, does the verify command expect to always terminate at a self-signed certificate? Yes. Or rather the libcrypto routine X509_verify_cert, used by the 'verify' utility and also the SSL handshake logic and also other applications if they wish, insists on reaching a root. Or, in other words: Let's assume I have a ultimate root (self-signed) Root and a branched CA X. I would like to trust X and all it's children, but not Root. Is this not possible? Not in OpenSSL, unless you change the verify logic, or replace or override it with your own (which AFAICS could be done, with some effort, using the optional verify callback). It's not clear to me this is the best policy choice; IE (or I believe actually some Windows feature IE uses) and Firefox and Java (JSSE) all allow you to establish a non-root as a trust anchor. But it's what OpenSSL does, and has for a long time. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
