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

[Benjamin Kaduk via openssl-users]

On 06/19/2017 04:12 PM, Neetish Pathak wrote:
>
>
> On Mon, Jun 19, 2017 at 11:11 AM, Neetish Pathak  > wrote:
>
> Hi Matt,
> Thanks
> Could you help with following queries
>
> 1) On the blogpost for TLS1.3, you mentions the following in the
> session section
> The specification recommends that applications only use a session
> once (although this is not enforced). For this reason some servers
> send multiple session messages to a client. To enforce the “use
> once” recommendation applications could
> use |SSL_CTX_remove_session()| to mark a session as non-resumable
> (and remove it from the cache) once it has been used.
>
> I am a bit confused here as to why "use once" is recommended. How
> will resumption be ensured then ? I get a PSK in first connection
> and use it again for all the other connections.
>

"use once" is recommended in a limited circumstance, to prevent an
attacker listening on the network from associating the (multiple)
resumed sessions as being derived from the initial session.
This is a new possibility in TLS 1.3, since in TLS 1.2 the session
ticket was given to the client in cleartext (and presented back to the
server in cleartext), so all uses of the ticket were traceable back to
the original connection and linkable to each other.

Using a given ticket more than once in TLS 1.3 just brings things back
to basically the TLS 1.2 state in terms of linkability; it's not a
catastrophic failure or anything like that.

>
> On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell  > wrote:
>
>
>
> Yes Matt, when I switch to remote machines and test my application
> programs, I see that TLS 1.3 is faster than TLS 1.2 in the first
> connection (around same time as resumption time in TLS 1.2) itself and
> there is marginal or no improvement in the subsequent connections even
> on using resumption. Does this mean that resumption in TLS 1.3 is
> bringing not much benefit in terms of latency. It makes sense because
> round trips count for resumption or no resumption is 1 in TLS 1.3. 
>
> The only benefit with resumption is that the client can now send
> zero-RTT data. (early data). However, if we consider the overall
> latency in handshake, it is going to be the same equivalent to 1 round
> trip.
> Is my understanding correct ?
>
> Is there any way to enable early data or it gets activated by default
> once the pre-shared keys are available at both the client and server
> ends ?
>

No no no no no, many times no.
You really must not blindly enable early data without a proper protocol
analysis to determine what would happen if an attacker replayed the
early data millions of times, as is possible with the current TLS 1.3
draft specification.  There are a lot of ways to hurt yourself and your
users with it, and I strongly recommend against trying to enable it just
because it looks faster.
(There are separate APIs from the normal read/write APIs to use early
data, to make you explicitly think about whether it's safe when adding
support to an application.)


> I believe session resumption as a concept doesn't hold that much value
> from TLS 1.3 onwards since 1-RTT is directly achieved in TLS 1.3 first
> connection. Do you agree?
>

No.  Resumption saves on transferring (and validating!) certificates and
can be done without incurring the cost of an additional diffie-hellman
exchange, among other things.

-Ben
-- 
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 Mon, Jun 19, 2017 at 11:11 AM, Neetish Pathak  wrote:

