Hi Matt, Thanks for your reply! 2018-05-23 20:33 GMT+08:00 Matt Caswell <m...@openssl.org>:
> > 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: 0000 - 54 03 c8 0e e6 75 f3 ef-3f 7a 73 89 bc 87 69 ab T....u..?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.].0....t.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 y6r........B._.. 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..+.....<N... Start Time: 1527153377 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- Should I see PSK identity here? Or, it is the TLS 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? 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 <k...@roeckx.be > > <mailto:k...@roeckx.be>>: > > > > 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> > > > > 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> 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> > > > > > > > > > -- > 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