Re: Verify intermediate certificate
On 12.01.2012 19:05, Kenneth Goldman wrote: 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's more than valid. I think it's essential that the server omit the root. If the server supplied the entire chain, they could create the entire chain, and thus could claim to be anyone. Hmm - I disagree with that assessment. The client has to check that the root (that the server may provide or may omit) is inside the trusted certificate store of the client -- regardless of the client provides it or not. And clients (and probably therefore OpenSSL) do that, too: When I for testing purposes create and send a complete certificate path for a SSL webserver, Firefox still rejects it as it should, because no certificate is in the truststore. The root must be delivered out of band, trusted by other means. Correct. The question is just: can this root of trust be an intermediate certificate or must it be a self-signed certificate? Is this one of the checks that occurs within the OpenSSL client? To clarify what I mean, please consider the tiny picture at http://pastebin.ca/2102780 Let's say I have some ultimate root A which has issued a sub-CA B for me. I use B to create, for example, a certificate for my webserver D. Now I have clients which should only connect to webservers that have been issued by D. I configure the webserver to only send D certificate and have in my clients only one certificate in the certificate store: B. The clients cannot connect (cannot verify peer), because in the client's certificate store, A is missing (deliberately!). The reason why it is missing is the following: If I put A into the store of the clients, A might have issued a sub-CA certificate to my opponent C (which I do not have control over). C would sign a certificate for Eve which contains my server's DNS name as CN. Then when Eve would make a man-in-the-middle attack with it's fake webserver, my clients would still connect, since they can construct a path to the root A (E - C - A). I really hope I explained this well enough, it's kind of hard via mail, I'm afraid. Best regards, Joe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: AES-Assembler for Powerpc
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.
http://cvs.openssl.org/chngview?cn=22015. It addresses similar issue
even sha512-ppc.pl module.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: how to see the SSL handshake
You can use wireshark to analyse ssl packets. -- View this message in context: http://old.nabble.com/how-to-see-the-SSL-handshake-tp33046057p33125719.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Get CMS algorithm
Hello, I'm currently developping a API using CMS object with openssl. In a first function I create a CMS_encrypt object in which I specify an algorithm to cipher the session key. In a second function, I need to get the algorithm used to cipher this session key in the CMS object. Do you know which function i should use to get this algorithm ? Thanks Jérémy -- View this message in context: http://old.nabble.com/Get-CMS-algorithm-tp33126800p33126800.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
FW: Optional validation of time in OpenSSL Reg.
-Original Message- From: Dr. Stephen Henson [mailto:st...@openssl.org] Sent: Thursday, January 12, 2012 8:52 AM To: openssl-users@openssl.org Subject: 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 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
stunnel 4.52 released
Dear Users, I have released version 4.52 of stunnel. This is a bugfix release. Upgrade is highly recommended. The ChangeLog entry: Version 4.52, 2012.01.12, urgency: MEDIUM: * Bugfixes - Fixed write closure notification for non-socket file descriptors. - Removed a line logged to stderr in inetd mode. - Fixed Socket operation on non-socket error in inetd mode on Mac OS X platform. - Removed direct access to the fields of the X509_STORE_CTX data structure. Home page: http://www.stunnel.org/ Download: ftp://ftp.stunnel.org/stunnel/ SHA-256 hash for stunnel-4.52.tar.gz: 7c78c178074e9b96331518a9c309d2e95ca9ad6e0338a96d5ab8ad47fde4347c Best regards, Mike PGP.sig Description: This is a digitally signed message part
Re: Reworking OpenSSL code from using files to reading keys from memory
On Thu January 12 2012, Dave Thompson wrote: 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. If using gnu/binutils ld to build your application for the custom OS (or native ld on HP-UX or Solaris) you can use the linker's: --wrap=symbol command option to provide your own fopen as required. Ref: http://okmij.org/ftp/syscall-interpose.html http://linux.die.net/man/1/ld Mike __ 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
Re: Verify intermediate certificate
On 12.01.2012 19:23, Michael S. Zick wrote: 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? I can trust the webserver because the signature of it's certificate was verifiably created by the intermediate CA (which I trust and who's certificate the client has in its trust store). 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. Well, the thing is: Having them self-signed is not necessary for security purposes. It apparently is what OpenSSL requires. Which in this post, the 'trusted third party' seems to be your own network admin (which may be yourself ;-) ) Well, I'm just part of the big picture ;-) Best regards, Joe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify intermediate certificate
On 13.01.2012 01:02, Dave Thompson wrote: 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. Ah, I figured I'd have to go there. The reason why I was hoping to get around this is that the OpenSSL code is properly reviewed and auditted -- I would rather not write code which could have serious sercurity implications if it's broken (especially since it's not properly reviewed). 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. Thank you for your clarification. I also do not really see the point why the anchor of trust has to be self-signed. In my scenario this restriction actually makes the whole system less secure (since it allows a superset of certificates to be valid instead of just a tiny subset). I'll have a look into the custom verify-peer-callback and see how difficult it is and how easily it can be used. Best regards, Joe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Verify intermediate certificate
On 13.01.2012 10:15, Curt Sampson wrote: On 2012-01-13 09:54 +0100 (Fri), Johannes Bauer wrote: Let's say I have some ultimate root A which has issued a sub-CA B for me. I use B to create, for example, a certificate for my webserver D. Now I have clients which should only connect to webservers that have been issued by D. I configure the webserver to only send D I think you meant, B there. Ah, yes. I really hope I explained this well enough, it's kind of hard via mail, I'm afraid. I think understand exactly what you are doing and why you want to do it. (I have similar issues within a system in which I'm working.) Ah, good, then I explained it well enough :-) Do you have a solution for your scenario? Do you manually check certificates? Or is there some workaround? Best regards, Joe __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: java to openssl
Thank you for your help! The files were given to me in .txt format and the original file is a .txt. as for the keyfile being in .txt I don't know. I used -p to print the key and iv and used those instead of using -kfile. iv did not print as 8 zeros either it prints a 16 digit alpha numberic. The encrypted file .txt is not readable(not alpha numeric) also when I add -a it will output a blank .txt file. Thank you for your help again. Philip Landreth -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Thursday, January 12, 2012 6:58 PM To: openssl-users@openssl.org Subject: 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.
Re: Re: Verify intermediate certificate
* Johannes Bauer wrote on Fri, Jan 13, 2012 at 14:22 +0100: [...] 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? [yes, it is not possible by default] Thank you for your clarification. I also do not really see the point why the anchor of trust has to be self-signed. I also wondered about this time ago. I think when a user explicitely puts a sub-CA or even a non-CA certificate into the database of trusted certificates, chain verification could stop there without knowing the root-CA. Only point to require root-CA is to check if it still is valid and require it in order to be able to check it's CRL for the sub-CA being included. Personally, I still wonder why I should be stopped from trusting a sub-CA even if the root-CA revoked it when I explicitely configure it to do so, but anyway usually OS or browser vendors seem to decide for the users whom to trust ;-) In my scenario this restriction actually makes the whole system less secure (since it allows a superset of certificates to be valid instead of just a tiny subset). Certify the identity to be authentic, that means that the name given in the certificate is authentic. This is like an ID card or passport. From this it cannot be concluded whether the authentic name owner is authorized for communication (or whatever). For this, some list of allowed names is needed. This is like a guest list. Unfortunately it seems to happen from time to time to meet some projects/installations that check only whether a peer is authentic but not it authorized (like: anyone with a valid password can use the VIP entry, because no guest list check is performed). For example, in a typical webbrowser I think you cannot configure NOT to communicate with authentic badguy.malware.com; if TLS makes it absolutely sure that you really communicate with `badguy', you will get a green security symbol :-) oki, Steffen -- End of message. My personal opinion only etc. About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Removing a cipher
Is there a way to remove a cipher completely from ever being used? We use retina and it is picking up DES-CBC-SHA and I need to remove it from being used, seen, or included in any scan. Even better is there away to remove all LOW ciphers from being used or listed? Thanks In Advance -r- _ Sr. Solaris Systems Network Engineer - SCSA, Sec+ Code - 724000D Desk: 760.939.2738 DSN: 437 Fax: 760 939 1684 *** UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity. -Dennis Ritchie smime.p7s Description: S/MIME cryptographic signature
Re: Removing a cipher
Hi, In an application that you use or one that you've written? Ie where is this low cipher being seen? alan
