Ciphers: disabling
Tried to turn off one cipher via: #!/bin/bash make clean ./config -no-CAMELLIA-128-CBC make depend make But still cannot turn it off (as i see output of openssl list-cipher-algorithms or even ./apps/openssl list-cipher-algorithms for new compiled client). I don't see way to really turn off ciphers. Hoew to turn them off -- kind regards, Serhiy Ivanov __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Ciphers: disabling
On Wed, Jan 9, 2013 at 7:02 AM, Serhiy Ivanov serhiy.i.iva...@globallogic.com wrote: Tried to turn off one cipher via: #!/bin/bash make clean ./config -no-CAMELLIA-128-CBC make depend make Try make dclean Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Cert in DNS (DANE, DNSSEC) and OpenSSL
(reposting this on users list) Hi, When can we expect an OpenSSL release, that will support DANE protocol to verify SSL/TLS certificates (which are added/kept in the DNS RR) using DNSSEC protocols ? Thanks, -- Bright Star (Bry8 Star / Bry8Star). signature.asc Description: OpenPGP digital signature
Re: openssl RPM package
I am (still) looking for an OpenSSL 1.0.1c rpm or srpm / src.rpm for CentOS 6.3 (32bit). If same version with fips module were downloadable, that would have been great as well. From Walter H., received on 2013-01-08 8:47 PM: Hello, is there an openssl RPM package with version 0.9.8 or better for CentOS 4.x? (upgrade to CentOS 5.x or 6.x is impossible) Thanks, Walter signature.asc Description: OpenPGP digital signature
Re: Cert in DNS (DANE, DNSSEC) and OpenSSL
On 1/9/2013 2:46 PM, Bry8 Star wrote: (reposting this on users list) Hi, When can we expect an OpenSSL release, that will support DANE protocol to verify SSL/TLS certificates (which are added/kept in the DNS RR) using DNSSEC protocols ? Is there an RFC for DANE, or is it still an experimental or project- specific protocol. Since OpenSSL is mostly a library, the normal/expected way would be for OpenSSL to pass back to the OpenSSL-using application with a certificate that needs locating/verification by external means. This application callback can then implement any needed mechanisms, such as ldap lookups over SSL, http(s) downloads, lookup in a database or querying using a DNSSEC supporting DNS resolver library or simply prompting the user to accept a certificate. Each of those mechanisms can of cause itself use OpenSSL for its cryptographic security. Others on this list may be able to point you to precisely which existing OpenSSL mechanisms can do the trick. 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: References to NSS libraries
On 1/8/2013 7:59 PM, Jeffrey Walton wrote: On Tue, Jan 8, 2013 at 1:14 PM, Carson Gaspar car...@taltos.org wrote: On 1/8/13 9:52 AM, Jeffrey Walton wrote: That seems like a really odd requirement. Is there any reading on the topic? man nsswitch.conf Generally, I prefer static linking in high integrity software. And I oppose plug-in like functionality. For completeness, I was talking about high integrity software in both cases. I don't consider a $50 Amazon transaction worthy of high integrity software since the value of the data is low (or perhaps approaches medium). Then you need to not run on Linux or Solaris, or roll your own name service lookup code (or use an alternate libc). I believe some of the *BSDs share your opinion. Are those the only two options? Forgive my ignorance - I've never studied the problem. Name Service Switch is what underlies all the getfoobybar and getfooent calls. They indirect vi the nss library, which reads /etc/nsswitch.conf, and then dispatches the lookup to the configured backend(s) (files, NIS, LDAP, DNS, ...) So I'm clear, NSS library is Name Service Switch, and not the Mozilla security library of the same name. I really don't want Mozilla code polluting my code if it can avoided. Before the Mozilla folks get their panties in a wad: Trustwave, and the non-public negotiations that occurred between Trustwave and Mozilla before the blog. What is the motivation for Mozilla's penchant to performing fellacio on the CA industry? As a google whore, it makes money hand over fist and does not need the CA industry. That sort of crap does not serve the end users well (and that's all I care about). Dynamic linking is here to stay - embrace your shared object overlords ;-) OT: Do you think the tools will ever catch up? Autoconf and friends (including Make) never evolved with the addition of shared objects. So there's no way to specify a consistent set of LDFLAGS tuned both compiled programs and shared objects (which is common with library code that supplies utility programs and test programs to exercise the library). For example, a shared object needs -fPIC and -shared; while a compiled program needs -fPIE and -pie. So how do we pidgin hole this common idiom: ./configure CFLAGS=-Wall -Wextra \ -Wconversion -Wstrict-overflow \ other options ASLR where ASLR is either -fPIC and -shared; or -fPIE and -pie. I think we need two LDFLAGS like variables, or use LDFLAGS as a base and ability to specify addition personalities for shared objects and compiled programs. And don't get me started on Debug vs Release builds, Autoconf's lack of support, and Make's ignorance to changing flags (-g3 -ggdb -O0 vs -g -O2). Its too bad we are stuck with using tools form the 1970s while the platform and art has evolved. Please don't blame make for the failures of other programs (such as the autoconf abomination or the cc library linking flags). The two big failures are: - Autoconf fundamentally assumes that you will compile the source on every machine that runs it, that there is no cross compiling and that any arbitrary aspect of the build machine (such as CPU model, kernel version or installed software) will be equally true at runtime. Much effort has since been wasted trying to add back cross-machine and cross-platform abilities. - The cc/gcc library linking flags on POSIX-like systems don't facilitate explicitly specifying which libraries should be linked statically and which ones dynamically, whichever comes first on the search path wins. - The linker semantics for shared libraries on POSIX-like platforms take the list of names exported from a shared object on the build machine as the definition of which names should be exported from any compatible shared object, which again makes it harder to build for use on other machines. To further complicate matters, most systems generate executable binaries that are susceptible to accidentally calling a similarly named function in a completely different shared object which happens to be around at run time. As for the last two points, it is worth noting that the DOS family of later operating systems (OS/2, Windows) operates differently: For each shared object there is a static-like import library specifying which names to import from which shared object, and this is passed to the linker like a regular static library, such that if you have both a static and shared version of a library available, their link-time libraries will have different names, such as libc-static.a versus libc-dynamic.a (an import library). On these platforms, the typical build tools do not include an Autoconf like mechanism, since it is always assumed you are compiling for other machines, which may have less (or more) software than the build machine. 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
Re: References to NSS libraries
On Wed, Jan 9, 2013 at 10:42 AM, Jakob Bohm jb-open...@wisemo.com wrote: On 1/8/2013 7:59 PM, Jeffrey Walton wrote: On Tue, Jan 8, 2013 at 1:14 PM, Carson Gaspar car...@taltos.org wrote: On 1/8/13 9:52 AM, Jeffrey Walton wrote: ... OT: Do you think the tools will ever catch up? Autoconf and friends (including Make) never evolved with the addition of shared objects. So there's no way to specify a consistent set of LDFLAGS tuned both compiled programs and shared objects (which is common with library code that supplies utility programs and test programs to exercise the library). For example, a shared object needs -fPIC and -shared; while a compiled program needs -fPIE and -pie. So how do we pidgin hole this common idiom: ./configure CFLAGS=-Wall -Wextra \ -Wconversion -Wstrict-overflow \ other options ASLR where ASLR is either -fPIC and -shared; or -fPIE and -pie. I think we need two LDFLAGS like variables, or use LDFLAGS as a base and ability to specify addition personalities for shared objects and compiled programs. And don't get me started on Debug vs Release builds, Autoconf's lack of support, and Make's ignorance to changing flags (-g3 -ggdb -O0 vs -g -O2). Its too bad we are stuck with using tools form the 1970s while the platform and art has evolved. Please don't blame make for the failures of other programs (such as the autoconf abomination or the cc library linking flags). The two big failures are: - Autoconf fundamentally assumes that you will compile the source on every machine that runs it, that there is no cross compiling and that any arbitrary aspect of the build machine (such as CPU model, kernel version or installed software) will be equally true at runtime. Much effort has since been wasted trying to add back cross-machine and cross-platform abilities. Its even worse. From a recent conversation with Carson (off list): ] Autoconf is broken: ] https://lists.gnu.org/archive/html/automake/2012-12/msg00018.html. In ] response to my question on supporting Debug, Release, and Test ] configurations: I haven't hit that kind of projects to be honest — I ] would say they don't fare well into the usual automake configs, ] https://lists.gnu.org/archive/html/automake/2012-12/msg00019.html. ] ] All the tools in this toolchain are a mess, and have not evolved. Its ] crippling to folks like me. - The cc/gcc library linking flags on POSIX-like systems don't facilitate explicitly specifying which libraries should be linked statically and which ones dynamically, whichever comes first on the search path wins. - The linker semantics for shared libraries on POSIX-like platforms take the list of names exported from a shared object on the build machine as the definition of which names should be exported from any compatible shared object, which again makes it harder to build for use on other machines. To further complicate matters, most systems generate executable binaries that are susceptible to accidentally calling a similarly named function in a completely different shared object which happens to be around at run time. I really believe Make is the root of the problem. It did not evolve, so the other tools, such as Autoconf and Automake, did not have to evolve. I've tried finding work arounds from all the tools in the tool chain form Autoconf to GCC. All they do is finger pointing (that's better suited to be addressed at X), which does not help me with my task. ] Its too bad we are stuck with using tools form the 1970s ] while the platform and art has evolved. This sums it up for me :) Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl RPM package
On 01/09/2013 02:55 PM, Bry8 Star wrote: I am (still) looking for an OpenSSL 1.0.1c rpm or srpm / src.rpm for CentOS 6.3 (32bit). The Fedora 18 SRPM builds fine on RHEL 6.3, at least. I haven't checked the result. Replacing such a central system component is always a bit tricky. -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl RPM package
THANKS. At first (or initially) i want to install the v1.0.1c as a second (2nd) openssl in the system, so it does not replace the existing openssl and start to create conflicts/fails with other base/core components. And initially want to (at least) start creating/managing cert with it manually, and specify the 2nd openssl in apps which can use the 2nd one. I have seen one article, explaining how to completely replace/upgrade the older openssl on CentOS 6.2 or centos 6.3, to the last stable one, but i was bit afraid to follow it. If anyone more familiar in these area, can point to such an article, (to completely replace the older one with a newer one, then) that would be very helpful. -- Bright Star. From Florian Weimer, received on 2013-01-09 5:02 PM: On 01/09/2013 02:55 PM, Bry8 Star wrote: I am (still) looking for an OpenSSL 1.0.1c rpm or srpm / src.rpm for CentOS 6.3 (32bit). The Fedora 18 SRPM builds fine on RHEL 6.3, at least. I haven't checked the result. Replacing such a central system component is always a bit tricky. signature.asc Description: OpenPGP digital signature
RE: Ciphers: disabling
From: Serhiy Ivanov [mailto:serhiy.i.iva...@globallogic.com] Sent: Wednesday, January 09, 2013 12:03 PM Tried to turn off one cipher via: #!/bin/bash make clean ./config -no-CAMELLIA-128-CBC make depend make But still cannot turn it off (as i see output of openssl list-cipher-algorithms or even ./apps/openssl list-cipher-algorithms for new compiled client). I don't see way to really turn off ciphers. Hoew to turn them off Follow the style specified in the INSTALL file - -no-camellia should disable all Camellia ciphers. I'm not aware of any easy way to disable individual cipher suites at library build time. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Compile 0.9.8x for 64bit is missing _SHA* symbols
Hi all, I've compiled openssl 0.9.8x on windows 7 using VS2010 pro using the following steps: perl Configure VC-WIN64A --prefix=%LIB_OUT% CALL ms\do_win64a nmake -f ms\ntdll.mak nmake -f ms\ntdll.mak test nmake -f ms\ntdll.mak install Unfortunately the resulting libraries do not have any of the following symbols: _SHA512_Init _SHA512_Update _SHA512_Final _SHA256_Init _SHA256_Update _SHA256_Final _SHA1_Init _SHA1_Update _SHA1_Final On the other hand, the 32bit compilation works fine. Any suggestions on what I might be doing wrong. Please any help would greatly appreciated. -- -- Ribhi
Fwd: How to remove certificate from X509_STORE?
Hi, X509_STORE_add_cert() would add a certificate to the list of trusted certificates in the ctx. What is the way to remove a certificate from this trusted store? Am not finding any function to remove the certificate. Can anyone of you suggest a way to remove the certificate from this trusted store? Or is there a way to make a already loaded certificate an untrusted one? Thank-you, Sri
Cut openssl
As i see from demos (even such supposed to be tiny one as easy-tls or bio/sconect) all files created are too big (my requirement are =100kb for binary and =300kb more for all memory includding heap). Is it possible to cut opensll in next ways: 1) use onle a few cypher algorithms and do not even compile others 2) more transparent bio object Are these options configurable (i see -no-ciphers as multioption to config, but i don't see smth like no-message-digests) or i should recompile rather msnually? -- kind regards, Serhiy Ivanov| __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
EVP_aes_256_gcm - Retrieving the MAC value
Hi,
This is an API question on using OpenSSL and AES GCM. I am successfully able to
perform encryption / decryption and I am also able to detect errors in the mac
value. The code I am using for this is below. I want to retrieve the mac value
to my own buffer, in addition to just doing the internal comparison. I tried
this by providing a local buffer in the function call 'DecryptFinal(..)', but
nothing is written to the buffer. What am I doing wrong?
- Roar
int decryptAes256Gcm(byte_t* pIv, int ivLen,
byte_t* pKey, int keyLen,
byte_t* pAAD, int AADLen,
byte_t* pCipherText, int cipherTextLen,
byte_t* pClearText,
byte_t* pMAC, int MACLen)
{
int iResult = 0;
EVP_CIPHER_CTX ctx;
int bytesProcessed;
EVP_CIPHER_CTX_init(ctx);
EVP_DecryptInit_ex(ctx, EVP_aes_256_gcm(), NULL, pKey, pIv);
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_TAG, MACLen, pMAC);
EVP_DecryptUpdate(ctx, NULL, bytesProcessed, pAAD, AADLen);
EVP_DecryptUpdate(ctx, pClearText, bytesProcessed, pCipherText,
cipherTextLen);
if(NULL != pMAC)
{
byte_t localTag[GCM_BLOCK_SIZE];
int localTagLen = GCM_BLOCK_SIZE;
if(1 != EVP_DecryptFinal_ex(ctx, localTag, bytesProcessed))
{
goto CleanUp;
}
}
else
{
if(!EVP_DecryptFinal_ex(ctx, NULL, bytesProcessed))
{
goto CleanUp;
}
}
iResult = 1;
CleanUp:
EVP_CIPHER_CTX_cleanup(ctx);
return iResult;
}
