TLS 1.3 #167

kazu-yamamoto · 2016-11-15T04:59:25Z

Note

My implementation has been fully merged to this upstream. This contents are now outdated.

Introduction

This is the current status of TLS 1.3 implementation in Haskell. This text is repeatedly updated if necessary.

If you are not Haskellers, please refer to this first.

If you want to use TLS 1.3 of the tls package in Haskell, you should track the tls13 branch of the kazu-yamamoto's fork:

% git clone https://github.com/kazu-yamamoto/hs-tls.git
% git checkout -t orign/tl13

All draft versions are available on this branch. See the commit logs.

On the tls13 branch, commits are frequently squashed, rebased and force-updated. So, you should do the following if necessary:

% git fetch
% git reset --hard origin/tls13

Supported

TLS 1.3 draft 18,19,20,21,22,23,24,25,26,27,28
Server: full negotiations, HRR, PSK, 0RTT
Client: full negotiations, HRR, PSK, 0RTT

Interoperability

TLS 1.3 draft 28 interoperability

Other clients to Haskell TLS server:

	Full	HRR	PSK	0RTT
picotls	OK	OK	OK	OK
OpenSSL	OK	OK	OK	OK
NSS	OK	OK	OK	OK
BoringSSL	OK	OK	OK	OK
Firefox Nightly	OK	-	-	-
Chrome Canary	OK	-	-	-

Haskell client to other servers:

	Full	HRR	PSK	0RTT
picotls	OK	OK	OK	OK
OpenSSL	OK	OK	OK	OK
NSS	OK	OK	OK	OK
BoringSSL	OK	OK	OK	OK
tris
www.tls13.facebook.com	OK	OK	OK	OK	fizz
enabled.tls13.com	OK	OK	OK	OK	BoringSSL
tls13.crypto.mozilla.org	OK	OK	NG	NG

BoringSSL server sends multiple NSTs in a single handshake

TLS 1.3 draft 23/24 interoperability

Other clients to Haskell TLS server:

	Full	HRR	PSK	0RTT
picotls	OK	OK	OK	OK
OpenSSL	OK	OK	OK	OK
NSS	OK	OK	OK	OK
BoringSSL	OK	OK	OK	OK
Firefox Nightly	OK	-	-	-
Chrome Canary	OK	-	-	-

Haskell client to other servers:

	Full	HRR	PSK	0RTT
picotls	OK	OK	OK	OK
OpenSSL	OK	OK	OK	OK
NSS	OK	OK	OK	OK
BoringSSL	OK	OK	OK	OK
tris
www.tls13.facebook.com	OK	OK	OK	OK	fizz
enabled.tls13.com	OK	OK	OK	OK	BoringSSL
tls13.crypto.mozilla.org	OK	OK	NG	NG

draft 22

Other clients to Haskell TLS server:

	Full	HRR	PSK	0RTT
picotls	OK	OK	OK	OK
OpenSSL	OK	OK	OK	OK
NSS	OK	OK	OK	OK
BoringSSL	OK	OK	OK	OK

Haskell client to other servers:

	Full	HRR	PSK	0RTT
picotls	OK	OK	OK	OK
OpenSSL	OK	OK	OK	OK
NSS	OK	OK	OK	OK
BoringSSL	OK	OK	OK	OK
tris	OK	NG	OK	OK

tris does not support HRR yet.

draft 21

Other clients to Haskell TLS server:

	Full	HRR	PSK	0RTT
OpenSSL	OK	OK	OK	OK
NSS	OK		OK	OK

Haskell client to other servers:

	Full	HRR	PSK	0RTT
OpenSSL	OK	OK	OK	OK
NSS	OK	NG	OK	NG

draft 20

Other clients to Haskell TLS server:

	Full	HRR	PSK	0RTT
OpenSSL	OK	OK	OK	OK
NSS	OK		OK	OK

Haskell client to other servers:

	Full	HRR	PSK	0RTT
OpenSSL	OK	OK	OK	OK
NSS	OK

