Re: [openssl-users] OpenSSL and RPATH's (was: Cannot find SSL_CTX_get0_param in libssl library)

[Jeffrey Walton]

> RPATHs have advantages, but they have some major issues, too. For
> instance, if for whatever reason you need to move files around so that
> things are stored in a different location, suddenly you'll need to
> recompile everything -- because the RPATH is a hardcoded location of the
> library in use. This is very confusing, and not something that an
> average developer will expect.
>
> There is usually no need to hardcode the location of the library in use,
> provided the SONAME is configured correctly. Surprise surprise, OpenSSL
> actually does that right:
>
> wouter@gangtai:~$ objdump -p /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
> |grep SONAME
>   SONAME   libssl.so.1.0.2
> wouter@gangtai:~$ objdump -p /usr/lib/x86_64-linux-gnu/libssl.so.1.1
> |grep SONAME
>   SONAME   libssl.so.1.1
>
> There is no way that ld.so will load libssl1.1 for an application that
> is compiled against libssl.so with an SONAME of libssl.1.0.2 -- unless,
> of course, you do things like muck about with RPATH and point it to the
> wrong version of the library. In that case, you broke it, you get to
> keep both pieces.

The OpenSSL I build from sources is located in /usr/local. The gear
from /usr/local is first on-path.

This is what happens on Ubuntu 16.10:

$ /usr/bin/openssl errstr 0x3208408D
/usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libssl.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: /usr/local/lib/libcrypto.so.1.0.0: no version
information available (required by /usr/bin/openssl)
/usr/bin/openssl: relocation error: /usr/bin/openssl: symbol
COMP_zlib_cleanup, version OPENSSL_1.0.0 not defined in file
libcrypto.so.1.0.0 with link time reference

This is what happens on Fedora release 25:

$ /usr/bin/openssl errstr 0x3208408D
error:3208408D:lib(50):func(132):reason(141)

It seems to me SONAME's just don't work as expected.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Floodeenjr, Thomas]

Is there a recommendation for a newer book?

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Salz, Rich via openssl-users
Sent: Wednesday, June 14, 2017 11:43 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

> I am quoting a line from Network Security with OpenSSL book (O'Reilly Media)

That book is 15 years old.  Throw it out.
-- 
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] Session Ticket Support in Openssl TLS 1.2

[Salz, Rich via openssl-users]

> Is there a recommendation for a newer book?

Many people like the Feisty Duck book(s).  See if others on this list say 
anything.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Salz, Rich via openssl-users]

