Thank you for the explanation, Viktor.

On Mon, Feb 24, 2014 at 4:35 PM, Viktor Dukhovni <openssl-us...@dukhovni.org
> wrote:

> On Mon, Feb 24, 2014 at 04:10:28PM -0800, Zi Hu wrote:
>
> > Recently, I am trying to write a simple SSL client  and server code to
> test
> > the function of TLS resumption with session ticket (RFC5077).  But I
> > couldn't find any useful information on google about how to do that.
>
> OpenSSL does this automatically, when the saved session includes
> a ticket, which is true when the server sent a ticket.  This requires
> no new code on the OpenSSL client (OpenSSL needs to be recent enough
> to support session tickets).
>
>
OK, so no new code needed for the OpenSSL client. How about the server code?
Do I need to call certain APIs explicitly to ask the server to send a
session ticket to the client?


> Could someone point me some example code about TLS resumption with session
> > ticket (not session id reuse).   Or give me some instructions about which
> > APIs I should use in the client/server code to make the TLS resumption
> > work. I would really appreciate that.
>
> Resumption with session tickets is identical to resumption without
> session tickets, the ticket is part of the cached session structure.
>
>
I thought they are different.
My understanding is that using session ticket for TLS resumption shifts the
state from server to client.
That is if we use session ticket,  the client needs to cache the ticket
from the server, then uses it for later resumption. But the server doesn't
need to remember anything.
While if we DON'T use session ticket, the server needs to cache the session
information (e.g. session id) for resumption.

Am I misunderstanding something here?

thanks
-Zi



> --
>         Viktor.
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    openssl-users@openssl.org
> Automated List Manager                           majord...@openssl.org
>

Reply via email to