draft 19

The specification of draft 19 has a bug that EndOfEarlyData is not included in transcript calculation. Draft 19 implementators should include it.

I don't spend time for draft 19 anymore because of draft 20.

Other clients to Haskell TLS server:

	Full	HRR	PSK	0RTT
picotls	OK		OK
OpenSSL	OK		OK	OK

Haskell client to other servers:

	Full	HRR	PSK	0RTT
OpenSSL	OK	OK	OK	OK

draft 18

Other clients to Haskell TLS server

	Full	HRR	PSK	0RTT
Nightly	OK		OK	OK
NSS	OK		OK	OK
Canary	OK	OK	OK	*1
picotls	OK	OK	OK	OK
OpenSSL	OK		OK	OK

*1 I don't know this browser supports 0RTT

Haskell client to other servers

	Full	HRR	PSK	0RTT	note
Tris	OK	*1	OK	OK	blog.cloudflare.com
NSS	OK	OK	OK	OK
BoringSSL	OK	OK	OK	OK	tls.ctf.network
picotls	OK	OK	OK	OK
OpenSSL	OK	OK	OK	NG*2

*1 Not supported
*2 0RTT is not used. Instead, PSK is used.
Note: tls13.crypto.mozilla.org(NSS) is suffering from a mod_nss bug relating to session ticket

Things merged or fixed

X25519 and X448 in NamedCurve supporting X25519 and X448 in the IES style. #205
RSAPSS in SignatureAndHashAlgorithm Supporting RSAPSS defined in TLS 1.3 #207
Cryptonite: ECC for ECDH, P384, X25519, etc Rewriting ECC haskell-crypto/cryptonite#114
Cryptonite: Fixing segfault of P256 in C: using pointSize in withTempPoint to fix #151. haskell-crypto/cryptonite#152
Cryptonite: ECDHE key validation Using cryptonite-0.24 #245
In-memory session manager for single-use tickets TLS session manager yesodweb/wai#630
Cryptonite: DHE key validation Negotiated FFDHE parameters #256

Todo

Server: checking ticket age: absolute
Client: checking ticket age
Client: verifying certificate chain (cf --no-validate)
Client: Set 0RTTAccepted in ctx (checking EarlyData from a server)
Client authentication
Key update
Test cases

Todo but NOT motivated

DHE

The text was updated successfully, but these errors were encountered:

kazu-yamamoto · 2016-11-21T01:35:27Z

Usage of `tls-simpleclient`

tls-simpleclient takes a server name and optionally a port number then generates HTTP/1.1 GET.

-O : logging received HTML to the file
--http1.1: ensuring that HTTP/1.1 is used instead of HTTP/1.0
--no-valid: skipping verification of a server certificate

Full negotiation

Specify -g x25519 to not trigger HRR.

% stack exec tls-simpleclient -- --no-valid -O html-log.txt -g x25519 --http1.1 127.0.0.1 13443
groups = [X25519], keyshare = [X25519]
TLS 1.3: AES128GCM-SHA256 SHA256
NewSessionTicket received

HRR

The default value of -g is x448,x25519,p256. To trigger HRR, omit the -g option. The first value is only used for key-share.

% stack exec tls-simpleclient -- --no-valid -O html-log.txt --http1.1 127.0.0.1 13443
groups = [X448,X25519,P256], keyshare = [X448]
Retrying client hello...
groups = [X25519], keyshare = [X25519]
TLS 1.3: AES128GCM-SHA256 SHA256
NewSessionTicket received

PSK

Specify --session. The client stores a ticket in the memory and tries to make a new connection with the ticket. Note that a proper keyshare is selected on the second try to avoid HRR. "PSK[0] is used" indicates that PSK is succeeded.

% stack exec tls-simpleclient -- --no-valid -O html-log.txt --session --http1.1 127.0.0.1 13443
groups = [X448,X25519,P256], keyshare = [X448]
Retrying client hello...
groups = [X25519], keyshare = [X25519]
TLS 1.3: AES128GCM-SHA256 SHA256
NewSessionTicket received

