| Age | Commit message (Collapse) | Author |
|---|
|
OK tb@
|
|
OK tb@
|
|
Both BIRD 2 & 3 support ASPA in supported releases, so just emit
the Validated ASPA Payloads into a single file suitable for both
trains. Should operators have a need to omit ASPA information, the
-A flag can be used. Remove the -T option. Document what BIRD
versions are targetted.
With this, the bgpd(8) and BIRD outputs are structured similarly.
Input from sthen@
OK tb@ deraadt@
|
|
ok job
|
|
OK tb@
|
|
OK tb@
|
|
We already check that the fileList isn't excessively large. A bit later we
also check that the list contains a CRL, as required by RFC 9286. However,
between these two checks a zero-sized allocation may happen, which is now
avoided. sk_num() is one of those gifts that keep on giving, but it seems
that this is the only occurrence in rpki-client that can be problematic.
ok job
|
|
In some cases, following a fallback from RRDP to RSYNC, files are
moved to the wrong place. With this change, only rsync repositories
are considered when looking up where to move DIR_TEMP files.
repo.c requires more study, this fix might be a bandaid for a problem
not fully understood.
"put it in" claudio@ OK tb@
|
|
|
|
The RPKI ecosystem suffers from a partially unmitigated risk related to
long-lived Trust Anchor certificate issuances.
Issues could arise when a on-path attackers (or, operational errors such
as restoring a super old backup of a webserver) bring back into
circulation old (but still valid) TA certificate. Older certificates
remain valid for the duration of their validity period, because TA
certificates - being top of the chain - cannot be revoked.
Real world examples of old potential replayable certificates that today
still would pass validation are here:
https://mailarchive.ietf.org/arch/msg/sidrops/NxzvSFH0sPXEmyfOS99cLApFKqM/
The trouble with these replayable TA certificates is that when an
on-path entity ends up presenting such an outdated-but-still-valid
certificate to the RP, accepting such a cert will damage the RP's local
validated cache. Parts of the validated output will disappear, in an
unpredictably manner.
Periodic reissuance of TA certs is important because TA certificates are
not entirely static, which of course is why replay might even be an issue
in the first place!. There are 3 'dynamic' fields in TA certificates:
- the validity period (notBefore, notAfter)
- the SubjectInfoAccess (where can the RP find the first repository?)
- the extensions for IP addresses & AS identifiers (RFC 3779 INRs)
(the RFC 3779 extensions are of critical importance to the
RPKI's chain validation algorithm)
RIRs will want RPs to validate using the 'latest' issuance of the TA
certificate, because a TA cert from 10 years ago obviously will be 10
years behind on operational decisions, potential SIA migrations,
resource transfers, new IANA assignments, or any other updates to the
RIR's current holdings.
How to repair this situation?
The plan to overcome this risk has three steps:
step 1) RPs to prefer shorter-lived Trust Anchor certificates over
longer-lived ones. (rpki-client already implemented this)
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-ta-tiebreaker
step 2) RPs ship with scheduled future refusal of ultra long-lived Trust
Anchor certificates (that's the below diff).
step 3) Consequently, RIRs have to reissue shorter-lived TA certificates
to avoid being rejected by RPs.
The end result is that after anno 2026 / 2027, if 100 year or 10 year
certs somehow be brought back into circulation, RPs will simply refuse
such long-lived certs, despite them technically being 'valid'.
Why this works:
The ta-tiebreaker mechanism provides an incentive for TA operators to
reissue with reasonable (1 or 2 year) validity periods, as those certs
will be preferred. In turn, RPs scheduling refusal of long-lived certs
at a predetermined future point in time, relieves TA operators from
worrying about previously issued certs with ultra long lifetimes. It is
a win win for everyone in the ecosystem.
Scheduling details:
- February 2nd 2026 for phase 1, because 02-02-2026 is an unambiguous
date both in the US and elsewhere.
- March 3rd 2027 for phase 2, because 03-03-2027 also is unambiguous and
visually is very distinct from the phase 1 date.
The hope is that with this schedule global coordination less will be less
error-prone, and everyone should get adequate preparation time.
Discussed with various RIRs
with & OK tb@
|
|
Avoids an incorrect "Signature path expired" for such certs.
noticed by and ok job
|
|
|
|
ok job
|
|
|
|
OK tb@
|
|
AS0 TALs represent unmitigated operational risks: what if the RIR by
accident marks some IP space as 'unassigned'?
APNIC notes in their limitation of liability statement:
"""
Depending on router configuration, errors in the AS0 ROA could
cause unintended interruption to routing with other networks.
For this reason, it is strongly recommended that the AS0 ROA is
used for advisory and/ or alerting purposes only, and not for
automatic filtering of BGP routes.
"""
https://www.apnic.net/community/security/resource-certification/apnic-limitations-of-liability-for-rpki-2/
Guard usage of AS0 TALs behind new '-0' option
OK deraadt@ tb@
|
|
|
|
This is mostly stolen from the imsg handler and should probably be cleaned up
further.
OK tb@
|
|
Historically, CMS_get1_crls() returned NULL if the CMS is an
unsupported content type or contained zero CRLs. Nowadays, if
the CMS contains zero CRLs, some implementations will return a
pointer to a STACK of CRLs with zero objects.
OK tb@
|
|
OK tb@
|
|
OK tb@
|
|
OK tb@
|
|
OK tb@
|
|
ok claudio
|
|
Binary change in main.o and tal.o due to an assertion change and in spl.o
due to line number changes
looks good to claudio, ok clang + sha256
|
|
Having a single letter to distinguish a length from a pointer is error
prone. This results in binary change only in validate.c and cert.c due
to a line wrap resulting in line number changes and in cert.c there's in
addition two asserts that change.
checked with/ok job
|
|
ok tb
|
|
ok claudio
|
|
Currently the validation indicator only takes the certificate's status
into account. In case everything check out, check the product's life
time and the signature path's expiration moment before printing OK.
should fix an issue encountered by job
looks good to claudio
|
|
|
|
It is helpful for network operators, publication point operators, and CA
operators to have more insight into whether the RP noticed an issuance
gap between two versions of a given manifest.
* high number of gaps all the time might be an indication the RP is not
refreshing often enough
* the CA is trying to issue manifests more than once a second
* the RFC 8181 publication server's ingress API endpoint has issues
* the RFC 8181 publication client has trouble reaching the server
* the CA's private keys (RPKI + BPKI) are used on a second (cloned) system
* the CA's issuance database is broken
Correlation opportunity: detection of a gap means some of the CA's
intermediate states were occluded from the RP; the RP operator might
want to correlate this to traffic shifts in BGP or publication point
reachability issues.
Going forward, emit a warning per manifest, adds metrics to the
openmetrics output, and displays a summary at the end of the run about
issuance gaps.
OK tb@
|
|
are used to store file descriptors.
OK tb@
|
|
EVP_PKEY_get0_* were made const correct in OpenSSL 3 and now cause the
build of rpki-client to emit warnings. Of course no one is able to see
these warnings because they are hidden in all the deprecation vomit.
Makes rpki-client build cleanly against OpenSSL 3 when configured with
--with-openssl-cflags=-DOPENSSL_SUPPRESS_DEPRECATED.
ok claudio deraadt job
|
|
|
|
|
|
The language in RFC 5280, section 4.1.2.5 includes the end points of the
validity interval.
Reported by Tom Harrison
ok claudio job
|
|
An ASN1_INTEGER doesn't contain the ASN.1 encoding in its data. It contains
a BIGNUM. In particular, there's no padding octet for integers with the top
bit of the top octet set. Do the check the dumb way and check all the parts
individually: non-negative, not larger than 20 octets and bit 159 not set.
Reported by Tom Harrison
ok claudio job
|
|
ok claudio
|
|
ok claudio
|
|
claudio agress
|
|
requested by tb@
|
|
The CRL number draft clarified what ignoring means and it includes checking
that the CRL number is well-formed again. So do this but continue to ignore
the value for any other purpose. This refactors x509_convert_seqnum() into
a couple of helpers. There's some duplication between crl_check_crl_number()
and crl_parse_crl_number() which could be removed if anyone cares.
tweaks/ok job
|
|
|
|
ok job
|
|
|
|
OK tb@ claudio@
|
|
joint effort with/ok claudio
|
|
This changes the JSON output, without -x some keys are missing from 'metadata'
OK tb@
|
|
does not exist.
OK tb@
|
|
OK claudio@
|
