Re: [openssl-users] Call for testing TLS 1.3

[Matt Caswell]

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

Re: [openssl-users] Call for testing TLS 1.3

[John Jiang]

2018-06-20 17:01 GMT+08:00 Matt Caswell :

>
>
> On 20/06/18 07:11, John Jiang wrote:
> > 2018-06-19 6:21 GMT+08:00 Matt Caswell  > >:
> >
> >
> >
> > 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.
>
> 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

Re: [openssl-users] Call for testing TLS 1.3

[Matt Caswell]

On 20/06/18 07:11, John Jiang wrote:
> 2018-06-19 6:21 GMT+08:00 Matt Caswell  >:
> 
> 
> 
> 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.

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

Re: [openssl-users] Call for testing TLS 1.3

[John Jiang]

2018-06-19 6:21 GMT+08:00 Matt Caswell :

>
>
> 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

Re: [openssl-users] Call for testing TLS 1.3

[Matt Caswell]

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




signature.asc
Description: OpenPGP digital signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Call for testing TLS 1.3

[Hubert Kario]

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

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 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

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Call for testing TLS 1.3

[Matt Caswell]

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  >:
> 
> 
> 
> 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  
> > >>:
> > 
> >     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.
> > 
> > 
> >     Kurt
> > 
> >     -- 
> >     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
> 
> 
> 
> 
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Call for testing TLS 1.3

[John Jiang]

Is it possible to check Key/IV update feature via these tools?
Thanks!

2018-05-23 20:33 GMT+08:00 Matt Caswell :

>
>
> 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  > >:
> >
> > 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.
> >
> >
> > Kurt
> >
> > --
> > 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
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Call for testing TLS 1.3

[Benjamin Kaduk via openssl-users]

(For those who are not Jouni, there is some spec work needed for
TLS 1.3/EAP integration as well, occurring in the IETF EMU working group.
I assume Jouni is on the mailing list and knows this already)

-Ben

On Mon, May 28, 2018 at 03:28:13PM +0300, Jouni Malinen wrote:
> On Sun, Apr 29, 2018 at 12:43:26PM +0200, Kurt Roeckx wrote:
> > 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.
> 
> It looks like couple of TLS 1.3 changes result in breaking functionality
> for various EAP methods that are based on TLS unless significant changes
> in both the EAP method definition and implementations are done before
> enabling the new TLS version. This seems to have an impact to at least
> EAP-TLS, EAP-PEAP, EAP-TTLS, and EAP-FAST.
> 
> As far as wpa_supplicant (EAP peer) and hostapd (EAP server)
> implementations are concerned, I've prepared changes to make EAP-TLS
> work with TLS 1.3, but the other EAP methods are still failing for
> various known (and to some extend, unknown) issues. Anyway, I'm
> currently explicitly disabling TLS 1.3 support with OpenSSL by default
> in these application due to these issues and the expected
> interoperability issues and as such, the OpenSSL 1.1.1 release default
> behavior regarding TLS 1.3 support should not have impact for these
> applications. That said, other EAP implementations may want to do
> something similar or face possibility of breaking functionality if
> OpenSSL 1.1.1 does go out with TLS 1.3 enabled by default and both ends
> of the EAP connection have TLS 1.3 enabled.
> 
> -- 
> Jouni MalinenPGP id EFC895FA
> -- 
> 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] Call for testing TLS 1.3

[Jouni Malinen]

On Sun, Apr 29, 2018 at 12:43:26PM +0200, Kurt Roeckx wrote:
> 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.

It looks like couple of TLS 1.3 changes result in breaking functionality
for various EAP methods that are based on TLS unless significant changes
in both the EAP method definition and implementations are done before
enabling the new TLS version. This seems to have an impact to at least
EAP-TLS, EAP-PEAP, EAP-TTLS, and EAP-FAST.