Resuming the session...
groups = [X25519], keyshare = [X25519]
TLS 1.3: AES128GCM-SHA256 SHA256
PSK[0] is used
NewSessionTicket received

0RTT

Use -Z to specify a file containing early-data. "0RTT is accepted" indicates that 0RTT is succeded.

% cat early-data.txt 
GET / HTTP/1.1
Host: 127.0.0.1

% stack exec tls-simpleclient -- --no-valid -O html-log.txt -Z $SOMEWHERE/early-data.txt --session --http1.1 127.0.0.1 13443
groups = [X448,X25519,P256], keyshare = [X448]
Retrying client hello...
groups = [X25519], keyshare = [X25519]
TLS 1.3: AES128GCM-SHA256 SHA256
NewSessionTicket received

Resuming the session...
groups = [X25519], keyshare = [X25519]
Sending 0RTT request...
TLS 1.3: AES128GCM-SHA256 SHA256
PSK[0] is used
0RTT is accepted
NewSessionTicket received

kazu-yamamoto · 2016-11-21T01:36:45Z

Using TLS 1.3 servers

Using Mighty

First, clone mighty:

% git clone https://github.com/kazu-yamamoto/mighttpd2
% cd mighttpd2
% git checkout -t origin/tls13

Then, clone the tls13 branches of warp-tls and wai:

% sh setup.sh

Build it (this takes a long time at the first time):

% stack setup
% stack build
% stack exec which mighty
/Users/kazu/work/mighttpd2/.stack-work/install/x86_64-osx/lts-9.14/8.0.2/bin/mighty

Create index.html and copy your certificate and private key files:

% echo '<html></html>' > /tmp/index.html
% cp $SOMEWHERE privkey.pem
% cp $SOMEWHERE cert.pem

And run:

% stack exec mighty -- conf/example.conf conf/example.route
HTTP service on port 8080 and HTTP/TLS service on port 13443.
28 Nov 2017 13:58:18: pid = 18974: Mighty started

Next time

% sh setup.sh
% stack build
% stack exec which mighty
/Users/kazu/work/mighttpd2/.stack-work/install/x86_64-osx/lts-9.14/8.0.2/bin/mighty
% stack exec mighty -- conf/example.conf conf/example.route

Public servers

Mighty supporting TLS 1.3 draft 23: https://mew.org/

tls-simpleserver

% cd hs-tls
% sh setup.sh
% stack build
% stack exec tls-simpleserver -- --key=$SOMEWHERE/key.pem --certificate=$SOMEWHERE/certificate.pem -v -Z 13443

kazu-yamamoto · 2016-11-30T02:21:07Z

How to use this package for non Haskellers

First time

You need GHC(Glasgow Haskell Compiler) to compile Haskell code. Recently, many Haskellers use stack as a package manager. stack kindly installs GHC! So, you should install stack first:

% curl -sSL https://get.haskellstack.org/ | sh
% which stack
/usr/local/bin/stack

Install GHC:

% stack setup

GHC is installed in ~/.stack/programs/x86_64-osx/ghc-8.0.2. Let's use the GHC interpreter via stack:

% stack ghci
> 1 + 2
3
> Ctr+D
%

Now, you should clone this repository:

% git clone https://github.com/kazu-yamamoto/hs-tls.git
% cd hs-tls
% git checkout -t origin/tls13

Let's build Haskell tls. At the first time, this takes a long time!

% sh setup.sh
% stack build

OK. tls-simpleclient and tls-simpleserver are created. Let's use tls-simpleclient via stack:

% stack exec tls-simpleclient -- --no-valid --http1.1 mew.org 13443

Next time

% sh setup.sh
% stack build

kazu-yamamoto · 2016-12-20T08:20:52Z

Proposed APIs for 0RTT

