Call for testing TLS 1.3

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Call for testing TLS 1.3

Matt Caswell-2


On 08/06/18 02:48, John Jiang wrote:
> Is it possible to check Key/IV update feature via these tools?
> Thanks!

Yes. See the "CONNECTED COMMANDS" sections of these pages:
https://www.openssl.org/docs/manmaster/man1/s_server.html
https://www.openssl.org/docs/manmaster/man1/s_client.html

Basically typing "k" or "K" from an s_server/s_client session will issue
a KeyUpdate message. Using the capitalised form ("K"), additionally
requests a KeyUpdate from the peer.

Matt


>
> 2018-05-23 20:33 GMT+08:00 Matt Caswell <[hidden email]
> <mailto:[hidden email]>>:
>
>
>
>     On 23/05/18 12:39, John Jiang wrote:
>     > Hi,
>     > If just using s_server and s_client, can I test the TLS 1.3 features,
>     > likes HelloRetryRequest and resumption?
>
>     Yes.
>
>     To create a normal (full handshake) TLSv1.3 connection just use
>     s_server/s_client in the normal way, e.g.
>
>     $ openssl s_server -cert cert.pem -key key.pem
>     $ openssl s_client
>
>     To test resumption first create a full handshake TLSv1.3 connection and
>     save the session:
>
>     $ openssl s_server -cert cert.pem -key key.pem
>     $ openssl s_client -sess_out session.pem
>
>     Close the s_client instance by entering "Q" followed by enter. Then
>     (without closing the s_server instance) resume the session:
>
>     $ openssl s_client -sess_in session.pem
>
>
>     A HelloRetryRequest will occur if the key share provided by the client
>     is not acceptable to the server. By default the client will send an
>     X25519 key share, so if the server does not accept that group then an
>     HRR will result, e.g.
>
>     $ openssl s_server -cert cert.pem -key key.pem -groups P-256
>     $ openssl s_client
>
>
>     Of course a HelloRetryRequest all happens at the protocol layer and is
>     invisible as far as a user of the command line apps is concerned. You
>     will have to look at what happens "on the wire" to actually see it in
>     action - for example by using wireshark. Alternatively you can compile
>     OpenSSL with the "enable-ssl-trace" option, and pass the "-trace" flag
>     to s_server or s_client to see what protocol messages are being
>     exchanged.
>
>     Matt
>
>
>
>     >
>     > 2018-04-29 18:43 GMT+08:00 Kurt Roeckx <[hidden email] <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>>:
>     >
>     >     The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
>     >     1.3 brings a lot of changes that might cause incompatibility. For
>     >     an overview see https://wiki.openssl.org/index.php/TLS1.3
>     <https://wiki.openssl.org/index.php/TLS1.3>
>     >     <https://wiki.openssl.org/index.php/TLS1.3
>     <https://wiki.openssl.org/index.php/TLS1.3>>
>     >
>     >     We are considering if we should enable TLS 1.3 by default or not,
>     >     or when it should be enabled. For that, we would like to know how
>     >     applications behave with the latest beta release.
>     >
>     >     When testing this, it's important that both sides of the
>     >     connection support the same TLS 1.3 draft version. OpenSSL
>     >     currently implements draft 26. We would like to see tests
>     >     for OpenSSL acting as client and server.
>     >
>     >     https://github.com/tlswg/tls13-spec/wiki/Implementations
>     <https://github.com/tlswg/tls13-spec/wiki/Implementations>
>     >     <https://github.com/tlswg/tls13-spec/wiki/Implementations
>     <https://github.com/tlswg/tls13-spec/wiki/Implementations>> lists
>     >     other TLS 1.3 implementations and the draft they currently
>     >     support. Note that the versions listed there might not be for the
>     >     latest release. It also lists some https test servers.
>     >
>     >     We would really like to see a diverse set of applictions being
>     >     tested. Please report any results you have to us.
>     >
>     >
>     >     Kurt
>     >
>     >     --
>     >     openssl-users mailing list
>     >     To unsubscribe:
>     >     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
>     >     <https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>>
>     >
>     >
>     >
>     >
>     --
>     openssl-users mailing list
>     To unsubscribe:
>     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
>
>
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Call for testing TLS 1.3

Hubert Kario
On Friday, 8 June 2018 10:26:07 CEST Matt Caswell wrote:

> On 08/06/18 02:48, John Jiang wrote:
> > Is it possible to check Key/IV update feature via these tools?
> > Thanks!
>
> Yes. See the "CONNECTED COMMANDS" sections of these pages:
> https://www.openssl.org/docs/manmaster/man1/s_server.html
> https://www.openssl.org/docs/manmaster/man1/s_client.html
>
> Basically typing "k" or "K" from an s_server/s_client session will issue
> a KeyUpdate message. Using the capitalised form ("K"), additionally
> requests a KeyUpdate from the peer.
Are there similar commands to perform or control post-handshake client
authentication?


--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Call for testing TLS 1.3

Hubert Kario
In reply to this post by Kurt Roeckx
On Sunday, 29 April 2018 12:43:26 CEST Kurt Roeckx wrote:

> The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> 1.3 brings a lot of changes that might cause incompatibility. For
> an overview see https://wiki.openssl.org/index.php/TLS1.3
>
> We are considering if we should enable TLS 1.3 by default or not,
> or when it should be enabled. For that, we would like to know how
> applications behave with the latest beta release.
>
> When testing this, it's important that both sides of the
> connection support the same TLS 1.3 draft version. OpenSSL
> currently implements draft 26. We would like to see tests
> for OpenSSL acting as client and server.
>
> https://github.com/tlswg/tls13-spec/wiki/Implementations lists
> other TLS 1.3 implementations and the draft they currently
> support. Note that the versions listed there might not be for the
> latest release. It also lists some https test servers.
>
> We would really like to see a diverse set of applictions being
> tested. Please report any results you have to us.
We are moving forward with the TLS 1.3 support in tlsfuzzer and early results
with OpenSSL look good.

We do have a lot more sketched out than actually done though: https://
github.com/tomato42/tlsfuzzer/projects/1 (in total about 170 different
scenarios are planned with just 12 implemented).
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Call for testing TLS 1.3

Matt Caswell-2
In reply to this post by Hubert Kario


On 18/06/18 21:23, Hubert Kario wrote:

> On Friday, 8 June 2018 10:26:07 CEST Matt Caswell wrote:
>> On 08/06/18 02:48, John Jiang wrote:
>>> Is it possible to check Key/IV update feature via these tools?
>>> Thanks!
>>
>> Yes. See the "CONNECTED COMMANDS" sections of these pages:
>> https://www.openssl.org/docs/manmaster/man1/s_server.html
>> https://www.openssl.org/docs/manmaster/man1/s_client.html
>>
>> Basically typing "k" or "K" from an s_server/s_client session will issue
>> a KeyUpdate message. Using the capitalised form ("K"), additionally
>> requests a KeyUpdate from the peer.
>
> Are there similar commands to perform or control post-handshake client
> authentication?
Yes. As mentioned on the above s_server link, type "c" from an s_server
session to send a certificate request to the client.

Matt



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

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Call for testing TLS 1.3

John Jiang
2018-06-19 6:21 GMT+08:00 Matt Caswell <[hidden email]>:


On 18/06/18 21:23, Hubert Kario wrote:
> On Friday, 8 June 2018 10:26:07 CEST Matt Caswell wrote:
>> On 08/06/18 02:48, John Jiang wrote:
>>> Is it possible to check Key/IV update feature via these tools?
>>> Thanks!
>>
>> Yes. See the "CONNECTED COMMANDS" sections of these pages:
>> https://www.openssl.org/docs/manmaster/man1/s_server.html
>> https://www.openssl.org/docs/manmaster/man1/s_client.html
>>
>> Basically typing "k" or "K" from an s_server/s_client session will issue
>> a KeyUpdate message. Using the capitalised form ("K"), additionally
>> requests a KeyUpdate from the peer.
>
> Are there similar commands to perform or control post-handshake client
> authentication?

Yes. As mentioned on the above s_server link, type "c" from an s_server
session to send a certificate request to the client.
With the mentioned pages, I don't get how to test 0-RTT.
But it sounds that OpenSSL already supports this feature.

Thanks!


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Call for testing TLS 1.3

Matt Caswell-2


On 20/06/18 07:11, John Jiang wrote:

> 2018-06-19 6:21 GMT+08:00 Matt Caswell <[hidden email]
> <mailto:[hidden email]>>:
>
>
>
>     On 18/06/18 21:23, Hubert Kario wrote:
>     > On Friday, 8 June 2018 10:26:07 CEST Matt Caswell wrote:
>     >> On 08/06/18 02:48, John Jiang wrote:
>     >>> Is it possible to check Key/IV update feature via these tools?
>     >>> Thanks!
>     >>
>     >> Yes. See the "CONNECTED COMMANDS" sections of these pages:
>     >> https://www.openssl.org/docs/manmaster/man1/s_server.html
>     <https://www.openssl.org/docs/manmaster/man1/s_server.html>
>     >> https://www.openssl.org/docs/manmaster/man1/s_client.html
>     <https://www.openssl.org/docs/manmaster/man1/s_client.html>
>     >>
>     >> Basically typing "k" or "K" from an s_server/s_client session will issue
>     >> a KeyUpdate message. Using the capitalised form ("K"), additionally
>     >> requests a KeyUpdate from the peer.
>     >
>     > Are there similar commands to perform or control post-handshake client
>     > authentication?
>
>     Yes. As mentioned on the above s_server link, type "c" from an s_server
>     session to send a certificate request to the client.
>
> With the mentioned pages, I don't get how to test 0-RTT.
> But it sounds that OpenSSL already supports this feature.

It is on those pages - just not in the "CONNECTED COMMANDS" section.

To test 0-RTT early data start s_server with the "-early_data" flag:

$ openssl s_server -early_data

Obtain a session that can later be used for sending early data:

$ openssl s_client -sess_out session.pem

Type "Q" in the s_client window to close the connection. Now you can do
a 0-RTT handshake and send early data (assuming the existence of a file
"myearlydata.dat" containing the early data you want to send):

$ openssl s_client -sess_in session.pem -early_data myearlydata.dat


Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Call for testing TLS 1.3

John Jiang

2018-06-20 17:01 GMT+08:00 Matt Caswell <[hidden email]>:


On 20/06/18 07:11, John Jiang wrote:
> 2018-06-19 6:21 GMT+08:00 Matt Caswell <[hidden email]
> <mailto:[hidden email]>>:
>
>
>
>     On 18/06/18 21:23, Hubert Kario wrote:
>     > On Friday, 8 June 2018 10:26:07 CEST Matt Caswell wrote:
>     >> On 08/06/18 02:48, John Jiang wrote:
>     >>> Is it possible to check Key/IV update feature via these tools?
>     >>> Thanks!
>     >>
>     >> Yes. See the "CONNECTED COMMANDS" sections of these pages:
>     >> https://www.openssl.org/docs/manmaster/man1/s_server.html
>     <https://www.openssl.org/docs/manmaster/man1/s_server.html>
>     >> https://www.openssl.org/docs/manmaster/man1/s_client.html
>     <https://www.openssl.org/docs/manmaster/man1/s_client.html>
>     >>
>     >> Basically typing "k" or "K" from an s_server/s_client session will issue
>     >> a KeyUpdate message. Using the capitalised form ("K"), additionally
>     >> requests a KeyUpdate from the peer.
>     >
>     > Are there similar commands to perform or control post-handshake client
>     > authentication?
>
>     Yes. As mentioned on the above s_server link, type "c" from an s_server
>     session to send a certificate request to the client.
>
> With the mentioned pages, I don't get how to test 0-RTT.
> But it sounds that OpenSSL already supports this feature.

It is on those pages - just not in the "CONNECTED COMMANDS" section.

To test 0-RTT early data start s_server with the "-early_data" flag:

$ openssl s_server -early_data

Obtain a session that can later be used for sending early data:

$ openssl s_client -sess_out session.pem

Type "Q" in the s_client window to close the connection. Now you can do
a 0-RTT handshake and send early data (assuming the existence of a file
"myearlydata.dat" containing the early data you want to send):

$ openssl s_client -sess_in session.pem -early_data myearlydata.dat

If s_server doesn't use option -early_data, the NewSessionTicket won't contain early_data extension,
and then in the second connection, s_client won't send early data even option -early_data is used.
Right?
Is it possible to take s_client to send early data, even though the server don't support 0-RTT.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Call for testing TLS 1.3

Matt Caswell-2


On 21/06/18 10:44, John Jiang wrote:
> If s_server doesn't use option -early_data, the NewSessionTicket won't
> contain early_data extension,
> and then in the second connection, s_client won't send early data even
> option -early_data is used.
> Right?

Correct.

> Is it possible to take s_client to send early data, even though the
> server don't support 0-RTT.

You can start s_server with the -early_data option and connect to it via
s_client to get the session with the early_data extension in it. Then
stop and restart s_server without the early_data extension. Start
s_client and attempt to send early_data. The early_data will get
rejected and a full handshake will occur instead.

Or, another possibility is to do things as I originally suggested (so
that s_client sends early data that the server accepts), but then use
s_client *again* reusing the same session to send early data. The replay
protection will kick in, and s_server will refuse the early data.

Matt

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