Implementing a toy version of TLS 1.3

This is wonderful.<p>I was super excited to dive in an find the RSA code so I could preen about Bleichenbacher&#x27;s vulnerability, but she neatly sidestepped that by doing ECDH. Then I thought, well, maybe it&#x27;s P-curve ECDH and I can preen about invalid curve attacks on static-ephemeral ECDH. But nope, X25519! My point here, apart from making fun of myself for being the kind of person who would write this stuff on a message board, is TLS 1.3 is pretty solid.<p>The &quot;block thing&quot; that&#x27;s kind of weird is, I assume, the TLS Record Layer. TLS runs (ordinarily) over TCP, which provides a non-demarcated stream of bytes. TLS breaks that stream up into records, and runs its handshake messages over one type of record, (say) HTTPS over another, and &quot;alerts&quot; over a third. The Record Layer also interacts, I think, with TLS&#x27;s misbegotten compression system?<p>In the same vein as this project (but with different goals) is Trevor Perrin&#x27;s tlslite, which is implemented in pure Python: <a href="https:&#x2F;&#x2F;github.com&#x2F;trevp&#x2F;tlslite" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;trevp&#x2F;tlslite</a>

&gt; an amazing TLS resource: tls13.ulfheim.net<p>Readers, i made a &quot;squee&quot; noise just now. Glad it was useful, this is exactly the sort of thing I wrote it for. &lt;3

This is certainly something interesting and worth trying, but I&#x27;d recommend starting with 1.2 first, because the handshake isn&#x27;t encrypted so you can follow along more easily.<p><i>I only looked at the TLS 1.3 RFC for a few small things.</i><p>As someone who has written implementations of various widely-considered-nontrivial things (mostly image and video codecs, some crypto -- but not TLS, although upon seeing this article, that may change...) for self-educational purposes, I strongly recommend that the official standard be the first thing you look at and refer to during the process. It will clarify a lot of doubts, and in the case of TLS, the RFCs are relatively readable as far as standards go.<p><i>I’m not sure why the blocks have the size they do (maybe it’s so that each one will fit inside a TCP packet ???), but in theory I think they could be up to 65535 bytes, since their size field is 2 bytes.</i><p>That&#x27;s due to either MTU or server-side write fragmentation, and the limit is 16K(+overhead). It is a stream to the application layer, but the record-layer protocol breaks it up into chunks of smaller limited size to allow for the integrity checks.<p><i>I assume a real TLS implementation would use a thread pool or coroutines or something to manage this.</i><p>That&#x27;s a very strange assumption. Depending on the API, the ones I&#x27;ve used will either just read in a loop until the length is fulfilled or an error occurs; or return an &quot;incomplete message&quot; error meaning that the caller is the one to continue reading. Getting a partial read from a TCP socket is a <i>very</i> common &quot;trap for young players&quot; --- if you don&#x27;t keep it in mind, you&#x27;ll write code that appears to work on localhost or inside a fast LAN, but fails intermittently and sometimes mysteriously over the Internet or when there&#x27;s more latency. You can never assume message boundaries when using TCP.

Learning a protocol by writing a toy client (or toy server) is a blast. It&#x27;s so satisfying to see a real, production-quality server sending real responses to your little mess.

I&#x27;m super impressed that they got it to work so quickly. What I hate about crypto is that is either wrong or right, there is no &quot;mostly working&quot; that you can identify easily and use as a debugging aid.<p>This drove me crazy when I was working on kTLS in FreeBSD. When I worked on other features (like getting checksum offload right in NIC firmware) there were easy tricks I could use for debugging, like sending a stream of all zeros. For crypto, it was basically back to first principals and code examination..

I was one of the folks kinda down on the DNS server implementation...but this, this is awesome. TLS is a serious black box to 90%+ of even veteran programmers I meet.<p>To break it down and write a small implementation showing the steps is seriously both impressive and extremely generous. Kudos!

Hopefully I have actually insightful things to say about this fun toy. However before that<p>&gt; elliptic curve “multiplication”, where n * P means “add P to itself n times”<p>Not very smoothly described but this is all multiplication meant for the natural numbers you learned in primary school too! Why is 7 x 7 = 49? Because if you start with zero and add 7, seven times, you get 49. Try it. This is an important and re-usable insight, it&#x27;s part of a larger beautiful framework of mathematics and I believe is much better instructed via modern teaching of arithmetic in schools than &quot;rote learning&quot; of times tables did for my parents.

&gt; When the HTTP response is done, we get these bytes: []byte{48, 13, 10, 13, 10, 23}. I don’t know what this is supposed to mean exactly but it seems to signal the end of the connection.<p>HTTP headers include Content-Length, so you should know when you get a truncated response, but TLS is supposed to be more general purpose, so it includes its own crypto secure end of connection indicator.

Did anyone else find this line interesting?<p>&gt; This was pretty annoying to get working because I kept passing the wrong arguments to things.<p>I think this sentiment shows up twice in fact in the article.<p>I’m not sure what language the listings are in, but it looked static-type-ish.<p>Are there things the current batch of safety focused languages do to mitigate these types of ordering errors?<p>In Kotlin, Python, and Swift, we make it a practice to always use the keywords in calls if there are multiple arguments of the same type (e.g. two or more ints). I wish I could figure out how to configure any of their linters to enforce it better.<p>Despite its late bound unsafe nature, this was just never an error I made (argument ordering) back when I used to do a lot of Smalltalk with its interwoven keyword syntax.

One thing I like about cryptography, and wish we could get politicians to understand, the mathematical steps to implement many of the core concepts are not hard. Obviously implementing them robustly such that they’re safe at scale is another matter, but “criminals” won’t have any difficulty getting access to secure implementations, and adding any kind of weakness only means that the implementations used by the public are more likely to have bugs, in addition to the legally mandated ones.