Re: EVP_CIPHER_CTX_set_key_length and EVP_CIPHER_key_length
Yup, using the correct function helps :-) Thanks! - Reply message - From: Dr. Stephen Henson st...@openssl.org To: openssl-users@openssl.org Subject: EVP_CIPHER_CTX_set_key_length and EVP_CIPHER_key_length Date: Wed, Aug 29, 2012 1:37 am On Tue, Aug 28, 2012, la...@angry-red-pla.net wrote: Hi all I created a shared key based on a DH exchange and want to use that key with a symmetric encryption algorithm. This key has a length of 16 Bytes (128 bit). Here is what I do to initialize AES: char *key,*iv; // DH exchange which ends with a 16B value in key RAND_pseudo_bytes(iv,16); EVP_EncryptInit(enc_ctx,EVP_aes_128_cbc(),NULL,NULL); EVP_CIPHER_CTX_set_key_length(enc_ctx,16); EVP_EncryptInit(enc_ctx,NULL,skey,iv); None of the functions seems to generate an error. I checked that by calling ERR_print_errors_fp. However when I check the key length printf(key len: %d\n,EVP_CIPHER_key_length(enc_ctx)); It returns 1. Shouldn't it return 16? I guess I make a mistake when setting the key, but where? The cipher EVP_aes_128_cbc() has a fixed key length so there is no need to set it, though it is harmless to do so. The function EVP_CIPHER_key_length works on an EVP_CIPHER structure not an EVP_CIPHER_CTX. You need to call EVP_CIPHER_CTX_key_length instead. 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
Re: my code can't connect while openssl s_client can
Sorry for the long delay. I moved and had some holydays afterwards. So I have been away from work for some time. Am Mittwoch, 8. August 2012, 00:44:20 schrieben Sie: From: owner-openssl-us...@openssl.org On Behalf Of Alexandra Druecke Sent: Tuesday, 07 August, 2012 08:02 I'm using the attached code to connect to a server. This works perfectly until I had to excange the certificate which now needs two additional intermediate certs. All certs are merged within one file. The code can handle certificate chains as it is able to connect to another server with the same certificate. The EE cert and intermediate certs *and* privatekey, since otherwise you would have gotten errors you don't report. Yes, of course. I didn't mentioned them but all certs and keys are included except for the root-certificate. I tried to connect the server with my new certificate using openssl and it works fine: openssl s_client -connect the.server.net:700 -cert myCert.pem -CApath mycapath s_client calls use_certificate, not use_certificate_chain, Okay, this explains the different behaviour. to fill out the (client) chain. If not, apparently your servers don't need you to send the full chain; it's entirely possible a server has intermediate certs in its truststore and uses them. Well, I have to send the full chain as the server obviously does not have any intermediate certs in its truststore. Moreover I could fix the problem by adding the root-certificate to the chain. I expected the root-cert to be present on the server-side since the server sends a list of accepted CAs. It doesn't make sense to me though anyway it fixes the problem. Thanks a lot - Alexandra __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Is openssl 0.9.8r and openssl1.0.0 compatible ?
Hi All, We have a Linux box1 (Client) that has openssl 0.9.8r. That box communicates with a different kind of Linux box2 (Server) that has openssl 1.0.0e. openssl0.9.8r and openssl1.0.0e seem fairly happy together. In the near future our 2nd Linux box is migrating to a new Platform, as a result, it will have openssl1.0.0. My question is: Should I anticipate any incompatibilities between those two versions of openssl (0.9.8r -and- 1.0.0)? Out of curiosity, what version(s) of openssl1.0.X.Y are most compatible (functionality-wise) with the openssl0.9.8r version ? Thanks a bunch.
Negotiating TLS 1.0 from 1.2
I have a client that I want to attempt to negotiate TLS 1.2 but will accept TLS
1.0. What is the magic incantation (e.g. TLSv1_client_method() vs
TLSv1_2_client_method() in conjunction with what options)?
Specifying TLSv1_client_method() seems to only offer TLS 1.0 {3,1}. Specifying
TLSv1_2_client_method() offers TLS 1.2 {3,3}, but then when the server returns
a TLS 1.0 {3,1} ServerHello, the client generates a Protocol Version alert.
How do I tell the client that this is acceptable? Appendix E of RFC 5246
indicates this should be possible.
I am using OpenSSL 1.0.1c.
Erik Tkal
Juniper OAC/UAC/Pulse Development
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: Negotiating TLS 1.0 from 1.2
Hi Erik:
If you only want to allow TLSv1.2 and TLSv1.0 handshakes you will need to try a
connection with the TLSv1_2_client_method and then by TLSv1_client_method. You
can also use SSLv23_client_method to negotiate only TLSv1.2 and TLSv1.0 using
an SSLv2 handshake by explicitly disabling SSLv2, SSLv3 and TLSv1.1 using
SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3|SSL_OP_NO_TLSv1_1). At
least that's my understanding.
Regards
Abhi
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Erik Tkal
Sent: Wednesday, August 29, 2012 10:47 AM
To: openssl-users@openssl.org
Subject: Negotiating TLS 1.0 from 1.2
I have a client that I want to attempt to negotiate TLS 1.2 but will accept TLS
1.0. What is the magic incantation (e.g. TLSv1_client_method() vs
TLSv1_2_client_method() in conjunction with what options)?
Specifying TLSv1_client_method() seems to only offer TLS 1.0 {3,1}. Specifying
TLSv1_2_client_method() offers TLS 1.2 {3,3}, but then when the server returns
a TLS 1.0 {3,1} ServerHello, the client generates a Protocol Version alert.
How do I tell the client that this is acceptable? Appendix E of RFC 5246
indicates this should be possible.
I am using OpenSSL 1.0.1c.
Erik Tkal
Juniper OAC/UAC/Pulse Development
__
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: Negotiating TLS 1.0 from 1.2
TLS 1.1 would be acceptable, but the server is 1.0 (we don't have any
implementing 1.1). The server sends a TLS 1.0 ServerHello, which per the RFC
should work:
A TLS 1.2 client who wishes to negotiate with such older servers will
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version. If the server does not support this
version, it will respond with a ServerHello containing an older
version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol.
What I'm trying to figure out is how to tell OpenSSL that the client agrees to
use this version, whereas now it generates a fatal alert. I cannot use an
SSLv2 handshake, as this is inside EAP-TLS.
Erik Tkal
Juniper OAC/UAC/Pulse Development
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Abhiram Shandilya
Sent: Wednesday, August 29, 2012 2:38 PM
To: openssl-users@openssl.org
Subject: RE: Negotiating TLS 1.0 from 1.2
Hi Erik:
If you only want to allow TLSv1.2 and TLSv1.0 handshakes you will need to try a
connection with the TLSv1_2_client_method and then by TLSv1_client_method. You
can also use SSLv23_client_method to negotiate only TLSv1.2 and TLSv1.0 using
an SSLv2 handshake by explicitly disabling SSLv2, SSLv3 and TLSv1.1 using
SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3|SSL_OP_NO_TLSv1_1). At
least that's my understanding.
Regards
Abhi
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Erik Tkal
Sent: Wednesday, August 29, 2012 10:47 AM
To: openssl-users@openssl.org
Subject: Negotiating TLS 1.0 from 1.2
I have a client that I want to attempt to negotiate TLS 1.2 but will accept TLS
1.0. What is the magic incantation (e.g. TLSv1_client_method() vs
TLSv1_2_client_method() in conjunction with what options)?
Specifying TLSv1_client_method() seems to only offer TLS 1.0 {3,1}. Specifying
TLSv1_2_client_method() offers TLS 1.2 {3,3}, but then when the server returns
a TLS 1.0 {3,1} ServerHello, the client generates a Protocol Version alert.
How do I tell the client that this is acceptable? Appendix E of RFC 5246
indicates this should be possible.
I am using OpenSSL 1.0.1c.
Erik Tkal
Juniper OAC/UAC/Pulse Development
__
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
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
