continuum-proxy

74 Commits 2 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
octoturge	1cd8ce25c3	Authenticate config bundles: Ed25519, per-box identity, no plaintext The hash in a bundle only proved it was undamaged. Anyone who could write the stick could write both files, so a Proxy Box would install a config handed to it by whoever got physical access - including a config pointing the box at a different cloud. Encryption alone does not fix that either. While plaintext was accepted an attacker simply did not encrypt, and the box took it. So a Box now refuses plaintext outright, and the bundle carries a signature. A third entry, `config.toml.sig`: strict TOML with `box_id`, `config_version` and a raw Ed25519 signature. What is signed is `signed_message()` - a domain tag, the length-prefixed box id, the version big-endian, then the raw `config.toml` bytes. Raw bytes rather than the archive, so the signature is independent of ZIP framing, compression, entry order and encryption. The box id and version are inside the signed message rather than beside it, so neither can be edited without breaking it, and the length prefix stops a byte-shifting collision between the id and the config. Past decryption the order is hash, signature, box id, version, then parse and validate. The claims in the `.sig` are attacker-controlled text until the signature over them verifies, so nothing is concluded from them before then - and nothing about this box's identity is revealed before then either, which is why unsigned junk cannot be used to probe which box it is talking to. Which error wins when a box cannot even open a bundle: a signature over the plaintext is only checkable after decryption, so a box with the wrong key cannot distinguish "meant for another box" from "forged". Wrong key wins. Neither bundle installs either way, it is nearly always the true cause, and calling something forged that we could not open would be an accusation we cannot support. Replay is enforced rather than documented away: `config_version` must not go backwards, recorded in a sidecar beside the installed config. An equal version is accepted on purpose, because the version is written before the config, so a power cut between the two leaves "new version, old config" and re-inserting the same stick repairs it. The other write order would leave a replay window instead. Both key sets are lists, so the cloud's signing key and a box's own key can be rotated. `load_provisioning()` is the single seam where a box's identity and keys come from; a TPM or secure element replaces that function and nothing else. A missing file means unprovisioned, and the box then says loudly what it cannot check - but an empty or malformed one is an error, because quietly reading a broken key file as absent would turn a provisioning mistake into a box that accepts unsigned bundles. Not verified: interop with the real cloud signer. These tests prove the box accepts what this code defines as correct, not that the cloud will produce the same bytes - the message layout, the pure-Ed25519-no-prehash choice and the `.sig` shape all need a cross-check against the configurator's own crypto library once it exists. A compromised cloud signing key still breaks every box trusting it; revocation is not built.	2026-10-19 08:08:27 +00:00
octoturge	ad55645ec9	Accept an AES-encrypted config bundle from the cloud The bundle is authored by Continuum Cloud's configurator and downloaded by the customer, so it travels over the internet and then on a USB stick while holding the gateway token and possibly a wifi PSK. That makes it a secret at rest, and confidentiality is the benefit encryption actually delivers here. WinZip AES-256 ("AE-x"), via the zip crate's `aes-crypto` feature. That pulls in aes, hmac, pbkdf2, sha1, constant_time_eq and zeroize - all permissive (MIT/Apache-2.0, and CC0-1.0 OR MIT-0 OR Apache-2.0 for constant_time_eq), each checked against docs/LICENSES.md, and `cargo deny check licenses` passes. Legacy ZipCrypto is refused outright, whatever key is configured: it falls to a known-plaintext attack. The test is on metadata, not on a failed decrypt - `encrypted()` is set for ZipCrypto and AES alike, but only AES carries the AE-x extra field, so encrypted-without-it is ZipCrypto and the whole bundle is rejected. Judged in the first pass, before any decrypt call, so the crate's ZipCrypto path never runs on our input. Mixed bundles - one entry encrypted, the other not - are rejected too. The caps now bound decrypted output, so a small ciphertext that inflates is capped exactly as a plaintext bomb is. Everything else holds unchanged for an encrypted bundle: zip-slip, the inner config.toml.sha256, the no-environment validation, atomic install, and a rejected bundle never touching the installed config. Failures are distinguished, because "wrong key" and "damaged" need different answers: no key on the box and a wrong key both say "not for this box", while tampered or damaged ciphertext says it failed its AES integrity check. A wrong key passes AES's 16-bit password check 1 time in 65536 and then fails the HMAC, so that message names a wrong key as a possibility. The limitation to be clear about: with plaintext bundles still accepted, encryption does nothing against tampering. An attacker supplies a plaintext bundle and never touches the crypto. The tamper goal only begins to hold once `accept_unencrypted` is false, which is one line in main.rs and is deliberately not flipped yet - doing so breaks every stick made before the configurator encrypts, and every hand-made development stick. That is a product decision, not a code one. More generally, encryption is not authenticity: the AES HMAC detects modification only by someone without the password, and the password has to live on the box, so extracting it from one image breaks every box sharing it. It raises the bar from "anyone with a text editor" to "anyone who can read a firmware image". The module docs say exactly that and do not call it tamper-proof. `check_authenticity` is a named no-op where an Ed25519 check over the config, verified against a public key in the box image, belongs - it verifies nothing and says so, so the missing authenticity is a searchable gap rather than an implicit one. `load_bundle_key` is the single marked seam where provisioning lands. Its current `$CONTINUUM_BUNDLE_KEY_FILE` / `/etc/continuum/bundle.key` lookup is a placeholder, not a decision: shared-vs-per-box keys, where the key lives, and rotation are open product questions and the mechanism depends on none of them. Encrypted fixtures are genuine AES ZIPs written by the zip crate itself, and one test confirms the config text is absent from the ciphertext. The ZipCrypto fixture sets the encrypted flag without an AE-x field, which is the metadata shape this must refuse. Unproven: interop with whatever ZIP writer the cloud actually uses (only archives written by this same crate version were read back), AES-128/192, and `load_bundle_key` itself, which reads process env and so has no test.	2026-10-19 07:56:25 +00:00
octoturge	64d46dbc49	Load proxy settings from a file, and import them from a pendrive Everything came from CONTINUUM_* environment variables, which suits neither shape the product ships in. A Proxy Box is an appliance whose settings arrive on a USB stick; a proxy on someone's PC is a config file they edit. Precedence is stated once, in config.rs: the file is the base, env overrides it, defaults fill the rest. `Config::from_env` keeps its behaviour and the struct is unchanged, so existing callers and tests are untouched. Layering is `Config::layered(file, env_lookup)` with the environment injected as a closure, so tests do not have to mutate process env to cover it. The bootstrap is read from $CONTINUUM_BOOTSTRAP, then /etc/continuum/bootstrap.toml, then nowhere - and nowhere means PC mode with ./continuum.toml, so an env-only deployment behaves exactly as before. The working directory is deliberately not searched, and the bootstrap itself must never come from a stick: it is what says whether sticks are trusted at all. Bundle format is continuum-config.zip holding config.toml and config.toml.sha256. The hash is checked before the bytes are parsed - the TOML parser should not be the first thing to read possibly-corrupt input - and the comments say plainly what that buys: corruption and change, not forgery. Anyone who can write the stick writes both files. It is an integrity check under a recorded trust assumption, that physical access to the box is trusted; a signature with the key in the box image is named as the follow-up that would give authenticity. sha256 via openssl, already a direct dependency, so no new crate and `cargo deny check licenses` still passes. The hazards of ingesting a file off removable media, all tested: Zip-slip is refused on absolute paths, `..` components, backslash separators, drive prefixes, NUL and non-UTF-8 names, and one bad entry rejects the whole bundle rather than being skipped. The stronger guarantee is structural though: entries are only ever read by index, matched against two literal names, and no write path is ever derived from an archive name, so a hole in the name check still writes nothing. A test confirms a bundle carrying `../evil.toml` alongside a valid config writes nothing outside the target and leaves the installed config alone. Zip bombs are capped at 16 entries, 256 KiB per entry and a 1 MiB file on the stick. Declared sizes are refused in a first pass that decompresses nothing, and a bounded reader then caps actual output so a lying header gains nothing. Installing is atomic: temp file in the destination directory - not /tmp, since rename is only atomic within a filesystem - created 0600 from the first byte because the config holds the gateway token, fsync, rename, then a best-effort directory fsync. A write that fails halfway leaves the previous config intact and no temp file behind. A bad stick never costs the box its config: a bad hash, bad TOML, an unsafe entry or missing settings all return Rejected and are logged as keeping the existing config. A correctly-hashed config is also validated with no environment at all, so a stick cannot install something that parses now and fails to start on the next boot - which would be a bricked box caused by exactly the stick we were being careful about. PC mode ignores pendrives twice over, by mode and by an emptied directory list, because on a general-purpose machine importing settings from a USB stick would be a way to change them behind the user's back. A [network] block is parsed, validated and exposed, and stops there. main.rs logs a warning that this build does not apply it, so a box given network settings cannot look like it acted on them. Applying them needs root, is specific to the appliance image, and a wrong write strands the box - it wants its own decision, not a side effect of reading a file. continuum.toml is gitignored, since it holds the gateway token. Not done, and not claimed: no signature, so no authenticity. There is no real pendrive here, so the removable-media path was tested with ordinary directories standing in for mount points - real udisks/udev mounts, FAT behaviour, a genuinely yanked stick and how promptly the 5s poll notices a mount are all unproven. The watcher's install-then-exit flow, which relies on a supervisor restarting the process, has no test and no supervisor exists in this environment; a stick left permanently inserted reports Unchanged rather than looping, because the hash matches. Env still overrides on a box, so a box is only pendrive-only to the extent its environment is trusted - bootstrap.rs says so.	2026-10-19 07:49:46 +00:00