> I am quoting a line from Network Security with OpenSSL book (O'Reilly Media)

That book is 15 years old.  Throw it out.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

On Wed, Jun 14, 2017 at 3:43 AM, Matt Caswell  wrote:

>
>
> On 14/06/17 01:38, Salz, Rich via openssl-users wrote:
> > It’s disabled by default.  Servers that want to use server-side session
> > caching have to call an API to turn it on
>
> Err, no, that's not correct. Server side caching is on by default.
> Client side caching is off by default.
>


I am quoting a line from Network Security with OpenSSL book (O'Reilly Media)

"All sessions must have a session ID context. For the server, session
caching is disabled by default unless a call to SSL_CTX_set_session_id_context
is made."

That's why I thought server side session caching is disabled by default.


>
>
> On 14/06/17 02:03, Neetish Pathak wrote:
> > Thanks for your reply Salz. However, I want to know should the session
> > caching be enabled on server side for TLS 1.3 for session resumption.
>
> It should just work by default for TLSv1.3. You don't need to enable
> anything.
>

Yea it worked for previous TLS versions, so everything was inline. But
since with TLS 1.3, I was not observing the same behavior, that's why my
question was for TLS 1.3.

>
> > Also, I need a clarification on how does resumption work in case of
> > session identifiers if server side caching is not enabled
>
> As noted above server side caching is on by default.
>




>
> On 14/06/17 02:33, Neetish Pathak wrote:
> > I need some suggestions on how I can implement session resumption in TLS
> > 1.3. I have implemented the resumption on the client side using a
> > callback as recommended on the TLS 1.3
> > blog https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/
> >  . Still, the
> > session resumption is not working. I know this because my new_session_cb
> > which I have set using SSL_CTX_sess_set_new_cb is never getting invoked
> > and also I don't see any improvement in connection time.
> >
> > The same implementation when I change the max TLS version to TLS1.2
> > works and session resumption works as desired.
> > I am not sure how I can resolve this.
> >
> > As mentioned on the blog post
> >
> > "In TLSv1.3 sessions are not established until after the main handshake
> > has completed. The server sends a separate post-handshake message to the
> > client containing the session details. Typically this will happen soon
> > after the handshake has completed, but it could be sometime later (or
> > not at all)."
> >
> > I think the server is not informing the session details to client at all
> > in my case and hence the resumption is not working. Can someone please
> > suggest how to resolve this
>
> Just to be clear: you are using OpenSSL on both the server and client
> sides right? If you are using something other than OpenSSL on the server
> then the policy might be different around when the session information
> is sent to the client (i.e. it could happen sometime later, or not at
> all). If you are using OpenSSL on the server then it sends its session
> information immediately after the main handshake has completed, so that
> should not be a problem.
>
> So if I understand you correctly the client is successfully creating a
> TLSv1.3 connection, but the client side new session callback is never
> being invoked? Did you call SSL_CTX_sess_set_new_cb() before or after
> the SSL object itself was created? Are you able to share any code for
> how you have done this?
>



Yes, I am using OpenSSl on both the server and client sides and my
implementation works for TLS 1.2.
Yea you understood correctly, the client is creating a connection but new
session callback is not getting invoked.
I have called SSL_CTX_sess_set_new_cb before SSL object is created



Yea, sure following is a snippet from my client side implementation. I have
highlighted the relevant section for new session callback registration



*static* *int* *new_session_cb*(SSL* ssl, SSL_SESSION * sess){



BIO *stmp = BIO_new_file(SESS_OUT,"w");


*if*(stmp == NULL){

BIO_printf(bio_err,"Error writing session file %s\n",SESS_OUT);

}*else*{

fprintf(stderr,"Session getting set\n");

PEM_write_bio_SSL_SESSION(stmp,sess);

BIO_free(stmp);

resumeInput = TRUE;

}


*return* 0;

}


*int* *SocketClient::connectToServer*(){


/*Initialization

** (1)Register SSL/TLS ciphers and digests

** (2)Load Opessl error Strings*/

init_OpenSSL();


/*Creating a new SSL context object*/

ssl_ctx = SSL_CTX_new(TLS_client_method());

SSL_CTX_set_max_proto_version(ssl_ctx, MAX_TLS_VERSION);

SSL_CTX_set_min_proto_version(ssl_ctx, MIN_TLS_VERSION);


*if*(NULL == ssl_ctx){

fail("SocketClient.cpp : ssl_ctx object creation failed"); perror("");

}*else*{

pass("SocketClient.cpp : ssl Context created successfully");

}



*if(ssl_ctx){*

* SSL_CTX_set_session_cache_mode(ssl_ctx, SSL_SESS_CACHE_CLIENT*

* | SSL_SESS_CACHE_NO_INTERNAL_STORE);*

* SSL_CTX_sess_set_new_cb(ssl_ctx, new_session_cb);*

* }*

*return* 0;

}

int *SocketClient::sslTcpConnect*(){


/*Attaching the 

Re: [openssl-users] Understanding RSA_sign and type argument

[Ignacio Alamo Corsino]

Hello Erwann,


Merci beaucoup!

It has worked but with "-sigalgs RSA+SHA256" instead of "sigalgs SHA256+RSA"


Finding this option was driving me crazy because I could not find it in the 
wiki page of s_server:

https://wiki.openssl.org/index.php/Manual:S_server(1)

Manual:S server(1) - 
OpenSSLWiki
wiki.openssl.org
NAME. s_server - SSL/TLS server program SYNOPSIS. openssl s_server [-accept 
port] [-naccept count] [-context id] [-verify depth] [-Verify depth] 
[-crl_check] [-crl ...





De: openssl-users  en nombre de Erwann 
Abalea 
Enviado: lunes, 12 de junio de 2017 10:42
Para: openssl-users@openssl.org
Asunto: Re: [openssl-users] Understanding RSA_sign and type argument

Bonjour,

Add « -sigalgs SHA256+RSA » to one of your command lines.

Cordialement,
Erwann Abalea

Le 9 juin 2017 à 09:45, Ignacio Alamo Corsino 
> a écrit :

Hello everyone,

i am having some issues understanding the RSA_sign function:

RSA_sign(int type, const unsigned char *m, unsigned int m_len, unsigned char 
*sigret, unsigned int *siglen, RSA *rsa);

As far as I know, the signing is a four step process:
- Calculate hash with digest algorithm  (given as argument to this 
function -> m)
- Encapsulate hash in a DigestInfo structure (X509_SIG)
- Structure padding (in RSA_private_encrypt)
- Private key operation on this padded structure (in RSA_private_encrypt)

Is that correct?

So, during the TLS handshake, the RSA_sign function is called in the 
CertificateVerify step.
For my tests, everytime this function is called, the hashing type is SHA512 
even though I specify to use a SHA256 hash.

These are the commands that I use to test TLS:

#openssl s_server -accept 443 -cert cert.pem -key key.pem  -Verify 1 -msg 
-debug -cipher eNULL:aRSA:!SHA512:SHA256 -serverpref
#openssl s_client -connect localhost:443 -cert client_cert.pem   -key 
client.key -state -cipher eNULL:aRSA:!SHA512:SHA256

How can I force TLS to use a SHA256 digest for DH?
--
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] Session Ticket Support in Openssl TLS 1.2

[Matt Caswell]

On 14/06/17 01:38, Salz, Rich via openssl-users wrote:
> It’s disabled by default.  Servers that want to use server-side session
> caching have to call an API to turn it on

Err, no, that's not correct. Server side caching is on by default.
Client side caching is off by default.


On 14/06/17 02:03, Neetish Pathak wrote:
> Thanks for your reply Salz. However, I want to know should the session
> caching be enabled on server side for TLS 1.3 for session resumption.

It should just work by default for TLSv1.3. You don't need to enable
anything.

> Also, I need a clarification on how does resumption work in case of
> session identifiers if server side caching is not enabled

As noted above server side caching is on by default.

On 14/06/17 02:33, Neetish Pathak wrote:
> I need some suggestions on how I can implement session resumption in TLS
> 1.3. I have implemented the resumption on the client side using a
> callback as recommended on the TLS 1.3
> blog https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/
>  . Still, the
> session resumption is not working. I know this because my new_session_cb
> which I have set using SSL_CTX_sess_set_new_cb is never getting invoked
> and also I don't see any improvement in connection time.
>
> The same implementation when I change the max TLS version to TLS1.2
> works and session resumption works as desired.
> I am not sure how I can resolve this.
>
> As mentioned on the blog post
>
> "In TLSv1.3 sessions are not established until after the main handshake
> has completed. The server sends a separate post-handshake message to the
> client containing the session details. Typically this will happen soon
> after the handshake has completed, but it could be sometime later (or
> not at all)."
>
> I think the server is not informing the session details to client at all
> in my case and hence the resumption is not working. Can someone please
> suggest how to resolve this

Just to be clear: you are using OpenSSL on both the server and client
sides right? If you are using something other than OpenSSL on the server
then the policy might be different around when the session information
is sent to the client (i.e. it could happen sometime later, or not at
all). If you are using OpenSSL on the server then it sends its session
information immediately after the main handshake has completed, so that
should not be a problem.

So if I understand you correctly the client is successfully creating a
TLSv1.3 connection, but the client side new session callback is never
being invoked? Did you call SSL_CTX_sess_set_new_cb() before or after
the SSL object itself was created? Are you able to share any code for
how you have done this?

Matt

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users