Entropy collection is outside the FIPS boundary. If you don't want to
modify the code, you can pass in -DDEVRANDOM using CFLAGS and set it to
whatever value you desire. For instance, maybe you have a hardware
device mapped to /dev/entropy that provides sufficient random data to
seed the DRBG.
On 09/23/2015 08:16 AM, Steve Marquess wrote:
> John, let me elaborate on my comment above by noting that the Cisco
> contribution includes a bunch of FIPS specific code for which there is
> no counterpart on the master branch (i.e. no place to put it). A
> version which worked on master with all
Pull request 368 has KDF support for FIPS:
https://github.com/openssl/openssl/pull/368
I've already updated libsrtp to use this API for FIPS compliance. We would like
to contribute to other downstream projects as well. But it would help if
OpenSSL accepted this pull request.
--
The following commit changed the behavior of checking the extended key
usage bits in a server certificate when using X509_PURPOSE_SSL_SERVER:
http://marc.info/?l=openssl-cvsm=132759007026375w=2
This commit was put into 1.0.2 on April 6, 2012. Therefore, 1.0.1 and
1.0.2 behave differently in
Well, since you're using the fips-ecp tarball, you'll need to include
no-ec2m when configuring OpenSSL 1.0.2a. But this isn't why you're
seeing a fork error from fipsld.
I'm using Ubuntu 14.04 (Is there a 14.4?) and don't see any issue.
However, I'm not setting CC, FIPSLD and FIPSDIR. You
Not sure.
Are you using blocking or non-blocking IO?
Have you tried SSL_MODE_AUTO_RETRY?
Do you notice a different return value from SSL_read() after a zero byte
read compared to other errors?
On 05/06/2015 07:12 PM, Bryan Call wrote:
Do you know if there is a way from preventing a call to
That's the same symptom I see on 32-bit systems. It appears to be
caused by 5b38d54753acdabbf6b1d5e15d38ee81fb0612a2.
On 05/04/2015 09:21 AM, The Doctor wrote:
This also occured in openssl-1.0.2-stable-SNAP-20150503
Script started on Mon May 4 07:06:41 2015
...
-Bryan
On May 1, 2015, at 5:34 AM, John Foley fol...@cisco.com wrote:
Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors. It
appears your application is generating a lot of errors for some reason.
Never tried it myself, but you probably can't disable this lock
Lock #1 is CRYPTO_LOCK_ERR, which I believe is used for logging errors.
It appears your application is generating a lot of errors for some
reason. Never tried it myself, but you probably can't disable this lock
with multiple threads running. You should take a look at the error log
to identify
The changes to SSL_locking_callback() look good. But the code you've
added to SSL_CTX_add_extra_chain_cert_file() doesn't accomplish much.
You're checking if FIPS is on or off, then setting the FIPS mode to the
current setting, which is a no-op.
On 04/30/2015 09:49 PM, Bryan Call wrote:
there are
callbacks for type 39 and 40 locks (for OpenSSL 1.0.1 and 1.0.2)?
-Bryan
On Apr 28, 2015, at 10:22 AM, John Foley fol...@cisco.com
mailto:fol...@cisco.com wrote:
In the context of OpenSSL 1.0.1 or 1.0.2, this means FIPS_mode_set(1)
has returned with a successful return value
On Apr 24, 2015, at 4:17 PM, John Foley fol...@cisco.com
mailto:fol...@cisco.com wrote:
Some of the algorithms still invoke the FIPS flavor of the algorithm
even when FIPS is disabled. For example, this code is from
EVP_DigestUpdate().
int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *data
) FIPS_mode: 0
-Bryan
On Apr 24, 2015, at 10:56 AM, John Foley fol...@cisco.com
mailto:fol...@cisco.com wrote:
When you create the private key given to SSL_CTX, be sure to
instantiate a private key for each thread as well. If you share the
same key across all threads, this can introduce
-52.20.2/src/crypto/err/err_def.c
line: 343 type: 1
-Bryan
On Apr 23, 2015, at 4:46 PM, John Foley fol...@cisco.com
mailto:fol...@cisco.com wrote:
Looking at your call stack, it appears you're testing with FIPS mode
enabled. There's a lock in FIPS_selftest_failed() that's used to
ensure
Looking at your call stack, it appears you're testing with FIPS mode
enabled. There's a lock in FIPS_selftest_failed() that's used to ensure
the crypto algorithms inside the FIPS boundary are not utilized until
after the POST has completed and passed. Unfortunately this lock remains
installed for
Are you packaging libcrypto.so into the APK yourself? The Android OS
comes with it's own resident copy of libcrypto. You can leverage this
from your app without having to package libcrypto into your
application. This assumes the version of libcrypto that comes with
Android meets your needs.
I'm impressed you were able to do a FIPS build for Windows x64. I
didn't think this was possible. ;-)
This looks like the hash that FINGERPRINT_premain() spits out when the
signature hasn't been embedded into the binary. You may want to confirm
the signature is embedded during the build
Do you see the same stack trace when simply using the random number
generator:
./openssl rand 64
What if you simply use SHA1:
./openssl sha1 somefile
On 04/14/2015 12:17 PM, John Unsworth wrote:
Is no-one interested at all about this problem? Or do I need to send
it to another place?
Of *John Foley
*Sent:* 15 April 2015 13:31
*To:* openssl-users@openssl.org
*Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is
broken
Do you see the same stack trace when simply using the random number
generator:
./openssl rand 64
What if you simply use SHA1
, 2b3d78) + 108
Regards,
John
*From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On
Behalf Of *John Foley
*Sent:* 15 April 2015 15:10
*To:* openssl-users@openssl.org
*Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is
broken
How about
failure:s23_lib.c:177:
John.
*From:*openssl-users [mailto:openssl-users-boun...@openssl.org] *On
Behalf Of *John Foley
*Sent:* 15 April 2015 16:45
*To:* openssl-users@openssl.org
*Subject:* Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is
broken
Looks like the crash
Have you recompiled Apache? Or did you only recompile OpenSSL 1.0.2a?
There is no binary compatibility between 0.9.8 and 1.0.2. You'll need
to recompile Apache if you haven't done this. Or, possibly a newer
Apache binary (2.4.12) would work with your OpenSSL 1.0.2a build.
On 04/06/2015
The 'make depend' regenerates the dependencies for the makefiles. The
dependencies will change depending on the configuration options you've
passed to OpenSSL. If you're new to using GNU make, here's a decent
explanation:
We looked at this very briefly a couple of years ago. In theory, there
may be a way to achieve the goal as a loadable kernel module (a.k.a.
device driver). The idea would be to have a kernel module that provides
crypto support. This kernel module would be the FIPS object module,
with the
We maintain our own derivative of OpenSSL and haven't had any
significant issues due to the code reformat. We simply run the reformat
script on our downstream derivative. We can then generate patch files
of our changes and reapply them to new OpenSSL releases. It was fairly
straight forward.
If it fits your needs, you may want to look into using EST (RFC 7030)
instead of SCEP. EST is the replacement for SCEP. The SCEP draft was
never ratified. The libest open source project implements RFC 7030 and
uses OpenSSL. It's available at https://github.com/cisco/libest.
On 03/17/2015
You don't even need to modify e_os.h. You can just pass in a new value
for DEVRANDOM using the gcc -D compiler option. For instance, maybe you
have a hardware device mapped to a Linux device file called
/dev/entropy1. You can override DEVRANDOM to use this device without
modifying any OpenSSL
Appendix E.2 in the FIPS 2.0 users guide
(https://www.openssl.org/docs/fips/UserGuide-2.0.pdf) contains blank
pages on pages 134-136. Is this intentional? It appears the iOS build
instructions starting on page 133 are incomplete.
___
openssl-users
On 02/20/2015 12:30 PM, Steve Marquess wrote:
On 02/20/2015 10:52 AM, John Foley wrote:
Appendix E.2 in the FIPS 2.0 users guide
(https://www.openssl.org/docs/fips/UserGuide-2.0.pdf) contains blank
pages on pages 134-136. Is this intentional? It appears the iOS build
instructions starting
Tried again using the 20140613 snapshot and it's now working. Thanks
for committing the fix yesterday.
On 06/12/2014 11:35 AM, John Foley wrote:
Using the 201406012 snapshot on the 1.0.2 branch, I'm seeing an error
while trying to build for the VC-WIN32 target. The compiler is VS2010.
Can
Using the 201406012 snapshot on the 1.0.2 branch, I'm seeing an error
while trying to build for the VC-WIN32 target. The compiler is VS2010.
Can anyone confirm this is the correct build procedure?
perl Configure VC-WIN32
ms\do_nasm.bat
nmake -f ms\ntdll.mak
The error is:
cl
We plan to publish an open source EST stack in the near future. This
will support both client-side and server-side capabilities. The code
will be hosted here:
https://github.com/cisco/libest
I've also recently setup an EST test server, which is available here:
There were several commits to the 0_9_8 trunk after the 0.9.8y release
last week that appear to be related to CVE-2013-0169. Will there be a
forthcoming 0.9.8z release as a result? Or are these commits not needed
to mitigate CVE-2013-0169?
Thank you.
attachment: foleyj.vcf
Now that 1.0.1 has been released, will there be any future maintenance
releases on the 0.9.8 branch? For instance, will any vulnerabilities
found in the future be addressed on 0.9.8? Or is the 0.9.8 branch
effectively end of life at this time?
Thank you.
attachment: foleyj.vcf
Looking at OpenSSL_add_all_ciphers() in crypto/evp/c_allc.c, AES-CCM
mode is not in the list of ciphers added. Has this cipher intentionally
been omitted, or is this a bug?
attachment: foleyj.vcf
Does anyone know why the CertificateVerify message is still limited to a
max size of 514 bytes?
http://www.mail-archive.com/openssl-dev@openssl.org/msg13520.html
Is there any risk with increasing this to 4096 bytes?
Thank you.
None of the ECDH-RSA cipher suites appear to work in 0.9.8r. Yet they
work in 1.0.0. Is this expected?
Looking at s3_lib.c, all the older DH-RSA cipher suites are disabled
(SSL_CIPHER-valid=0). But the ECDH-RSA ciphers listed in s3_lib.c are
enabled. This leads to the following questions:
1.
Does the OpenSSL OCSP stack support IPv6 in version 0.9.8r?
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager
Is there a known bug with ECDH_RSA key exchange cipher suites in
0.9.8r? For instance, using cipher suite ECDH-RSA-AES128-SHA in 0.9.8r
does not work. But it does work in 1.0.0d. This is tested using the
following command:
ssltest -tls1 -cert servercert.pem -key serverkey.pem -cipher
Section 4.2.1 of the FIPS User Guide states...
Per the conditions of the FIPS 1402 validation only two configuration
commands may
be used:
./config fipscanisterbuild
or
./config fipscanisterbuild noasm
However, section 4.2.2 states...
Note that fipscanister.o can either be
40 matches
Mail list logo