> Hi Matt,
> Thanks
> Could you help with following queries
>
> 1) On the blogpost for TLS1.3, you mentions the following in the session
> section
> The specification recommends that applications only use a session once
> (although this is not enforced). For this reason some servers send multiple
> session messages to a client. To enforce the “use once” recommendation
> applications could use SSL_CTX_remove_session() to mark a session as
> non-resumable (and remove it from the cache) once it has been used.
>
> I am a bit confused here as to why "use once" is recommended. How will
> resumption be ensured then ? I get a PSK in first connection and use it
> again for all the other connections.
>
>
> 2) Can you suggest some places to put a time stamp in OpenSSL code.
>
> Thanks
> Best Regards,
> Neetish
>
> On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell  wrote:
>
>>
>>
>> On 16/06/17 23:51, Neetish Pathak wrote:
>> > Thanks Matt, Appreciate ur response and tips
>> >
>> > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell > > > wrote:
>> >
>> >
>> >
>> > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote:
>> > > On 06/16/2017 01:58 PM, Neetish Pathak wrote:
>> > >> Hello
>> > >> Thanks
>> > >> I tried reading  some content from the server side and I
>> observed the
>> > >> new_session_cb getting invoked in that case on the client side. I
>> > >> understand that may be due to delayed NewSession info transfer
>> from
>> > >> server side to client side. But it is helpful for saving the
>> session
>> > >> info on the client side. (Thanks Matt for your input)
>> > >>
>> > >> However, now I have two concerns
>> > >>
>> > >> 1) I see that latency for handshake with session resumption in
>> > TLS 1.3
>> > >> has not improved as much as it improves for TLS 1.2
>> > >> With TLS 1.3, I observed that resumption brings down the
>> connection
>> > >> time from 2.5 ms to 1.2-1.3 ms
>> > >> while with TLS 1.2 (using either session IDs or tickets), the
>> > >> connection time reduces from 2.5 ms to 0.5-0.6 ms.
>> > >>
>> > >> The whole code is similar for running the two experiments with
>> only
>> > >> max TLS version changed. Can someone comment on the latency
>> > >> measurements for the two cases.
>> > >> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion.
>> Please
>> > >> comment.
>> > >>
>> > >
>> > > Are you seeing a HelloRetryRequest in the resumption flow?  That
>> would
>> > > add an additional round trip.  (Your numbers in milliseconds are
>> of
>> > > course not transferrable to other systems; round-trips is an
>> easier to
>> > > understand number.)  RFC 5246 and draft-ietf-tls-tls13-20 both
>> have
>> > > message-flow diagrams that show the number of round trips in
>> various
>> > > handshake flows.
>> >
>> > Care should also be taken about when you are starting your "timer"
>> and
>> > when you stop it, e.g. if you stop your timer after the session
>> ticket
>> > data has been received by the client then this is not a "fair" test
>> (the
>> > connection is ready for data transfer earlier than the arrival of
>> the
>> > session ticket).
>> >
>> > I would expect to see the TLS1.3 latency for a full handshake to be
>> > around the same as for a TLS1.2 resumption handshake. With a TLS1.3
>> > resumption only marginally different. There are the same number of
>> round
>> > trips for a TLS1.3 full handshake as that there are for a resumption
>> > one. The primary difference is that the Certificate message is not
>> sent
>> > (which can be quite a large message).
>>
>

Yes Matt, when I switch to remote machines and test my application
programs, I see that TLS 1.3 is faster than TLS 1.2 in the first connection
(around same time as resumption time in TLS 1.2) itself and there is
marginal or no improvement in the subsequent connections even on using
resumption. Does this mean that resumption in TLS 1.3 is bringing not much
benefit in terms of latency. It makes sense because round trips count for
resumption or no resumption is 1 in TLS 1.3.

The only benefit with resumption is that the client can now send zero-RTT
data. (early data). However, if we consider the overall latency in
handshake, it is going to be the same equivalent to 1 round trip.
Is my understanding correct ?

Is there any way to enable early data or it gets activated by default once
the pre-shared keys are available at both the client and server ends ?

I believe session resumption as a concept doesn't hold that much value from
TLS 1.3 onwards since 1-RTT is directly achieved in TLS 1.3 first
connection. Do you agree?


> >
>> > Your timings suggest you are testing this over a LAN where the
>> effects
>> > of network latency are 

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

[Neetish Pathak]

Hi Matt,
Thanks
Could you help with following queries

1) On the blogpost for TLS1.3, you mentions the following in the session
section
The specification recommends that applications only use a session once
(although this is not enforced). For this reason some servers send multiple
session messages to a client. To enforce the “use once” recommendation
applications could use SSL_CTX_remove_session() to mark a session as
non-resumable (and remove it from the cache) once it has been used.

I am a bit confused here as to why "use once" is recommended. How will
resumption be ensured then ? I get a PSK in first connection and use it
again for all the other connections.


2) Can you suggest some places to put a time stamp in OpenSSL code.

Thanks
Best Regards,
Neetish

On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell  wrote:

>
>
> On 16/06/17 23:51, Neetish Pathak wrote:
> > Thanks Matt, Appreciate ur response and tips
> >
> > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell  > > wrote:
> >
> >
> >
> > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote:
> > > On 06/16/2017 01:58 PM, Neetish Pathak wrote:
> > >> Hello
> > >> Thanks
> > >> I tried reading  some content from the server side and I observed
> the
> > >> new_session_cb getting invoked in that case on the client side. I
> > >> understand that may be due to delayed NewSession info transfer
> from
> > >> server side to client side. But it is helpful for saving the
> session
> > >> info on the client side. (Thanks Matt for your input)
> > >>
> > >> However, now I have two concerns
> > >>
> > >> 1) I see that latency for handshake with session resumption in
> > TLS 1.3
> > >> has not improved as much as it improves for TLS 1.2
> > >> With TLS 1.3, I observed that resumption brings down the
> connection
> > >> time from 2.5 ms to 1.2-1.3 ms
> > >> while with TLS 1.2 (using either session IDs or tickets), the
> > >> connection time reduces from 2.5 ms to 0.5-0.6 ms.
> > >>
> > >> The whole code is similar for running the two experiments with
> only
> > >> max TLS version changed. Can someone comment on the latency
> > >> measurements for the two cases.
> > >> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion.
> Please
> > >> comment.
> > >>
> > >
> > > Are you seeing a HelloRetryRequest in the resumption flow?  That
> would
> > > add an additional round trip.  (Your numbers in milliseconds are of
> > > course not transferrable to other systems; round-trips is an
> easier to
> > > understand number.)  RFC 5246 and draft-ietf-tls-tls13-20 both have
> > > message-flow diagrams that show the number of round trips in
> various
> > > handshake flows.
> >
> > Care should also be taken about when you are starting your "timer"
> and
> > when you stop it, e.g. if you stop your timer after the session
> ticket
> > data has been received by the client then this is not a "fair" test
> (the
> > connection is ready for data transfer earlier than the arrival of the
> > session ticket).
> >
> > I would expect to see the TLS1.3 latency for a full handshake to be
> > around the same as for a TLS1.2 resumption handshake. With a TLS1.3
> > resumption only marginally different. There are the same number of
> round
> > trips for a TLS1.3 full handshake as that there are for a resumption
> > one. The primary difference is that the Certificate message is not
> sent
> > (which can be quite a large message).
> >
> > Your timings suggest you are testing this over a LAN where the
> effects
> > of network latency are going to be relatively low. The real benefits
> > from fewer round trips will really be seen when network latency is
> more
> > significant.
> >
> >
> >
> > In my application program, I put start and stop timer before and after
> > SSL_accept on server side and before and after SSL_connect on the client
> > side.
>
> That should be fine (my worry was that you might also be including the
> subsequent session ticket transfer).
>
> > I am not sure how I can put timers at individual steps of Handshake
> > using my client applications. I was assuming SSL and SSL_accept take
> > care of the entire handshake process.
> >
> > Yes, I am testing on local machine. I will migrate my test to remote
> > machines. But I am not really able to understand why TLS 1.3 is slower
> > on my machine.
>
> If you are on a local machine I would not expect a significant speed up
> in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce the number of
> round-trips required in order to avoid unnecessary network latency. If
> you are on a local machine then there isn't any significant network
> latency anyway - so timings are presumably dominated by the CPU
> intensive tasks. You should make sure that you are comparing like with
> like, 

[openssl-users] Building OpenSSL-1.1.0f for WinCE (Windows Embedded Compact 7.0)

[Topolewski, Tom]

Hello,

This is the first time I'm building OpenSSL for any platform (I'm pretty new to 
this solution).

I'm trying to build OpenSSL 1.1.0f library on ARM7 (backwards compatible, SDK 
version is ARM4) running Windows Embedded Compact 7.0. I'm hoping to implement 
a client interfacing web service requiring TLS 1.2 with the https connections.

I'm following this instructions:
http://documentation.unified-automation.com/uasdkcpp/1.5.2/html/CompileOpenSSLCE.html

wcecompat compatibility library is compiled successfully - I'm getting two 
libraries: wcecompat.lib and wcecompatex.lib.

