Adding Homemade TLS to a Homemade Web Server

Rebuilt

SubscribeSign in

Adding Homemade TLS to a Homemade Web Server I combined my self-written web server and my self-written TLS project. The surprising part was how little the HTTP layer needed to know.

Dmytro Huz Jul 04, 2026

Original series: Building Your Own Web Server + Rebuilding TLS from ScratchThis article connects two earlier series. In the web-server series, I rebuilt the HTTP side from raw sockets up to routing and file serving. In the TLS series, I rebuilt the secure-channel side: key exchange, certificates, key derivation, and encrypted records. This piece is where the two meet: what has to change when a web server stops receiving plaintext HTTP bytes and starts receiving encrypted TCP bytes?

I expected adding TLS to my web server to change almost everything.It did not. The HTTP parser stayed boring. The router stayed boring. The file-serving code stayed boring. The real change happened one layer below HTTP. I had two separate learning projects before this: a small web server built from scratch: sockets, HTTP parsing, location matching, file serving, and eventually a single-threaded event-loop server;

a small TLS-like secure channel built from scratch: ephemeral key exchange, certificate chains, server authentication, HKDF, AES-GCM records, and the difference between identity keys and session keys.

Putting them together led to one question: What changes in the web server when the bytes coming from TCP are encrypted?

The useful answer is smaller than I expected: TCP socket TLS handshake / record layer ↓ decrypted plaintext bytes HTTP parser / router / file serving ↓ plaintext HTTP response TLS record protection ↓ encrypted bytes TCP socket That is the whole architecture of the companion project. This is not production HTTPS. It does not implement the real TLS 1.3 wire format, and browsers will not connect to it with https://localhost:8443. It is a learning project. The goal is to make the integration boundary visible. Once that boundary becomes clear, HTTPS feels much less magical.

The plain web server had one assumption

Before TLS, the web server had a simple mental model. A client connects over TCP. The server reads bytes from the socket. Those bytes are HTTP bytes. The server appends them to a per-connection buffer, tries to parse an HTTP request, matches the path, reads a file, and writes an HTTP response. The flow looked like this: accept TCP connection read bytes from socket append bytes to HTTP input buffer parse HTTP request match URL against location config read file from root write HTTP response The buffer is important because TCP is a stream. One recv() call can give you half a request. Or exactly one request. Or multiple requests joined together. The parser cannot assume that one socket read equals one HTTP request. In my server, the parser consumes complete HTTP messages from a buffer. If the request is incomplete, the server waits for more bytes. If there are extra bytes after a complete request, they stay in the buffer for the next parse. For plain HTTP, socket bytes and HTTP bytes are the same thing: context.http_input.append(data) self._handle_http_messages(context) That line works only because the bytes from the socket are already plaintext HTTP. TLS breaks that assumption.

After TLS, socket bytes are no longer HTTP bytes

Once TLS is added, the TCP socket no longer carries a readable HTTP request. The client still wants to send this: GET / HTTP/1.1 Host: localhost Connection: close But that request is not placed directly on the wire. It is wrapped inside TLS records. After the handshake, those records are encrypted and authenticated. The bytes arriving at the server socket are now protocol bytes for the TLS layer, not text for the HTTP parser. That is the shift: plain listener: TCP bytes are HTTP bytes

TLS listener: TCP bytes are TLS records TLS records decrypt into HTTP bytes If the HTTP parser starts caring about certificates, keys, record sequence numbers, or AES-GCM tags, the abstraction has leaked. The HTTP parser should parse HTTP. The TLS layer should turn unsafe network bytes into authenticated plaintext bytes.

The integration point belongs below HTTP

Production servers use the same high-level boundary. NGINX does not ask the HTTP parser to understand encrypted TLS records. A TLS implementation such as OpenSSL handles the connection security first. After that, the HTTP processing layer receives plaintext HTTP bytes. My project copies that architecture in a smaller educational form: Production-ish mental model: TCP → OpenSSL/TLS state → plaintext HTTP → NGINX HTTP processing

This project: TCP → ToyTLSServerConnection → plaintext HTTP → HTTPParser / route matcher The analogy is architectural, not protocol-compatible. The project uses a small TLS-like protocol so the moving pieces are possible to read in one sitting. The handshake messages are simplified. The record framing is simplified....

Adding Homemade TLS to a Homemade Web Server

Related Articles

(no title)

Scientists reverse brain aging, with a nasal spray

AI has torched the market for junior programmers

Al Vigier: Canada's AI strategy shouldn't include secret Palantir bills

Is AI ruining our skills? Early results are in – and they're not good