Author

SHA1

Message

Date

octoturge

1cd8ce25c3

Authenticate config bundles: Ed25519, per-box identity, no plaintext

The hash in a bundle only proved it was undamaged. Anyone who could write
the stick could write both files, so a Proxy Box would install a config
handed to it by whoever got physical access - including a config pointing the
box at a different cloud.

Encryption alone does not fix that either. While plaintext was accepted an
attacker simply did not encrypt, and the box took it. So a Box now refuses
plaintext outright, and the bundle carries a signature.

A third entry, `config.toml.sig`: strict TOML with `box_id`, `config_version`
and a raw Ed25519 signature. What is signed is `signed_message()` - a domain
tag, the length-prefixed box id, the version big-endian, then the raw
`config.toml` bytes. Raw bytes rather than the archive, so the signature is
independent of ZIP framing, compression, entry order and encryption. The box
id and version are inside the signed message rather than beside it, so
neither can be edited without breaking it, and the length prefix stops a
byte-shifting collision between the id and the config.

Past decryption the order is hash, signature, box id, version, then parse and
validate. The claims in the `.sig` are attacker-controlled text until the
signature over them verifies, so nothing is concluded from them before then -
and nothing about this box's identity is revealed before then either, which
is why unsigned junk cannot be used to probe which box it is talking to.