Supported supportedEarlyData :: AcceptEarlyData Word32 for server and SendEarlyData ByteString for client
Information infoIsEarlyDataAccepted :: telling whether or not TLS 1.3 early data is accepted. If not, the client should resend the data

axman6 · 2017-05-25T02:41:39Z

I was wondering if there's much progress on this in the last 5 months - it would be good to add a checklist of tasks done and yet to be done to the issue description above - would help people know if there's something they an help with too. Link for reference if you haven't used this feature before: https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-comments

kazu-yamamoto · 2017-05-25T03:21:47Z

I'm actively working:
https://github.com/kazu-yamamoto/hs-tls/commits/tls13-18
https://github.com/kazu-yamamoto/hs-tls/commits/tls13-19

The first commit of tls13-18 contains what's done and todo.
But I should copy them to here.

I will support TLS 1.3 ID20 soon. Some features of TLS 1.3 have already merged into the master.

kazu-yamamoto · 2017-05-26T03:18:33Z

@axman6 I re-wrote the first text. I hope you like it.

kazu-yamamoto · 2017-05-26T03:31:02Z

I also wrote usage of tls-simpleclient. See above.

axman6 · 2017-05-26T03:37:39Z

You've got one above and beyond Kazu, this is fantastic! Glad to see things are progressing so well. Do you have any comments on what an interface using the early data feature would look like? Wondering how easy it might be to use in general network code and also if it'll be accessible from say Wai.

axman6 · 2017-05-26T03:39:11Z

You've gone above and beyond*

kazu-yamamoto · 2017-05-26T03:56:19Z

Client side:

You can set early data to ClientParams clientTLS13ZeroRttData and can tell whether or not it is accepted through Context (the later is still todo, see above).

Server side:

recvData simply returns early data. There is no way to tell whether or not it is early data at this moment.

See: haskell-tls#167

kazu-yamamoto · 2017-05-26T06:30:14Z

I also wrote how to use this lib in the server side. See above.

See: haskell-tls#167 This jumbo patch will be eventually divided into logical patches after standardization of TLS 1.3 is finished and before a pull request is sent. This patch is jumbo to observe the entire patch to make difference minimum. This patch is repeatedly rebased and overridden to clean up the TLS 1.3 code. Take care.

See: haskell-tls#167

See: haskell-tls#167 This jumbo patch will be eventually divided into logical patches after standardization of TLS 1.3 is finished and before a pull request is sent. This patch is jumbo to observe the entire patch to make difference minimum. This patch is repeatedly rebased and overridden to clean up the TLS 1.3 code. Take care.

See: haskell-tls#167

ocheron · 2017-05-30T19:16:38Z

What is "isPointValid for draft 19" exactly?

kazu-yamamoto · 2017-05-31T03:21:57Z

TLS 1.3 draft says:

For the curves secp256r1, secp384r1 and secp521r1, peers MUST
validate each other's public value Y by ensuring that the point is a
valid point on the elliptic curve. The appropriate validation
procedures are defined in Section 4.3.7 of [X962] and alternatively
in Section 5.6.2.6 of [KEYAGREEMENT]. This process consists of three
steps: (1) verify that Y is not the point at infinity (O), (2) verify
that for Y = (x, y) both integers are in the correct interval, (3)
ensure that (x, y) is a correct solution to the elliptic curve
equation. For these curves, implementers do not need to verify
membership in the correct subgroup.

For X25519 and X448, the contents of the public value are the byte
string inputs and outputs of the corresponding functions defined in
[RFC7748], 32 bytes for X25519 and 56 bytes for X448.

So, the EllipticCurve class or something should provide isPointValid.
But I have no idea on how to implement this for X25519 and X448.

vincenthz · 2017-05-31T07:27:02Z

@kazu-yamamoto decodePoint already take care of validity checking by construction. ed25519 doesn't need "point-validation"

ocheron · 2017-06-01T19:52:56Z

@kazu-yamamoto Thanks for the reference, I didn't find it.

This is mostly right, with the point format chosen for X25519 and X448 there is not much to validate.