As far as wpa_supplicant (EAP peer) and hostapd (EAP server)
implementations are concerned, I've prepared changes to make EAP-TLS
work with TLS 1.3, but the other EAP methods are still failing for
various known (and to some extend, unknown) issues. Anyway, I'm
currently explicitly disabling TLS 1.3 support with OpenSSL by default
in these application due to these issues and the expected
interoperability issues and as such, the OpenSSL 1.1.1 release default
behavior regarding TLS 1.3 support should not have impact for these
applications. That said, other EAP implementations may want to do
something similar or face possibility of breaking functionality if
OpenSSL 1.1.1 does go out with TLS 1.3 enabled by default and both ends
of the EAP connection have TLS 1.3 enabled.

-- 
Jouni MalinenPGP id EFC895FA
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Call for testing TLS 1.3

[Matt Caswell]

On 24/05/18 10:58, John Jiang wrote:
> Should I see PSK identity here? Or, it is the TLS session ticket.

It's the session ticket.


> 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
> 
> It looks option "-groups" just specifies the most preferable named groups,
> but other groups still could be negotiated. Right?

No, it restricts the groups acceptable to the server.

> 
> I found interesting things from trace logs.
> 
> BTW, the TLS 1.3 wiki [1] stats that the TLS 1.3 cipher suites are named:
> TLS13-AES-256-GCM-SHA384
> TLS13-CHACHA20-POLY1305-SHA256
> TLS13-AES-128-GCM-SHA256
> TLS13-AES-128-CCM-8-SHA256
> TLS13-AES-128-CCM-SHA256
> But with version 1.1.1-pre6, they are using the formal names,
> like TLS_AES_256_GCM_SHA384.

Ah, right thanks - we renamed them to the standard names a while ago. I
fixed the wiki.

Matt



> 
> [1] https://wiki.openssl.org/index.php/TLS1.3
> 
> Thanks!
>  
> 
> 
> Matt
> 
> 
> 
> > 
> > 2018-04-29 18:43 GMT+08:00 Kurt Roeckx  
> > >>:
> > 
> >     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.
> > 
> > 
> >     Kurt
> > 
> >     -- 
> >     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
> 
> 
> 
> 
> 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Call for testing TLS 1.3

[John Jiang]

Hi Matt,
Thanks for your reply!

2018-05-23 20:33 GMT+08:00 Matt Caswell :

>
> 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
>
This way looks the same to test resumption on TLS 1.2.

The followings are some logs from my test.
The first connection:
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
Protocol  : TLSv1.3
Cipher: TLS_AES_256_GCM_SHA384
Session-ID:
Session-ID-ctx:
Master-Key:
B4A20A467729A8179ECE5912AD87A0E5A784B8573A6F98CB414498142A10A37593B10DE254197A98E05CE65BDD664776
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1527153377
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---

The second connection:
---
Reused, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
Protocol  : TLSv1.3
Cipher: TLS_AES_256_GCM_SHA384
Session-ID:
601F249C2033D5E5DF23D3380E6A2D81B335AF420D59849BB2023C415D0553C5
Session-ID-ctx:
Master-Key:
68695BD547856C14E04C747CE884F876B1564DADC66F28CD24B95DF3240FE0C0F93F59ED650B5EE45F6D3EA40A71C993
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
 - 54 03 c8 0e e6 75 f3 ef-3f 7a 73 89 bc 87 69 ab
