Re: [openssl-users] session resumption tls1.2/tls1.3

2017-07-24 Thread Neetish Pathak
On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell  wrote:

>
>
> On 18/07/17 22:27, Neetish Pathak wrote:
> > Hi ,
> > thanks Matt, this is helpful
> >
> >
> > One more query on how I can enable 0.5 RTT data from the server side. It
> > is mentioned in TLS 1.3 specification. I thought it can be implemented
> > by sending early data  from server side after reading the early data.
>
> That is correct, and is as documented on this page:
>
> https://www.openssl.org/docs/manmaster/man3/SSL_write_early_data.html



Thanks Matt
To send 0.5 RTT data I m sending the early_data from the server side just
after the early_read data. But when I see the wire-shark logs, I see that
the server data is sent only once the complete handshake has taken place.
(which is the same as using SSL_write after SSL_accept).
I am performing following steps on client and server respectively as per
understanding developed from previous discussions

*Pseudocode for client*

tcp_connect

write_early(data)

ssl_connect

if(early_data_write_failed){
  ssl_write(data)
}

ssl_read


*Pseudocode for server*

tcp_accept

read_early{

 if(read_early_success){
  write_early(data)
  }
}

ssl_accept

if(read_early_fail){
ssl_read
ssl_write(data)
}


I am measuring latency on the *client side* from TCP connection start  till
it completes the read (ssl_read returns) (analogues to making a request
from client and reading response).
Please suggest what may be going wrong basically with these queries

1) Why is there no difference (or negligible) in latencies when i use early
write and then later ssl_read compared to when I execute normal write/read
on the client side

2) Why does the server not send data (for early write) after the server
Hello(and other encrypted message) message even when early_write succeeds
on server side. Why does server wait to finish the handshake. I know it
waits because I see client sending encrypted messages after server hello
message before my intended application data gets sent from server. These
encrypted messages from the client side are the usual messages from the
client side for handshake completion.

3) Also, the performance of TLS 1.3 using early data or resumption is worse
than TLS 1.2 resumption on LAN. I see on wire-shark that encrypted messages
get exchanged in TLS 1.3 during handshake which are plaintext in TLS 1.2. I
think that causes extra latency. So can we say that TLS 1.3 resumption is
not recommended for LAN for performance enhancement when compared with TLS
1.2 resumption. On WAN, I see TLS 1.3 resumption at par with TLS 1.2
resumption and full handshake better for TLS 1.3.

Thanks
Best regards,
Neetish












> > But then how can that data be read on the client side since
> > read_early_data api is invalid on client side ?
>
> 0.5 RTT data is sent from the server to an unauthenticated client. At
> this point in the process the server has sent all of its messages
> (including its Certificate/CertificateVerify/Finished messages) but it
> has not received the Client Finished or any client
> Certificate/CertificateVerify if one is going to be sent.
>
> From the client's perspective 0.5 RTT data is received *after* it has
> processed the server's Certificate/CertificateVerify/Finished messages),
> and after it has sent its own Finished (and
> Certificate/CertificateVerify if appropriate). In other words from the
> client's perspective the server is fully authenticated and 0.5 RTT data
> is indistinguishable from post-handshake data. Just use SSL_read() as
> normal to receive it.
>
> Matt
> --
> 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] Difference between libssl.a in static openssl build versus libssl.a in dynamic openssl build ???

2017-07-24 Thread Michael Wojcik
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Joe Flowers
> Sent: Monday, July 24, 2017 08:54
> To: Salz, Rich; openssl-users@openssl.org
> Subject: Re: [openssl-users] Difference between libssl.a in static openssl 
> build versus libssl.a in dynamic openssl build ???

>> You know you are going from something horribly out of date to something very 
>>out of date, right?

> Yes.

>> Can’t you at least move to 1.0.2?

> That is out of my hands and is almost entirely irrelevant to the information 
> I asked for and need.

Perhaps, but it's not irrelevant to your question, because:

- The OpenSSL build process has been updated significantly since the days of 
1.0.0 or 1.0.1 (your original message said 1.0.0e, but the directory paths you 
quoted say 1.0.1e), so it's easier for people to comment on build questions 
regarding supported releases.

