HPUX 64-bit make error in crypto/dso/dso_dlfcn.c
If I modify crypto/dso/dso_dlfcn.c: # define HAVE_DLINFO 1 /* # if defined(_AIX) || defined(__CYGWIN__) || \ defined(__SCO_VERSION__) || defined(_SCO_ELF) || \ (defined(__osf__) !defined(RTLD_NEXT)) || \ (defined(__OpenBSD__) !defined(RTLD_SELF)) || \ defined(__ANDROID__) */ # undef HAVE_DLINFO /* # endif */ Then the error disappears and openSSL build successfully. But is that ok? Maybe some strange side effect may happen?
Re: applying openssl patch
On 1/7/2014 5:50 AM, Sravanthi wrote: Hi, I'm using binary of the openssl for windows. I download the binary from the openssl site. How should I be applying the vulnerability patches on windows if I use binaries? Thanks, Sravanthi New binaries are available now. Might have to refresh the page/clear your cache. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Merkle signature scheme
On 1/6/2014 9:05 PM, Andrey Utkin wrote: Hi all. It seems subj is not present in OpenSSL as implementation or any helper functionality. Hmm, I believe you are right, as I am not aware of any support for limiting the number of invocation of a a private key, nor am I sure the OpenSSL code is structured in a way suitable to the unusually large key sizes needed. At the moment I have no deep understanding of both MSS and OpenSSL design, but I'd like to know qualified opinions: is there a possibility for adding MSS implementation to OpenSSL? If yes, I could work on implementation if i get some menthorship, or i could donate for it. For a 256 bit security level (512 bit hashes), each one-time Lamport private or public key will be 64 KB, and each Lamport signature 32KB. To allow 2**n signatures per Merkle public key, the private key needs to be 2**n * 64 KB (e.g. 64MB for 1024 signatures) and each Merkle signature will be 32 KB + (n-1) * 64 bytes (e.g. 32.6 KB for 1024 signatures). The Merkle public key, however is just a single 64 byte hash. While it saves space, using a PRNG to replace the private key by an RNG key that generates it is probably not a good idea if you worry about the level of attacker skill implied by the need for Merkle signatures. In practice, the infrastructure needed to handle Merkle signatures with a practical usage count is going to be very similar to that which is needed to implement one-time pads. Which means some kind of tape-like storage with gradual self-destruct as each private key is read and used. A modern 1TB backup tape could handle a private key with 8 million uses, if supplemented by 1 GB of disk storage for the public key hashes, however backup tape systems don't have the gradual destruction mechanism, since they are designed for backup survival, not destruction. 8 million uses corresponds to 8 million hits on a HTTPS server using Merkle signatures with EDH or ECDH key exchange. And we still need a usable quantum-resistant encryption and package mac scheme to make this worthwhile. (Plus a quantum resistant key exchange that doesn't require a private dark fiber between the parties). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL CA and signing certs with SANs
On 1/7/2014 12:17 AM, Biondo, Brandon A. wrote: I am using ‘ca’ not ‘x509’. It too ignores/discards extensions. Turning on copy_extensions solved the issue though, thanks. I have some follow-up questions: 1.If including SANs in CSRs is non-standard, what is the accepted way of passing all the metadata you want to an authority to construct your certificate? Many commercial CAs take all the certificate information out-of-band on a web form, the only thing those CAs use from the CSR is that it is signed with the requested public/private key pair and has the right subject. 2.Why does the config file say to be careful using copy_extensions? Why wouldn’t you want all your extensions to be part of your certificate? Isn’t the whole point of a CSR to package up all the data you want in your certificate? Because copy-extensions copies all the extensions in the CSR, so if you use it, you will need to carefully check every extension in every CSR you receive from users. Note that security-wise, you should not blindly trust a CSR from a less secure computer than the CA computer, even if you happen to be the person who generated that CSR (when you take off your user hat and put on your CA administrator hat, you need to check if the User's computer generated a different CSR than what you agreed to sign). When I generate certificates with SANs (which I usually do), I typically use one of two approaches: A) For the common case: The CA's openssl.cnf adds the usual SANs as extensions, taking the actual name parts from environment variables which my scripts set from my input before signing each cert. B) For the handful of more complex cases, I construct a custom section in openssl.cnf which adds those specific SANs, as well as any other unusual extensions. *From:*owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] *On Behalf Of *Dave Thompson *Sent:* Monday, January 06, 2014 5:38 PM *To:* openssl-users@openssl.org *Subject:* RE: OpenSSL CA and signing certs with SANs It is debatable whether putting SAN in the request is really ‘proper’; I don’t know of any ‘real’ (public) CA that accepts it that way. But for openssl: If you are using ‘ca’, set copy_extensions in the config file. See the man page. If you are using ‘x509 –req’, that ignores/discards extensions from the CSR. It can **add** extensions from a config file, but since you usually want SAN to be different for every subject cert that isn’t very convenient. Do you really mean ‘x509 –signkey’ to selfsign, or ‘req –x509’? The latter is IME much more common. *From:*owner-openssl-us...@openssl.org mailto:owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] *On Behalf Of *Biondo, Brandon A. *Sent:* Monday, January 06, 2014 16:16 *To:* openssl-users@openssl.org mailto:openssl-users@openssl.org *Subject:* OpenSSL CA and signing certs with SANs Hello, Forgive me if I breach etiquette. This is my first post to this list in quite a while. I am having trouble tracking down information regarding how you reconfigure an OpenSSL CA to handle SANs in requests. There is a wealth of information on how to configure OpenSSL to form a proper request, but in my searching I can only ever find people who use the x509 function to self-sign their certs. When you use an OpenSSL CA to sign this type of request, the certificate is made without issue but the SANS are stripped out of the final product. What am I missing here? Regards, Brandon Biondo Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL doesn't pass full cert chain
Hello Dave, I would like to simplify the issue as following. 1. Both client and server performs SSL Handshake using cert chain. 2. In our case server responds correctly with the entire chain of cert (Server is some proprietary system) 3. Client also expected to send the entire cert chain, which is already available as a single file in .pem mode (Client is Kannel) 4. What happens is, seems libssl pass only the first cert in the cert chain file and doesn't pass the rest. 5. Need a mechanism to configure libssl to pass the entire chain, How to implement this? Thanks in advance, Fahim From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Tuesday, January 07, 2014 4:08 AM To: openssl-users@openssl.org Subject: RE: OpenSSL doesn't pass full cert chain To be certain I'm clear, since your terminology is a bit unusual: you have a server application using openssl library (libssl), which has a cert that was issued by a CA using intermediate certs. The prover (server in nearly all cases, client in rare cases) per RFC MUST send the full chain except optionally the root i.e. entity cert and any intermediate/chain cert(s) in order. In some situations this isn't actually needed, if the child cert(s) specify where the parent(s) can be obtained using AuthorityInfoAcccess extension and the relier implements AIA (which libssl as relier does not), or if the relier has the lower cert(s) in its truststore (which libssl and some other SSL implementations can, but I know nothing about your client kannel). Assuming you want to go with the standard approach, a libssl prover (here your server) will send the full chain if you do either of two (or maybe three) things: - call SSL_CTX_use_certificate_chain_file INSTEAD OF use_certificate_file and provide a file containing first the entity=server cert and then the chain=intermediate cert(s), and optionally root, all in PEM - provide a truststore which contains the chain certs, and optionally root, unambiguosly (i.e. there are NOT two or more certs for the same CA name). There are two variants of this: - set up a private CA file and/or CA directory and call load_verify_locations - put them in your system's default store and call set_default_verify_paths Both of these also mean that the provided certs are considered trusted when verifying the peer, which for a server occurs only if client authentication aka client cert is requested and is provided by the client. This should rarely if ever be a problem because if you expect and assert the peer should trust these CAs when verifying you, then you ought to trust them also. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Fahim Sent: Saturday, January 04, 2014 12:36 To: openssl-users@openssl.org Subject: OpenSSL doesn't pass full cert chain Hello, We are looking for a potential tweak or customization of openSSL for an existing project, and I was wondering if I could get your input. Summary: we want to alter or configure openSSL so that it will pass the entire cert chain for authentication instead of just the first certificate. Passing just the first cert appears to be the default, which is not working for our application, but we cannot figure out how to change that particular setting so that the entire certificate chain is sent. Background: We are trying to perform SMPP over SSL connectivity using kannel on the client side and done configuration changes at the kannel side to make it perform as client and created the single cert file with the whole certificate chain (Signed certificate of the server, intermediate certs and the root cert) and the same currently deployed with kannel. But still clientside authentication fails because openssl which handles the SSL at the server passes the first certificate only (in our case it is signed certificate only) to the server side and does not process beyond that. In fact, openSSL must be configured to pass the entire chain (Intermediate certs and root cert), but it fails to do so. It turns out it is the by default behavior of the openSSL .We found at http://gagravarr.org/writing/openssl-certs/general.shtml that In almost all cases, OpenSSL will assume that there's only one certificate in a given file. As such, it will generally only use the first certificate that it finds, and will ignore all others. This is the behavior we are trying to figure out how to chain. Does anyone have any suggestions here? I would appreciate your feedback. Thanks in advance, Best Regards, Fahim
RE: OpenSSL doesn't pass full cert chain
That is much clearer, thank you. Looking quickly at www.kannel.org I don't see any clear statement that it uses libssl (and libcrypto) rather than e.g. GnuTLS or NSS, but I'll trust you've already confirmed that. It does describe using openssl commandline to generate key, CSR and possibly cert, and people who use commandline often use the library also and vice versa but it's not technically required. As an aside, the doc example does 1024-bit RSA key, which was good advice until about 2009; today you technically need more for a margin of safety, and most standards/authorities have gone to 2048 as the next convenient size. In particular if you try to get a cert from a public CA, as opposed to a homebrew or enterprise one, industry standards as of this month say it should reject 1024-bit. http://www.kannel.org/download/kannel-userguide-snapshot/userguide.html#AEN4 68 describes ssl-client-certkey-file as A . certificate and private key .. and The certificate . This wording certainly suggests the code is calling use_certificate_file (which accepts only the entity cert, not a chain) not use_certificate_chain_file, although only looking at the source is certain - have you done that, or can you? It is a bit inconsistent that it apparently expects client certkey in one file, but has separate files for server cert and key. Maybe those were written by different people and not coordinated. It also has ssl-trusted-ca-file . certificates . [will] trust as HTTPS client. That description does not exactly match openssl functionality for CAfile, at least through 1.0.1; libssl will use all certs in CAfile to build a chain, but will trust (as anchors) only the root certs. Are you using that parameter and if so do you have the root for the server's chain in it? Assuming the above, your options are: - change the code to call use_certificate_chain_file either for that config item, or perhaps some other config item or flag if you prefer - or perhaps the project maintainers, if you can ask them (I didn't even look, I wouldn't have time). - add the chain certs for your client cert to your trusted-ca file. Even though CAfile's primary purpose is to verify the peer, here the server, libssl also uses it to build out its own chain if necessary and possible. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Fahim Sent: Tuesday, January 07, 2014 14:15 To: openssl-users@openssl.org Subject: RE: OpenSSL doesn't pass full cert chain Hello Dave, I would like to simplify the issue as following. 1. Both client and server performs SSL Handshake using cert chain. 2. In our case server responds correctly with the entire chain of cert (Server is some proprietary system) 3. Client also expected to send the entire cert chain, which is already available as a single file in .pem mode (Client is Kannel) 4. What happens is, seems libssl pass only the first cert in the cert chain file and doesn't pass the rest. 5. Need a mechanism to configure libssl to pass the entire chain, How to implement this? Thanks in advance, Fahim From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Tuesday, January 07, 2014 4:08 AM To: openssl-users@openssl.org Subject: RE: OpenSSL doesn't pass full cert chain To be certain I'm clear, since your terminology is a bit unusual: you have a server application using openssl library (libssl), which has a cert that was issued by a CA using intermediate certs. The prover (server in nearly all cases, client in rare cases) per RFC MUST send the full chain except optionally the root i.e. entity cert and any intermediate/chain cert(s) in order. In some situations this isn't actually needed, if the child cert(s) specify where the parent(s) can be obtained using AuthorityInfoAcccess extension and the relier implements AIA (which libssl as relier does not), or if the relier has the lower cert(s) in its truststore (which libssl and some other SSL implementations can, but I know nothing about your client kannel). Assuming you want to go with the standard approach, a libssl prover (here your server) will send the full chain if you do either of two (or maybe three) things: - call SSL_CTX_use_certificate_chain_file INSTEAD OF use_certificate_file and provide a file containing first the entity=server cert and then the chain=intermediate cert(s), and optionally root, all in PEM - provide a truststore which contains the chain certs, and optionally root, unambiguosly (i.e. there are NOT two or more certs for the same CA name). There are two variants of this: - set up a private CA file and/or CA directory and call load_verify_locations - put them in your system's default store and call set_default_verify_paths Both of these also mean that the provided certs are considered trusted when
