HTTP, HTTPS and TLS

What is it?

This roadmap builds the web client layer: a URL parser, HTTP GET and POST, wget and curl commands, TLS through Mbed TLS, a store of trusted root certificates, HTTPS, and a pool of reusable connections. It is the foundation for the web browser, the email client, update downloads and anything else that talks to a server on the internet. Impossible OS has none of it running today. The Mbed TLS source is already in the tree but is not compiled, and HTTP needs the TCP connections and sockets that earlier roadmaps have not built yet. All eight sections are unstarted.

How does it work?

What exists. Three pieces are in place:

Mbed TLS 3.6.2, vendored unmodified in src/libs/mbedtls/ and recorded in PROVENANCE.md and the credits file. It is dual-licensed Apache-2.0 or GPL-2.0-or-later, both compatible with this project's GPL-3.0-only licence. The Makefile excludes it from the kernel build, and its mbedtls_config.h is still the stock upstream configuration, which enables the hosted networking and timing modules a freestanding kernel cannot use. The freestanding port is owned by Kernel Libraries and is not finished.
A kernel random number generator: csprng_fill() in csprng.h, which the TLS port is meant to use for its entropy instead of inventing its own.
SHA-256 and other hashes in sha256.h and its neighbours.

There is no URL parser, no HTTP code, no certificate store and no wget or curl.

Planned design. The plain-HTTP half comes first:

url_parse() splits a URL into scheme, host, port (80 or 443 by default), path and query without allocating.
http_get() sends an HTTP/1.1 request over a TCP socket, parses the status line and headers, and follows up to five redirects.
http_post() adds request bodies and decodes chunked transfer encoding.
wget <url> [-o file] and curl <url> commands with a progress display.

Then the secure half:

The Mbed TLS kernel port: memory through kmalloc, randomness through the kernel generator, and a transport that sends over the kernel socket layer.
A certificate store loaded from C:\Impossible\System\Certs\ca-bundle.crt, planned as the Mozilla root bundle of about 130 authorities. That bundle is MPL-2.0 data, so adding it needs its own provenance and credits entries.
https_get() and https_post() with TLS 1.2 and 1.3 and full certificate chain and host name checks.
A keep-alive pool of up to eight connections per host, reused across requests and closed after 30 idle seconds.

flowchart LR
    CMD[wget / curl / apps] --> URL[url_parse]
    URL --> H[http_get / http_post]
    URL --> HS[https_get / https_post]
    HS --> TLS[Mbed TLS port]
    TLS --> CA[CA bundle]
    H --> POOL[keep-alive pool]
    TLS --> POOL
    POOL --> SOCK[socket layer, planned]

What are its interfaces?

All of these are planned; none exist yet.

Interface	Purpose
`url_parse(str, &url)`	Split a URL into its parts
`http_get(url, buf, max)`, `http_post(url, ct, body, blen, buf, max)`	Plain HTTP requests
`https_get()`, `https_post()`	The same over TLS
`wget`, `curl`	Command-line downloads
`C:\Impossible\System\Certs\ca-bundle.crt`	Trusted root certificates

These are kernel functions first. User programs will reach HTTP through the socket system calls from DNS Resolver and Sockets, not through new system calls.

How do I use it?

It cannot be used yet. The closest check today is confirming the library is vendored: the Mbed TLS row in src/libs/PROVENANCE.md names the exact upstream version and vendoring commit.

What is not implemented yet?

Prerequisites: TCP (TCP and Network Infrastructure) and name resolution and sockets (DNS Resolver and Sockets).
Plain HTTP: URL Parser, HTTP GET, HTTP POST + Chunked Transfer Encoding and wget / curl Shell Commands.
TLS: Mbed TLS Kernel Port, CA Certificate Store, HTTPS GET / POST and HTTP/1.1 Keep-Alive Connection Pool.
HTTP/2 and HTTP/3 are not planned.

How does it compare with Windows 11 and Linux?

Windows 11 ships WinHTTP and WinINet, TLS in schannel.dll, the Windows Certificate Store and, since Windows 10, curl.exe. Linux distributions use libcurl and wget over OpenSSL or GnuTLS, with root certificates under /etc/ssl/certs and optional in-kernel TLS offload. Impossible OS plans a kernel-resident HTTP and TLS client on a mature vendored TLS library, so the browser, mail client and updater share one audited TLS path rather than each bringing its own.