RE: Differences in defaults between 1.0.2 and 1.1.1
Thanks Matt, the command you listed did succeed. I was hoping to be able to change our code so that we could connect to any server we were able to connect to before, but if this is truly a server-side bug, there's only so much we can do on the client side. If our customers see this change in behaviour after we upgrade OpenSSL, my understanding is that they will simply have to fix their server. Graeme -Original Message- From: openssl-users On Behalf Of Matt Caswell Sent: March 19, 2019 10:23 AM To: openssl-users@openssl.org Subject: Re: Differences in defaults between 1.0.2 and 1.1.1 On 19/03/2019 13:40, Perrow, Graeme wrote: > TLS: error: accept - force handshake failure: errno 11 - moznss error -12162 > > TLS: can't accept: TLS error -12162:Unsupported hash algorithm used by TLS > peer.. Just to confirm - you've not configured client authentication? Assuming not, the above error message from the server suggests that it doesn't like one of the signature algorithms sent through from the client in the ClientHello. At least I'm assuming that's the point at which it fails. You omitted most of the -debug output so its a little unclear exactly how far through the handshake it got before the failure occurred. If my assumption is right then it looks like the server may be behaving incorrectly. It isn't supposed to fail if it encounters a parameter it doesn't recognise - its just supposed to ignore it. To test the theory I suggest sending through the same list of signature algorithms in the same order that 1.0.2 sends them. You can do that using the "-sigalgs" parameter to s_client: openssl s_client -showcerts -host : -debug -sigalgs "RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1" Matt
Differences in defaults between 1.0.2 and 1.1.1
I have an LDAP server that accepts TLS connections, and I can make a connection to it using "openssl s_client -showcerts -host : -debug". The output shows this is a TLSv1.2 connection using ECDHE-RSA-AES128-SHA. This is using OpenSSL version 1.0.2j. If I run exactly the same command using the openssl executable built with 1.1.1, I get errors: CONNECTED(0184) write to 0x2917b30 [0x2928090] (326 bytes => 326 (0x146)) - 16 03 01 01 41 01 00 01-3d 03 03 5a e6 ad 03 79 A...=..Z...y ... 0140 - cb bb 7f 9c 78 24 x$ read from 0x2917b30 [0x291edf3] (5 bytes => 0 (0x0)) write:errno=0 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 326 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- read from 0x2917b30 [0x290e960] (8192 bytes => 0 (0x0)) The connection is closed by the server, which is reporting an error: TLS: error: accept - force handshake failure: errno 11 - moznss error -12162 TLS: can't accept: TLS error -12162:Unsupported hash algorithm used by TLS peer.. If I add the -no_tls1_2 switch, the openssl 1.1.1 command succeeds. Since the server didn't change and the client command line didn't change, it would seem that some default behaviour has changed within OpenSSL for 1.1.1. I know that some ciphersuites were removed or disabled but the one used by OpenSSL 1.0.2j (ECDHE-RSA-AES128-SHA) does not seem to be one of them (it's listed in "openssl ciphers"). Does anyone know what might be happening here? Thanks Graeme Perrow
Re: [openssl-users] openssl 1.0.2 and TLS 1.3
AFAIK 1.1.1 does not support the FIPS module, which means that those of us who require FIPS must stay on 1.0.2. Any ETA on when FIPS support might be added? Graeme -Original Message- From: openssl-users On Behalf Of Matt Caswell Sent: September 11, 2018 4:31 AM To: openssl-users@openssl.org Subject: Re: [openssl-users] openssl 1.0.2 and TLS 1.3 On 11/09/18 09:05, Dr. Matthias St. Pierre wrote: >> Von: openssl-users Im Auftrag von The >> Doctor >> Gesendet: Dienstag, 11. September 2018 08:49 >> An: openssl-users@openssl.org; openssl-...@openssl.org >> Betreff: [openssl-users] openssl 1.0.2 and TLS 1.3 >> >> Will that combination occur? > > Support for TLS 1.3 is a new feature in OpenSSL 1.1.1 which will be released > today. > OpenSSL 1.0.2 is an LTS release which will only receive security updates and > no new > features. Strictly speaking 1.0.2 will receive bug fixes and security fixes until the end of this year. From the end of this year until the end of 2019 it will receive security fixes only. In any case it will receive no new features (including TLSv1.3). >From the release of 1.1.1 (today), 1.1.0 will receive security fixes only for one year. Matt > > HTH, > Matthias > > See also > https://wiki.openssl.org/index.php/TLS1.3 > https://www.openssl.org/policies/releasestrat.html > > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Can I rename the OpenSSL shared objects for FIPS?
We are shipping OpenSSL (1.0.2j) shared objects built with FIPS, which are automatically loaded when the application starts. But if our software directory is in the path (or LD_LIBRARY_PATH or platform equivalent) earlier than the system directories, then other applications that load OpenSSL dynamically (eg. ssh on some systems) could use our libraries rather than the system ones. This is not a huge deal except that we may want to disable certain algorithms that we don't use, and we don't want to break system utilities that do use them. We would like to avoid this by renaming these libraries, i.e. libMYcrypto.so.1.0.0 and libMYssl.so.1.0.0, and then we'll know that only our application would load them. Simply renaming the files is obviously no good, and I've found that renaming them before linking with them does not work either. It would seem that the names "libcrypto" and "libssl" are hard-coded in a million places within Makefiles and scripts and such. Is there a way to solve this problem? This would apply to Linux, HP-UX, and Solaris. Thanks Graeme Perrow -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] PKI encryption failing on 32-bit Solaris
I have a small test program (source attached) that does a very simple PKI
encrypt / decrypt. This program works on Windows, Linux, and Solaris (64-bit)
but fails if I run a 32-bit version on Solaris 10. Solaris 11 is fine.
If I use "./config -kPIC -m32 -xarch=sparc" to build OpenSSL, I get a crash in
bn_mul_mont_t4_32. I added "no-asm" and it no longer crashes but I get this
error output:
OSSL error
4275158204:error:0407109F:rsa routines:RSA_padding_check_PKCS1_type_2:pkcs
decoding error:rsa_pk1.c:272:
End OSSL error
decrypt failed
I also tried adding -d to the config line and then the program succeeds though
is very verbose.
Could this be a bug in OpenSSL, or am I configuring it incorrectly, or is there
a bug in my code?
Thanks for any insight
Graeme Perrow
#include
#include
#include
#include "openssl/rsa.h"
#include "openssl/pem.h"
#include "openssl/err.h"
#include "openssl/ssl.h"
#include "openssl/rand.h"
int _ossl_err_printf_callback( const char *str, size_t len, void *u )
/***/
{
printf( "%s\n", str );
return 0;
}
void _ossl_err_printf( void )
/***/
{
if( ERR_peek_error() > 0 ) {
printf( "OSSL error\n" );
ERR_print_errors_cb( _ossl_err_printf_callback, NULL );
printf( "End OSSL error\n" );
}
}
const char *PUBLIC_KEY = "-BEGIN RSA PUBLIC KEY-\n"
"MIIBCgKCAQEAvg95SwHiiiN/ttddVS7nUR1Gtbg1xMgFdrPUTidgGmS2DM5k/y7B\n"
"VNCIp93gLjg5fKB3nqcuIhqppEDadDdWhlRFjImRqUlhppYjoIuP5t7tXHqzTwa8\n"
"QUHZ29Y8/CZXwtpud4C7o2vzJStFVXc1goehTD1lig9KXI5FAZDyKsGlzJPNm0+c\n"
"YrU7UNXA6DtRdKhVNynHuCRaoglkZ/5x4Qxk3O4yCeuuttTqcfo8hqOiM8TtQGgD\n"
"sOlOHgn26abs+rpAtgqyQIVogRVfQKm1pfatqK/PvVdw75/c9t88tglzPhTo3CHH\n"
"e5wv67m08Wy5TKiQL+SYZi9wQA/ktdUc5wIDAQAB\n"
"-END RSA PUBLIC KEY-";
const char *PRIVATE_KEY = "-BEGIN RSA PRIVATE KEY-\n"
"MIIEoQIBAAKCAQEAvg95SwHiiiN/ttddVS7nUR1Gtbg1xMgFdrPUTidgGmS2DM5k\n"
"/y7BVNCIp93gLjg5fKB3nqcuIhqppEDadDdWhlRFjImRqUlhppYjoIuP5t7tXHqz\n"
"Twa8QUHZ29Y8/CZXwtpud4C7o2vzJStFVXc1goehTD1lig9KXI5FAZDyKsGlzJPN\n"
"m0+cYrU7UNXA6DtRdKhVNynHuCRaoglkZ/5x4Qxk3O4yCeuuttTqcfo8hqOiM8Tt\n"
"QGgDsOlOHgn26abs+rpAtgqyQIVogRVfQKm1pfatqK/PvVdw75/c9t88tglzPhTo\n"
"3CHHe5wv67m08Wy5TKiQL+SYZi9wQA/ktdUc5wIDAQABAoH/QtEt0zDWc7oHLECK\n"
"j2ft6pZgRYJ9ZLDtOs391XwCTUUau2XUG+JUFX06jclzBsy9aRMA+sXLcjHtcdFa\n"
"+4B46sC1srKqgtlJe0dNPyPRc1jsGZcJcr7rcAW2kZK/3eWc9OPV8i1PyiQpVuff\n"
"eCxwo3MLQcJT8DVv7xoVKHfMqzrNt6hbymGMklpw9Nwc/CqGq28jw1K1+h1Ekryt\n"
"hwqr4C0bDvIb/mJ+ipVbakOSFytNaVJeyB2vfS8sJ/2ojZieraloiLHSY6vCZPGC\n"
"w+DMHUIAHVCfHN23arZStHxAlqWjpgECRWB9Y5oHCRtZDcUx6eCfn9IIkTX4TdVK\n"
"LDhRAoGBAOleqXQM7nlOYavwWaClR75mVhT1wCf9hgq9hhlJbWS67xwWCAIQVp2x\n"
"G3M/iNPbDUBqfIsrS7h3lox5p/QijmBdwdchvc4a8EETr+0XSe/+E7p11RoWVBzd\n"
"LmUoAcM4yU/S5ro/WJ6+iyk1y3og0+TJ50Cx0Tk8Khpj7AdhL5GVAoGBANB9q45T\n"
"YwPsyCVAVvMxFxk2QboBhLh5sYbTbqsT/JMSowav/09vpL6+ZGvSz1DoD5NVusgw\n"
"LAgUt0ZczqCE8xRdl3RmfxRDeElgBQE2fXYIcNiKIpJNcr9bLfDusu3myAYiPWEH\n"
"xv68zmtMTdmlmB9dkkWIMMome0YsWDhWCo2LAoGAFFuKorICF5jr0kjsOKRSZtyc\n"
"g8WQVqy6BbPUv9306gWYmDWfyzZLqAPsJhiTwg9oz4a6iJVlTJk6C9UM/rIJA4UK\n"
"RM8PtKwK61JhVWhjrcjXRbvDtDvgaIgu5OohhTst7IW0VOjzvR1YHGcx8dxtP5cR\n"
"UkZwvvJtpdGzpE0pDiUCgYEAj/pZIN6BAFLiHKeD5EnAU87eMN+fke2oJR2ZzVbu\n"
"E3rJTnL38xl8QaUloDhiptK6/tozNM/feG0l69dncf6eBzBiySWHGK1HQhSnICFL\n"
"HtnRZBhwq2wElBUZcsrEkfnPpDy8+mbuizhDrGFzWZw7o11xB8d3OgK9GsbA3Za9\n"
"juUCgYA5t2LtfTEMye2YJs6IHb8cD3LlUAN8RO6Wju63PtDUfjuiBc9z8XcDkaBa\n"
"GCW5y6oKfchFUo6IN8VMY8LjsRX6rXsfvc8MPi6f0Z+CLL1/AqM27Wdn6SvhEy89\n"
"5q5blS0A+fTdcHPCGle5YROBWSEF5hbwl2E9AEkq8E4MbVPF+g==\n"
"-END RSA PRIVATE KEY-";
int main( int, char ** )
/**/
{
OpenSSL_add_all_algorithms();
RAND_poll();
SSL_load_error_strings();
BIO *bio = BIO_new_mem_buf( (void*)PUBLIC_KEY, (int)strlen(PUBLIC_KEY) );
char * name = NULL;
char * header2 = NULL;
unsigned char * data = NULL;
longlen;
RSA *rsa;
EVP_PKEY *key;
size_t keylen;
int rsa_pad;
char *input;
size_t input_len;
char * output;
size_t output_len;
char *decrypted;
int rc = PEM_read_bio( bio, , , , );
if( rc != 1 ) {
fprintf( stderr, "PEM_read_bio returned %d\n", rc );
return 1;
}
BIO_free( bio );
bio = BIO_new_mem_buf( (void*)data, (int)len );
rsa = d2i_RSAPublicKey_bio( bio, NULL );
if( rsa == NULL ) {
fprintf( stderr, "d2i_RSAPublicKey_bio failed\n" );
return 1;
}
key = EVP_PKEY_new();
EVP_PKEY_assign_RSA( key, rsa );
BIO_free( bio );
keylen = EVP_PKEY_size( key );
rsa_pad = RSA_PKCS1_PADDING;
input = new char[keylen-11];
input_len = keylen-11;
memset( input, 'a', keylen-11 );
output = new char[keylen];
output_len =
[openssl-users] Cannot initialize FIPS library in 1.0.2j but 1.0.2i is OK
I'm seeing a problem where my application cannot initialize the FIPS library (i.e. the call to FIPS_mode_set fails) when using 1.0.2j libraries. The error I get is: "FIPS_check_incore_fingerprint:fingerprint does not match:fips.c:232:" However if I build 1.0.2i libraries, everything is fine. I am using the same script to build both versions, and completely wiping the directories and re-creating from the .tar.gz files each time. The weirdest thing is that if I build my application for 1.0.2i but replace 1.0.2i with the 1.0.2j code (just modifying the version number in the header files), everything works. If I build it for 1.0.2j but actually use 1.0.2i (again just changing the version number), it fails. This is on 64-bit Linux. Other platforms (32-bit and 64-bit Windows, 32-bit Linux, Solaris, HP) are all working fine. This seems to be a problem with *my* code but I have no idea how I could possibly cause this to happen. Any ideas? Graeme -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Building FIPS-capable OpenSSL on Linux PPC64
I am trying to build FIPS OpenSSL libraries for Linux PPC64 but it does not seem possible. This has been raised before (link below) but I didn't see any resolution. http://openssl.6102.n7.nabble.com/BUG-FIPS-capable-OpenSSL-fails-to-build-on-Linux-PPC64-td66890.html I can build it if I run "./Configure linux-ppc64" but it is my understanding that you **must** build the FIPS libraries using "./config" or "./config no-asm". Is there a workaround? Is there a fix coming? Given that the problem is within the FIPS module, is a fix possible without recertification? Thanks Graeme Perrow -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Can RSA_private_decrypt succeed with the wrong padding?
Excellent, this is exactly the kind of information I was looking for. Thanks very much Viktor for your help Graeme -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Viktor Dukhovni Sent: Wednesday, April 29, 2015 1:34 PM To: openssl-users@openssl.org Subject: Re: [openssl-users] Can RSA_private_decrypt succeed with the wrong padding? On Wed, Apr 29, 2015 at 03:42:40PM +, Perrow, Graeme wrote: Apologies for the top-post; Outlook makes it hard to do anything else. Here is a small C++ reproducible. I am generating a key pair, encrypting a small string using OAEP and decrypting using PKCS1 and expecting the decryption to fail. If I run this (on 64-bit Red Hat 6) repeatedly, the program will eventually fail because RSA_private_decrypt doesn't fail. I can run it hundreds of times successfully before it fails. I have also seen it fail on Windows 7. Originally, you said the decryption used RSA_NO_PADDING, the code below decrypts with RSA_PKCS1_PADDING. int output_pad = RSA_PKCS1_PADDING; memset( decrypted, 0, sizeof(decrypted) ); size_t dec_len = RSA_private_decrypt( (int)enc_len, encrypted, decrypted, rsa_key, output_pad ); If you generate enough OAEP samples, some of them will look like PKCS1 padding. Padding is *NOT* integrity protection. Per: https://tools.ietf.org/html/rfc2313#section-8.1 an input block that resembles PKCS1 padding for encryption with a public key looks like: 00 02 pseudo-random-non-zero* 00 data So, all you need is for the first two octets to be 00 02 (a 00 has an ~40% chance to follow somewhere in a sample of ~126 random octets). So this will happen from time to time (somewhat south of once every 64k tries). Encryption and decryption alone do not provide integrity protection. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Can RSA_private_decrypt succeed with the wrong padding?
Apologies for the top-post; Outlook makes it hard to do anything else.
Here is a small C++ reproducible. I am generating a key pair, encrypting a
small string using OAEP and decrypting using PKCS1 and expecting the decryption
to fail.
If I run this (on 64-bit Red Hat 6) repeatedly, the program will eventually
fail because RSA_private_decrypt doesn't fail. I can run it hundreds of times
successfully before it fails. I have also seen it fail on Windows 7.
Graeme
#include string.h
#include openssl/rsa.h
int main( int, char ** )
/**/
{
BIGNUM *exponent = BN_new();
RSA *rsa_key = RSA_new();
BN_set_word( exponent, RSA_F4 );
int rc = RSA_generate_key_ex( rsa_key, 1024, exponent, NULL );
if( rc == 0 ) {
printf( RSA key generation failed\n );
return 1;
}
int input_pad = RSA_PKCS1_OAEP_PADDING;
const char *input = abcd;
size_t input_len = strlen( input );
unsigned char encrypted[1000];
unsigned char decrypted[1000];
size_t enc_len = RSA_public_encrypt( (int)input_len,
(const unsigned char *)input,
encrypted, rsa_key, input_pad );
int output_pad = RSA_PKCS1_PADDING;
memset( decrypted, 0, sizeof(decrypted) );
size_t dec_len = RSA_private_decrypt( (int)enc_len, encrypted, decrypted,
rsa_key, output_pad );
if( dec_len == -1 ) {
return 0; // expected outcome
}
printf( RSA_private_decrypt succeeded, len=%ld bytes\n, dec_len );
return 1;
}
-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
Viktor Dukhovni
Sent: Saturday, April 25, 2015 1:41 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Can RSA_private_decrypt succeed with the wrong
padding?
On Sat, Apr 25, 2015 at 12:49:21AM +, Perrow, Graeme wrote:
Using OpenSSL 1.0.1m on 64-bit Windows and Linux.
I have implemented RSA encryption using the RSA_public_encrypt and
RSA_private_decrypt functions and various padding types. This is working
fine except that in very rare cases, my test fails because decrypting
succeeds when it should fail. I'm basically doing this (pseudocode):
RSA_public_encrypt( abc, encrypted_data, my_public_key,
RSA_PKCS1_OAEP_PADDING );
RSA_private_decrypt( encrypted_data, decrypted_data, my_private_key,
RSA_NO_PADDING );
A real code fragment would be substantially more useful that
pseudo-code here. This should *always* succeed, provided you
pass the correct length to RSA_private_decrypt. From the manpage:
flen must be ... and exactly RSA_size(rsa) for RSA_NO_PADDING.
Note that the padding types are different. The vast majority of the time,
I get an error from the RSA_private_decrypt call but now and again, it
succeeds.
You're doing something wrong, it should always recover the OAEP
padded data, which is basically random, you need to reverse the
OAEP padding to recover the plaintext.
I don't understand the underlying crypto well enough to know - is it
possible for RSA_private_decrypt to be unable to tell that the wrong
padding was used, or is this a bug in OpenSSL?
When not using padding, that's not wrong padding, you're just
doing a raw RSA decrypt, and any input that is smaller than the
modulus (but has the same bit length) should decrypt to something.
--
Viktor.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Can RSA_private_decrypt succeed with the wrong padding?
Using OpenSSL 1.0.1m on 64-bit Windows and Linux. I have implemented RSA encryption using the RSA_public_encrypt and RSA_private_decrypt functions and various padding types. This is working fine except that in very rare cases, my test fails because decrypting succeeds when it should fail. I'm basically doing this (pseudocode): RSA_public_encrypt( abc, encrypted_data, my_public_key, RSA_PKCS1_OAEP_PADDING ); RSA_private_decrypt( encrypted_data, decrypted_data, my_private_key, RSA_NO_PADDING ); Note that the padding types are different. The vast majority of the time, I get an error from the RSA_private_decrypt call but now and again, it succeeds. The output data is NOT abc however, it's seemingly random data. I've seen varying lengths for the output data as well, from 11 bytes to 115. I don't understand the underlying crypto well enough to know - is it possible for RSA_private_decrypt to be unable to tell that the wrong padding was used, or is this a bug in OpenSSL? Thanks Graeme Perrow ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Build failure in 1.0.1k on Windows
I just downloaded 1.0.1k and when trying to build it on Windows (using Visual
Studio 10.0), I get a compile error:
.\crypto\cversion.c(80) : error C2065: 'cflags' : undeclared identifier
.\crypto\cversion.c(80) : warning C4047: 'return' : 'const char *' differs in
levels of indirection from 'int'
The problem is this block in cversion.c:
if (t == SSLEAY_CFLAGS)
{
#ifdef CFLAGS
return(cflags);
#else
return(compiler: information not available);
#endif
}
There is no cflags variable anywhere. I suspect this should be return
(CFLAGS);, and making this change to the source does make the compile succeed.
I'm not sure how it compiles as-is on Linux but it does.
Graeme Perrow
___
openssl-users mailing list
openssl-users@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Building a DLL that includes the FIPS static libraries
I am trying to build a Windows DLL that includes the static OpenSSL FIPS libraries. I built the FIPS libraries using the perl Configure fips --with-fipslibdir=... -no-shared and then nmake -f ms\nt.mak. I'm using openssl-fips-2.0.5, openssl-1.0.1j, and MS Visual Studio 2010. Now I'm trying to link the resulting libraries into my DLL. I've followed the instructions in the FIPS 2.0 User's Guide, setting a bunch of environment variables (FIPS_LINK, FIPS_CC, FIPS_CC_ARGS, etc.) and then called fipslink.pl. But I'm getting a First stage Link failure. It reports Integrity check OK and then compiles fips_premain.c, but when linking the DLL I get a bunch of locally defined symbol _time64 imported warnings (as well as strncmp, _errno, abort, fprintf, and others), and then some unresolved external symbols including: __imp_strncpy __imp_qsort __imp_wcsstr __imp_vsnwprintf All of the errors come from libeayfips32.lib, libeaycompat32.lib, and ssleay32.lib. I've played around with /NODEFAULTLIB:msvcrt and /NODEFAULTLIB:libcmtd, and building with /MT or /MD or neither, but I keep getting linker errors each time. What am I missing? Thanks Graeme Perrow ___ openssl-users mailing list openssl-users@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
32-bit Windows rebasing of OpenSSL FIPS library
I am having trouble loading the OpenSSL FIPS DLLs (2.0.5, using OpenSSL 1.0.1e) in my 32-bit Windows application. Most of the time I get a fingerprint does not match error from FIPS_mode_set but now and again, with no code changes, it succeeds. I have a feeling it has to do with rebasing and where the DLL is loaded into memory. Running dumpbin on libeay32.dll shows an image base of FB0 which I believe is correct. My application executable loads a DLL which loads a second DLL, and that second DLL is the one that loads the FIPS DLLs. My DLLs are built with /FIXED:NO and /BASE: with a specific address. I have made no changes to the OpenSSL build procedure. My problem is that I don't understand rebasing well enough to know if I need to build my DLLs differently, or if I need to tweak the OpenSSL build procedure. I was seeing a similar problem on 64-bit Windows for a while but that error just magically went away and I haven't seen it since. I'm worried that the 64-bit problem is still there and I'm just getting lucky. Thanks for any pointers Graeme Perrow
OPENSSL_Uplink: no OPENSSL_Applink
On 32-bit Windows, I am seeing this error when trying to determine why the
FIPS_mode_set(1) call is failing. I am building the OpenSSL FIPS module
(OpenSSL 1.0.1e, OpenSSL FIPS 2.0.5), and I want to load it from another DLL
which is itself loaded from an application. The application knows nothing about
OpenSSL, only the DLL does.
I have seen the page http://www.openssl.org/support/faq.html#PROG2 describing
what needs to be done. I have tried linking applink.c into my DLL, and I've
tried #include'ing it from an existing source file in the DLL. In both cases, I
get the no OPENSSL_Applink message. The code I'm executing looks like:
if( !FIPS_mode_set(1) ) {
ERR_load_crypto_strings();
FILE *f = fopen( D:\\openssl.txt, w );
ERR_print_errors_fp( f );
fclose( f );
}
I get the no OPENSSL_Applink message in the ERR_print_errors_fp() call.
Adding a call to CRYPTO_malloc_init above this changes nothing. I am not seeing
this problem on 64-bit Windows, possibly because the FIPS_mode_set(1) call
succeeds there.
What am I missing? I need to solve this problem so I can solve the original
problem of why the FIPS_mode_set(1) call fails. Alternatively, if you can help
me solve that problem, I may not need to solve this one. :-)
Graeme Perrow
OpenSSL FIPS library fingerprint doesn't match
I am building a DLL that includes the OpenSSL FIPS object module. This is on Windows using Visual Studio 10.0. I have the 64-bit version working fine but when I build a 32-bit version, the incore fingerprint fails to match when I load the DLL and call FIPS_mode_set(1). I had the same problem with the 64-bit version at one point but then it seemed to just fix itself and I never saw the problem again. While debugging the code, I found that when linking the DLL, the .text and .rodata values are: .text:5CC1B000+302160=5CC64C50 .rodata:5CCDA134+46364=5CCE5650 But when we load the DLL, the values are: .text:5C85B000+302160=5C8A4C50 .rodata:5C91A134+46364=5C925650 (Not always exactly this, but they never match the numbers above. The sizes are always correct.) We're calculating the signature on a different chunk of memory so obviously they will not match. The question is why are the pointers different? Graeme Perrow
RE: Using MD5 certificates in OpenSSL FIPS
If I do openssl x509 -in mycert.crt -text I see Signature Algorithm: sha1WithRSAEncryption. There's no mention of MD5 here but since OpenSSL is attempting to load it, I assume it's using the MD5-SHA1 combination. If that *is* permitted, why am I getting the disabled for FIPS error? Graeme -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Friday, July 26, 2013 7:39 AM To: openssl-users@openssl.org Subject: Re: Using MD5 certificates in OpenSSL FIPS On Fri, Jul 26, 2013, Carl Young wrote: As far as I remember, the use of MD5 is only allowed in TLS 1 for the specific use within the PRF for key generation as the __combination__ of SHA-1 and MD5 is not considered weak usage. Use of MD5 elsewhere is still disallowed. It is also permitted with the MD5+SHA1 combined RSA signature again because the combination is not considered weak. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Using MD5 certificates in OpenSSL FIPS
I am using OpenSSL FIPS module 2.0.5 with OpenSSL 1.0.1e on Windows. After calling FIPS_mode_set(1), I cannot call SSL_CTX_use_RSAPrivateKey_file. When I debug into it, it is failing when trying to initialize MD5. Apparently the private key is encrypted with MD5. I was under the impression that MD5 was not allowed in FIPS mode **unless** it's being used with TLS, which is what I'm doing. Am I wrong, or is there something else I have to do to allow MD5 in this case? Thank you Graeme Perrow __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL FIPS library POST fails
I am trying to build a DLL that includes the OpenSSL FIPS Object Module, and then load that DLL from my application. This is on Windows 7 64-bit using Microsoft Visual Studio v10. The DLL is built successfully and my application can load it, but when I call the FIPS_mode_set(1) function, the self-test fails. Here is how I'm building everything: cd openssl-fips-2.0.5 C:\Program Files (x86)\Microsoft Visual Studio 10.0\vc\bin\amd64\vcvars64.bat ms\do_fips.bat cd ..\openssl-1.0.1e perl Configure VC-WIN64A fips --with-fipslibdir ..\openssl-fips-2.0.5 ms\do_win64a.bat nmake -f ms\nt.mak Then when building my DLL, I'm including the ssleay32.lib, libeayfips32.lib, and libeaycompat32.lib files from the openssl-1.0.1e\out32 directory and running the following batch file instead of link.exe: call C:\Program Files (x86)\Microsoft Visual Studio 10.0\vc\bin\amd64\vcvars64.bat set FIPS_LINK=link set FIPS_CC=cl set FIPS_CC_ARGS=/Foobj\fips_premain.obj -MD -c set PREMAIN_DSO_EXE=openssl-1.0.1e\out32\fips_premain_dso.exe set FIPS_TARGET=mydll.dll set FIPS_SHA1_EXE=openssl-fips-2.0.5\out32dll\fips_standalone_sha1.exe set FIPSLIB_D=openssl-fips-2.0.5\out32dll perl openssl-fips-2.0.5\util\fipslink.pl /map /out:mydll.dll obj\fips_premain.obj @mydll.lnk Where mydll.lnk contains all the standard link directives we usually use. This succeeds, and I end up with a DLL that is functional. In fact, if I don't call FIPS_mode_set (1), I can make TLS connections to remote servers and such. But FIPS_mode_set(1) always fails. When I debug into it, the FIPS_selftest() routine fails because in FIPS_check_incore_fingerprint, the FIPS_incore_fingerprint call returns a different signature than the one used during the build procedure. What's the best way to determine why this is failing? Is there something missing from my build procedure, or some other gotcha I should be looking for? Thanks for any help. Graeme Perrow
