Cybersecurity

Cybersecurity / 24 Sep 2026 / 6 min read

TLS Delegated Credentials Limit Certificate Key Exposure

Large TLS deployments often need signing capability on many serving machines. Copying the certificate private key to every endpoint expands the set of systems whose compromise can expose a long-lived credential. Keeping that key in one tightly controlled location reduces exposure, but remote signing for every handshake can add an operational dependency to the serving path. Delegated Credentials for TLS, standardized in RFC 9345, provide a narrower option for TLS 1.3. A certificate holder can use its certificate private key to authorize another public key for a limited period. The endpoint receives the corresponding delegated private key and can authenticate TLS handshakes without holding the certificate private key itself.

Cybersecurity TLS

Cybersecurity / 24 Sep 2026 / 6 min read

SSHFP Anchors SSH Host Key Fingerprints in DNSSEC

An SSH client has to decide whether the host key presented by a server belongs to the intended host. A previously stored key can provide that reference on later connections, but the first connection needs another basis for authentication. SSHFP places a fingerprint of an SSH host public key in DNS so a client can compare the server key with independently retrieved data. The DNS record alone is not a trust anchor. RFC 4255 ties trusted SSHFP verification to authenticated DNS data. DNSSEC protects the lookup path and lets a validating client distinguish signed data from an unauthenticated DNS answer. The useful security property comes from that combination: SSH supplies the host key, SSHFP carries its fingerprint, and DNSSEC authenticates the DNS record used for comparison.

Cybersecurity SSH

Cybersecurity / 24 Sep 2026 / 6 min read

security.txt Publishes a Machine-Readable Vulnerability Contact

A vulnerability report can lose value before triage begins if the reporter cannot identify a current, organization-controlled contact. RFC 9116 addresses that routing problem with security.txt, a machine-parsable text file published at a predictable HTTPS location. The file does not grant testing permission, establish a bug bounty, or prove that a listed recipient is trustworthy. Its narrower role is to publish vulnerability disclosure metadata in a format that people and automated tools can retrieve consistently.

Cybersecurity security.txt

Cybersecurity / 24 Sep 2026 / 5 min read

security.txt Publishes a Bounded Vulnerability Reporting Route

A security flaw can be difficult to report even when the affected service is easy to identify. A generic support form may route the message to the wrong queue, an old security mailbox may no longer be staffed, and a researcher cannot safely infer disclosure policy from a company name alone. RFC 9116 addresses that routing problem with security.txt, a small machine-parsable file published by the service operator. The file does not certify that a service is secure, authorize testing, or define a complete vulnerability disclosure program. Its narrower job is to publish current reporting coordinates and related metadata at a predictable location.

Cybersecurity Vulnerability Disclosure

Cybersecurity / 24 Sep 2026 / 5 min read

RPKI Origin Validation Checks Prefix and Origin Authorization

A BGP announcement can name an origin AS without proving that the holder of the advertised address space authorized that AS to originate the route. Resource Public Key Infrastructure, or RPKI, supplies signed routing objects from which relying parties derive validated authorization data. BGP origin validation compares that data with the route seen by a router. The check is deliberately narrow. It evaluates the route prefix and origin AS against validated records. It does not authenticate every AS in AS_PATH, prove that the observed path is legitimate, or determine whether export policy was followed.

Cybersecurity RPKI

Cybersecurity / 24 Sep 2026 / 6 min read

OCSP Stapling Delivers Certificate Status in the TLS Handshake

Certificate validation answers more than one question. A client checks that a certificate chains to a trusted root, matches the intended identity, falls inside its validity interval, and satisfies applicable policy. Revocation status is a separate signal: a certificate can still be inside its notBefore and notAfter interval after the issuer has revoked it. The Online Certificate Status Protocol (OCSP), specified in RFC 6960, gives clients a mechanism to query certificate status. A direct query, however, adds a network dependency to connection setup and exposes the queried certificate identity to the responder. OCSP stapling moves retrieval to the TLS server. The server periodically obtains a signed OCSP response and sends that response to clients as part of the TLS handshake.

Cybersecurity TLS

Cybersecurity / 24 Sep 2026 / 6 min read