Tu..?zs...i.
0010 - cf e6 ff d1 f9 d8 24 36-0d e5 67 52 30 7c ea 0c
..$6..gR0|..
0020 - c8 a2 67 ad 24 f6 29 cc-2c 95 48 36 e8 87 f6 4e
..g.$.).,.H6...N
0030 - c1 e8 44 a7 49 9d d6 61-36 32 37 80 01 1a 67 38
..D.I..a627...g8
0040 - ee b7 fb 83 d8 fc 66 69-51 29 3e c4 81 38 c5 2f
..fiQ)>..8./
0050 - 62 a2 fe 65 76 20 91 b4-fb 7b e3 eb 06 fa b7 d6   b..ev
...{..
0060 - 1a 1e 2e b5 e0 ea c1 a3-d2 bf 12 bf 38 94 29 10
8.).
0070 - 79 52 de 5d ef 30 d6 a7-01 a5 74 05 69 d1 31 61
yR.].0t.i.1a
0080 - a8 05 ac 83 d1 ab 17 82-c0 cc 1d 23 96 4e d2 af
...#.N..
0090 - 74 56 aa f2 24 8c 02 f9-90 b3 e1 65 8f 81 12 a1
tV..$..e
00a0 - 79 36 72 a1 cf 0e a7 f0-fb b5 d0 42 81 5f ca 13
y6rB._..
00b0 - 24 97 a3 92 40 07 bd 5b-2c 3e 9d e8 af 3e f0 56
$...@..[,>...>.V
00c0 - 9d 00 86 b2 30 fe 4b 68-c0 2e 17 d6 aa a7 5f 5b
0.Kh.._[
00d0 - 3f 0f 30 81 a4 2b a1 fd-f6 b5 8c 3c 4e 03 cb de
?.0..+. 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
>
It looks option "-groups" just specifies the most preferable named groups,
but other groups still could be negotiated. Right?


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.
>
I found interesting things from trace logs.

BTW, the TLS 1.3 wiki [1] stats that the TLS 1.3 cipher suites are named:
TLS13-AES-256-GCM-SHA384
TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES-128-GCM-SHA256
TLS13-AES-128-CCM-8-SHA256
TLS13-AES-128-CCM-SHA256
But with version 1.1.1-pre6, they are using the formal names,
like TLS_AES_256_GCM_SHA384.

[1] https://wiki.openssl.org/index.php/TLS1.3

Thanks!


>
> Matt
>
>
>
> >
> > 2018-04-29 18:43 GMT+08:00 Kurt Roeckx  > >:
> >
> > 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 

Re: [openssl-users] Call for testing TLS 1.3

[Matt Caswell]

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  >:
> 
> 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.
> 
> 
> Kurt
> 
> -- 
> 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] Call for testing TLS 1.3

[John Jiang]

Hi,
If just using s_server and s_client, can I test the TLS 1.3 features, likes
HelloRetryRequest and resumption?

2018-04-29 18:43 GMT+08:00 Kurt Roeckx :

> 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.
>
>
> Kurt
>
> --
> 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] Call for testing TLS 1.3

[Salz, Rich via openssl-users]

>Interoperability issues with middle-boxes or existing software written for 
> TLS 1.2.
 
Facebook, Google, and Mozilla did lots of testing with TLS 1.3 and middleboxes. 
 If something was missed, the whole Internet will have problems.  Existing 
software is the question we are trying to answer.

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

Re: [openssl-users] Call for testing TLS 1.3

[Dennis Clarke]

On 30/04/18 05:41 PM, Matt Caswell wrote:



On 30/04/18 21:55, Dennis Clarke wrote:

On 30/04/18 03:48 PM, Salz, Rich via openssl-users wrote:

   I think that makes a very strong argument that TLS 1.3 should be
enabled by default if it all possible.



Question would be "why would it not be?"


TLSv1.3 behaves differently to TLSv1.2. Applications written with
TLSv1.2 in mind might not work as expected when TLSv1.3 is negotiated.

Some of the issues that might be encountered are here:

https://wiki.openssl.org/index.php/TLS1.3

