"openssl(1.0.2k) s_client -connect data.reversinglabs.com:443 -tls1_2" gives error: SSL3_GET_RECORD"wrong version number:s3_pkt.c:365
I run into the following issue when I use openssl 1.0.2k (amazon linux2) to check the connection. [ec2-user@ip-172-31-29-28 ~]$ openssl s_client -connect data.reversinglabs.com:443 -tls1_2 CONNECTED(0003) 139994515941280:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:365: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 5 bytes and written 0 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None Start Time: 1652817101 Timeout : 7200 (sec) Verify return code: 0 (ok) --- [ec2-user@ip-172-31-29-28 ~]$ openssl version OpenSSL 1.0.2k-fips 26 Jan 2017 If I use brew install the latest openssl (3.0.*), then the same command works. As our production is still using openssl 1.0.2k, my question is what causes this error and whether this is really an issue. Thanks.
Re: AES and EVP_CIPHER question
> On May 17, 2022, at 4:32 AM, Matt Caswell wrote:
>
>
>
> On 16/05/2022 23:48, Philip Prindeville wrote:
>> Sorry, I shouldn't have phrased that inartfully.
>> There is no EVP_CIPHER_CTX_get_padding(), so how does one achieve something
>> analogous?
>
>
> From 3.0, assuming you are using provided ciphers (i.e. not engine ones),
> then OSSL_CIPHER_PARAM_PADDING is a "gettable" parameter. See the section
> "Gettable and Settable EVP_CIPHER_CTX parameters" on this page:
>
> https://www.openssl.org/docs/man3.0/man3/EVP_EncryptInit_ex2.html
>
> So you can use EVP_CIPHER_CTX_get_params() to obtain that value (documented
> on the same man page as above). E.g. something like:
>
> OSSL_PARAM params[2], *p = params;
> unsigned int pad;
>
> *p++ = OSSL_PARAM_construct_uint(OSSL_CIPHER_PARAM_PADDING,
> );
> *p = OSSL_PARAM_construct_end();
>
> if (!EVP_CIPHER_CTX_get_params(ctx, params)) {
>/* Error */
> }
>
> Matt
Thanks, and for 1.1.x?
Re: Why does 'SSL_export_keying_material' return a different value than whats printed to the NSS keylog file?
On Tuesday, 17 May 2022 02:33:29 CEST, Ian Spence via openssl-users wrote:
I am trying to wrap my head around the keying material I can access
within my TLS client application using OpenSSL 3.0.3
I have `SSL_CTX_set_keylog_callback` set to just printf() the lines.
I also have the following code to extract the client random:
unsigned char * keymat = malloc(48);
const char * label = "CLIENT_RANDOM";
SSL_export_keying_material(ssl, keymat, 48, label,
strnlen(label), NULL, 0, 0);
printf("[EXPORT] %s: ", label.UTF8String);
for (int i = 0; i < 48; i++) {
printf("%02x", keymat[i]);
}
printf("\n");
Looking in ssl_local.h I found definitions for the various labels.
I've omitted the code from this email for brevity sake, but I print
out the value for each of the labels.
What I don't understand is why I'm getting different values from the
two. When connecting to a TLS1.3 server I see the following:
[NSS_KEYLOG] SERVER_HANDSHAKE_TRAFFIC_SECRET
f60a59b1ca9629281d4ee45b9966f19277de0652fb12513d71d388d9a8545077
882c1c081f9fe2708cee4067956717caf1936e60511d8d01b2e63541378e44671903e15c5a4b5b7fb3208452d71681e3
[NSS_KEYLOG] EXPORTER_SECRET
f60a59b1ca9629281d4ee45b9966f19277de0652fb12513d71d388d9a8545077
6333438b11e60e3ebd3a4795d7bd8400c08b878854e181ae2d084f95a264192e92ab108a2bd0cb284f7f82dd78a6b4eb
[NSS_KEYLOG] SERVER_TRAFFIC_SECRET_0
f60a59b1ca9629281d4ee45b9966f19277de0652fb12513d71d388d9a8545077
eabc8a14fc818707f03c2e0d7456011aa6aed025cfc43c25591aa7444ee6a045f643bc05b0daf9de9a1e863e7254681e
[NSS_KEYLOG] CLIENT_HANDSHAKE_TRAFFIC_SECRET
f60a59b1ca9629281d4ee45b9966f19277de0652fb12513d71d388d9a8545077
ef410252e24f3bc03d62218aa42d5f002d5a5bbf12d5f0f3e356ed2b56bc5e5151b26995f0dcb57564d2192fd2b6a1e8
[NSS_KEYLOG] CLIENT_TRAFFIC_SECRET_0
f60a59b1ca9629281d4ee45b9966f19277de0652fb12513d71d388d9a8545077
c88e7cc09e1c5b271aa5c722b527aa3a3f9744011c28cddce9a258be853dac6798aac67588bfbb57108cdbaae3c76130
[EXPORT] CLIENT_RANDOM:
a5ec0b54b796ef98bd1c8fad4f2459b657f6850d0b222a351444fd9deafa125d86991612cbec030e4ca2ee46eadb66ab
[EXPORT] CLIENT_EARLY_TRAFFIC_SECRET:
ae2cca098e941c88b574f068a52ea1cabbc2100a7b52afe3a1ba7981220111f348f5a0925092f619576649e3ddf15921
[EXPORT] CLIENT_HANDSHAKE_TRAFFIC_SECRET:
f916455fb08173176794188bb52bef126517248f04e6da47d6426a71c4e9b6a9d4381cfa89f4fcbf8a79de5183589725
[EXPORT] SERVER_HANDSHAKE_TRAFFIC_SECRET:
e6c60c26694e9d1eaaf97fd83f030dd3d9a0133231a2f803169d131f2238343dffd0a5328b561549cfc32cb30f7955c8
[EXPORT] CLIENT_TRAFFIC_SECRET_0:
e84885f1be1a25cd798768c2cf07d5593173ebe8ec6d2ed0959ff0332d6ad6a3ce6a38abe528db6be4a25500ad81cabe
[EXPORT] SERVER_TRAFFIC_SECRET_0:
643296314df063c06642faf895075afa2d8b9ec3922fcc94a46e69e1be628d09deb62c43fda18f2acdfe27d3b986f1dd
[EXPORT] EARLY_EXPORTER_SECRET:
c78b3e4ba7caca9318621f795100811cd6fbf4090f551e44bde0002e6ecdad78d211e9dc6a459fe44f305d35631c34bf
[EXPORT] EXPORTER_SECRET:
02fec8ac7a633d6b532e1ee0699a455f5a454cecbd684f9ed1c573cd820196a8a2a764726fa9236c168f356d776a5f60
Looking at the implementation of ssl_log_secret in ssl_lib.c I see
that the first parameter to the NSS log is the client random, but then
when I ask for CLIENT_RANDOM why do I get a different value?
I can reproduce this behaviour as well using the s_client: openssl
s_client ... -keymatexport "CLIENT_RANDOM" -keymatexportlen 48
-keylogfile keylog.txt
Keying material exporter is a way to implement channel binding:
https://datatracker.ietf.org/doc/html/rfc5705
not to extract the keys used for the connection.
The option to replicate the SSLKEYLOGFILE of NSS is the -keylogfile in
s_server.
Here's an example use:
https://github.com/openssl/openssl/blob/598bd7741568a1aae678e5472f18aae1ab991e8d/apps/lib/s_cb.c#L1517
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
Re: AES and EVP_CIPHER question
On 16/05/2022 23:48, Philip Prindeville wrote:
Sorry, I shouldn't have phrased that inartfully.
There is no EVP_CIPHER_CTX_get_padding(), so how does one achieve something
analogous?
From 3.0, assuming you are using provided ciphers (i.e. not engine
ones), then OSSL_CIPHER_PARAM_PADDING is a "gettable" parameter. See the
section "Gettable and Settable EVP_CIPHER_CTX parameters" on this page:
https://www.openssl.org/docs/man3.0/man3/EVP_EncryptInit_ex2.html
So you can use EVP_CIPHER_CTX_get_params() to obtain that value
(documented on the same man page as above). E.g. something like:
OSSL_PARAM params[2], *p = params;
unsigned int pad;
*p++ = OSSL_PARAM_construct_uint(OSSL_CIPHER_PARAM_PADDING,
);
*p = OSSL_PARAM_construct_end();
if (!EVP_CIPHER_CTX_get_params(ctx, params)) {
/* Error */
}
Matt
On May 16, 2022, at 1:00 PM, Philip Prindeville
wrote:
Thanks. That fixed the return value of EVP_CipherFinal().
Is there a reciprocal EVP_CIPHER_CTX_get_padding() method to find out what the
default padding method is for ECB?
On May 16, 2022, at 12:41 AM, Tomas Mraz wrote:
The EVP_CIPHER_CTX_set_padding(ctx, 0) must be called after the
EVP_CipherInit() to have an effect.
Also what is the AST_CRYPTO_AES_BLOCKSIZE value? Is it in bits (i.e,
128)?
Also res should be initialized to -1 so you do not return uninitialized
value on error.
Tomas Mraz
On Fri, 2022-05-13 at 09:49 -0600, Philip Prindeville wrote:
Hi,
I'm trying to rewrite some legacy AES_* code to use EVP_CIPHER_* so
it's forward compatible into 3.x.
My code, in a nutshell, looks like:
static int evp_cipher_aes_decrypt(const unsigned char *in, unsigned
char *out, unsigned inlen, const ast_aes_decrypt_key *key)
{
EVP_CIPHER_CTX *ctx;
int res, outlen, finallen;
unsigned char final[AST_CRYPTO_AES_BLOCKSIZE / 8];
if ((ctx = EVP_CIPHER_CTX_new()) == NULL) {
return -1;
}
EVP_CIPHER_CTX_set_padding(ctx, 0);
do {
if ((res = EVP_CipherInit(ctx, EVP_aes_128_ecb(),
key->raw, NULL, 0)) <= 0) {
break;
}
if ((res = EVP_CipherUpdate(ctx, out, , in,
inlen)) <= 0) {
break;
}
/* for ECB, this is a no-op */
if ((res = EVP_CipherFinal(ctx, final, )) <=
0) {
break;
}
res = outlen;
} while (0);
EVP_CIPHER_CTX_free(ctx);
return res;
}
It's ECB, so there's no IV. Or padding. The block size and key size
are both 128 bits.
One thing I noticed right away is that EVP_CipherUpdate() returns 1,
and sees "outlen" to zero.
And then EVP_CipherFinal() returns 0, and sets "finallen" to zero.
What's wrong with this code?
I'm trying to write "naive" code that counts on the primitives to
indicate how much resultant output is generated for the input I've
given (yes, I know that it's 1:1 in the case of ECB, but I shouldn't
have to hard-code that in case I want to use the same code with
multiple block modes).
The function is supposed to return <= 0 on error, otherwise the
number of bytes decrypted into "out" on success.
Thanks,
-Philip
--
Tomáš Mráz, OpenSSL
