Re: Unknown message digest algorithm sha256RSA OpenSSL 1.0.1e
On 27-02-2013 23:54, John Unsworth wrote: I have a Windows CA that has created a sha256RSA CA cert and server cert. However OpenSSL fails to validate them. C:\MetaAndDirectory\certsopenssl verify -verbose -CAfile win2k8r2-ca.cer win2k8r2-server.cer win2k8r2-server.cer: /DC=net/DC=cp/DC=macc/CN=macc-JOHN-WIN2K8R2-1-CA error 7 at 1 depth lookup:certificate signature failure 7892:error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm:.\crypto\asn1\a_verify.c:141: C:\MetaAndDirectory\certsopenssl ciphers DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DS S-DE S-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:A ES12 8-SHA:IDEA-CBC-SHA:IDEA-CBC-MD5:RC2-CBC-MD5:DHE-DSS-RC4-SHA:RC4-SHA:RC4-MD5: RC4- MD5:RC4-64-MD5:EXP1024-DHE-DSS-DES-CBC-SHA:EXP1024-DES-CBC-SHA:EXP1024-RC2-C BC-M D5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:DES-CBC-MD5:EXP1024-D HE-D SS-RC4-SHA:EXP1024-RC4-SHA:EXP1024-RC4-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-D SS-D ES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC2-CBC-MD5:EXP-RC4-MD5:EXP-R C4-M D5 Try the command openssl version I suspect you may not be running the OpenSSL version you think! (Note that the openssl ciphers command lists SSL/TLS protocol cipher suites, not the individual ciphers in other parts of OpenSSL, however the output above looks like it is from an older version). -- Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10 call:+4531131610 This message is only for its intended recipient, delete if misaddressed. 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: Can I build the FIPS module with /MT?
On 18-01-2013 20:26, Jeffrey Walton wrote: On Fri, Jan 18, 2013 at 11:01 AM, Memmott, Lester lester.memm...@landesk.com wrote: All modern Versions of Microsoft's C Runtime are thread safe. That occurred around Visual Studio 6.0 (circa 2000 or so). From http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx: The single-threaded CRT (libc.lib, libcd.lib) (formerly the /ML or /MLd options) is no longer available. Instead, use the multithreaded CRT. Thanks for the quick response. My proposal isn't to use the single threaded C runtime, but instead to use the statically linked (multithreaded) C runtime instead of the dynamically linked (multithreaded) runtime. My bad. I read that wrong (I think I crossed wires on /MT and /ML). Your installer should unconditionally install vcredist_*.exe before installing the program proper. I say 'unconditionally' because some installers don't offer a way to check for the CRT version. Since vcredist_x86.exe is a Microsoft executable, the Microsoft installer will exit if its not needed; and the binary should not have any negative platform side effects. ... This is so obviously a non-solution, you should have thought about this before making the rookie mistake of FIPS-certifying the MSVCRTxx.DLL needing build option. As every seriously experienced Visual C++ developer knows, Microsoft has a terrible track record when it comes to making their DLL C runtimes useful for reliable or secure software (I will not bother to enumerate their epic fails here, they are actually documented in various individual Microsoft documents that each try to talk down the problems). In practice for library designs (such as future releases of the OpenSSL FIPS module), the realistic design options are: A. Require any memory, FILE* objects and POSIX-like int file handles allocated by library functions to be freed by other library functions and also require that the FILE* objects and int file handles are used exclusively through the library. And the converse for any such things allocated outside the library. Then the library can use a private statically linked C runtime even if the calling application does not. Many aspects of OpenSSL already do this, but there may be a few unsafe functions laying around, maybe in the BIO_ family. B. Create the one-compilation-only part (the FIPS module in this case) not to call the stateful parts of the C runtime (especially malloc/free etc.) directly but leave that to the recompilable part (the FIPS-compatible OpenSSL library in this case). This way a single code blob becomes independent of such factors and also becomes reusable across compiler versions, and even operating systems (imagine an x86_64 module that is compiled once by a known good compiler, FIPS certified for different CPU capabilities and then reused on all the many OSes for that architecture with Apple's legal requirements as a possible exception). This also creates a clearer specification of the module boundary, as this no longer includes an unknown C runtime library, just a specific environment condition on helper functions supplied by the FIPS-compatible OpenSSL library. Its also a recommended solution with, for example, Inno Installer when the setup program carries around both an x86 and x64 copy of the program to install. I can't give you a reference since it appears http://news.jrsoftware.org/read/thread.php?group=jrsoftware.innosetup is not indexed. But I asked a similar question a few years ago. This won't work for code running outside the protective bubble of a completely installed multi-megabyte application. Anything running during install/uninstall/upgrade or downloaded as a small piece of mobile code will not be able to satisfy this, by definition. That sidesteps the FIPS requirements, and the nasty interactions between mixing/matching static and dynamic libraries with /NODEFAULTLIB. The nasty side effects have been deliberately exaggerated by the documentation writers, the realities are much more manageable as explained above. -- Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10 This message is only for its intended recipient, delete if misaddressed. 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: Conditionally Patching output of Makefile from Configure?
On 30-12-2012 21:01, Jeffrey Walton wrote: Hi All, While working on Apple with Mac OS X and iOS, I found I needed to patch OpenSSL 1.0.1c's Makefile. Makefile.org has the following line, and it was copied directly into Makefile by Configure: MAKEDEPPROG=makedepend When the Configure target is iphoneos (cross), iphonesimulator (cross), or macosx (native), I need a different statement: MAKEDEPPROG=$(CC) -M I've looked at Configure, but I have no clue on the best way to handle the support/additions needed. Can anyone offer some advice? Jeff I have found the script build.sh from https://github.com/st3fan/ios-openssl to work nicely for iOS builds of 1.0.1c with no patching of openssl. (Admitted, I did adapt the script for our environment) -- Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10 call:+4531131610 This message is only for its intended recipient, delete if misaddressed. 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: Conditionally Patching output of Makefile from Configure?
On 30-12-2012 21:34, Jeffrey Walton wrote:
On Sun, Dec 30, 2012 at 3:20 PM, jb-open...@wisemo.com wrote:
On 30-12-2012 21:01, Jeffrey Walton wrote:
Hi All,
While working on Apple with Mac OS X and iOS, I found I needed to
patch OpenSSL 1.0.1c's Makefile.
Makefile.org has the following line, and it was copied directly into
Makefile by Configure:
MAKEDEPPROG=makedepend
When the Configure target is iphoneos (cross), iphonesimulator
(cross), or macosx (native), I need a different statement:
MAKEDEPPROG=$(CC) -M
I've looked at Configure, but I have no clue on the best way to handle
the support/additions needed.
Can anyone offer some advice?
I have found the script build.sh from
https://github.com/st3fan/ios-openssl
to work nicely for iOS builds of 1.0.1c with no patching of openssl.
(Admitted, I did adapt the script for our environment)
Thanks Jakob.
If you run the script with an -no-xxx option, how does it perform?
For example, try -no-dtls. A quick drive by did not reveal MAKEDEPEND
modification.
Sorry, didn't try that. I don't have the OS/X machine handy, so I can't
test it right now.
What I found (using the same tool chain): -no-xxx requires a `make
depend`. 'make depend` fails on my 10.7 and 10.8 test machines because
Apple removed `makedepend` at 10.7.2 or 10.7.3. So I need to cut over
to `$(CC) -M`.
Isn't there a third party makedepend you could use, or a simple two line
script like:
#!/bin/bash
${CC} -M $@
--
Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10
call:+4531131610
This message is only for its intended recipient, delete if misaddressed.
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: Conditionally Patching output of Makefile from Configure?
On 31-12-2012 00:14, jb-open...@wisemo.com wrote:
On 30-12-2012 21:34, Jeffrey Walton wrote:
On Sun, Dec 30, 2012 at 3:20 PM, jb-open...@wisemo.com wrote:
On 30-12-2012 21:01, Jeffrey Walton wrote:
Hi All,
While working on Apple with Mac OS X and iOS, I found I needed to
patch OpenSSL 1.0.1c's Makefile.
Makefile.org has the following line, and it was copied directly into
Makefile by Configure:
MAKEDEPPROG=makedepend
When the Configure target is iphoneos (cross), iphonesimulator
(cross), or macosx (native), I need a different statement:
MAKEDEPPROG=$(CC) -M
I've looked at Configure, but I have no clue on the best way to handle
the support/additions needed.
Can anyone offer some advice?
I have found the script build.sh from
https://github.com/st3fan/ios-openssl
to work nicely for iOS builds of 1.0.1c with no patching of openssl.
(Admitted, I did adapt the script for our environment)
Thanks Jakob.
If you run the script with an -no-xxx option, how does it perform?
For example, try -no-dtls. A quick drive by did not reveal MAKEDEPEND
modification.
Sorry, didn't try that. I don't have the OS/X machine handy, so I
can't test it right now.
What I found (using the same tool chain): -no-xxx requires a `make
depend`. 'make depend` fails on my 10.7 and 10.8 test machines because
Apple removed `makedepend` at 10.7.2 or 10.7.3. So I need to cut over
to `$(CC) -M`.
Isn't there a third party makedepend you could use, or a simple two
line script like:
#!/bin/bash
${CC} -M $@
At second thought, I seem to recall that the old gcc-based apple
toolchain had severe anomalies in the handling of the -M family
of options, and I am unsure how the new clang/llvm tools do. I
also seem to recall that you may need to use their old gcc-based
toolchain when targeting the older armv6 based devices.
So it is probably safer to just do whichever of the following3
works best:
ln -s /bin/true /usr/local/bin/makedepend
ln -s /bin/echo /usr/local/bin/makedepend
ln -s /usr/local/bin/fakedepend /usr/local/bin/makedepend
(where /usr/local/bin/fakedepend would be a small script to output
semantically empty dependency lines for each of its args).
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: Need input for Certificate generation
On 16-11-2012 19:57, Jeffrey Walton wrote:
Hi Jacob,
On Fri, Nov 16, 2012 at 1:22 PM, Jakob Bohm jb-open...@wisemo.com wrote:
On 11/16/2012 3:36 AM, Jeffrey Walton wrote:
...
Headless servers, entropy starvation, and rollbacks are a concern in
modern environments. OpenSSL and other entropy gathers, such as EDG,
don't account for the later. Its best to take the bull by the horns
and do it yourself. At minimum, you need to call RAND_add() with
entropy external to /dev/{u}rand.
Would you care to elaborate on the following points:
1. What do you mean by rollback
Virtual Machine rollback attacks.
And how would an attacker rollback the victims VM?, an attacker with that
level of control is already presumably able to access the VMs data,
storage and execution state directly.
2. What RNG/PRNG are you referring to as EDG
EDG is Entropy Gatering Daemon. I was talking to John Steven about it
over the summer (John is CTO of Cigital, OWASP member, and part of the
project). EDG does not take measure to mitigate rollback attacks.
Ah, I thought that was called EGD
3. What exactly makes /dev/{u,}random in current (not ancient) Linux
kernelsinsecure given an appropriate supply of entropy?
Note that the two papers you site on the Linux kernel PRNG are:
I. A 6 year old document, presumably not applicable to the code in
currentkernel versions.
I don't believe this is correct. For example, the Linux generator
still lacks forward secrecy.
Do you mean lack forward secrecy as in past random bits can be predicted
from later random bits (very bad) or lack forward secrecy as in internal
PRNG state may reveal bits output in the recent past (less of a concern for
most real attacks).
II. A document about the consequences of using any PRNG without
sufficient entropy input, with the Linux kernel PRNG as a common
example. This would presumably be irrelevant if feeding the kernel
plenty of external entropy e.g. by getting it from a hardware RNG
hooked up to a trusted server (under your own control of course).
The trusted server is a problem. First some background.
The Linux kernel folks *disabled* feeding data into the generator
based on interrupts because the attacker may control it. For example,
the arrival of a network packet. There's a real problem of starvation,
especially in headless servers and mobile devices. The problem was
highlighted (again) in a recent paper: Mining Your Ps and Qs:
Detection of Widespread Weak Keys in Network Devices,
https://factorable.net/paper.html. See Section 5 where the analysis
occurs and 5.1, Weak entropy and the Linux RNG.
What I said, the consequences of entropy starvation and ignoring the
starvation.
If I go to https://www.wisemo.com, I initiated that connection so its
not under control of an attacker). The exchange contains some random
(but public) data - namely, Wisemo's public key. A passive attacker on
the public internet may be able to observe the exchange. So we can
improve entropy in the generator at the cost of leaking information
about state input.
And what if (hypothetically speaking) I had doctored that public key
to negatively affect the entropy of some well known PRNG when used
with some well known hedging software (I haven't, but you have to
take my word for it).
If the server is within my logical security boundary (for example, my
LAN/MAN segment), the attacker probably cannot observe the exchange.
In this case, I can improve entropy in the generator without the side
effect of leaking information about state input.
Of cause, I recommend having it within the data center, as the amount
of entropy requested by a server is likely to be a valuable side
channel.
Later, when the
machine goes out on the internet, its quality of random numbers will
be improved.
Only if your PRNG is secure against a partially known/chosen entropy
attack, not all are. For instance the PRNG entropy management code
might batch up enough raw entropy for a full PRNG state and then
discard the past state to improve long term forward secrecy, this
would be a great strategy with trusted secret entropy sources, but
fatal if fed large amounts of attacker-known/chosen entropy, as it
would make the state completely known.
You should join us over at the cryptography mailing list
(http://lists.randombit.net/mailman/listinfo/cryptography).
e.g. by getting it from a hardware RNG
I personally use an Entropy Key when I need to ensure I have
sufficient bits to generate a long term key
(http://www.entropykey.co.uk). I carry it with me in my laptop bag.
I personally try not to let the world know precisely what brand and
version of countermeasures I use, just in case of a 0-day.
I know of a number of medium and large size enterprises that don't use
hardware, and rely on the software generator provided by the OS. Those
enterprises include financial institutions in New York.
This is a true story. I'm a security architect, and this got pushed to
the team for risk acceptance. One financial
Re: ECDH-RSA and TLS 1.2
On 02-11-2012 21:46, Jeffrey Walton wrote: On Fri, Nov 2, 2012 at 4:30 PM, Jakob Bohm jb-open...@wisemo.com wrote: (continuing TOFU posting to keep the thread somewhat consistent) Given some of the mathematical restrictions on parameters needed to keep DSA and ECDSA safe from attackers, I don't think using the same private key for ECDSA and ECDH is a good/safe idea. However I am not a genius cryptanalyst, so I cannot guarantee that this is really dangerous, it is just a somewhat educated guess. Not at all - its good advice. Its called Key Separation, and its covered in the Handbook of Applied Cryptography (HAC), Chapter 13. I usually see folks trying to use the same key for signing and encryption. This is a slight twist in that they want to do signing and agreement. The HAC is available for free online at http://cacr.uwaterloo.ca/hac/. I am aware of the general principle, but that is not my point at all. My point is that the very specific math of DSA signatures may enable specific attacks if the same key pair is used as a static DH key. Information on this possibility (or its absence) is obscured by replies like yours (and by similar general statements in official Government materials from NIST etc.). DSA/ECDSA is an algorithm which (like DES) is engineered on the edge, such that almost any modification is unlikely to improve security, and in fact likely to undermine it. And unlike PKCS#1 RSA operations, there is very little in the design which limits the ability of an attacker to use one operation (DH exchange) to help break another (DSA signature) or the other way round. On 11/2/2012 9:06 PM, Abhiram Shandilya wrote: I thought the keys in ECC certificates can be used for both ECDH key agreement and ECDSA digital signature. -Original Message- From: Erik Tkal Sent: Friday, November 02, 2012 8:24 AM To: openssl-users@openssl.org Subject: RE: ECDH-RSA and TLS 1.2 What if the server has an ECDH certificate? Would that then be the appropriate set of suites? -Original Message- From: Dr. Stephen Henson Sent: Thursday, November 01, 2012 10:38 PM To: openssl-users@openssl.org Subject: Re: ECDH-RSA and TLS 1.2 On Fri, Nov 02, 2012, Abhiram Shandilya wrote: Hi Steve, Thanks for your response. I'm just trying to figure out what it takes to get this working - are you of the opinion that an SSL server should not support TLS 1.2 ECDH-RSA cipher suites? Could you also mention why? Well one reason is that the fixed ECDH cipher suites do not support forward secrecy because they always use the same ECDH key. -- Jakob Bohm, CIO, partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. direct: +45 31 13 16 10 call:+4531131610 This message is only for its intended recipient, delete if misaddressed. 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 support of Intel AES instruction set.
On 24-09-2012 22:34, Alex Chen wrote: I remember seeing somewhere that OpenSSL supports Intel AES instruction set. If so, which release is that and what flag is needed to enable it. Does the 'no-asm' flag in 'Configure' disable the use of these instructions? Please start a new thread for your new question, you have posted your question deep inside a thread on a completely unrelated topic. I don't know the Apple mail user interface, but the rule for all mailing lists is to never start a new topic with the Reply button or menu command. Always use the New mail command and then fill in the address (openssl-users@openssl.org) manually or from your contacts. 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 bug database?
On 18-08-2012 17:06, Jeffrey Walton wrote: On Fri, Aug 17, 2012 at 5:19 PM, Cassie Helms cassie.he...@hp.com wrote: Actually, my real question was, where can I see a list of bugs that are already reported for openssl, so I can anticipate certain openssl functions failing? I wish I could contribute more to the source by reporting bugs, but I have so many of my own already...and would like to be able to see where they are going to happen next, if that's possible. http://lmgtfy.com/?q=openssl+bug+report That was a very unhelpful answer. I suppose you would have pointed Ms/Mrs Helms to http://rt.openssl.org/NoAuth/Buglist.html Unfortunately however, the tags or other ticket properties that control the output on that page seem to be woefully unmaintained, with bugs still listed as pending for old OpenSSL versions and no bugs listed as related to the current version. So it seems like the project doesn't have a usable list of open bugs right now. 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: How tell OpenSSL to prompt?
On 19-08-2012 15:05, CharlesTSR wrote: On Sat, Aug 18, 2012, Charles Mills wrote: snip There is no prompt option but you can use the $ENV syntax to expand an environment variable and use that on the command line. Thanks. I apologize -- I freely admit I have not RTFM. Where IS the top level documentation for the configuration file? Where is the starting point? http://www.openssl.org/docs/apps/config.html I am missing some step here. I am running on Windows 7. I say set VAR_DNS_1 = foo.com set VAR_DNS_2 = bar.com Then in the configuration file I say [ alt_names ] DNS.1 = $ENV::VAR_DNS_1 # line 224 of the configuration file DNS.2 = $ENV::VAR_DNS_2 OpenSSL gives me the error 5288:error:0E065068:configuration file routines:STR_COPY:variable has no value:.\crypto\conf\conf_def.c:618:line 224 What else do I need to do? Thanks much, and apologies for the dumb questions. Did you run openssl.exe from the same command prompt where you typed the SET commands? 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: FIPS Mode
Use the 3rd option suggested by McAfee, it is better than their first two options. The 3rd option is to configure the ciphersuite used by the server to not include any Diffie-Hellman key exchanges until your choice of distribution includes OpenSSL 1.0.1 with the new FIPS module. On 08-07-2012 20:58, Mike Hoy wrote: We received the following from McAfee PCI Compliance service: Description The remote SSL/TLS server accepts a weak Diffie-Hellman (DH) public key value. This flaw may aid an attacker in conducting a man-in-the-middle (MiTM) attack against the remote server since it could enable a forced calculation of a fully predictable Diffie-Hellman secret. By itself, this flaw is not sufficient to set up a MiTM attack (hence a risk factor of 'none'), as it would require some SSL implementation flaws to affect one of the clients connecting to the remote host. General Solution OpenSSL is affected when compiled in FIPS mode. To resolve this issue, either upgrade to OpenSSL 1.0.0, disable FIPS mode or configure the ciphersuite used by the server to not include any Diffie-Hellman key exchanges. PolarSSL is affected. To resolve this issue, upgrade to version 0.99-pre3 / 0.14.2 or higher. If using any other SSL implementation, configure the ciphersuite used by the server to not include any Diffie-Hellman key exchanges or contact your vendor for a patch. We want to know how to disable FIPS mode. We cannot upgrade OpenSSL without compiling it and we would rather use yum to upgrade our software on our servers. CentOS is only offering .9.x currently. My understanding is that only people working for the government would be utilizing FIPS mode while browsing the net. So is our solution correct: Disable FIPS mode? If so how does one go about doing this on a GoDaddy dedicated CentOS system? Thanks, -- Mike Hoy 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
Re: Win32OpenSSL.html
On 20-06-2012 22:06, Gerald L Collins wrote: John, Your Openssl package should have a manifest file with the same name as the executable with a .manifest extension. I.E. openssl.exe would have openssl.exe.manifest . In that manifest file it tells you what version of libraries it is looking for. For example part of a manifest file one of my executables has looks like below: dependency dependentAssembly assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' / /dependentAssembly /dependency The version should point you to the proper set to load. Hope this helps. In most correctly linked exe and dll files, this is stored inside the file as a PE file resource. A quick trick is to open the exe file in a text viewer and search for the string dependentAssemply, if the manifest is there, the XML file should appear in clear text near the end of the file. (Of cause there are APIs and tools to follow the various header fields to the exact location that the system will look, but the text viewer is a quick and dirty way that usually gets the right result). Gerald Collins Senior Member Technical Staff, Programmer / Analyst CSC 8 Executive Drive, Suite 300, Fairview Heights, IL 62208 North American Public Sector | p: +1-618-632-9252 x410 | | gcoll...@csc.com | www.csc.com *From:* John jw72...@verizon.net mailto:jw72...@verizon.net *To:* openssl-users@openssl.org mailto:openssl-users@openssl.org *Date:*06/20/2012 01:13 PM *Subject:Re: Win32OpenSSL.html* *Sent by:* owner-openssl-us...@openssl.org mailto:owner-openssl-us...@openssl.org John A. Wallace jw72...@verizon.net mailto:jw72...@verizon.net wrote in message news:00a701cd4f01$2b569ab0$8203d010$@net... Hello. In this instance I am using 64-bit Win7 on a laptop in a home network. When I downloaded this version of OpenSSL http://slproweb.com/download/Win64OpenSSL_Light-1_0_1c.exe, during installation it alerted me about not finding but needing the Visual C++ 2008 Redistributable. I was a bit surprised to see this alert because I could see that I already had several other such Redistributables installed on my system. These are what I currently had: Microsoft Visual C++ 2008 Redistributable - x64 9.0.30729.17 Microsoft Visual C++ 2008 Redistributable - x64 9.0.30729.4148 Microsoft Visual C++ 2008 Redistributable - x64 9.0.30729.6161 Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.17 Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.4148 Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.6161 Apparently, this version of OpenSSL required a different one, so I went online hunting down what I could find along these lines until coming across another one that seemed to suffice, namely, this one: Microsoft Visual C++ Redistributable - x64 9.0.21022 I was lucky, I suppose, in that I did not have to spend much time looking around before I found one that would fit the bill and satisfy and satisfy its requirements. However, to be honest, I am no programmer and, therefore, I am not at all sure how many different versions of the 2008 Redistributable are floating around. In the alert that I got during the installation there was no mention of any specific version at all. In general, how would a person know which of these version might be needed without having to go through a hunt and peck approach while looking for one of them? This is an awesome product, but it would be swell also, if possible, to tweak the installation process with a little more information about its dependencies under the circumstances. Or am I seeming too picky about it? Thanks. In fairness I should add to this explanation that I did in fact see on the same website where a number of versions of the “C++ 2008 Redistributable” were also available for download. Even so, when I clicked on the download link of the one identified as the correct version for my installation, it directed me to a Microsoft download site on which it stated that the system requirements for this particular version included a number of other operating systems, but it did not include mine. Therefore, I was not sure about whether it was appropriate for my situation. It turns out that it was sufficient, but, again, the Microsoft instructions were not adequately prepared for efficiency. Thanks. After downloading the version listed in the XML manifest, you need to do these additional steps (steps 1 to 3 are only needed if you have not already installed KB2718704 http://support.microsoft.com/?kbid=2718704 which was released on May 31 to stop an attack that falsifies Microsoft's own signature on Windows Updates and ActiveX controls, the steps ensure the update itself is not falsified): 1. Temporarily disable Windows Update and ActiveX support, even for trusted
Re: How to use ocsp in openssl
Of cause you shouldn't write your own OCSP code. OCSP is already part of the OpenSSL library and the file apps/ocsp.c shows how to use it. Alexander Konyagin's patch from 12 days ago doesn't seem to have been reviewed or commented by anybody else, so I am not sure if it is because he also posted it on a dev list, if it is so perfect even the top experts had no comments, if they are still testing it or if they reject it, I simply don't know at this time. Anyway, as his patch extends the OpenSSL API, I wouldn't use it until it has been integrated and adapted for an official OpenSSL release, as this ensures compatibility with future code updates. apps/ocsp.c is released code though, and the OpenSSL functions it calls are official released API functions, but it doesn't hook itself into the regular certificate verification, which seems to be what Alexander's patch adds. On 20-06-2012 17:19, JT Rosin wrote: hi, Jakob! Though it may work, i personally don't think that it's a good idea to implement ocsp code myself! Not only because I'm a lazy guy, but mainly for practical reasons :-) In google I found that some guy had already made a patch that brings some kind of ocsp client functionality to openssl (http://www.mail-archive.com/openssl-users@openssl.org/msg67721.html). I'll check that one tomorrow!! On Wed, 2012-06-20 at 16:04 +0200, Jakob Bohm wrote: Look in the openssl source code in the apps directory. There you will find the source code for each of the openssl command line subcommands (including openssl ocsp). Use this as inspiration for how to do the ocsp directly in your code. For most of the openssl command line subcommands, the code in apps is just a thin wrapper around some of the documented interface calls, with most of the code in apps dealing with the command line options, loading certificates from files and other extra stuff you probably will not need if the stuff is already in memory and you only want to do one or two things, not all the possible permutations of command line options. On 6/20/2012 2:53 PM, JT Rosin wrote: Any help on this?? On Mon, 2012-06-18 at 15:32 +0400, JT Rosin wrote: Hello to everybody!! I'm writing a client/server app with communication over SSL. Every setup can be a server or a client so I think I could benefit from using ocsp for validation purposes! I'm very new to openssl but i found that i can use bundled command-line `ocsp` application for checking certificates. Documentation says that I need to call it with the remote certificate as argument. I think I can get that certificate itself by calling SSL_get_peer_certificate(), though i have completely no idea how to pass the certificate to command-line app? Thanks for your help!! BRs, JT. 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: Generating random keys/data on Windows
On 13-05-2012 04:09, Web Developer wrote: Hey guys, I need to generate random data (for keys, IVs etc.) but I can't seem to find the right way to do it. Here is the background - I am developing my server in c/c++ on windows using visual studio and am using the openssl1.0.1c library. I was reading the documentation for random data generation using openssl at http://www.openssl.org/docs/crypto/RAND_add.html# and stumbled onto the following - OpenSSL makes sure that the PRNG state is unique for each thread. O*n systems that provide |/dev/urandom|, the randomness device is used to seed the PRNG transparently. However, on all other systems, the application is responsible for seeding the PRNG by calling |RAND_add(),| RAND_egd(3) http://www.openssl.org/docs/crypto/RAND_egd.html# or RAND_load_file(3) http://www.openssl.org/docs/crypto/RAND_load_file.html#.* |RAND_seed()| is equivalent to |RAND_add()| when *num == entropy*. |RAND_event()| collects the entropy from Windows events such as mouse movements and other user interaction. It should be called with the *iMsg*, *wParam* and *lParam* arguments of /all/ messages sent to the window procedure. It will estimate the entropy contained in the event message (if any), and add it to the PRNG. The program can then process the messages as usual. The |RAND_screen()| function is available for the convenience of Windows programmers. It adds the current contents of the screen to the PRNG. For applications that can catch Windows events, seeding the PRNG by calling |RAND_event()| is a significantly better source of randomness.*It should be noted that both methods cannot be used on servers that run without user interaction. * Now, my server does run in an unattended mode so I guess I cannot use the Rand_event() and Rand_screen() methods. How do I securely use the Rand_bytes() method on Windows? I don't already have a file with entropy so RAND_load_file() is out of question and the links on the documentation page for EGD seem to not have an EGD that is supported on Windows. How do I make sure that it is seeded with enough entropy? Any help is appreciated... Regards, Web developer All that drivel in the documentation is extremely outdated for Windows. Please ignore it (and somebody please fix the official docs). Since 1996, all releases of Windows have included a software API very similar to the UNIX /dev/random. And since many versions ago, the OpenSSL functions still misnamed with the word screen actually use this API to get randomness without us users having to do anything. It is unfortunate that documentation, code comments and user interface messages in OpenSSL still keep repeating this hopelessly outdated misinformation. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 tel:+4531131610 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: openssl0.9.8{v,w} return signal 4 Illegal instruction on cpu amd geode-lx and VIA Nehemiah
On 30-04-2012 17:40, Roberto Corrado wrote:
Good evening, I have a some problem with openssl {v,w} and cpu via
Nehemiah, the version t work fine.
root@gatto:/tmp# gdb -c core /usr/bin/openssl
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show
copying
and show warranty for details.
This GDB was configured as i486-slackware-linux.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/openssl...(no debugging symbols
found)...done.
[New LWP 11782]
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need set solib-search-path or set sysroot?
Core was generated by openssl version'.
Program terminated with signal 4, Illegal instruction.
#0 0xb76bc1f3 in _init () from /usr/lib/libcrypto.so.0
(gdb) disassemble
Dump of assembler code for function _init:
0xb76bc1d0+0: push %ebx
0xb76bc1d1+1: sub$0x8,%esp
0xb76bc1d4+4: call 0xb76bc840
0xb76bc1d9+9: add$0x12c697,%ebx
0xb76bc1df+15:mov-0x220(%ebx),%eax
0xb76bc1e5+21:test %eax,%eax
0xb76bc1e7+23:je 0xb76bc1ee_init+30
0xb76bc1e9+25:call 0xb76bc4d0__gmon_start__@plt
0xb76bc1ee+30:call 0xb76bc970
= 0xb76bc1f3+35:nopw %cs:0x0(%eax,%eax,1)
0xb76bc1fd+45:nopl (%eax)
0xb76bc200+48:call 0xb76bcc10OPENSSL_cpuid_setup
0xb76bc205+53:jmp0xb76bc210_init+64
0xb76bc207+55:mov%esi,%esi
0xb76bc209+57:lea0x0(%edi,%eiz,1),%edi
0xb76bc210+64:call 0xb7797110
0xb76bc215+69:add$0x8,%esp
0xb76bc218+72:pop%ebx
0xb76bc219+73:ret
End of assembler dump.
(gdb)
For clarity, could you please add the following info:
1. Actual 12 hex code bytes from 0xb76bc1f3 to 0xb76bc1ff inclusive.
2. Arguments passed to the openssl build scripts, including any
environment variables
3. The versions of gcc and libc used when building the failing copy of
openssl.
4. If any of those were different for your compile of 0.9.8t
As this failure happens in compiler/libc init code, I strongly suspect
#4 is the problem.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.1b released, invalid tar file!
On 26-04-2012 15:05, Thomas J. Hruska wrote: On 4/26/2012 5:10 AM, OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.1b released === Heads up warning: This archive under 7-Zip 9.20 (latest stable) displays a There are no trailing zero-filled records error dialog but then proceeds to work just fine. The last time this happened there was discussion on the list but no resolution. Ignoring the error seemed to work fine. This is not limited to 7-Zip, see also the post by Mr. Bergeron of IBM. I have looked closer at the tar.gz file (my download matches the checksums and digital signature from Dr. Henson), and the file is not valid according to the tar file format specifications that I have looked at. According to the basic tar specification, each file is prefixed by a 512 byte header with filename, size etc. and zero padded to a multiple of 512 bytes, and the last file is followed by at least 2x512 bytes of all-zero bytes to indicate end of file. Additional details vary among tar format versions, but these three aspects are amongst the common features. But the tar file inside the gzip file openssl-1.0.1b.tar.gz lacks those last 1024 bytes of zeroes. I think this must be a bug in whatever tool Dr. Henson used to create the file. 7-Zip 9.20, GNU tar 1.25 and BSD tar 2.8.3 all produce the correct format, but of those 3 only 7-Zip loudly complains about the missing end-of-file blocks. Mr. Bergeron seems to be using a 4th implementation (maybe a derivative of the original UNIX tar, maybe a version for an IBM OS) which also complains. 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 1.0.1b released, invalid tar file!
(Adding some supplemental information I found after sending) On 27-04-2012 01:36, jb-open...@wisemo.com wrote: On 26-04-2012 15:05, Thomas J. Hruska wrote: On 4/26/2012 5:10 AM, OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.1b released === Heads up warning: This archive under 7-Zip 9.20 (latest stable) displays a There are no trailing zero-filled records error dialog but then proceeds to work just fine. The last time this happened there was discussion on the list but no resolution. Ignoring the error seemed to work fine. This is not limited to 7-Zip, see also the post by Mr. Bergeron of IBM. I have looked closer at the tar.gz file (my download matches the checksums and digital signature from Dr. Henson), and the file is not valid according to the tar file format specifications that I have looked at. According to the basic tar specification, each file is prefixed by a 512 byte header with filename, size etc. and zero padded to a multiple of 512 bytes, and the last file is followed by at least 2x512 bytes of all-zero bytes to indicate end of file. Additional details vary among tar format versions, but these three aspects are amongst the common features. But the tar file inside the gzip file openssl-1.0.1b.tar.gz lacks those last 1024 bytes of zeroes. I think this must be a bug in whatever tool Dr. Henson used to create the file. 7-Zip 9.20, GNU tar 1.25 and BSD tar 2.8.3 all produce the correct format, but of those 3 only 7-Zip loudly complains about the missing end-of-file blocks. Mr. Bergeron seems to be using a 4th implementation (maybe a derivative of the original UNIX tar, maybe a version for an IBM OS) which also complains. The perl Archive::Tar::Streamed module produces such invalid files if the user forgets to call the writeeof method after adding the last file. Mr. Bergeron's reported error message is the one produced by AIX tar for truncated or unterminated tar files. Enjoy Jakob __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Deadlock in RAND_poll's Heap32First call
On 06-04-2012 01:12, Jeffrey Walton wrote: On Thu, Apr 5, 2012 at 6:58 PM, Jeffrey Waltonnoloa...@gmail.com wrote: On Thu, Apr 5, 2012 at 6:06 PM, Jakob Bohmjb-open...@wisemo.com wrote: On 4/5/2012 9:01 PM, Jeffrey Walton wrote: [SNIP] The following list of permission bits are most (not all) of those that may appear in the DACL of a process on any NT derived Windows version, and are unrelated to any Vista specific privileged processes concept: Correct. They are the permissions removed in support of DRM. I use it to harden a process in general. For the heap walking, I believe - but have not tested via code - that PROCESS_VM_READ would be of interest. My bad: s/Correct/Incorrect/g. Take a look at http://msdn.microsoft.com/en-us/windows/hardware/gg463417. PROCESS_ALL_ACCESS is not a permission bit, it is the OR of almost all the other bits. Personally, I harden selected processes by allowing only SYNCHRONIZE access for most accounts other than SYSTEM, but also allowing PROCESS_TERMINATE access for the applicable user account (otherwise even ExitProcess() may fail in some OS versions, besides allowing kill -9 to still work is more polite to users). I also change thread permissions and the token default ACL. However for most processes it is acceptable to allow same-user access (this is also the default on most Unix-like systems), and the grand total of the resulting crap allocations of GUI elements can provide a few much needed bits of entropy for seeding the cryptographic RNG in a freshly started process with only predictable startup allocations of its own. I also think that allowing same user processes to invade gpg is a non-issue, as the same effect can be trivially achieved by intercepting the launch of gpg.exe and launching a trojan version in its place. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: seg-fault in malloc called from DH_compute_key
General hint:
seg-faults in malloc(), free(), realloc() etc. are usually caused by earlier
corruption of the heap. Looking at the stack at the time of crash is
rarely successful.
A better hint is to link to a special debug variant of malloc(), which is
specifically designed to report the exact point when a bug is corrupting
the heap. On UNIX/Linux/BSD etc. there are several such libraries and
I am not sure which one to recommend. On Windows, the best choice
for heap corruption cases is usually the Page Heap in Windows itself,
controlled on a per process basis with the Global Flags facility.
On 22-01-2012 20:22, Prashant Batra wrote:
Hi,
I am observing a seg-fault with following back-trace-
#0 0x089277fe in _int_malloc ()
#1 0x08926a72 in malloc ()
#2 0x087df811 in default_malloc_ex (num=4, file=0x89eda40 bn_lib.c,
line=336) at mem.c:79
#3 0x087dfe30 in CRYPTO_malloc (num=4, file=0x89eda40 bn_lib.c,
line=336) at mem.c:304
#4 0x087e729d in bn_expand_internal (b=0xa1c0bc8, words=1) at bn_lib.c:336
#5 0x087e74c2 in bn_expand2 (b=0xa1c0bc8, words=1) at bn_lib.c:451
#6 0x087e7885 in BN_set_word (a=0xa1c0bc8, w=1) at bn_lib.c:589
#7 0x087ea037 in DH_check_pub_key (dh=0x8be1688, pub_key=0x982de00,
ret=0xbfdcebd8) at dh_check.c:130
#8 0x087e965e in compute_key (key=0xbfdcec38 , pub_key=0x982de00,
dh=0x8be1688) at dh_key.c:212
#9 0x087e9204 in DH_compute_key (key=0xbfdcec38 ,
pub_key=0x982de00, dh=0x8be1688) at dh_key.c:81
DH_compute_key is called with following values-
(gdb) p *pub_key
$28 = {d = 0x982dff8, top = 32, dmax = 32, neg = 0, flags = 1}
(gdb) p *dh
$29 = {pad = 0, version = 0, p = 0x8bdfea0, g = 0x8bdaac0, length = 0,
pub_key = 0x8bdfeb8, priv_key = 0x8bd9c40, flags = 1, method_mont_p =
0x8be0898, q = 0x0, j = 0x0, seed = 0x0, seedlen = 0,
counter = 0x0, references = 1, ex_data = {sk = 0x0, dummy =
146792592}, meth = 0x8a26240, engine = 0x0}
Can somebody help me debugging this issue as I am new to the openssl code.
Any help will be appreciated.
Regards,
Prashant
__
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: Problems with including zlib
Merry Christmas, and thanks to Michael for pointing out a GNU gcc/ld specific option to do this in manually written Makefiles. My replies below are about how to achieve this without GNU specific options and without having to edit the Configure and Makefiles. These answers do not apply to Windows, OS/2, DOS and other non-POSIX based build environments. On 24-12-2011 05:31, grarpamp wrote: 1. Make sure there is a libz.a in /lib or /usr/lib, otherwise you have no static zlib to link in. Of course there's an old libz.a there. And it should not matter as we're given the --with-zlib arguments to point the build elsewhere for those libraries. And as seen in the report, it is following those pointers. It's just not using them correctly regarding being told to link against libz.a, not libz.so, with the 'zlib' parameter to config. If you pass Configure and option to look for zlib in an additional directory, all of these steps apply to that directory too. 2. Temporarily remove or rename the symlink named exactly libz.so in /lib, /usr/lib, /usr/local/lib and /zlib125/lib (This ensures it cannot link to the dynamic zlib). No, this appears to be to be a ./config build parameter setup error. Why should user's break their perfectly sound systems in order to work around a bug? If users wanted it to link dynamically against libz, they would have specified 'zlib-dynamic' to ./config. As partly explained by Michael, there is no portable option that ./config could tell the Makefile to pass to the compiler/linker to get the desired effect. It simply hasn't got a chance. Michael's other suggestion to first use the linker to produce and intermediary .o file with some unresolved externals is not portable either, as only some linkers have the ability to do that. However a general way to achieve this on almost any UNIX/POSIX based system is to artificially present the linker with a scenario where the linker thinks there is no shared library version of zlib available, only a PIC-compiled static libz.a, which the linker will then have to use when creating an OpenSSL shared library. This is achieved by temporarily hiding the libz.so - libz.so.N symlinks that the linker uses, but keeping the libz.so.N - libz.so.N.N.N symlinks used by the dynamic linker on your working computer. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Transferring DH public key from server to client
It could be that (undetailed) step obtain parameters from hardware and/or other indirect hardware calls caused by your OpenSSL calls makes the hardware think the key is now spent and can/must be deleted. Hardware crypto is often designed to protect keys much more strictly than software crypto, because it is often used to ensure no virus can steal the private key. FIPS certification is also all about such strict protections. So as the SSL handshake is outside both the FIPS sealed and hardware sealed modules, maybe you should look at a way of grabbing the public key from wherever the SSL code temporarily holds it for transmission in the handshake, thus avoiding suspect extra calls to the paranoid key protection systems. On 08-12-2011 18:01, Odomae Bro wrote: Thanks for the response Dave! I was using a FIPS compliant version of openssl (0.9.8r) and anonymous DH for DTLS was broken with that version. I am now working with 1.0.0.e and am able to get the anonymous DH going. There is only one small problem. We use the p and g from the client/server exchange, but the DH private(say a) and public i.e. (A = g exp a mod p) is offloaded and obtained from our hardware module. Once I get the keys, I copy them into the dh_clnt-pub_key and dh_srvr_pub_key in d1_clnt.c and d1_srvr.c respectively. The way I update the dh_*-pub_key is this: DH_compute_key(...) // openssl call . //obtain parameters from hardware //then copy key into openssl structure for it to be exchanged dh_clnt-pub_key = BN_bin2bn(pub_key_buff, modulus_len, dh_clnt-pub_key); If I do this, the exchange stops after the GET_FINISHED_A. If I remove the above line, the exchange completes and the client/server exit gracefully. Any ideas on why the copy back into the openssl structure would cause issues? On Mon, Dec 5, 2011 at 7:55 PM, Dave Thompson dthomp...@prinpay.com mailto:dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org mailto:owner-openssl-us...@openssl.org On Behalf Of Odomae Bro Sent: Saturday, 03 December, 2011 23:23 I would like to generate my own DH private/public keys and have the client/server exchange these values. The problem I am having is that the openssl build I have is configured to use certificates. Hence the client side is getting the server's DH public value from the certificate. If I need to bypass this, how do I go about this? I assume you are talking about SSL/TLS, if not describe further. AFAIK OpenSSL has no _build_ option to use or not use certs; that's a must-implement part of the protocol(s). OpenSSL _applications_ can and often do have runtime options to use certs/keys, or not; what applications are you concerned with? What exactly do you mean by public value? TLS has ciphersuites that use 'static' DH with publickey(s) in cert(s), but OpenSSL doesn't support them. (It does enable static ECDH suites, but it appears to me 'full' (both) static isn't implemented.) The client side is retrieving the server's public key value from s-session-sess_cert- peer_dh_tmp i.e dh_srvr= s-session-sess_cert- peer_dh_tmp That is an 'ephemeral' aka 'temporary' key, NOT taken from the cert (but *signed by* the server's cert/key unless anonymous).OpenSSL does implement those. If you have a DSA (resp ECDSA) cert, you could use the *parameters* (P and G but ignore Q) from the key in the cert. So I thought I would set the s-session-sess_cert- peer_dh_tmp with my custom values, but I cannot find ? the code on the server side where this is being set? peer_tmp in the client is remembered from the ServerKeyExchange message received from the server, which creates it in ssl3_send_server_key_exchange from [ec]dh_tmp or _tmp_cb. The *parameters* are set by SSL_[CTX_]set_[ec]dh_tmp[_callback]. The doc isn't entirely clear, but looking at the code it appears to me that if the callback returns a DH or ECDH *with* a keypair and SINGLE_[EC]DH_USE is not set, that keypair is used; if you return only parameters, or (always?) if parameters were pre-set, or if SINGLE_USE, a random keypair is generated. So if you want to use your own (pregenerated) DH or ECDH keys as ephemeral keys, setting a callback that returns them and leaving SINGLE_USE off should work. Of course the client and server keys must share the same parameters; if you are not using the parameters transmitted in the ServerKeyExchange to do this, I presume you do it by some other means. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org mailto:openssl-users@openssl.org Automated List Manager majord...@openssl.org mailto:majord...@openssl.org
Re: Renewed CA's own cert, IE still trusted signed sites but firefox does not
On 08-12-2011 19:46, Gaiseric Vandal wrote: I am using Openssl 1.0.0a (on Solaris 10) as a basic CA. I use this to sign SSL certificates for various internal servers (web, e-mail etc.) I recently used the openssl ca command to renew the CA's machine own public certificate. The modulus (public key) of the new certificate is the same as the old one. I put the new cert on an internal web page so that users could install it. On Windows (XP, 2003, Win 7) users can use Internet Explorer to install the certificate as a trusted root certificate. (If an admin, this can be installed for the computer rather than just the user.) IE and Outlook and any other apps that rely on the Windows/IE cert store are OK. Firefox (various version) on Windows now complains that a server is not trusted when I connect to an internal site, even if the new CA certificate has been installed. On linux, firefox, thunderbird and google-chrome also complain. If I generate a new server certificate it seems to be OK.It seems that Firefox and some other apps do not like server certificates that are older than the CA certificate.Is this correct? FYI Citrix XenApp Receiver ver 11 for Linux has problems. It seemed to just ignored the updated certificate. Citrix XenApp Receiver ver 12 did not. Sounds like you have found a security hole in Windows CryptoAPI, certificates that are signed before the CA certificates not before date are invalid by definition, but such certificates are rare and not a common attack, so the Windows code to detect that condition may be untested. You should regenerate the CA cert with its old not before date, but its new not after date. Not sure of the openssl x509 option to set not before to a date other than the current, but it should be possible. P.S. For Windows clients, you can also distribute the CA cert via group policy, it has a specific option to do this, often mentioned in relation to Microsoft's own CA, but it works fine with OpenSSL CAs too if you follow the instructions for We purchased an entire computer + Windows Server license to keep the Microsoft CA permanently disconnected from the network. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS Overhead
For authenticated encryption speed on a typical general purpose processor (such as Atom), I would suggest AES-128 in GCM (Galois Counter Mode), this does one 12-round AES per 16 bytes, plus one extra per message, with no additional hashing algorithm use. I don't know if that mode is in TLS, or you will have to run it independently of TLS. Running outside TLS context will also allow you to manage key selection independently of socket level connection setup, so If you maintain a key and message number counter for each direction with each peer (64 bytes per peer including the IP address, 320,000 bytes for 5000 peers), you can even avoid the need to keep 5000 open connections (which uses a lot more RAM, just for the TCP state in the kernel). Keys can be exchanged over once-in-a-while TLS connections with certificate and client certificate checking against your own private CA only (so a Comodo incident will not affect it). On 14-11-2011 02:16, Curt Sampson wrote: I'm dealing with some of the exact same issues; I am trying to satisfy a requirement that a rather lightweight host (an embedded system with an Atom processor) handle conversations with about 5,000 other hosts with strict latency requirements. I'm currently attempting this as peer-to-peer TLS communication, but I'm not sure if it's actually going to meet the latency requirements. Basically, you're going to have to keep all of your TLS connections up and running at all times; in my quick-and-dirty benchmarks connection setup uses about a thousand times more CPU than sending a single message on an existing connection. If you really, really need keep the number of sockets down you can look at using DTLS/UDP instead of TLS/TCP and hacking OpenSSL to let you use an unconnected socket for multiple DTLS connections (standard OpenSSL will not do this). I had a reference somewhere to a page discussing various ways of doing this, but I seem to have lost it, so you'll have to dig around and see if you can find it. (Please post it here if you do.) But if you're only dealing with something on the order of 10,000 other hosts, Linux at least will handle that just fine once you bump up the per-process socket limits. (Do make sure you're using epoll or whatever; libevent can be helpful here.) In my situation, unfortunately, even using RC4-SHA (which is only about 10% slower than NONE-MD5) may be too slow to handle the traffic volume on my system, so we may just be dropping authentication of our data entirely. I'd be interested in ideas about how to avoid doing this. cjs __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: is crypto part of openssl-1.0.0e.tar.gz
On 01-10-2011 04:14, Dave Thompson wrote: From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm Sent: Friday, 30 September, 2011 13:27 On 9/30/2011 5:04 PM, michael lush wrote: On Fri, Sep 30, 2011 at 3:07 PM, Jakob Bohmjb-open...@wisemo.com wrote: snip Linkable shared libraries lib/libcrypto.so and lib/libssl.so (.DLL if Windows, OS/2 or Symbian). Linkable static libraries lib/libcrypto.a and lib/libssl.a (.LIB if Windows, OS/2 or Symbian). For Windows shared=DLL the basename also changes, for historical compatibility: libcry(pto) = libeay32.dll and libssl = ssleay32.dll. I believe on some Unix shared is .sl instead of .so. And in some Unix packagers shared libs have a version number added to the name. These shouldn't confuse a human, but may matter for e.g. a configure script. Yes. Generally the scheme is libfoo.so.1.0.0e : Actual shared library named after exact version libfoo.so.1.0 or libfoo1.0.so: Symlink to libfoo.so.1.0.0e but named from API version, this is what linked programs refer to at load time, allowing different versions to coexist. libfoo.so: Symlink to the version that matches the headers in /usr/include/foo, this is what the linker looks for when you run cc --dynamic bar.c -lfoo or similar. Thanks for this its a real help! I've had a look at the installation and there is lib/libcrypto.a but no lib/libcrypto.so I'll have another look at how in installed it. Ok, this means you compiled openssl as static libraries to be linked into you postgres programs. I believe static/nonshared is always the default for openssl configure; it definitely is on all platforms I use. Yes, probably. To get the .so variant, compile openssl as dynamic libraries (DLLs). To get both types you typically need to compile openssl twice, because on Linux, code that goes in DLLs is typically compiled as Position Independent Code which code for a program file is not. The .a file is typically compiled for inclusion in a program. OpenSSL and Unix call it shared (as you did above). AFAIK only Windows calls it DLL. Although it is basically the same thing. I have seen *N*X/GNU documentation use the phrase dynamic link library about .so files. For instance the gcc option to use them is called dynamic. The .DLL file name convention is found on multiple PC-related OS-es. Alternatively, there might be a way to make postgres happy with static libraries. That would be a question for postgres people. Unlikely, due to the plugin based nature of this beast. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Is certificate a CA or Client Certificate
Because the attributes mentioned are only meaningful if covered by the digital signature on the certificate, it cannot change in any format conversion that keeps the certificate valid. The true format of certificates is binary BER encoded X.509. A .cer file is simply that structure directly. A P7b/PKCS#7 file is really a digitally signed message with zero or more attached signatures to help the recipient to check the signature, each certificate is the same X.509 BER structure, just placed inside a list (SEQUENCE) inside a PKCS#7 structure (which is also BER encoded just like the certificate). When using a P7b file to transport certificates, the message and signature fields are just left blank. A P12/PFX/PKCS#12 file is an encrypted file which stores various certificates (the same X.509 BER structure as before), various private keys and hints on where these items should be imported into CryptoAPI and/or the old Netscape browser. So whatever the format, after loading and unpacking, you are left with an X.509 structure which contains a few mandatory fields (such as Subject, Issuer, Public Key, Private Key, Serial Number), and a lot of optional fields. One of those optional fields is a list of authenticated attributes. Each entry in that list has a type OID, a critical flag and some data. The entries may be found in any order, your code needs to work whatever field entry comes first, needs to ignore any entry whose type OID you don't understand. The optional CA occurs in this list as an entry with the CA OID and a TRUE/FALSE value. So CA may be not there, TRUE or FALSE. The optional Key Usage also occurs in this list as an entry with the Key Usage OID and a value which is a list of OIDs (one for each usage). So Key Usage mat be not there, there with the certificate sign OID listed in its value, or there without the certificate sign OID in its value. I don't remember the function names to look at the authenticated attribute list in OpenSSL and/or CryptoAPI, but there should be functions that will let you check if the list is there at all, and if so loop over all the entries, looking at each to see if it is one you care about today. On 29-09-2011 17:33, Harshvir Sidhu wrote: Thanks Jakob. Is this key usage only available in P7b format, when i tried this on CER and P12 format then its not working on them, Crypt API is not able to read extended information about Key Usage. Is the process format specific? I am trying to use CertFindExtension API for this. // Harshvir On Thu, Sep 29, 2011 at 9:42 AM, Jakob Bohm jb-open...@wisemo.com mailto:jb-open...@wisemo.com wrote: You forgot to also check the Key Usage attribute IF (CA: TRUE OR Key Usage: Certificate Sign) If Self Signed ROOT Else Intermediary Else If Self Signed Toy certificate Else End use (server / person / company / etc.) On 9/29/2011 3:39 PM, Harshvir Sidhu wrote: Hey, I tried using this method following is the flow. IF CA: TRUE If Self Signed ROOT else Intermediate else Personal When i try parsing the PKCS7 (.p7b) files, then for Intermediate CA Certifites I get that its a personal Certificate? Is there something different that i need to do for p7b file format? Thanks. // Harshvir On Fri, Sep 16, 2011 at 2:33 PM, Jakob Bohm jb-open...@wisemo.com mailto:jb-open...@wisemo.com mailto:jb-open...@wisemo.com mailto:jb-open...@wisemo.com wrote: On 9/16/2011 9:02 PM, Harshvir Sidhu wrote: I already tried this command, but its not giving any information showing wheter its a root certificate or a client certificate. - Harshvir On Fri, Sep 16, 2011 at 1:53 PM, Jakob Bohm jb-open...@wisemo.com mailto:jb-open...@wisemo.com mailto:jb-open...@wisemo.com mailto:jb-open...@wisemo.com mailto:jb-open...@wisemo.com mailto:jb-open...@wisemo.com mailto:jb-open...@wisemo.com mailto:jb-open...@wisemo.com wrote: On 9/16/2011 7:58 PM, Harshvir Sidhu wrote: Hi, In openssl is there some method using which i can find whether the cerficiate in a file a Client Certificate or a CA/Root Certificate? - H S Try the following command, at look for the CA property and also see if the certificate lists itself or someone else as issuer: openssl x509 -in somecert.cer -noout -text somecert.txt (somecert.txt will then contain a nice human readable printout of the certificate) Look for the
Re: Becoming a CA for group of internal servers?
On 01-09-2011 21:51, Dave Thompson wrote: From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm Sent: Thursday, 01 September, 2011 13:44 req_extensions will put the names in a CSR (signing request) file when running the req command. x509_extensions will put the names in the actual certificate file when running the x509 command. Small correction: [req]req_extensions will put SubjectAltName (or other) in the CSR for 'req -new' but 'x509 -req' ignores extensions in the CSR. [$default_ca]x509_extensions will put in the cert (regardless of the CSR) *for 'ca' which this OP is not using*. Also for 'ca' [$default_ca]copy_extensions will put extensions from the CSR. My point exactly, I was trying to keep the explanations simple for this user. [] OR []extensions, or -extsec, will put in the cert for 'x509 -req'. But only if -extfile explicit; it doesn't have any config by default. Hmm, the way I read the docs, -extensions my_exts should use the extensions from section [my_exts] in openssl.cnf (or the file specified with -config), however I assumed that this part of the users setup was already working when I joined the discussion. On 9/1/2011 7:37 PM, Hopkins, Nathan wrote: thanks - sorry my previous post wasn't clear enough, the req_extensions value references the section I put the subject. and alt names in... req_extensions = v3_req [ v3 req ] SubjectAltName = @alt_names Should this work? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