One small exception though: RFC7748 mentions an optional all-zero result check after D-H.
This is actually already implemented in the C code cryptonite is based on, but not returned by the Haskell APIs.

This check becomes a MUST in draft-ietf-tls-rfc4492bis § 5.10 and 5.11.

kazu-yamamoto · 2017-06-01T23:39:38Z

This is mostly right, with the point format chosen for X25519 and X448 there is not much to validate.

Check length but this is already implemented in cryptonite. :-)

One small exception though: RFC7748 mentions an optional all-zero result check after D-H.
This is actually already implemented in the C code cryptonite is based on, but not returned by the Haskell APIs.

We should implement it.

ocheron · 2017-06-16T09:22:41Z

We should implement it.

We don't need to do anything special in tls if cryptonite has a check for point-at-infinity in ECIES, like described on the Wikipedia page or SEC 1 standard. All-zero value is identity element of X25519 and X448.

But this means ECIES functions deriveEncrypt and deriveDecrypt should have a CryptoFailable result. The API is only 6-month old, so maybe not to late to change.

kazu-yamamoto · 2017-06-26T01:28:51Z

@ocheron Would you bring this issue to cryptonite repo?

ocheron · 2017-06-26T17:03:44Z

Yes that's my plan.

ocheron · 2017-06-29T19:27:06Z

Quick status update:

Inconsistent behavior in Crypto.ECC.decodePoint haskell-crypto/cryptonite#165 is fixed in cryptonite HEAD
ECDH and ECIES failures haskell-crypto/cryptonite#178 is created to get opinion on API change

[EDIT: both now fixed in cryptonite-0.24]

erikd · 2018-06-23T08:02:24Z

Anything I can do to help move this along?

kazu-yamamoto · 2018-06-25T00:11:13Z

I'm waiting for RFC8446 to be published. :-)
https://www.rfc-editor.org/auth48/rfc8446

erikd · 2018-06-25T02:23:13Z

Ah ok, that I cannot help you with :).

kazu-yamamoto self-assigned this Feb 22, 2017

ocheron mentioned this issue May 19, 2017

Bytes vs ByteString #229

Closed

kazu-yamamoto added a commit to kazu-yamamoto/hs-tls that referenced this issue May 26, 2017

Supporting TLS 1.3 ID 20.

928079b

See: haskell-tls#167

kazu-yamamoto mentioned this issue May 26, 2017

TLS 1.3 yesodweb/wai#592

Closed

kazu-yamamoto added a commit to kazu-yamamoto/hs-tls that referenced this issue May 26, 2017

Supporting TLS 1.3 draft 19.

17129b5

See: haskell-tls#167

kazu-yamamoto added a commit to kazu-yamamoto/hs-tls that referenced this issue May 26, 2017

Supporting TLS 1.3 draft 20.

5551cdc

See: haskell-tls#167

kazu-yamamoto added a commit to kazu-yamamoto/hs-tls that referenced this issue May 29, 2017

Supporting TLS 1.3 draft 19.

803499b

See: haskell-tls#167

kazu-yamamoto added a commit to kazu-yamamoto/hs-tls that referenced this issue May 29, 2017

Supporting TLS 1.3 draft 20.

6b14867

See: haskell-tls#167

kazu-yamamoto added the TLS1.3 label May 30, 2017

ocheron mentioned this issue May 31, 2017

Inconsistent behavior in Crypto.ECC.decodePoint haskell-crypto/cryptonite#165

Closed

Lekensteyn mentioned this issue Dec 15, 2017

tris: integrate Haskell TLS in interop test cloudflare/tls-tris#59

Open

kazu-yamamoto mentioned this issue Jul 30, 2018

Extensions for TLS 1.3 #278

Merged

kazu-yamamoto closed this as completed Sep 13, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

TLS 1.3 #167

TLS 1.3 #167

kazu-yamamoto commented Nov 15, 2016 •

edited

Loading

kazu-yamamoto commented Nov 21, 2016 •

edited

Loading

