[openssl-users] no shared cipher issue with freeradius
Hi All, My client is a windows XP and Freeradius version is 3.0.15 and openssl version is [OpenSSL 1.0.1t 3 May 2016 (Library: OpenSSL 1.0.2k 26 Jan 2017)] The client sends these cipher suites to the server in auth request Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009) Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064) Cipher Suite: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x0062) Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003) Cipher Suite: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012) Cipher Suite: TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA (0x0063) but I get a no shared cipher error and handshake fails. My understanding is quite limited on this issue but I've tried to set cipher_list = "DEFAULT" and "ALL:!EXPORT:!eNULL:!SSLv2" in eap.conf but nothing seems to work, I get the same no cipher issue. Assuming FreeRadius gets its ciphers from Openssl, is there a way I can make openssl to include the above keys in its cipher list? I tried to update these ciphers on the client but I couldn't find anything on google. I would appreciate if anyone can help in this regard. Many Thanks Ali -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1 certificate verification fails with non-standard public key algorithm
> On Jul 25, 2018, at 4:50 PM, Ken Goldman wrote: > > For background, this is the TPM 1.2 endorsement key certificate. I.e., this > is a real application with millions of certificates issued. The key is an > RSA-2048 key. > > The TCG (for a while) specified > > Public Key Algorithm: rsaesOaep > > rather than the commonly used > > Public Key Algorithm: rsaEncryption > > because the key is an encryption key rather than a signing key. > The X509 certificate parser fails to get the public key. > > > > An alternative fix (I got a patch for 098 from an openssl maintainer) > that accepts rsaOaep would also fix the issue. Or perhaps both. It is not clear that my choice of rejecting unsupported key algorithms at security level 0 is the right one, but it would of course be best if the key algorithm were supported if it has non-negligible "legitimate" use. Perhaps open an issue (or PR) on github proposing (or implementing) a change to the check_key_level() logic and see whether there is support for it? -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1 certificate verification fails with non-standard public key algorithm
On 7/25/2018 4:27 PM, Viktor Dukhovni wrote: Yes, that's what I'm saying, but also asking the broader list for feedback on such a change. Should security level zero succeed even with unsupported EE keys (which somehow get used with some other software???). For background, this is the TPM 1.2 endorsement key certificate. I.e., this is a real application with millions of certificates issued. The key is an RSA-2048 key. The TCG (for a while) specified Public Key Algorithm: rsaesOaep rather than the commonly used Public Key Algorithm: rsaEncryption because the key is an encryption key rather than a signing key. The X509 certificate parser fails to get the public key. An alternative fix (I got a patch for 098 from an openssl maintainer) that accepts rsaOaep would also fix the issue. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1 certificate verification fails with non-standard public key algorithm
> On Jul 25, 2018, at 3:00 PM, Ken Goldman wrote: > > > If you're suggesting that altering the above code to do the level check > before the call to get pkey, I think that would fix my problem. Yes, that's what I'm saying, but also asking the broader list for feedback on such a change. Should security level zero succeed even with unsupported EE keys (which somehow get used with some other software???). > ... if I can set level to a negative value. How do I set level? Is there an > API or a configuration file. It does not need to be negative, the test is "<= 0", but the default is in fact -1 (not set). There is indeed a function for setting a non-default security level: X509_VERIFY_PARAM_set_auth_level() and it is documented. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] conversion of RAND_bytes to rand in fips apporved way
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of William Roberts
> Sent: Wednesday, July 25, 2018 13:00
>
> >unsigned char bytes[2];
> >RAND_bytes(bytes, 2);
> >return (bytes[0] | (bytes[1] << 8)) & 0x7fff;
>
> You can ditch the shift logic. Offhand, i'm not sure what would
> happen on Big Endian machine, would it leave bit 15 high since it's in
> byte 0?
No. Bitwise operators in C work according to value, not representation,
regardless of the byte order of multibyte integer types in that implementation.
> int openssl_rand(void) {
> uint16_t x;
> RAND_bytes((unsigned char *), sizeof(x));
> return x & 0x7FFF;
> }
That's OK if you include stdint.h, because you don't care which of the two
permissible representations uint15_t has (it has to be pure-binary with no trap
representations) - IF your implementation has a 16-bit unsigned integer type.
uint16_t won't be defined for an implementation that doesn't. Offhand I don't
know of one that is CHAR_BIT 8, though.
Personally, I don't care for your version, because I don't like to see code
manipulate the representation of an object without specific reason. My version
follows the same pattern that correctly-written integer-marshaling code should
use, for example; it has the same behavior regardless of implementation details
(assuming, once again, that CHAR_BIT is 8).
By the way, sizeof is an operator. There's no need to parenthesize its operand,
unless the operand is a type.
Of course, as Viktor pointed out, this all may be pointless anyway; it's not
clear that the OP needs this functionality.
--
Michael Wojcik
Distinguished Engineer, Micro Focus
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] openssl 1.1 certificate verification fails with non-standard public key algorithm
On 7/25/2018 10:47 AM, Viktor Dukhovni wrote:
On Jul 25, 2018, at 10:05 AM, Ken Goldman wrote:
I have a certificate with a non-standard public key algorithm -rsaesOaep. See
snippet #2.
With openssl 1.0, I can validate the certificate chain. With openssl 1.1 it
fails with the error X509_V_ERR_EE_KEY_TOO_SMALL. See dump #1.
I believe that this is due to new 1.1 code x509_vfy.c:check_key_level() calling
X509_get0_pubkey(). That call will fail for the non-standard algorithm.
The certificate is for old vendor hardware that cannot be updated. What are my
choices?
- Remain on 1.0
- Some configuration option?
- Something else?
The immediate cause is the order of the checks in check_key_level().
It first checks for a supported key, and only then short-circuits
the logic at level <= 0 (my fault). Perhaps level 0 should not be
strict in this way, in which case we might reverse the order of
then (pkey == NULL) and (level <= 0) tests:
static int check_key_level(X509_STORE_CTX *ctx, X509 *cert)
{
EVP_PKEY *pkey = X509_get0_pubkey(cert);
int level = ctx->param->auth_level;
/* Unsupported or malformed keys are not secure */
if (pkey == NULL)
return 0;
if (level <= 0)
return 1;
if (level > NUM_AUTH_LEVELS)
level = NUM_AUTH_LEVELS;
return EVP_PKEY_security_bits(pkey) >= minbits_table[level - 1];
}
If you're suggesting that altering the above code to do the level check
before the call to get pkey, I think that would fix my problem.
... if I can set level to a negative value. How do I set level? Is
there an API or a configuration file.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] conversion of RAND_bytes to rand in fips apporved way
On Wed, Jul 25, 2018 at 11:30 AM, Michael Wojcik
wrote:
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
>> Sudarshan Soma
>> Sent: Wednesday, July 25, 2018 12:13
>
>> But rand() returns max value of 32767 . Is there a recomended way to
>> convert RAND_bytes to libc rand()
>> something like this?
>
>> unsigned char buf[2];
>> RAND_bytes(buf,2)
>> int *rndp = malloc(4);
>> memcpy(rndp,buf,2);
>> return (unsigned) ((*rndp) % 32768)
>
> Ugh. Memory leak, unnecessary malloc, undefined behavior (only part of the
> rdnp object is initialized)... I really hope you don't have code like this in
> your application.
>
> C guarantees unsigned integer types use a pure binary representation, and
> 32767 is 2**15 - 1. So assuming you're only using octet-based C
> implementations (limits.h defines CHAR_BIT as 8), which is very likely the
> case, just do this:
>
> unsigned int openssl_rand(void) {
LibC's rand() is int, so if it matters you'll want to match that
interface. But usually, you want to avoid signed numbers when negative
doesn't matter..
>unsigned char bytes[2];
>RAND_bytes(bytes, 2);
>return (bytes[0] | (bytes[1] << 8)) & 0x7fff;
You can ditch the shift logic. Offhand, i'm not sure what would
happen on Big Endian machine, would it leave bit 15 high since it's in
byte 0?
int openssl_rand(void) {
uint16_t x;
RAND_bytes((unsigned char *), sizeof(x));
return x & 0x7FFF;
}
> }
>
> Untested, but I think that will work on any conforming C implementation with
> CHAR_BIT == 8, and as long as the 15 least-significant bits of the output of
> RAND_bytes are unbiased, the result will be an unbiased value in [0,32767].
>
> Note this does not give you the semantics of C's rand, as it ignores any
> invocation of srand. Some C programs require a predictable rand; they use it
> for reproducible Monte Carlo test runs, for example. So replacing rand this
> way is not necessarily valid.
>
> Also, calling it "rand" would be a violation of the C specification, so if
> you want your C applications to conform to the spec, you'll have to change
> them anyway. Or use a macro, provided the application code never suppresses a
> macro definition for rand.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
> --
> 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] conversion of RAND_bytes to rand in fips apporved way
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Sudarshan Soma
> Sent: Wednesday, July 25, 2018 12:13
> But rand() returns max value of 32767 . Is there a recomended way to
> convert RAND_bytes to libc rand()
> something like this?
> unsigned char buf[2];
> RAND_bytes(buf,2)
> int *rndp = malloc(4);
> memcpy(rndp,buf,2);
> return (unsigned) ((*rndp) % 32768)
Ugh. Memory leak, unnecessary malloc, undefined behavior (only part of the rdnp
object is initialized)... I really hope you don't have code like this in your
application.
C guarantees unsigned integer types use a pure binary representation, and 32767
is 2**15 - 1. So assuming you're only using octet-based C implementations
(limits.h defines CHAR_BIT as 8), which is very likely the case, just do this:
unsigned int openssl_rand(void) {
unsigned char bytes[2];
RAND_bytes(bytes, 2);
return (bytes[0] | (bytes[1] << 8)) & 0x7fff;
}
Untested, but I think that will work on any conforming C implementation with
CHAR_BIT == 8, and as long as the 15 least-significant bits of the output of
RAND_bytes are unbiased, the result will be an unbiased value in [0,32767].
Note this does not give you the semantics of C's rand, as it ignores any
invocation of srand. Some C programs require a predictable rand; they use it
for reproducible Monte Carlo test runs, for example. So replacing rand this way
is not necessarily valid.
Also, calling it "rand" would be a violation of the C specification, so if you
want your C applications to conform to the spec, you'll have to change them
anyway. Or use a macro, provided the application code never suppresses a macro
definition for rand.
--
Michael Wojcik
Distinguished Engineer, Micro Focus
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] conversion of RAND_bytes to rand in fips apporved way
On Wed, Jul 25, 2018 at 11:42:34PM +0530, Sudarshan Soma wrote: > Now few applications are using libc rand function. For FIPS compliance, > applications have to call approved SP 800-90A DRBG implementation. If you're using libc's rand() for non-cryptographic purposes, you can surely continue to do that. > I was planning to replace libc rand with RAND_bytes for the same. > > But rand() returns max value of 32767. Is there a recomended way to > convert RAND_bytes to libc rand() something like this? Since 16-bit random numbers do not provide any meaningful security, it makes little sense to use a CSPRNG in a context where 16-bit random values are sufficient. > Please suggest. Is there a way to give number of bits instead of bytes to > RAND_bytes? This is probably the wrong question. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] conversion of RAND_bytes to rand in fips apporved way
If RAND_MAX is a power of 2, then just ask RAND_bytes for the right number of bytes (four for 32768) and use bit-shifting to pack the value. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] conversion of RAND_bytes to rand in fips apporved way
Hi, we have linked FIPS compliant openssl version against our applications. Now few applications are using libc rand function. For FIPS compliance, applications have to call approved SP 800-90A DRBG implementation. I was planning to replace libc rand with RAND_bytes for the same. But rand() returns max value of 32767 . Is there a recomended way to convert RAND_bytes to libc rand() something like this? unsigned char buf[2]; RAND_bytes(buf,2) int *rndp = malloc(4); memcpy(rndp,buf,2); return (unsigned) ((*rndp) % 32768) Please suggest . Is there a way to give number of bits instead of bytes to RAND_bytes? Regards, -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Using a TPM to sign CSRs
On 25/07/18 20:58, William Roberts wrote: On Tue, Jul 24, 2018 at 4:18 AM, Kaarthik Sivakumar wrote: Hello I need to create a key pair using a TPM (proprietary) and build a CSR and What TPM Version? If it's TPM 2.0, a new Engine project has emerged here: https://github.com/tpm2-software/tpm2-tss-engine Yep 2.0. This might be able to handle to just calling the create CSR routine. I know back-in- the-day the OpenSC engine with a PIV card could do it. You can try to get ahold of the maintainer of that project (Andraes) through a direct email or the project mailing list: - https://lists.01.org/mailman/listinfo/tpm2 Ok, thanks for the info. -kaarthik- sign it using it the TPM as well. Currently I dont have an engine interface to talk to the TPM. I do the following: 1. generate key pair in the TPM. private key is kept private in the TPM and public key can be obtained out of the TPM 2. use the public key to generate a CSR (X509_REQ_init(), etc) 3. Get the hash of the CSR (X509_REQ_digest()) 4. Pass the digest to the TPM and get back signature 5. Add signature to the CSR - I dont see any way to do this. Is there an openssl API to perform this step? I dont think I can use X509_REQ_sign() since that will use the private key provided or if I have an engine interface then it will call the engine to do the signing. Is there a way to call sign() and make it call my function that can do the step 4 above? Thanks! -kaarthik- -- 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] Using a TPM to sign CSRs
On Tue, Jul 24, 2018 at 4:18 AM, Kaarthik Sivakumar wrote: > Hello > > I need to create a key pair using a TPM (proprietary) and build a CSR and What TPM Version? If it's TPM 2.0, a new Engine project has emerged here: https://github.com/tpm2-software/tpm2-tss-engine This might be able to handle to just calling the create CSR routine. I know back-in- the-day the OpenSC engine with a PIV card could do it. You can try to get ahold of the maintainer of that project (Andraes) through a direct email or the project mailing list: - https://lists.01.org/mailman/listinfo/tpm2 > sign it using it the TPM as well. Currently I dont have an engine interface > to talk to the TPM. I do the following: > > 1. generate key pair in the TPM. private key is kept private in the TPM and > public key can be obtained out of the TPM > > 2. use the public key to generate a CSR (X509_REQ_init(), etc) > > 3. Get the hash of the CSR (X509_REQ_digest()) > > 4. Pass the digest to the TPM and get back signature > > 5. Add signature to the CSR - I dont see any way to do this. Is there an > openssl API to perform this step? I dont think I can use X509_REQ_sign() > since that will use the private key provided or if I have an engine > interface then it will call the engine to do the signing. Is there a way to > call sign() and make it call my function that can do the step 4 above? > > Thanks! > > > -kaarthik- > > > -- > 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] openssl 1.1 certificate verification fails with non-standard public key algorithm
> On Jul 25, 2018, at 10:05 AM, Ken Goldman wrote:
>
> I have a certificate with a non-standard public key algorithm -rsaesOaep.
> See snippet #2.
>
> With openssl 1.0, I can validate the certificate chain. With openssl 1.1 it
> fails with the error X509_V_ERR_EE_KEY_TOO_SMALL. See dump #1.
>
> I believe that this is due to new 1.1 code x509_vfy.c:check_key_level()
> calling X509_get0_pubkey(). That call will fail for the non-standard
> algorithm.
>
> The certificate is for old vendor hardware that cannot be updated. What are
> my choices?
>
> - Remain on 1.0
> - Some configuration option?
> - Something else?
The immediate cause is the order of the checks in check_key_level().
It first checks for a supported key, and only then short-circuits
the logic at level <= 0 (my fault). Perhaps level 0 should not be
strict in this way, in which case we might reverse the order of
then (pkey == NULL) and (level <= 0) tests:
static int check_key_level(X509_STORE_CTX *ctx, X509 *cert)
{
EVP_PKEY *pkey = X509_get0_pubkey(cert);
int level = ctx->param->auth_level;
/* Unsupported or malformed keys are not secure */
if (pkey == NULL)
return 0;
if (level <= 0)
return 1;
if (level > NUM_AUTH_LEVELS)
level = NUM_AUTH_LEVELS;
return EVP_PKEY_security_bits(pkey) >= minbits_table[level - 1];
}
--
Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] openssl 1.1 certificate verification fails with non-standard public key algorithm
Seeking advice. I have a certificate with a non-standard public key algorithm -rsaesOaep. See snippet #2. With openssl 1.0, I can validate the certificate chain. With openssl 1.1 it fails with the error X509_V_ERR_EE_KEY_TOO_SMALL. See dump #1. I believe that this is due to new 1.1 code x509_vfy.c:check_key_level() calling X509_get0_pubkey(). That call will fail for the non-standard algorithm. The certificate is for old vendor hardware that cannot be updated. What are my choices? - Remain on 1.0 - Some configuration option? - Something else? #1 ~ openssl verify -CAfile cafile.pem infcert.pem error 66 at 0 depth lookup: EE certificate key too weak error infcert.pem: verification failed 22794983405376:error:0609E09C:digital envelope routines:pkey_set_type:unsupported algorithm:crypto/evp/p_lib.c:206: 22794983405376:error:0B09406F:x509 certificate routines:x509_pubkey_decode:unsupported algorithm:crypto/x509/x_pubkey.c:113: #2 ~ Subject: Subject Public Key Info: Public Key Algorithm: rsaesOaep Unable to load Public Key 140619228055400:error:0609E09C:digital envelope routines:PKEY_SET_TYPE:unsupported algorithm:p_lib.c:239: 140619228055400:error:0B07706F:x509 certificate routines:X509_PUBKEY_get:unsupported algorithm:x_pubkey.c:155: X509v3 extensions: -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