We have already seen a handful of issues. For example in this one an
application has implemented a PSK callback. Due to the way PSK works in
TLSv1.3 the callback can get called earlier in the process than in
TLSv1.2. Suddenly in the presence of TLSv1.3 this particular application
callback has started to crash (we don't know why yet):

https://github.com/openssl/openssl/issues/6110



I'm having no joy with apache 2.4.33 which just tossed a sigILL :

Reading mod_ssl.so
t@1 (l@1) program terminated by signal ILL (illegal opcode)
0x70d97320: TLSv1_2_enc_data   :.word0x
Current function is ssl_init_ctx_protocol
  613   ctx = SSL_CTX_new(method);
(dbx) where 


current thread: t@1
  [1] 0x70d97320(0x1002dc9d0, 0x0, 0x0, 0xfff8, 
0x0, 0x1002dccf8), at 0x70d97320
  [2] SSL_CTX_new(0x70d942b8, 0x1002dc9d0, 0x3b40, 0x2, 
0x742619fc, 0x74367460), at 0x7424bc00
=>[3] ssl_init_ctx_protocol(s = 0x10026ddc0, p = 0x1001f8a68, ptemp = 
0x100228c68, mctx = 0x1002be698), line 613 in "ssl_engine_init.c"
  [4] ssl_init_ctx(s = 0x10026ddc0, p = 0x1001f8a68, ptemp = 
0x100228c68, mctx = 0x1002be698), line 1076 in "ssl_engine_init.c"
  [5] ssl_init_server_ctx(s = 0x10026ddc0, p = 0x1001f8a68, ptemp = 
0x100228c68, sc = 0x1002be658, pphrases = 0x1002b51a0), line 1740 in 
"ssl_engine_init.c"
  [6] ssl_init_ConfigureServer(s = 0x10026ddc0, p = 0x1001f8a68, ptemp 
= 0x100228c68, sc = 0x1002be658, pphrases = 0x1002b51a0), line 1842 in 
"ssl_engine_init.c"
  [7] ssl_init_Module(p = 0x1001f8a68, plog = 0x100226c58, ptemp = 
0x100228c68, base_server = 0x10022ac78), line 369 in "ssl_engine_init.c"
  [8] ap_run_post_config(pconf = 0x1001f8a68, plog = 0x100226c58, ptemp 
= 0x100228c68, s = 0x10022ac78), at 0x10007d094

  [9] main(argc = 3, argv = 0x76d8), line 739 in "main.c"
(dbx) list
  613   ctx = SSL_CTX_new(method);
  614
  615   mctx->ssl_ctx = ctx;
  616
  617   SSL_CTX_set_options(ctx, SSL_OP_ALL);
  618
  619   #if OPENSSL_VERSION_NUMBER < 0x1010L
  620   /* always disable SSLv2, as per RFC 6176 */
  621   SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2);
  622
(dbx)

I'm digging around in there now ...

(dbx) listi 612, 613
  612   #endif
  613   ctx = SSL_CTX_new(method);
0x6e689b60: ssl_init_ctx_protocol+0x0330:   ldx  [%fp + 
1991], %o0
0x6e689b64: ssl_init_ctx_protocol+0x0334:   call 
_PROCEDURE_LINKAGE_TABLE_+0x1160 [PLT] ! 0x6e9afa60

0x6e689b68: ssl_init_ctx_protocol+0x0338:   nop
0x6e689b6c: ssl_init_ctx_protocol+0x033c:   mov  %o0, %o1
0x6e689b70: ssl_init_ctx_protocol+0x0340:   stx  %o1, 
[%fp + 1999]


(dbx) print method
method = 0x70d942b8
(dbx) x 0x70d942b8/8x
0x70d942b8: DTLSv1_2_enc_data+0x0400:0x0001 0x 0x 
0x 0x 0x 0x 0x

(dbx)
(dbx) x 0x6e9afa60/16x
0x6e9afa60: _PROCEDURE_LINKAGE_TABLE_+0x1160 [PLT]:  0x0100 
0x 0x0b22 0xf6d1 0x8239 0x60bf 0x81c0 0x6000
0x6e9afa70: _PROCEDURE_LINKAGE_TABLE_+0x1170 [PLT]:  0x0100 
0x 0x0100 0x 0x0100 0x 0x0100 0x

(dbx)

no idea why an illegal opcode slipped into the mix here but I may revert
back to 1.1.0h and do a sanity check, run httpd inside the debugger or
at least the foregorund and then try 1.1.1-pre5 again. I don't want to
have to unwind frames here and try to figure out why that call was sick.

oodles of fun.

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

Re: [openssl-users] Call for testing TLS 1.3

[Matt Caswell]

On 30/04/18 21:55, Dennis Clarke wrote:
> On 30/04/18 03:48 PM, Salz, Rich via openssl-users wrote:
>>   I think that makes a very strong argument that TLS 1.3 should be
>> enabled by default if it all possible.
> 
> 
> Question would be "why would it not be?"