- More importantly, the people who participate on this list have limited 
resources and other responsibilities. It makes sense for them to focus on 
questions from people who are using supported releases. That doesn't mean no 
one should help you, or that no one will; but it would be courteous to 
acknowledge that fact.

Now, on to your original question:

> When I perform a dynamic openssl build with the following commands, I get 
> (among other files) a libssl.a file.
> ...
> When I perform a static openssl build with the following commands, I get 
> (among other files) another libssl.a file.
> ...
> I am trying to determine which one of these two newer libssl.a files I should 
> use to replace the older ~0.9.7 libssl.a file.

For Linux, I believe it depends on whether you need PIC code, and whether you 
need the OpenSSL FIPS module. I'm going to ignore the latter case, because FIPS 
is a nightmarish wasteland of horrors. FIPS aside, I don't know of any reason 
*not* to use PIC code. The OpenSSL builds I work with always build sharable 
(PIC, on Linux and appropriate UNIXes) code, which we then put into static 
libraries, which are linked into dynamic libraries / shared objects containing 
our own cover routines.

There might be some other use case for building OpenSSL statically on Linux, 
but I'm not aware of one. Other list members may be.

Now, whether a dynamic-build libssl.a (and libcrypto.a) can be used as drop-in 
replacements for your 0.9.7 versions is another question entirely, of course.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 

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


Re: [openssl-users] Difference between libssl.a in static openssl build versus libssl.a in dynamic openssl build ???

2017-07-24 Thread Joe Flowers
> You know you are going from something horribly out of date to something
very out of date, right?

Yes.

> Can’t you at least move to 1.0.2?

That is out of my hands and is almost entirely irrelevant to the
information I asked for and need. Even if I could upgrade to 1.0.2 the same
problem and same question would remain.






On Mon, Jul 24, 2017 at 7:42 AM, Salz, Rich via openssl-users <
openssl-users@openssl.org> wrote:

> You know you are going from something horribly out of date to something
> very out of date, right?
>
>
>
> Can’t you at least move to 1.0.2?
>
> --
> 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] Default key length of DH/DHE/ECDH/ECDHE

2017-07-24 Thread Jakob Bohm

On 24/07/2017 13:35, SaAtomic wrote:
I'm not sure if this question is more suitable for the OpenVPN or the 
OpenSSl users list.


OpenSSL as the ssl/tls library for OpenVPN offers DH with and without 
ephemeral keys as well as with or without elliptic curves.


With OpenVPN 2.4.0 and OpenSSL 1.0.2l only ECDHE and DHE are 
available, but I do not have the option to define a key length,

so I assume OpenSSL's default key length will be used.

What is the default key length of OpenSSL for DH, DHE, ECDH and ECDHE?


For DHE, the key size is set by the group parameters, for
which there is no default other than what the application
(in this case OpenVPN) sets.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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


Re: [openssl-users] Default key length of DH/DHE/ECDH/ECDHE

2017-07-24 Thread Salz, Rich via openssl-users
For the elliptic curve choices, the curve picked (NIST256, NIST384, whatever) 
determines the keysize.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


[openssl-users] Default key length of DH/DHE/ECDH/ECDHE

2017-07-24 Thread SaAtomic
I'm not sure if this question is more suitable for the OpenVPN or the OpenSSl 
users list.

OpenSSL as the ssl/tls library for OpenVPN offers DH with and without ephemeral 
keys as well as with or without elliptic curves.

With OpenVPN 2.4.0 and OpenSSL 1.0.2l only ECDHE and DHE are available, but I 
do not have the option to define a key length,
so I assume OpenSSL's default key length will be used.

What is the default key length of OpenSSL for DH, DHE, ECDH and ECDHE?

Thank you and regards,
SaAtomic
 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] Difference between libssl.a in static openssl build versus libssl.a in dynamic openssl build ???

2017-07-24 Thread Salz, Rich via openssl-users
You know you are going from something horribly out of date to something very 
out of date, right?

Can’t you at least move to 1.0.2?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users