Repository navigation
Releases
ivory v0.3.1
3b45fa7 Changed: the XML parser behind tsl rejects malformed markup
that Go's encoding/xml lets through: an XML declaration with missing,
repeated or misordered pseudo-attributes or not at the start of the
document, a processing instruction target with a colon or without white
space after it, CDATA after the root element, attributes without white
space between them or with an empty prefix or local name, character
references to surrogates or other characters XML forbids (encoding/xml
reads them as U+FFFD), and namespace names that are not absolute URIs.
No genuine TSL contains them; libxml2 rejects them or can't
canonicalize them.
Documentation: the README, SECURITY.md,
AE26
the user guide and the
security notes say plainly that ivory is experimental and not ready for
production use in the TI, and that you should have an independent
security review done yourself before you adopt it; docs/security.md
lists what that review should cover.
Tests: new fuzz target tsl:FuzzVerifiedTSL: a TSL that verifies
against the test trust anchor must read exactly as the signed one (no
signature wrapping, no gap between what is signed and what is read);
tsl.TestSignedEdits pins 24 such edits. tsl.TestParseElementEdits
removes every element of a signed TSL in turn and checks that parsing
never panics; FuzzParse starts from the variants that pass the schema
check. New tests for the XML parser's well-formedness rules and depth
limit, the XML signature's structure rules, OCSP responses signed with
RSA-PSS, CertID matching, revocation reasons, ti's 24-hour session
limit to the second, and the parts of Go's session encoding that ti
reads. scripts/run-tls-anvil.sh runs TLS-Anvil's RFC 5246 and RFC
8446 tests against stock Go and against ivory, as server and client,
with and without Brainpool, and fails when ivory's results differ from
stock Go's in a way that isn't listed; the first runs show no
difference beyond what TLS-Anvil can't test with Brainpool (see
interop/README.md). TestLibxml2 in internal/xmldsig compares the
parser and the exclusive canonicalization with libxml2 (through lxml)
on generated hostile XML, the TSL corpora and fuzz corpora; it found
the malformed markup above.
Tooling: ivory-overlay tipcheck reads context: old => new lines
in overlay/tip-rewrites.txt: they rewrite the lines a patch expects in
the tree before it is applied, for a line next to a patch's change that
changed on Go's development branch. It now also lists the rejected hunks
when a patch doesn't apply.
ivory v0.3.0
6b85562 Changed (overlay profile kt):
- A TLS 1.2 CertificateRequest lists only the signature algorithms of
its one certificate type: ECDSA and Ed25519 withecdsa_signon
ECDHE_ECDSA suites, RSA withrsa_signon RSA suites. Strict clients
rejected the earlier message, which listed RSA algorithms with only
ecdsa_sign. Clients that sent a client certificate of the other key
type, ignoring the certificate type, now send none.
New command:
cmd/ivory(experimental: flags and reports may still change): a TLS
test tool for TI products.ivory clientconnects once and reports
the handshake and the server's certificate chain read the TI way (certificate type, roles from the admission extension, key)
with the check against the TSL of the test, reference or production
environment and OCSP.ivory serverreports what each connecting
client offers (ClientHello, JA3) and presents.ivory probefinds out
what a server supports with many narrowed handshakes: versions, cipher
suites and their order, TLS 1.2 and TLS 1.3 groups, signature schemes,
extensions, fallback protection, its certificates and CertificateRequests.
All three print a decoded record-by-record trace, write key logs for
Wireshark and report in JSON. Client identities come from PEM files;
active connections to the production environment need-allow-pu.
clientandprobeconnect through an HTTP or SOCKS5 proxy
(-proxy, by default fromHTTPS_PROXY;socks5h://forssh -D),
andclientalso checks the server's chain against the system's
roots.ivory tunnelandivory proxygive tools without Brainpool support,
such as curl, Brainpool TLS:tunnelforwards plain TCP connections
from localhost over TLS to one server,proxyis an HTTP proxy on
localhost that sends requests forhttp://URLs over TLS to their
server. Both check the server certificate (the TI way with-env,
-tslor-ca, otherwise against the system's roots) before any data
passes, listen on loopback addresses only unless told otherwise, and
proxyconnects only to the targets that-allownames. Both connect
through-proxylikeclient.ivory reverseis the other direction: it accepts Brainpool TLS
connections and forwards the plain text of each to a server without
Brainpool support on a loopback address. With-client-auth request
orrequire, client certificates are checked against the TSL (or
-tsl,-ca) and a failed check fails the handshake.-proxy envfalls back toALL_PROXYand honoursNO_PROXYentries
for domains and their subdomains,host:port, IP addresses and CIDR
ranges; loopback targets never use the proxy. The TSL and OCSP
downloads go through the same proxy (serverandreversetake
-proxyfor them).
Documentation: a first-steps walk-through for ivory with the test
PKI, a section on the tool in the user guide, what the tool trusts in
docs/security.md (Section 8), and the TSL, OCSP and tool code in the
scope of SECURITY.md.
Overlay tool: ivory-overlay pin accepts a patch that changes a file
an earlier patch adds.
CI: ci.yml runs on pushes to main and on demand, no longer on
every branch and pull request; the Windows SChannel jobs run on demand
only. Scheduled nightly.yml runs do their work only in a public
repository; anywhere, the workflow can be started by hand.