Which error wins when a box cannot even open a bundle: a signature over the
plaintext is only checkable after decryption, so a box with the wrong key
cannot distinguish "meant for another box" from "forged". Wrong key wins.
Neither bundle installs either way, it is nearly always the true cause, and
calling something forged that we could not open would be an accusation we
cannot support.

Replay is enforced rather than documented away: `config_version` must not go
backwards, recorded in a sidecar beside the installed config. An equal
version is accepted on purpose, because the version is written before the
config, so a power cut between the two leaves "new version, old config" and
re-inserting the same stick repairs it. The other write order would leave a
replay window instead.

Both key sets are lists, so the cloud's signing key and a box's own key can
be rotated. `load_provisioning()` is the single seam where a box's identity
and keys come from; a TPM or secure element replaces that function and
nothing else. A missing file means unprovisioned, and the box then says
loudly what it cannot check - but an empty or malformed one is an error,
because quietly reading a broken key file as absent would turn a
provisioning mistake into a box that accepts unsigned bundles.

Not verified: interop with the real cloud signer. These tests prove the box
accepts what this code defines as correct, not that the cloud will produce
the same bytes - the message layout, the pure-Ed25519-no-prehash choice and
the `.sig` shape all need a cross-check against the configurator's own crypto
library once it exists. A compromised cloud signing key still breaks every
box trusting it; revocation is not built.

