🥮 mooncakes.io
    Sign in

    moonbitstack/moontls/tls does not have a README file

    Client

    source
    pub(all) struct Client {
      roots : 
    Roots
      alpn : Array[String]
      suites : Array[
    Suite    ]
      groups : Array[Int]
      verify : Verify
      policy : 
    Policy
    }

    A client's configuration: the trust anchors, the application protocols it offers, the suites and groups it offers, how it judges the chain, and the path-validation policy.

    Client::new

    source

    Conn

    source
    pub struct Conn {
      // private fields
    }

    A TLS 1.3 connection (RFC 8446), client or server, without I/O: ciphertext from the peer goes in through receive, ciphertext for the peer comes out of take, application data is read with read and written with write. Randomness and the time come from the caller.

    Conn::alpn

    source
    fn Conn::alpn(self : Conn) -> String?

    The application protocol ALPN settled on (RFC 7301).

    Conn::client

    source
    fn Conn::client(config : Client, host : String, rand~ : (Int) -> Bytes, now~ : Int64) -> Conn raise 
    Alert

    A client connection to host, its ClientHello already queued for take. now is the time, in seconds since the Unix epoch, the server's certificate is judged at.

    Conn::close

    source
    fn Conn::close(self : Conn) -> Unit

    Queue close_notify (RFC 8446 §6.1) and stop accepting data.

    Conn::is_closed

    source
    fn Conn::is_closed(self : Conn) -> Bool

    Whether the connection has ended, by close_notify either way or by an alert.

    Conn::is_connected

    source
    fn Conn::is_connected(self : Conn) -> Bool

    Whether the handshake has completed and the connection is open.

    Conn::peer

    source
    fn Conn::peer(self : Conn) -> Array[Bytes]

    The peer's certificate chain, DER, leaf first.

    Conn::read

    source
    fn Conn::read(self : Conn) -> Bytes

    Application data received, emptied by the call.

    Conn::receive

    source
    fn Conn::receive(self : Conn, data : BytesView) -> Unit raise 
    Alert

    Feed ciphertext from the peer. A fatal alert raised here has also been queued for take, so the peer is told why before the connection is dropped.

    Conn::refused

    source

    Why a client refused the server's chain, when it did.

    Conn::server

    source
    fn Conn::server(config : Server, rand~ : (Int) -> Bytes) -> Conn

    A server connection awaiting a ClientHello.

    Conn::server_name

    source
    fn Conn::server_name(self : Conn) -> String?

    The host name a client asked for by SNI (RFC 6066 §3), on a server.

    Conn::suite

    source

    The suite negotiated.

    Conn::take

    source
    fn Conn::take(self : Conn) -> Bytes

    Ciphertext for the peer, emptied by the call.

    Conn::update

    source
    fn Conn::update(self : Conn, request? : Bool) -> Unit raise 
    Alert

    Ask for new traffic keys in both directions (RFC 8446 §4.6.3).

    Conn::write

    source
    fn Conn::write(self : Conn, data : BytesView) -> Unit raise 
    Alert

    Queue application data for the peer, in records of at most 2^14 octets.

    Server

    source
    pub(all) struct Server {
      chain : Array[Bytes]
      key : 
    PrivateKey
      alpn : Array[String]
      suites : Array[
    Suite    ]
      groups : Array[Int]
    }

    A server's configuration: its chain (DER, leaf first) and the leaf's private key, the application protocols it speaks in preference order, and the suites and groups it accepts.

    The scheme a CertificateVerify is signed under follows from the key: an ECDSA key signs with its curve's own hash, an RSA key with RSASSA-PSS.

    Server::new

    source

    Refuses an empty chain and a key that is not the leaf's: either would only show up later, as a client's alert in the middle of a handshake.

    Verify

    source
    pub(all) enum Verify {
      Chain
      Custom((Array[Bytes], String) -> Unit raise)
    }

    How a client judges the server's certificate chain. There is no switch that turns checking off: a self-signed server is trusted by putting its certificate in the roots, or by a Custom judge that raises to refuse.

    groups

    source
    let groups : Array[Int]

    The key-exchange groups, in preference order: X25519, then the two NIST curves.

    suites

    source

    The suites offered or accepted, in preference order: all three of TLS 1.3's, ChaCha20-Poly1305 first. The AES here is software, several times slower than ChaCha20 and with table lookups a cache can time; BoringSSL puts ChaCha20 first on hardware without AES instructions for the same two reasons.

    Source Files

    Powered by MoonBit

    Site sourceReport issuePackagesBuild queueSkillsStatistics

    © 2026 mooncakes.io