Re: openssl 1.0.1i
On 18.09.14 00:04, Tulasi wrote: Hi I installed openssl 1.0.1i fips enabled (fips 2.0.7) When i run the command openssl version, i get this OpenSSL 1.0.0-fips 29 Mar 2010 Why doesn't it show 1.0.1i in the version information. Please help. Did you run 'which openssl' and double-check the path? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl 1.0.1i
Yes this worked .thanks. On Thu, Sep 18, 2014 at 12:31 PM, Øystein Larsen oystein.lar...@usit.uio.no wrote: On 18.09.14 00:04, Tulasi wrote: Hi I installed openssl 1.0.1i fips enabled (fips 2.0.7) When i run the command openssl version, i get this OpenSSL 1.0.0-fips 29 Mar 2010 Why doesn't it show 1.0.1i in the version information. Please help. Did you run 'which openssl' and double-check the path? __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL v3.0 is not set as default protocol upon disabling v2.
Thanks John,
After reading through http://tools.ietf.org/html/rfc2246#appendix-E I
understood what you meant here, and couls make sense about fallback to
SSLv3.
TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both
is easy. TLS clients who wish to negotiate with SSL 3.0 servers
should send client hello messages using the SSL 3.0 record format and
client hello structure, sending {3, 1} for the version field to note
that they support TLS 1.0. If the server supports only SSL 3.0, it
will respond with an SSL 3.0 server hello; if it supports TLS, with a
TLS server hello. The negotiation then proceeds as appropriate for
the negotiated protocol.
I was under impression that client should advertise SSLv3.0 in its minimum
version, but it was the Server who had to fallback to SSLv3.
Thanks to all of you who bothered to help me on this.
Regards,
Abhijit
On Tue, Sep 16, 2014 at 10:34 PM, John Lane Schultz
jschu...@spreadconcepts.com wrote:
As Thulasi wrote, SSLv23_client_method supports *ALL* protocols that your
library supports by default. The name of the function is just historical
and should be ignored. From the documentation:
If the cipher list does not contain any SSLv2 ciphersuites (the default
cipher list does not) or extensions are required (for example server name)
a client will send out TLSv1 client hello messages including extensions and
will indicate that it also understands TLSv1.1, TLSv1.2 and permits a
fallback to SSLv3.
The real question is why the server that didn’t support TLS couldn’t fall
back to SSLv3? If a SSLv3 server can’t understand a TLSv1 hello, then it
kind of defeats the purpose of being able to fallback to SSLv3 ...
Cheers!
-
John Lane Schultz
Spread Concepts LLC
Cell: 443 838 2200
On Sep 16, 2014, at 12:36 PM, abhijit pai abhijitpa...@gmail.com wrote:
Hi Thulasi,
Thanks for the response.
But my point is little different here. I have a generic HTTP client, that
talks to SSL 3.0 as well as TLS 1.x enabled server.
And as mentioned earlier, I have disabled SSLv2.
Now, when I talk to any server, shouldn't the client be sending SSLv3(SSL
3.0) in the version instead of TLS 1.0 as seen from packet capture?
Is it some default behaviour? Is it configurable?
Regards,
Abhijit
Thulasi Goriparthi
SSLv23_client_method supports all protocols by default and connects using
the highest protocol that server supports(as received from server hello)
I suggest you try disabling TLS 1.0 along with SSL2 if you want to force
your client to use SSL3 without changing the context's method.
SSL_CTX_set_options(ctx, SSL_OP_ALL|
SSL_OP_NO_SSLv2 |
SSL_OP_NO_TLSv1);
If the server supports TLS1.1 and TLS 1.2, update the client ctx option
to
use SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 also.
On Fri, Sep 12, 2014 at 6:01 PM, abhijit pai abhijitpa...@gmail.com
wrote:
Hello All,
I am using openSSL in my custom HTTP client.
Here I use SSLv23_client_method() and disable SSLv2 using
SSL_CTX_set_options(ctx, SSL_OP_ALL| SSL_OP_NO_SSLv2)
I would expect the handshake method sent out to the server be SSL v3.0
but to my surprise it is TLS 1.0, which for some reasons the server
does not support.
This is a generic code, that would talk to even TLS 1.x enabled
servers, so I cannot fix it using SSLv3_client_method().
Is there any other API that I am not aware of that could help me achieve
it?
Thanks in advance!
Regards,
Abhijit
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Query reg AES_NI usage with OpenSSL-1.0.1h
Hi, I have written application code for encryption and decryption using OpenSSL library. I am testing on machine where AES-NI support is present. I am not sure how can I confirm whether execution is using AES-NI instruction set. When run command line openssl speed -evp aes128, I was seeing aesni_cbc_cipher() getting hit. But with my sample code, I am not seeing aesni_cbc_cipher() getting executed.. Openssl ver: OpenSSL-1.0.1h Sample high level code is like OpenSSL_add_all_algorithms(); ERR_load_crypto_strings(); OPENSSL_config(NULL); EVP_CIPHER_CTX_init(ctx); if(1 != EVP_DecryptInit_ex(ctx, EVP_aes_128_cbc(), NULL, key, iv)) handleErrors(); EVP_CIPHER_CTX_set_padding(ctx, 0); if(1 != EVP_DecryptUpdate(ctx, plaintext, len, ciphertext, ciphertext_len)) handleErrors(); plaintext_len = len; if(1 != EVP_DecryptFinal_ex(ctx, plaintext + len, len)) handleErrors(); plaintext_len += len; EVP_CIPHER_CTX_cleanup(ctx); Any pointers will be appreciated.. Thanks Mukesh
TLS handshake failure i/o timeout
I have an ubuntu 14.04 with openssl 1.0.1f-1ubuntu2.3 server running and a another server connecting as the client with ubuntu 12.04 with openssl 1.0.1-4ubuntu5.16. I am getting an error about the TLS handshake failing i/o timeout. I have tried using our internal wildcard certs on both servers since I already have that on my web server , aka - the client, and I generated a sif signed cert on the server and copied it to the client. Both produce the same results. On the server I took a tcpdump and then did an ssldup of that file and this is what I am seeing for every connection: 210 1 0.0012 (0.0012) CS Handshake ClientHello Version 3.1 cipher suites TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA Unknown value 0xc011 Unknown value 0xc012 Unknown value 0xc013 Unknown value 0xc014 compression methods NULL I have looking through posts trying to find an answer with no luck yet. Any and all help is appreciated. Thanks, Eric Speake Web Systems Administrator O'Reilly Auto Parts (417) 862-2674 Ext. 1975 This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Query reg AES_NI usage with OpenSSL-1.0.1h
I have written application code for encryption and decryption using OpenSSL library. I am testing on machine where AES-NI support is present. I am not sure how can I confirm whether execution is using AES-NI instruction set. ... Any pointers will be appreciated.. OpenSSL has a test for AES-NI, but it only works from the static lib. It only works for static libs because OPENSSL_ia32cap_P[] is not *not* exported/available from the shared object. Here's the test from crypto/evp/e_aes.c: #define AESNI_CAPABLE (OPENSSL_ia32cap_P[1](1(57-32))) If you want a test that works from both the static lib and shared object, then you have to provide it yourself. The stuff I use is available at http://stackoverflow.com/questions/25284119/how-can-i-check-if-openssl-is-suport-use-the-intel-aes-ni. Even if AES-NI is available, it does not mean you will use it. If you use low level AES_* functions, then you will not use it because its a software implementation. To [potentially] use AES-NI, you have to use the EVP_* functions. There's no guarantee EVP_* functions will use hardware features like AES-NI, but EVP_* functions will usually use features like AES-NI, if available. believe the OpenSSL docs state the same at https://www.openssl.org/docs/crypto/EVP_EncryptInit.html: Where possible the EVP interface to symmetric ciphers should be used in preference to the low level interfaces. This is because the code then becomes transparent to the cipher used and much more flexible. Additionally, the EVP interface will ensure the use of platform specific cryptographic acceleration such as AES-NI (the low level interfaces do not provide the guarantee). AES_* vs EVP_* is also why you see the difference in 'openssl speed ...' test when using (or not using) the '-evp' option. There was also a discussion about it about a year ago at Verify AES-NI use at runtime?, https://groups.google.com/d/msg/mailing.openssl.users/URRJ7Wx1fvw/ONdhjFxfrb0J. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
read call hangs in SSL library
Hi, We have an LDAP client that calls into OpenSSL libraries to talk to a secure LDAP server. If for any reason we lose connection to the LDAP server, the LDAP handle is freed. As part of ldap_unbind(LDAP *ld), the ssl3_shutdown() is called, which calls read and hangs. The stack is as follows: (gdb) bt 15 #0 0x00080166935c in read () at read.S:2 #1 0x0008014748f0 in __read (fd=49, buf=0x803293003, nbytes=5) at src/freebsd-c/lib/libthr/thread/thr_syscalls.c:384 #2 0x000802c715d2 in sb_stream_read (sbiod=0x805664850, buf=0x803293003, len=5) at src/openldap/libraries/liblber/sockbuf.c:493 #3 0x000802c7207e in sb_debug_read (sbiod=0x805664970, buf=0x803293003, len=5) at src /openldap/libraries/liblber/sockbuf.c:827 #4 0x000802356971 in tlso_bio_read (b=0x803205320, buf=0x803293003 \027\003\001, len=5) at tls_o.c:687 #5 0x00080252c2df in BIO_read () from /usr/lib/libcrypto.so.1.0.0 #6 0x000802eb9f01 in ssl3_read_n () from /usr/lib/libssl.so.1.0.0 #7 0x000802eba3ce in ssl3_read_bytes () from /usr/lib/libssl.so.1.0.0 #8 0x000802eb67ac in ssl3_shutdown () from /usr/lib/libssl.so.1.0.0 #9 0x000802356cf6 in tlso_sb_close (sbiod=0x8056649d0) at tls_o.c:808 #10 0x000802c71253 in ber_int_sb_close (sb=0x80329e0d0) at src/openldap/libraries/liblber/sockbuf.c:383 #11 0x00080233d625 in ldap_free_connection (ld=0x80323f800, lc=0x803205240, force=1, unbind=1) at request.c:769 If anyone has seen a similar problem and know any fix, please let me know what needs to be done, appreciate any help. I have posted this to OpenLDAP, but did not have much luck. Thanks R.K. Aditham
Re: TLS handshake failure i/o timeout
This may sound basic, but have you verified that the firewall on the server is set up to allow communication from the client? I think Ubuntu's firewall rejects all traffic to ports that don't match what its installed and configured packages claim they run on, without external configuration. -Kyle H On September 18, 2014 6:02:16 AM PDT, espe...@oreillyauto.com wrote: I have an ubuntu 14.04 with openssl 1.0.1f-1ubuntu2.3 server running and a another server connecting as the client with ubuntu 12.04 with openssl 1.0.1-4ubuntu5.16. I am getting an error about the TLS handshake failing i/o timeout. I have tried using our internal wildcard certs on both servers since I already have that on my web server , aka - the client, and I generated a sif signed cert on the server and copied it to the client. Both produce the same results. On the server I took a tcpdump and then did an ssldup of that file and this is what I am seeing for every connection: 210 1 0.0012 (0.0012) CS Handshake ClientHello Version 3.1 cipher suites TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA Unknown value 0xc011 Unknown value 0xc012 Unknown value 0xc013 Unknown value 0xc014 compression methods NULL I have looking through posts trying to find an answer with no luck yet. Any and all help is appreciated. Thanks, Eric Speake Web Systems Administrator O'Reilly Auto Parts (417) 862-2674 Ext. 1975 This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Query reg AES_NI usage with OpenSSL-1.0.1h
Thanks Jeff for really good amount of info.. I have integrated code from below link of HasAESNI() and HasRDRAND() in my application code. AESNI is enabled but RDRAND is not. http://stackoverflow.com/questions/25284119/how-can-i-check-if-openssl-is-suport-use-the-intel-aes-ni . I am using EVP interface and static library already. So in that case I suppose that AES-NI is supported.. Besides this how can it be confirmed that at run-time for operation like enc/dec, AES_NI are getting used instead of normal.. I was assuming if encryption is being done and it's using NI routines, aesni_cbc_cipher() will for sure get executed... In my case, this func is not getting hit Is there any other way to confirm the same objective Thanks Mukesh On 18 September 2014 19:16, Jeffrey Walton noloa...@gmail.com wrote: I have written application code for encryption and decryption using OpenSSL library. I am testing on machine where AES-NI support is present. I am not sure how can I confirm whether execution is using AES-NI instruction set. ... Any pointers will be appreciated.. OpenSSL has a test for AES-NI, but it only works from the static lib. It only works for static libs because OPENSSL_ia32cap_P[] is not *not* exported/available from the shared object. Here's the test from crypto/evp/e_aes.c: #define AESNI_CAPABLE (OPENSSL_ia32cap_P[1](1(57-32))) If you want a test that works from both the static lib and shared object, then you have to provide it yourself. The stuff I use is available at http://stackoverflow.com/questions/25284119/how-can-i-check-if-openssl-is-suport-use-the-intel-aes-ni . Even if AES-NI is available, it does not mean you will use it. If you use low level AES_* functions, then you will not use it because its a software implementation. To [potentially] use AES-NI, you have to use the EVP_* functions. There's no guarantee EVP_* functions will use hardware features like AES-NI, but EVP_* functions will usually use features like AES-NI, if available. believe the OpenSSL docs state the same at https://www.openssl.org/docs/crypto/EVP_EncryptInit.html: Where possible the EVP interface to symmetric ciphers should be used in preference to the low level interfaces. This is because the code then becomes transparent to the cipher used and much more flexible. Additionally, the EVP interface will ensure the use of platform specific cryptographic acceleration such as AES-NI (the low level interfaces do not provide the guarantee). AES_* vs EVP_* is also why you see the difference in 'openssl speed ...' test when using (or not using) the '-evp' option. There was also a discussion about it about a year ago at Verify AES-NI use at runtime?, https://groups.google.com/d/msg/mailing.openssl.users/URRJ7Wx1fvw/ONdhjFxfrb0J . Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: TLS handshake failure i/o timeout
Kyle, Thanks for the reply. It was certificate issue. After I was able to line the correct certs with the correct key it started working as advertised. Thank you, Eric Speake Web Systems Administrator O'Reilly Auto Parts (417) 862-2674 Ext. 1975 From: Kyle Hamilton aerow...@gmail.com To: openssl-users@openssl.org, espe...@oreillyauto.com Date: 09/18/2014 01:29 PM Subject:Re: TLS handshake failure i/o timeout This may sound basic, but have you verified that the firewall on the server is set up to allow communication from the client? I think Ubuntu's firewall rejects all traffic to ports that don't match what its installed and configured packages claim they run on, without external configuration. -Kyle H On September 18, 2014 6:02:16 AM PDT, espe...@oreillyauto.com wrote: I have an ubuntu 14.04 with openssl 1.0.1f-1ubuntu2.3 server running and a another server connecting as the client with ubuntu 12.04 with openssl 1.0.1-4ubuntu5.16. I am getting an error about the TLS handshake failing i/o timeout. I have tried using our internal wildcard certs on both servers since I already have that on my web server , aka - the client, and I generated a sif signed cert on the server and copied it to the client. Both produce the same results. On the server I took a tcpdump and then did an ssldup of that file and this is what I am seeing for every connection: 210 1 0.0012 (0.0012) CS Handshake ClientHello Version 3.1 cipher suites TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA Unknown value 0xc011 Unknown value 0xc012 Unknown value 0xc013 Unknown value 0xc014 compression methods NULL I have looking through posts trying to find an answer with no luck yet. Any and all help is appreciated. Thanks, Eric Speake Web Systems Administrator O'Reilly Auto Parts (417) 862-2674 Ext. 1975 This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you. OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Sent from my Android device with K-9 Mail. Please excuse my brevity.-- This message has been scanned for viruses and dangerous content, and is believed to be clean. Message id: 5AF0F60079E.A6C39This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS § 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
compilation error
/usr/bin/ld: cannot find -lopenssl
this is the error when i have tried to compile the code i attached below i
install the openssl lib in ubuntu 12.10 i use eclipse and add at the linker
setting openssl usr/include/openssl
i don't know how to solve this problem please help
--
Warmest regards and best wishes for a good health,*urs sincerely *
*mero*
//
// Name: certificate.cpp
// Author : Amir
// Version :
// Copyright : Your copyright notice
// Description : Hello World in C++, Ansi-style
//
#include iostream
#include server.h
#include client.h
using namespace std;
int main()
{
Client clientest;
Server servertest;
clientest.SetCert(clientest.MakeSignedCertReq(1,2,90));
return 0;
}
/*
* client.cc
*
* Created on: Sep 17, 2014
* Author: amirale32
*/
#include client.h
Client :: Client()
{
m_myCertReq = X509_REQ_new();
m_myCert = X509_new();
m_name = X509_NAME_new();
m_rsa_keyPair = RSA_new();
m_puk = EVP_PKEY_new();
GenerateRSAKeyPair();
SetPublicKey();
}
Client :: ~Client()
{
X509_REQ_free(m_myCertReq);
X509_free(m_myCert);
X509_NAME_free(m_name);
RSA_free(m_rsa_keyPair);
EVP_PKEY_free(m_puk);
}
void
Client :: GenerateRSAKeyPair ( )
{
m_rsa_keyPair = RSA_generate_key(2048,RSA_F4,NULL,NULL);
}
void
Client::SetPublicKey()
{
EVP_PKEY_assign_RSA(m_puk,m_rsa_keyPair);
}
X509_REQ*
Client::MakeSignedCertReq(int bits, int serial, int days)
{
X509_REQ_set_pubkey(m_myCertReq,m_puk);
m_name=X509_REQ_get_subject_name(m_myCertReq);
//X509_NAME_add_entry_by_txt(name,C,MBSTRING_ASC, UK, -1, -1, 0);
//X509_NAME_add_entry_by_txt(name,CN,MBSTRING_ASC, OpenSSL Group, -1, -1, 0);
X509_REQ_sign(m_myCertReq,m_puk,EVP_md5());
return m_myCertReq;
}
void
Client::SetCert(X509_REQ *req)
{
m_myCert = m_ca-CreateCertificate(m_myCertReq);
}
/*
* client.h
*
* Created on: Sep 17, 2014
* Author: amirale32
*/
#ifndef CLIENT_H_
#define CLIENT_H_
#include stdlib.h
#include stdio.h
#include openssl/rsa.h
#include openssl/conf.h
#include openssl/x509.h
#include server.h
class Client
{
public:
Client();
~Client();
void GenerateRSAKeyPair ();
void SetPublicKey ();
X509_REQ *MakeSignedCertReq(int bits, int serial, int days);
void SetCert (X509_REQ *req);
private:
X509_REQ *m_myCertReq;
X509 *m_myCert;
X509_NAME *m_name;
RSA*m_rsa_keyPair;
EVP_PKEY *m_puk;
Server *m_ca;
};
#endif /* CLIENT_H_ */
#include server.h
Server::Server()
{
m_myCert = X509_new();
m_caKeyPairs = RSA_new();
m_pukey = EVP_PKEY_new();
GenerateMyKeyPairs();
CreateMyCertificate();
SetPublicKey();
}
Server::~Server()
{
X509_free(m_myCert);
RSA_free(m_caKeyPairs);
EVP_PKEY_free(m_pukey);
}
X509*
Server::CreateCertificate(X509_REQ* req)
{
X509 *m_req_reply;
m_req_reply = X509_new();
X509_NAME *subject = NULL;
EVP_PKEY *pkey = NULL;
X509_NAME *issuerSubject = X509_get_subject_name(m_myCert);
X509_set_issuer_name(m_req_reply, issuerSubject);
//xn_req = X509_REQ_get_subject_name(req);
X509_set_subject_name(m_req_reply, subject);
pkey = X509_REQ_get_pubkey(req);
//rv = X509_set_pubkey(reqreply, pkey);
X509_gmtime_adj(X509_get_notBefore(m_req_reply), 0);
X509_gmtime_adj(X509_get_notAfter(m_req_reply), 36400);
X509_sign(m_req_reply, pkey, EVP_md5());
return m_req_reply;
}
void
Server::CreateMyCertificate()
{
EVP_PKEY_assign_RSA(m_pukey, m_caKeyPairs);
ASN1_INTEGER_set(X509_get_serialNumber(m_myCert), 1);
X509_gmtime_adj(X509_get_notBefore(m_myCert), 0);
X509_gmtime_adj(X509_get_notAfter(m_myCert), 31536000L);
X509_set_pubkey(m_myCert, m_pukey);
X509_NAME * name;
name = X509_get_subject_name(m_myCert);
X509_set_issuer_name(m_myCert, name);
X509_sign(m_myCert, m_pukey, EVP_md5());
}
void
Server::GenerateMyKeyPairs()
{
m_caKeyPairs = RSA_generate_key(2048,RSA_F4 , NULL , NULL);
}
void
Server::SetPublicKey()
{
EVP_PKEY_assign_RSA(m_pukey,m_caKeyPairs);
}
/*
* server.cc
*
* Created on: Sep 17, 2014
* Author: amirale32
*/
/*
* server.h
*
* Created on: Sep 17, 2014
* Author: amirale32
*/
#ifndef SERVER_H_
#define SERVER_H_
#include stdlib.h
#include stdio.h
#include openssl/asn1.h
#include openssl/ssl.h
#include openssl/rsa.h
#include openssl/conf.h
#include openssl/x509.h
class Server
{
public:
Server();
~Server();
X509 *CreateCertificate (X509_REQ *req);
void CreateMyCertificate();
void GenerateMyKeyPairs ( );
void SetPublicKey ();
private:
X509 *m_myCert;
RSA*m_caKeyPairs;
EVP_PKEY *m_pukey;
};
#endif /* SERVER_H_ */
Re: SSL v3.0 is not set as default protocol upon disabling v2.
Actually, Abhijit, I think your question still has merit.
The documentation says that a client will use a TLS hello even when SSLv3 is
one of its supported protocols. The problem then is, how can such a client
communicate with an SSLv3 only server, which probably won’t understand the TLS
hello msg?
How can a client force the library to use a SSLv3 hello msg while still
advertising that is also supports higher TLS protocols?
It wasn’t apparent to me how to cause this behavior from the top level
documentation.
Cheers!
-
John Lane Schultz
Spread Concepts LLC
Cell: 443 838 2200
On Sep 18, 2014, at 4:37 AM, abhijit pai abhijitpa...@gmail.com wrote:
Thanks John,
After reading through http://tools.ietf.org/html/rfc2246#appendix-E I
understood what you meant here, and couls make sense about fallback to SSLv3.
TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both
is easy. TLS clients who wish to negotiate with SSL 3.0 servers
should send client hello messages using the SSL 3.0 record format and
client hello structure, sending {3, 1} for the version field to note
that they support TLS 1.0. If the server supports only SSL 3.0, it
will respond with an SSL 3.0 server hello; if it supports TLS, with a
TLS server hello. The negotiation then proceeds as appropriate for
the negotiated protocol.
I was under impression that client should advertise SSLv3.0 in its minimum
version, but it was the Server who had to fallback to SSLv3.
Thanks to all of you who bothered to help me on this.
Regards,
Abhijit
On Tue, Sep 16, 2014 at 10:34 PM, John Lane Schultz
jschu...@spreadconcepts.com wrote:
As Thulasi wrote, SSLv23_client_method supports *ALL* protocols that your
library supports by default. The name of the function is just historical and
should be ignored. From the documentation:
If the cipher list does not contain any SSLv2 ciphersuites (the default cipher
list does not) or extensions are required (for example server name) a client
will send out TLSv1 client hello messages including extensions and will
indicate that it also understands TLSv1.1, TLSv1.2 and permits a fallback to
SSLv3.
The real question is why the server that didn’t support TLS couldn’t fall back
to SSLv3? If a SSLv3 server can’t understand a TLSv1 hello, then it kind of
defeats the purpose of being able to fallback to SSLv3 ...
Cheers!
-
John Lane Schultz
Spread Concepts LLC
Cell: 443 838 2200
On Sep 16, 2014, at 12:36 PM, abhijit pai abhijitpa...@gmail.com wrote:
Hi Thulasi,
Thanks for the response.
But my point is little different here. I have a generic HTTP client, that talks
to SSL 3.0 as well as TLS 1.x enabled server.
And as mentioned earlier, I have disabled SSLv2.
Now, when I talk to any server, shouldn't the client be sending SSLv3(SSL 3.0)
in the version instead of TLS 1.0 as seen from packet capture?
Is it some default behaviour? Is it configurable?
Regards,
Abhijit
Thulasi Goriparthi
SSLv23_client_method supports all protocols by default and connects using
the highest protocol that server supports(as received from server hello)
I suggest you try disabling TLS 1.0 along with SSL2 if you want to force
your client to use SSL3 without changing the context's method.
SSL_CTX_set_options(ctx, SSL_OP_ALL|
SSL_OP_NO_SSLv2 |
SSL_OP_NO_TLSv1);
If the server supports TLS1.1 and TLS 1.2, update the client ctx option to
use SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 also.
On Fri, Sep 12, 2014 at 6:01 PM, abhijit pai abhijitpa...@gmail.com wrote:
Hello All,
I am using openSSL in my custom HTTP client.
Here I use SSLv23_client_method() and disable SSLv2 using
SSL_CTX_set_options(ctx, SSL_OP_ALL| SSL_OP_NO_SSLv2)
I would expect the handshake method sent out to the server be SSL v3.0
but to my surprise it is TLS 1.0, which for some reasons the server
does not support.
This is a generic code, that would talk to even TLS 1.x enabled
servers, so I cannot fix it using SSLv3_client_method().
Is there any other API that I am not aware of that could help me achieve it?
Thanks in advance!
Regards,
Abhijit
__
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: compilation error
It’s -lssl, not -lopenssl. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Amir Reda Sent: Thursday, September 18, 2014 1:33 PM To: openssl-users@openssl.org Subject: compilation error /usr/bin/ld: cannot find -lopenssl this is the error when i have tried to compile the code i attached below i install the openssl lib in ubuntu 12.10 i use eclipse and add at the linker setting openssl usr/include/openssl i don't know how to solve this problem please help -- Warmest regards and best wishes for a good health,urs sincerely mero
Re: SSL v3.0 is not set as default protocol upon disabling v2.
On Thu, Sep 18, 2014 at 04:47:22PM -0400, John Lane Schultz wrote: The documentation says that a client will use a TLS hello even when SSLv3 is one of its supported protocols. The problem then is, how can such a client communicate with an SSLv3 only server, which probably won't understand the TLS hello msg? The TLS and SSLv3 client hello messages are identical. This message carries a minimum and maximum protocol version number and interoperates with SSLv3 when the minimum protocol is SSL 3.0. TLSv1 is SSL 3.1. TLSv1.1 is SSL 3.2, ... -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