Because with the 1.1.0 release the build process has changed I'm looking at 
this site as well:
https://stackoverflow.com/questions/39076244/why-there-is-no-ms-do-ms-bat-after-perl-configure-vc-win64a

Since I'm not sure where my problem is I will provide the list of steps I'm 
taking:

1. In Cygwin64 Terminal: tar -xvzf openssl-1.1.0f.tar.gz
2. In Visual Studio 2008 Command Prompt I'm changing directory to 
C:\cygwin64\home\myaccount\openssl-1.1.0f and entering the following:

set INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\atlmfc\include;C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v6.0A\include;
set LIB=C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\LIB;C:\Program Files\Microsoft SDKs\Windows\v6.0A\lib;
set LIBPATH=C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\ATLMFC\LIB;C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\LIB;
set Path=C:\Program Files (x86)\Microsoft Visual Studio 
9.0\Common7\IDE;C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\BIN;C:\Program Files (x86)\Microsoft Visual Studio 
9.0\Common7\Tools;C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\VCPackages;C:\Program Files\Microsoft 
SDKs\Windows\v6.0A\bin;C:\cygwin64\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;

set OSVERSION=WCE700
set PLATFORM=VC-CE
set TARGETCPU=ARMV4I
set WCECOMPAT="C:\cygwin64\home\myaccount\wcecompat-master"
set LIB=C:\Program Files (x86)\Windows CE 
Tools\SDKs\CA_MM2_CE7\Lib\ARMv4I;C:\Program Files\Microsoft 
SDKs\Windows\v6.0A\Lib;C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\ce\lib\ARMV4I;C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\lib
set INCLUDE=C:\Program Files (x86)\Windows CE 
Tools\SDKs\CA_MM2_CE7\Include\Armv4i;C:\Program Files (x86)\Microsoft Visual 
Studio 9.0\VC\atlmfc\include;C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v6.0A\include;
set Path=C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\ce\bin\x86_arm;C:\Perl64\site\bin;%Path%
set LIBPATH="C:\Program Files (x86)\Windows CE 
Tools\SDKs\CA_MM2_CE7\Lib\ARMv4I";C:\Program Files (x86)\Microsoft Visual 
Studio 9.0\VC\lib;C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\ce\lib\ARMV4I;

3. Configuring the make file with the following (full path to perl to make sure 
ActivePerl-5.24.0.2400 is used):

c:\Perl64\bin\perl Configure no-idea no-mdc2 no-rc5 no-asm no-ssl3 VC-CE

Configuring OpenSSL version 1.1.0f (0x1010006fL)
no-asan [default]  OPENSSL_NO_ASAN
no-asm  [option]   OPENSSL_NO_ASM
no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
no-crypto-mdebug-backtrace [default]  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128
no-egd  [default]  OPENSSL_NO_EGD
no-fuzz-afl [default]  OPENSSL_NO_FUZZ_AFL
no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
no-idea [option]   OPENSSL_NO_IDEA (skip dir)
no-md2  [default]  OPENSSL_NO_MD2 (skip dir)
no-mdc2 [option]   OPENSSL_NO_MDC2 (skip dir)
no-msan [default]  OPENSSL_NO_MSAN
no-rc5  [option]   OPENSSL_NO_RC5 (skip dir)
no-sctp [default]  OPENSSL_NO_SCTP
no-ssl-trace[default]  OPENSSL_NO_SSL_TRACE
no-ssl3 [option]   OPENSSL_NO_SSL3
no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
no-ubsan[default]  OPENSSL_NO_UBSAN
no-unit-test[default]  OPENSSL_NO_UNIT_TEST
no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
no-zlib [default]
no-zlib-dynamic [default]
Configuring for VC-CE
CC=cl
CFLAG =/W3 /WX /GF /Gy /nologo -DUNICODE -D_UNICODE 
-DOPENSSL_SYS_WINCE-DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DNO_CHMOD 
-DOPENSSL_SMALL_FOOTPRINT -D_WIN32_WCE=700 -DUNDER_CE=700 -DWCE_PLATFORM_VC-CE 
-DARM -D_ARM_ -DARMV4I -QRarch4T -QRinterwork-return -I$(WCECOMPAT)/include  
/MD /O1i
SHARED_CFLAG  =
DEFINES   =DSO_WIN32 NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL
_PIC
LFLAG =/nologo /opt:ref /subsystem:windowsce,7.00 /machine:THUMB
PLIB_LFLAG=
EX_LIBS   =3
APPS_OBJ  =win32_init.o
CPUID_OBJ =mem_clr.o