OCSP Stapling Carries Certificate Status Inside TLS

Certificate validation answers more than one question. A client can verify the issuer chain, names, signatures, and validity dates, yet still need current information about whether a certificate has been revoked before its scheduled expiration. The Online Certificate Status Protocol (OCSP), specified by RFC 6960, provides signed status information for a certificate. A direct OCSP design has the client contact a responder operated by, or delegated for, the certificate issuer. OCSP stapling changes the delivery path: the TLS endpoint obtains an OCSP response and sends that response to the client inside the TLS handshake.

Cybersecurity TLS

Cybersecurity / 24 Sep 2026 / 6 min read

NSEC3 Hashes DNSSEC Denial Records Without Hiding Guessable Names

A DNSSEC signature can authenticate data that exists, but a resolver also needs cryptographic evidence when a requested name or record type is absent. A plain unsigned NXDOMAIN response cannot provide that property: an attacker able to alter DNS traffic could fabricate the same response. NSEC3 supplies signed denial records while replacing clear-text owner names in the denial chain with hashes. RFC 5155 defines NSEC3 as an alternative to NSEC for authenticated denial of existence. Its main privacy-related distinction is narrow but useful: walking an NSEC chain directly reveals neighboring owner names, whereas NSEC3 exposes hashes that require additional work to map back to candidate names.

Cybersecurity DNSSEC

Cybersecurity / 24 Sep 2026 / 7 min read

MTA-STS Pins SMTP Delivery to TLS-Capable Hosts

SMTP was designed to move mail between independently operated systems, and opportunistic STARTTLS was added later. That upgrade improves confidentiality when both sides support it, but opportunistic behavior has a structural weakness: if TLS negotiation fails, a sender may still deliver over plaintext. An active network attacker that can interfere with SMTP traffic can exploit that fallback by suppressing STARTTLS or redirecting delivery toward an unintended host. MTA-STS, standardized in RFC 8461, gives a receiving domain a way to state a stricter policy. A supporting sender retrieves that policy over HTTPS, caches it, and applies it to future SMTP delivery. In enforcement mode, the sender requires both an authorized MX host and a valid TLS connection before transmitting the message.

Cybersecurity MTA-STS

Cybersecurity / 24 Sep 2026 / 6 min read

MTA-STS Pins SMTP Delivery to Authenticated TLS

SMTP commonly upgrades a plaintext connection with STARTTLS. Without an authenticated transport policy, that upgrade can remain opportunistic: a sender may continue delivery when TLS is unavailable, depending on its configuration. An active intermediary that can interfere with the SMTP exchange can exploit that flexibility by suppressing the STARTTLS capability or redirecting delivery. MTA Strict Transport Security (MTA-STS), defined by RFC 8461, gives a recipient domain a policy that compliant sending MTAs can cache and enforce. The policy states which MX hosts are acceptable and whether delivery requires TLS with a certificate that passes PKIX validation.

Cybersecurity MTA-STS

Cybersecurity / 24 Sep 2026 / 5 min read

HTTP Message Signatures Bind Selected HTTP Components

TLS protects an HTTP exchange while traffic moves across a TLS connection, but some application designs need a cryptographic assertion attached to the HTTP message itself. A gateway may terminate TLS before forwarding a request, a service may need to authenticate selected request metadata, or a message may cross several HTTP hops where transport protection and application trust are separate concerns. HTTP Message Signatures, specified in RFC 9421, address that boundary. A signer chooses HTTP message components, constructs a defined signature base, signs it, and sends metadata that tells a verifier which components and parameters were covered. The mechanism is selective by design: a signature does not automatically cover every field or every property of the message.

Cybersecurity HTTP

Cybersecurity / 24 Sep 2026 / 5 min read

HSTS Pins HTTP Origins to TLS After First Secure Contact

HTTPS protects a connection only after the client has selected HTTPS and completed TLS. A user who enters a bare hostname, follows an http:// bookmark, or receives an HTTP link can still begin on cleartext HTTP before a server redirects the request. HTTP Strict Transport Security (HSTS), defined in RFC 6797, moves that redirect decision into the user agent after the origin has established a policy over a secure connection.

Cybersecurity HSTS

