Re: Query related to session resumption in TLS1.3

2019-06-09 Thread Viktor Dukhovni
On Sun, Jun 09, 2019 at 10:39:36AM +, shalu dhamija wrote:

>   "The default number of tickets is 2; the default number of tickets sent
>   following a resumption handshake is 1".  But in my case, following the
>   resumption handshake, I am always getting two session tickets from the
>   server.  Is this behavior fine as it is server dependent.

The behaviour is server-impementation dependent.  If the server is
not using OpenSSL, it might always return multiple tickets.  This
is IMHO unwise, because each resumption increases the number of
available tickets without bound.

In conversation with Matt Caswell he and I came up with the current
OpenSSL design in which a client that uses a pool of N concurrent
sessions *without* ticket re-use (each session repeatedly obtaining
a "continuation" ticket) obtains the requisite tickets after N-1
full handshakes, at which point no excess tickets are delivered so
long as the client's concurrency needs are met.

Servers also have the (non-default) *option* of resuming sessions
with a valid ticket *without* returning a new ticket.  Postfix makes
use of this option to vend exactly one ticket per full handshake,
and not return any new tickets on resumption.  Client MTAs that
support resumption are expected to re-use tickets.

-- 
Viktor.


Re: authEnvelopedData

2019-06-09 Thread Jakub Zelenka
>
>  I need to create a “authEnvelopedData“ (
> https://tools.ietf.org/html/rfc5083#2.1) ASN1 structure but I know how to
> archive this. I tried with “PKCS7_encrypt” but here I got only
> “envelopedData”.
>

This is not currently supported. I created a PR some time ago that adds
support for it: https://github.com/openssl/openssl/pull/8024

It still waits for review from the OpenSSL devs...


> I`ll try next with CMS_encrypt and to modify CMS_ContentInfo to add the
> authEnvelopedData parameter. Would this way work?
>

I guess you might end up with the similar result like my PR.

Cheers

Jakub


Re: failing in reproducing .so files

2019-06-09 Thread Kyle Hamilton
Can you try building an unmodified version of the tarball, and see if it
has a problem?

-Kyle

On Sun, Jun 9, 2019, 07:31 Giovanni Fontana 
wrote:

> Hello Kurt,
>
>
>- it's perl 5, version 26, subversion 1 (v5.26.1) built for
>x86_64-linux-gnu-thread-multi
>- ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
>
>
> I guess is something from what I added since the original OPENSSL I'm able
> to build, as well as other intermediate modifications. My issue is it looks
> like the log doesn't give so much info and also the *make update* doesn't
> complete his task.
>
> BR
> Giovanni
>
> Il giorno sab 8 giu 2019 alle ore 18:07 Kurt Roeckx  ha
> scritto:
>
>> On Sat, Jun 08, 2019 at 12:26:30AM +0200, Giovanni Fontana wrote:
>> > */usr/bin/ld:libcrypto.map:0: syntax error in VERSION scriptcollect2:
>>
>> There seems to be a problem generating the libcrypto.map file for
>> you. What does the file look like? Which perl version are you
>> using? Which libc do you use?
>>
>>
>> Kurt
>>
>>


Re: Query related to SSL_CTX_set_msg_callback_arg

2019-06-09 Thread Jeremy Harris
On 09/06/2019 11:31, shalu dhamija wrote:
> Hi All,In openssl 1.0.2, I was using  SSL_CTX_set_msg_callback_arg() API to 
> set the application specific argument. And in the callback, I was retrieving 
> that argument from SSL pointer received in the callback e.g. 
> "ssl->msg_callback_arg"But in openssl1.1.1, the SSL structure members are no 
> more accessible. And I did not find any API to get the msg_callback_arg back. 
> Can someone please comment on this if there is any way to get the 
> msg_callback_arg back in the callbacks from ssl pointer.

When the callback is called, the arg you set is given to the callback
function, as a function argument.  It's not intended as a general-
purpose data stash.

-- 
Cheers,
  Jeremy


Re: failing in reproducing .so files

2019-06-09 Thread Giovanni Fontana
Hello Kurt,


   - it's perl 5, version 26, subversion 1 (v5.26.1) built for
   x86_64-linux-gnu-thread-multi
   - ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27


I guess is something from what I added since the original OPENSSL I'm able
to build, as well as other intermediate modifications. My issue is it looks
like the log doesn't give so much info and also the *make update* doesn't
complete his task.

BR
Giovanni

Il giorno sab 8 giu 2019 alle ore 18:07 Kurt Roeckx  ha
scritto:

> On Sat, Jun 08, 2019 at 12:26:30AM +0200, Giovanni Fontana wrote:
> > */usr/bin/ld:libcrypto.map:0: syntax error in VERSION scriptcollect2:
>
> There seems to be a problem generating the libcrypto.map file for
> you. What does the file look like? Which perl version are you
> using? Which libc do you use?
>
>
> Kurt
>
>


Re: Query related to session resumption in TLS1.3

2019-06-09 Thread shalu dhamija
  Hi Viktor,Thanks for your response. In my code, somehow, the ssl_read was not 
getting called ( due to some bug) due to which the session ticket was not being 
read resulting in no callback. I have fixed it and its working now.Now the 
resumption using TLS1.3 is working fine but I want to clarify the following 
behavior:As per openssl documentation:'The default number of tickets is 2; the 
default number of tickets sent following a resumption handshake is 1'. 
(https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_num_tickets.html)But in 
my case, following the resumption handshake, I am always getting two session 
tickets from the server. Is this behavior fine as it is server dependent.
Regards,Shalini Dhamija'
 
On Thursday, 16 May, 2019, 10:10:57 pm IST, Viktor Dukhovni 
 wrote:  
 
 On Thu, May 16, 2019 at 04:22:13PM +, shalu dhamija via openssl-users 
wrote:

> But the same flow does not work for TLS1.3. In TLSv1.3, sessions are
> established after the main handshake has completed. So, I have implemented
> the callback SSL_CTX_sess_set_new_cb. And in the callback, I am storing
> the session into the cache. In subsequent connections, the session is
> present in the map, SSL_set_session API returns true. But SSL_session_reused
> is always returning false.

This is not expected, perhaps your code is not quite right.

> I have the following queries:
> 1. Is the above mentioned approach applicable for TLS 1.3?

Yes.  It works, for example, in Postfix:

  
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L543-L547
  
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1001-L1004
  
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1146

> 2. There is a mention that PreShared keys are used for session
> resumption in TLS1.3.

This is misleading.  In TLS 1.3, the PSKs and session tickets have
been internally unified into a single protocol mechanism.  This
internal detail is not something that users need to worry about.

> Can someone please clarify, how should I make my
> client send psk using openssl for subsequent connection?

This is not the right question.  SSL_set_session() is all you need
for session resumption.

-- 
    Viktor.
  

Query related to SSL_CTX_set_msg_callback_arg

2019-06-09 Thread shalu dhamija
Hi All,In openssl 1.0.2, I was using  SSL_CTX_set_msg_callback_arg() API to set 
the application specific argument. And in the callback, I was retrieving that 
argument from SSL pointer received in the callback e.g. 
"ssl->msg_callback_arg"But in openssl1.1.1, the SSL structure members are no 
more accessible. And I did not find any API to get the msg_callback_arg back. 
Can someone please comment on this if there is any way to get the 
msg_callback_arg back in the callbacks from ssl pointer.
Regards,Shalini Dhamija