[openssl-users] Android (ARM) build support

[smds gladiator]

Hello Everyone,

I am developing an android application which has a native stack underneath.
My project will use native OpenSSL library.
What i would to know is whether android platform (ARM arch) support for
OpenSSL library is there or not.

Please help me know how do I proceed building and using in my android app.

Thank you,
Senthil Kumar G S
-- 
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 16/06/17 23:51, Neetish Pathak wrote:
> Thanks Matt, Appreciate ur response and tips
> 
> On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell  > wrote:
> 
> 
> 
> On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote:
> > On 06/16/2017 01:58 PM, Neetish Pathak wrote:
> >> Hello
> >> Thanks
> >> I tried reading  some content from the server side and I observed the
> >> new_session_cb getting invoked in that case on the client side. I
> >> understand that may be due to delayed NewSession info transfer from
> >> server side to client side. But it is helpful for saving the session
> >> info on the client side. (Thanks Matt for your input)
> >>
> >> However, now I have two concerns
> >>
> >> 1) I see that latency for handshake with session resumption in
> TLS 1.3
> >> has not improved as much as it improves for TLS 1.2
> >> With TLS 1.3, I observed that resumption brings down the connection
> >> time from 2.5 ms to 1.2-1.3 ms
> >> while with TLS 1.2 (using either session IDs or tickets), the
> >> connection time reduces from 2.5 ms to 0.5-0.6 ms.
> >>
> >> The whole code is similar for running the two experiments with only
> >> max TLS version changed. Can someone comment on the latency
> >> measurements for the two cases.
> >> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. Please
> >> comment.
> >>
> >
> > Are you seeing a HelloRetryRequest in the resumption flow?  That would
> > add an additional round trip.  (Your numbers in milliseconds are of
> > course not transferrable to other systems; round-trips is an easier to
> > understand number.)  RFC 5246 and draft-ietf-tls-tls13-20 both have
> > message-flow diagrams that show the number of round trips in various
> > handshake flows.
> 
> Care should also be taken about when you are starting your "timer" and
> when you stop it, e.g. if you stop your timer after the session ticket
> data has been received by the client then this is not a "fair" test (the
> connection is ready for data transfer earlier than the arrival of the
> session ticket).
> 
> I would expect to see the TLS1.3 latency for a full handshake to be
> around the same as for a TLS1.2 resumption handshake. With a TLS1.3
> resumption only marginally different. There are the same number of round
> trips for a TLS1.3 full handshake as that there are for a resumption
> one. The primary difference is that the Certificate message is not sent
> (which can be quite a large message).
> 
> Your timings suggest you are testing this over a LAN where the effects
> of network latency are going to be relatively low. The real benefits
> from fewer round trips will really be seen when network latency is more
> significant.
> 
> 
> 
> In my application program, I put start and stop timer before and after
> SSL_accept on server side and before and after SSL_connect on the client
> side.

That should be fine (my worry was that you might also be including the
subsequent session ticket transfer).

> I am not sure how I can put timers at individual steps of Handshake
> using my client applications. I was assuming SSL and SSL_accept take
> care of the entire handshake process.
> 
> Yes, I am testing on local machine. I will migrate my test to remote
> machines. But I am not really able to understand why TLS 1.3 is slower
> on my machine.

If you are on a local machine I would not expect a significant speed up
in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce the number of
round-trips required in order to avoid unnecessary network latency. If
you are on a local machine then there isn't any significant network
latency anyway - so timings are presumably dominated by the CPU
intensive tasks. You should make sure that you are comparing like with
like, i.e. the same ciphers, key lengths, key exchange algorithms,
curves etc between TLSv1.2 and TLSv1.3. Differences in any one of these
could obviously have significant performance impacts.

Matt

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