TLSv1.3 behaves differently to TLSv1.2. Applications written with
TLSv1.2 in mind might not work as expected when TLSv1.3 is negotiated.

Some of the issues that might be encountered are here:

https://wiki.openssl.org/index.php/TLS1.3

We have already seen a handful of issues. For example in this one an
application has implemented a PSK callback. Due to the way PSK works in
TLSv1.3 the callback can get called earlier in the process than in
TLSv1.2. Suddenly in the presence of TLSv1.3 this particular application
callback has started to crash (we don't know why yet):

https://github.com/openssl/openssl/issues/6110


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

Re: [openssl-users] Call for testing TLS 1.3

[Viktor Dukhovni]

> On Apr 30, 2018, at 4:55 PM, Dennis Clarke  wrote:
> 
> Question would be "why would it not be?"

Interoperability issues with middle-boxes or existing software written for TLS 
1.2.

-- 
Viktor.

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

Re: [openssl-users] Call for testing TLS 1.3

[Dennis Clarke]

On 30/04/18 03:48 PM, Salz, Rich via openssl-users wrote:

  I think that makes a very strong argument that TLS 1.3 should be enabled by 
default if it all possible.



Question would be "why would it not be?"

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

Re: [openssl-users] Call for testing TLS 1.3

[Salz, Rich via openssl-users]

>The issue is most likely that no one "in the wild" has done any testing 
of significance.

I thought the Akamai numbers were significant.

I can certainly see tls1.2 exchange but there is nothing for tls1.3 and
so I am working on getting a site up pronto ( in the wild ) to test.

I am sorry if it wasn't clear, but I was referring to *Akamai* not *OpenSSL.*  
Let me repost the whole message edited a bit.

AKAMAI has partially deployed TLS 1.3 on one of its networks using its own 
server. Customer can opt-in to beta-test.  AKAMAI has already seen hundreds of 
millions of connections, with [xxx, elided] megabytes of data exchanged.   
AKAMAI has found no issues.  AKAMAI does not do 0RTT. This is production 
traffic, not staging or test. AKAMAI has received no customer complaints.

I was surprised by how many connections and how much data AKAMAI is already 
seeing.  I think that makes a very strong argument that TLS 1.3 should be 
enabled by default if it all possible.



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

Re: [openssl-users] Call for testing TLS 1.3

[Dennis Clarke]

On 30/04/18 03:01 PM, Salz, Rich via openssl-users wrote:

Sorry, typo.  We've had hundreds of millions of connections, with megabytes of data 
exchanged."



The issue is most likely that no one "in the wild" has done any testing 
of significance.


I can certainly see tls1.2 exchange but there is nothing for tls1.3 and
so I am working on getting a site up pronto ( in the wild ) to test.

thus :

subject=CN = www.openssl.org

issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3136 bytes and written 344 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384
etc etc etc

However tls1_3 results in .. not much, yet.


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

Re: [openssl-users] Call for testing TLS 1.3

[Salz, Rich via openssl-users]

Sorry, typo.  We've had hundreds of millions of connections, with megabytes of 
data exchanged."

On 4/30/18, 11:52 AM, "Salz, Rich"  wrote:

Akamai has had millions of connections with megabytes of data exchanged. 
This is with partial deployment on our network, and requiring customers to opt 
in to enable beta-testing.  We have found no issues.  We don't do 0RTT. We are 
using our own server.

I was surprised by how many connections and how much data we are already 
seeing.  I think that makes a very strong argument that TLS 1.3 should be 
enabled by default if it all possible.



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

Re: [openssl-users] Call for testing TLS 1.3

[Salz, Rich via openssl-users]

Akamai has had millions of connections with megabytes of data exchanged. This 
is with partial deployment on our network, and requiring customers to opt in to 
enable beta-testing.  We have found no issues.  We don't do 0RTT. We are using 
our own server.

I was surprised by how many connections and how much data we are already 
seeing.  I think that makes a very strong argument that TLS 1.3 should be 
enabled by default if it all possible.

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

Re: [openssl-users] Call for testing TLS 1.3

[Dennis Clarke]

Yes, by default only 3 are anbled, but there are also 2 other
supported included in ALL.


I must have done something wrong here as I see these 3 only :


n0$ LD_LIBRARY_PATH=`pwd`/openssl-1.1.1-pre5_SunOS5.10_sparc64vii+.001 \
> openssl-1.1.1-pre5_SunOS5.10_sparc64vii+.001/apps/openssl \
> ciphers -V -s -tls1_3 | \
> awk '{printf("%8s  %10s  %30s  %12s  %10s  %28s  %s\n", $4, $1, $3, 
$5, $6, $7, $8 )}' | sort
 TLSv1.3   0x13,0x01  TLS_AES_128_GCM_SHA256Kx=any 