Cybersecurity / 24 Sep 2026 / 5 min read

HSTS Keeps HTTPS Downgrades Out of Later Connections

TLS protects an HTTPS connection only after the client has chosen HTTPS and completed the TLS handshake. That leaves a separate problem at the scheme boundary. A user can enter a bare hostname, follow an old http:// link, or reach a redirect that starts in cleartext. An attacker able to interfere with that first HTTP exchange can try to keep the browser away from HTTPS. HTTP Strict Transport Security (HSTS), defined by RFC 6797, moves that decision into the user agent. After a host sends a valid Strict-Transport-Security header over a secure connection, a conforming user agent records the policy. During its lifetime, later attempts to contact that host with HTTP are converted to HTTPS before an HTTP request is sent.

Cybersecurity HTTPS

Cybersecurity / 24 Sep 2026 / 6 min read

Encrypted Client Hello Keeps Sensitive TLS Metadata Inside the Inner ClientHello

TLS 1.3 encrypts most handshake messages after ServerHello, but the initial ClientHello is sent before those handshake keys exist. That leaves fields in the first flight visible to an observer on the network. Server Name Indication (SNI) is especially revealing because it can identify the requested service even when the later certificate and application traffic are encrypted. RFC 9849 defines Encrypted Client Hello (ECH) to narrow that exposure. ECH does not encrypt the entire first packet. It constructs two ClientHello messages with different roles: a private ClientHelloInner containing the connection parameters intended for the backend, and a public ClientHelloOuter that carries an encrypted representation of the inner message.

Cybersecurity TLS

Cybersecurity / 24 Sep 2026 / 5 min read

DNS Cookies Bind UDP Requests to Return-Path Reachability

UDP lets a sender place a source address in a datagram without a transport handshake that proves the sender can receive traffic at that address. DNS inherits that property when it runs over UDP. An off-path attacker can therefore send a query with a forged source address and try to make a DNS server direct its response toward another host. DNS Cookies add a lightweight challenge-and-return mechanism inside EDNS. RFC 7873 defines the COOKIE option, while RFC 9018 tightens Server Cookie construction for interoperable deployments. The mechanism does not turn UDP into an authenticated transport. It gives DNS clients and servers additional evidence about whether a peer has participated in an earlier exchange at the relevant network address.

Cybersecurity DNS

Cybersecurity / 24 Sep 2026 / 5 min read

DNS Cookies Bind UDP Replies to Recent Client State

UDP gives DNS low-overhead transport, but its source address can be forged and its replies can be imitated by an off-path sender. DNS Cookies add a small piece of client-generated state and, after contact with a supporting server, server-generated state. The mechanism raises the cost of off-path forgery without requiring a server to keep a session table for every client. The mechanism is deliberately limited. RFC 7873 describes DNS Cookies as lightweight transaction security against off-path denial-of-service, amplification, forgery, and cache-poisoning attacks. It does not protect against an adversary that can observe the DNS exchange. RFC 9018 later tightened cookie construction so independently implemented anycast servers can interoperate.

Cybersecurity DNS

Cybersecurity / 24 Sep 2026 / 6 min read

DANE TLSA Binds TLS Keys to DNSSEC

TLS normally authenticates a server through a certificate chain that terminates at a trust anchor already accepted by the client. DANE adds another path: a domain can publish a TLSA record in DNS and protect that record with DNSSEC. A DANE-capable client can then compare certificate material from the TLS handshake with the association published by the domain. RFC 6698 defines the TLSA resource record. RFC 7671 updates the operational rules and narrows several deployment choices. The central security property is specific: only DNSSEC-validated TLSA data is suitable for DANE authentication. An insecure or indeterminate TLSA RRset does not provide the authenticated DNS binding that DANE requires.

Cybersecurity DANE

Cybersecurity / 24 Sep 2026 / 7 min read

DANE TLSA Binds TLS Credentials to DNSSEC

A TLS certificate normally reaches a client through the TLS handshake, while the client decides whether to trust it using its configured authentication policy. DNS-Based Authentication of Named Entities, or DANE, adds a separate authenticated input: a TLSA record protected by DNSSEC can state which certificate or public key material is acceptable for a specific service endpoint. The mechanism is not a replacement label for TLS. TLS still provides the handshake, key agreement, encryption, and record protection. DANE supplies authentication data that a client can apply while evaluating the server credential.