2026-10-19 08:08:27 +00:00

octoturge

ad55645ec9

Accept an AES-encrypted config bundle from the cloud

The bundle is authored by Continuum Cloud's configurator and downloaded by
the customer, so it travels over the internet and then on a USB stick while
holding the gateway token and possibly a wifi PSK. That makes it a secret at
rest, and confidentiality is the benefit encryption actually delivers here.

WinZip AES-256 ("AE-x"), via the zip crate's `aes-crypto` feature. That
pulls in aes, hmac, pbkdf2, sha1, constant_time_eq and zeroize - all
permissive (MIT/Apache-2.0, and CC0-1.0 OR MIT-0 OR Apache-2.0 for
constant_time_eq), each checked against docs/LICENSES.md, and
`cargo deny check licenses` passes.

**Legacy ZipCrypto is refused outright**, whatever key is configured: it
falls to a known-plaintext attack. The test is on metadata, not on a failed
decrypt - `encrypted()` is set for ZipCrypto and AES alike, but only AES
carries the AE-x extra field, so encrypted-without-it is ZipCrypto and the
whole bundle is rejected. Judged in the first pass, before any decrypt call,
so the crate's ZipCrypto path never runs on our input. Mixed bundles - one
entry encrypted, the other not - are rejected too.

The caps now bound *decrypted* output, so a small ciphertext that inflates
is capped exactly as a plaintext bomb is. Everything else holds unchanged
for an encrypted bundle: zip-slip, the inner config.toml.sha256, the
no-environment validation, atomic install, and a rejected bundle never
touching the installed config.

Failures are distinguished, because "wrong key" and "damaged" need different
answers: no key on the box and a wrong key both say "not for this box", while
tampered or damaged ciphertext says it failed its AES integrity check. A
wrong key passes AES's 16-bit password check 1 time in 65536 and then fails
the HMAC, so that message names a wrong key as a possibility.

**The limitation to be clear about: with plaintext bundles still accepted,
encryption does nothing against tampering.** An attacker supplies a
plaintext bundle and never touches the crypto. The tamper goal only begins to
hold once `accept_unencrypted` is false, which is one line in main.rs and is
deliberately not flipped yet - doing so breaks every stick made before the
configurator encrypts, and every hand-made development stick. That is a
product decision, not a code one.

More generally, encryption is not authenticity: the AES HMAC detects
modification only by someone without the password, and the password has to
live on the box, so extracting it from one image breaks every box sharing it.
It raises the bar from "anyone with a text editor" to "anyone who can read a
firmware image". The module docs say exactly that and do not call it
tamper-proof. `check_authenticity` is a named no-op where an Ed25519 check
over the config, verified against a *public* key in the box image, belongs -
it verifies nothing and says so, so the missing authenticity is a searchable
gap rather than an implicit one.

`load_bundle_key` is the single marked seam where provisioning lands. Its
current `$CONTINUUM_BUNDLE_KEY_FILE` / `/etc/continuum/bundle.key` lookup is
a placeholder, not a decision: shared-vs-per-box keys, where the key lives,
and rotation are open product questions and the mechanism depends on none of
them.

Encrypted fixtures are genuine AES ZIPs written by the zip crate itself, and
one test confirms the config text is absent from the ciphertext. The
ZipCrypto fixture sets the encrypted flag without an AE-x field, which is the
metadata shape this must refuse. Unproven: interop with whatever ZIP writer
the cloud actually uses (only archives written by this same crate version
were read back), AES-128/192, and `load_bundle_key` itself, which reads
process env and so has no test.

2026-10-19 07:56:25 +00:00