kazu-yamamoto commented Nov 21, 2016 •

edited

Loading

kazu-yamamoto commented Nov 30, 2016 •

edited

Loading

kazu-yamamoto commented Dec 20, 2016 •

edited

Loading

axman6 commented May 25, 2017 •

edited

Loading

kazu-yamamoto commented May 25, 2017

kazu-yamamoto commented May 26, 2017

kazu-yamamoto commented May 26, 2017

axman6 commented May 26, 2017

axman6 commented May 26, 2017

kazu-yamamoto commented May 26, 2017

kazu-yamamoto commented May 26, 2017

ocheron commented May 30, 2017

kazu-yamamoto commented May 31, 2017

vincenthz commented May 31, 2017

ocheron commented Jun 1, 2017

kazu-yamamoto commented Jun 1, 2017

ocheron commented Jun 16, 2017

kazu-yamamoto commented Jun 26, 2017

ocheron commented Jun 26, 2017

ocheron commented Jun 29, 2017 •

edited

Loading

erikd commented Jun 23, 2018

kazu-yamamoto commented Jun 25, 2018

erikd commented Jun 25, 2018

TLS 1.3 #167

TLS 1.3 #167

Comments

kazu-yamamoto commented Nov 15, 2016 • edited Loading

Note

Introduction

Supported

Interoperability

TLS 1.3 draft 28 interoperability

Other clients to Haskell TLS server:

Haskell client to other servers:

TLS 1.3 draft 23/24 interoperability

Other clients to Haskell TLS server:

Haskell client to other servers:

draft 22

Other clients to Haskell TLS server:

Haskell client to other servers:

draft 21

Other clients to Haskell TLS server:

Haskell client to other servers:

draft 20

Other clients to Haskell TLS server:

Haskell client to other servers:

draft 19

Other clients to Haskell TLS server:

Haskell client to other servers:

draft 18

Other clients to Haskell TLS server

Haskell client to other servers

Things merged or fixed

Todo

Todo but NOT motivated

kazu-yamamoto commented Nov 21, 2016 • edited Loading

Usage of tls-simpleclient

Full negotiation

HRR

PSK

0RTT

kazu-yamamoto commented Nov 21, 2016 • edited Loading

Using TLS 1.3 servers

Using Mighty

Next time

Public servers

tls-simpleserver

kazu-yamamoto commented Nov 30, 2016 • edited Loading

How to use this package for non Haskellers

First time

Next time

kazu-yamamoto commented Dec 20, 2016 • edited Loading

Proposed APIs for 0RTT

axman6 commented May 25, 2017 • edited Loading

kazu-yamamoto commented May 25, 2017

kazu-yamamoto commented May 26, 2017

kazu-yamamoto commented May 26, 2017

axman6 commented May 26, 2017

axman6 commented May 26, 2017

kazu-yamamoto commented May 26, 2017

kazu-yamamoto commented May 26, 2017

ocheron commented May 30, 2017

kazu-yamamoto commented May 31, 2017

vincenthz commented May 31, 2017

ocheron commented Jun 1, 2017

kazu-yamamoto commented Jun 1, 2017

ocheron commented Jun 16, 2017

kazu-yamamoto commented Jun 26, 2017

ocheron commented Jun 26, 2017

ocheron commented Jun 29, 2017 • edited Loading

erikd commented Jun 23, 2018

kazu-yamamoto commented Jun 25, 2018

erikd commented Jun 25, 2018

kazu-yamamoto commented Nov 15, 2016 •

edited

Loading

kazu-yamamoto commented Nov 21, 2016 •

edited

Loading

Usage of `tls-simpleclient`

kazu-yamamoto commented Nov 21, 2016 •

edited

Loading

kazu-yamamoto commented Nov 30, 2016 •

edited

Loading

kazu-yamamoto commented Dec 20, 2016 •

edited

Loading

axman6 commented May 25, 2017 •

edited

Loading

ocheron commented Jun 29, 2017 •

edited

Loading