Cybersecurity DANE

Cybersecurity / 24 Sep 2026 / 5 min read

CSP Nonces and strict-dynamic Shift Script Trust to Authorized Roots

Content Security Policy can restrict script execution without maintaining a long list of trusted hostnames. A nonce-based policy gives selected script elements an unpredictable, response-specific token. When strict-dynamic is also present, a supporting browser can propagate trust from those authorized root scripts to scripts they create programmatically. This changes the security boundary. Trust is attached to an authorized execution root rather than every network origin that might serve JavaScript. A nonce authorizes a specific script element A server can emit a policy such as:

Cybersecurity Content Security Policy

Cybersecurity / 24 Sep 2026 / 5 min read

Certificate Transparency Separates Log Promises from Inclusion Proofs

A TLS certificate can be valid under normal chain validation and still deserve public scrutiny. Certificate Transparency (CT) adds that visibility by placing certificates or precertificates in public logs designed for auditing. The security model is more precise than a simple claim that a certificate has been logged: CT separates a log’s signed promise from later evidence that the promised entry actually reached the log’s Merkle tree. RFC 9162 describes CT version 2.0. A conforming log is an append-only Merkle tree. When it accepts a certificate or precertificate submission, it returns a Signed Certificate Timestamp (SCT). That SCT is a signed commitment associated with the accepted submission and a timestamp. It is not, by itself, a Merkle inclusion proof.

Cybersecurity TLS

Cybersecurity / 24 Sep 2026 / 4 min read

Certificate Transparency Logs Expose Public Certificate Issuance

A publicly trusted certificate can be syntactically valid, correctly signed, and still be unexpected. A certificate authority might issue one for the wrong subject, an account might be compromised, or an authorization process might fail. Certificate Transparency (CT) adds public observability to certificate issuance so that such certificates do not have to remain invisible to the affected domain operator. RFC 9162 specifies Certificate Transparency Version 2.0. Its central mechanism is an append-only public log backed by a Merkle tree. Certificate authorities and other submitters can send certificates or precertificates to a log, and monitors can inspect logged entries for certificates relevant to domains they watch.

Cybersecurity PKI

Cybersecurity / 24 Sep 2026 / 6 min read

CDS and CDNSKEY Automate DNSSEC Delegation Trust Updates

A DNSSEC-signed child zone can rotate its signing keys without changing the delegation immediately, but validators ultimately depend on the DS record set published by the parent. That parent-side state creates an operational handoff: a new key in the child does not become a secure delegation anchor merely because the child publishes it. CDS and CDNSKEY provide an in-band mechanism for that handoff. RFC 7344 defines records that a child can publish at its zone apex to signal prospective DS parameters. A parental agent can retrieve the signal, validate it under the applicable rules, apply local acceptance policy, and update the parent-side DS set.

Cybersecurity DNSSEC

Cybersecurity / 24 Sep 2026 / 6 min read

CAA Records Constrain Public Certificate Issuance

A public certificate authority does more than validate control of a DNS name. Before issuing a certificate, a CA that follows the CAA specification also checks DNS for a Certification Authority Authorization policy relevant to each requested name. That policy can narrow the set of issuers permitted to create certificates for the domain. CAA is an issuance control, not a replacement for domain-control validation. An authorized CA still has to apply its normal validation and issuance requirements. The record adds another decision: even after validation succeeds, is this issuer permitted by the domain’s published CAA policy?

Cybersecurity CAA

Cybersecurity / 24 Sep 2026 / 4 min read

CAA Narrows Certificate Issuance to Authorized CAs

Public certificate authorities validate control of a domain name before issuing a certificate, but domain control is not the only policy a domain operator can publish. Certificate Authority Authorization (CAA), specified in RFC 8659, adds a DNS-based signal that states which CAs are permitted to issue for a name. CAA does not replace domain-control validation. It adds another decision point before issuance: a conforming CA checks the applicable CAA policy and proceeds only when that policy permits the CA to issue the requested certificate.

Cybersecurity CAA