octoturge

64d46dbc49

Load proxy settings from a file, and import them from a pendrive

Everything came from CONTINUUM_* environment variables, which suits neither
shape the product ships in. A Proxy Box is an appliance whose settings
arrive on a USB stick; a proxy on someone's PC is a config file they edit.

Precedence is stated once, in config.rs: the file is the base, env overrides
it, defaults fill the rest. `Config::from_env` keeps its behaviour and the
struct is unchanged, so existing callers and tests are untouched. Layering
is `Config::layered(file, env_lookup)` with the environment injected as a
closure, so tests do not have to mutate process env to cover it.

The bootstrap is read from $CONTINUUM_BOOTSTRAP, then
/etc/continuum/bootstrap.toml, then nowhere - and nowhere means PC mode with
./continuum.toml, so an env-only deployment behaves exactly as before. The
working directory is deliberately not searched, and the bootstrap itself
must never come from a stick: it is what says whether sticks are trusted at
all.

Bundle format is continuum-config.zip holding config.toml and
config.toml.sha256. The hash is checked before the bytes are parsed - the
TOML parser should not be the first thing to read possibly-corrupt input -
and **the comments say plainly what that buys: corruption and change, not
forgery.** Anyone who can write the stick writes both files. It is an
integrity check under a recorded trust assumption, that physical access to
the box is trusted; a signature with the key in the box image is named as
the follow-up that would give authenticity. sha256 via openssl, already a
direct dependency, so no new crate and `cargo deny check licenses` still
passes.

The hazards of ingesting a file off removable media, all tested:

Zip-slip is refused on absolute paths, `..` components, backslash
separators, drive prefixes, NUL and non-UTF-8 names, and one bad entry
rejects the whole bundle rather than being skipped. The stronger guarantee
is structural though: entries are only ever read **by index, matched against
two literal names**, and no write path is ever derived from an archive name,
so a hole in the name check still writes nothing. A test confirms a bundle
carrying `../evil.toml` alongside a valid config writes nothing outside the
target and leaves the installed config alone.

Zip bombs are capped at 16 entries, 256 KiB per entry and a 1 MiB file on
the stick. Declared sizes are refused in a first pass that decompresses
nothing, and a bounded reader then caps actual output so a lying header
gains nothing.

Installing is atomic: temp file in the destination directory - not /tmp,
since rename is only atomic within a filesystem - created 0600 from the
first byte because the config holds the gateway token, fsync, rename, then a
best-effort directory fsync. A write that fails halfway leaves the previous
config intact and no temp file behind.

A bad stick never costs the box its config: a bad hash, bad TOML, an unsafe
entry or missing settings all return Rejected and are logged as keeping the
existing config. A correctly-hashed config is also validated **with no
environment at all**, so a stick cannot install something that parses now
and fails to start on the next boot - which would be a bricked box caused by
exactly the stick we were being careful about.

PC mode ignores pendrives twice over, by mode and by an emptied directory
list, because on a general-purpose machine importing settings from a USB
stick would be a way to change them behind the user's back.

A [network] block is parsed, validated and exposed, and stops there. main.rs
logs a warning that this build does not apply it, so a box given network
settings cannot look like it acted on them. Applying them needs root, is
specific to the appliance image, and a wrong write strands the box - it wants
its own decision, not a side effect of reading a file.

continuum.toml is gitignored, since it holds the gateway token.

Not done, and not claimed: no signature, so no authenticity. There is no real
pendrive here, so the removable-media path was tested with ordinary
directories standing in for mount points - real udisks/udev mounts, FAT
behaviour, a genuinely yanked stick and how promptly the 5s poll notices a
mount are all unproven. The watcher's install-then-exit flow, which relies
on a supervisor restarting the process, has no test and no supervisor exists
in this environment; a stick left permanently inserted reports Unchanged
rather than looping, because the hash matches. Env still overrides on a box,
so a box is only pendrive-only to the extent its environment is trusted -
bootstrap.rs says so.

2026-10-19 07:49:46 +00:00