Au=any   Enc=AESGCM(128)  Mac=AEAD
 TLSv1.3   0x13,0x02  TLS_AES_256_GCM_SHA384Kx=any 
Au=any   Enc=AESGCM(256)  Mac=AEAD
 TLSv1.3   0x13,0x03TLS_CHACHA20_POLY1305_SHA256Kx=any 
Au=anyEnc=CHACHA20/POLY1305(256)  Mac=AEAD

n0$


Note that Apache requires a patch that was commited 4 weeks ago to
support TLS 1.3. It just seems to make TLS 1.3 known to the ...


I'll look around for that, thank you!

Dennis



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

Re: [openssl-users] Call for testing TLS 1.3

[Kurt Roeckx]

On Sun, Apr 29, 2018 at 10:05:39PM -0400, Dennis Clarke wrote:
> On 29/04/18 06:43 AM, 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
> 
> Looking at https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites
> there are five pure TLSv1.3 ciphersuites listed. At the moment the
> OpenSSL 1.1.1-pre5 utters :
> 
> n0$ LD_LIBRARY_PATH=`pwd` apps/openssl ciphers -v | grep " TLSv1\.3 "
> TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any  Au=any  Enc=AESGCM(256) Mac=AEAD
> TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any  Au=any
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any  Au=any  Enc=AESGCM(128) Mac=AEAD
> n0$

Yes, by default only 3 are anbled, but there are also 2 other
supported included in ALL.

> So using a client connect test to apache means build up a separate
> instance ( and toolchain perhaps ) running with pre4 beta only and a
> self cert and then ... isolate to only TLS_AES_256_GCM_SHA384 ( for
> example ) in the apache ssl config. This will take some days just for
> an initial test framework and then try :

Note that Apache requires a patch that was commited 4 weeks ago to
support TLS 1.3. It just seems to make TLS 1.3 known to the
configuration files and things like that, I'm not sure why that was
needed in the first place.


Kurt

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

Re: [openssl-users] Call for testing TLS 1.3

[Dennis Clarke]

On 29/04/18 06:43 AM, 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


Looking at https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites
there are five pure TLSv1.3 ciphersuites listed. At the moment the
OpenSSL 1.1.1-pre5 utters :

n0$ LD_LIBRARY_PATH=`pwd` apps/openssl ciphers -v | grep " TLSv1\.3 "
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any  Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any  Au=any 
Enc=CHACHA20/POLY1305(256) Mac=AEAD

TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any  Au=any  Enc=AESGCM(128) Mac=AEAD
n0$

So using a client connect test to apache means build up a separate
instance ( and toolchain perhaps ) running with pre4 beta only and a
self cert and then ... isolate to only TLS_AES_256_GCM_SHA384 ( for
example ) in the apache ssl config. This will take some days just for
an initial test framework and then try :

n0$ LD_LIBRARY_PATH=`pwd` apps/openssl s_client -connect 
www.tls13.net:443 -tls1_3

CONNECTED(0004)
4294967296:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert 
handshake failure:ssl/record/rec_layer_s3.c:1569:SSL alert number 40

---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 239 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
Protocol  : TLSv1.3
Cipher: 
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1525051962
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
n0$

This should be fun to test.


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.


I'll take a look.

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

[openssl-users] Call for testing TLS 1.3

[Kurt Roeckx]

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.


Kurt

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