Skip to content

Archive

Cybersecurity

535 articles
Cybersecurity 23 Sep 2026 6 min read

TLS-RPT Exposes SMTP TLS Failures as Aggregate Reports

SMTP transport security has an observability problem. A recipient domain can publish an MTA-STS policy or DANE TLSA records, yet many failures occur on remote sending systems: certificate validation can fail, an MX host can become unreachable, STARTTLS negotiation can break, or a published transport policy can be invalid. The recipient needs telemetry from those senders to distinguish a working deployment from a policy that silently blocks delivery. SMTP TLS Reporting, commonly called TLS-RPT, defines that telemetry channel in RFC 8460. A recipient domain publishes a DNS TXT record that names one or more report destinations. Participating sending systems then produce aggregate reports describing successful policy-compliant TLS sessions and failures encountered while delivering mail to that domain.

Cybersecurity 23 Sep 2026 5 min read

TLS Must-Staple Makes OCSP Status Mandatory

TLS Must-Staple Makes OCSP Status Mandatory OCSP stapling lets a TLS server carry certificate-status evidence inside the handshake. The client can validate that response without making a separate request to the certificate authority’s OCSP responder. Ordinary stapling, however, does not by itself make a missing response conclusive: absence can mean that the server did not provide one. RFC 7633 defines the X.509v3 TLS Feature extension. A certificate can use that extension to state that a TLS feature is required. The feature commonly called Must-Staple identifies status_request, binding use of the certificate to delivery of certificate-status information for clients that implement the extension.

Cybersecurity 23 Sep 2026 4 min read

The __Host- Cookie Prefix Constrains Cookie Scope

The __Host- Cookie Prefix Constrains Cookie Scope Cookie security depends on more than the value stored in a cookie. Scope determines which requests can carry it and which responses can attempt to replace it. For a sensitive session cookie, a broad domain rule can give sibling hosts influence that the application did not intend. The __Host- cookie name prefix gives supporting browsers a compact set of scope requirements. A cookie whose name starts with __Host- is accepted only when it is set with Secure, has Path=/, and omits the Domain attribute. The result is a host-only cookie available across paths on that host and restricted to secure transport.

Cybersecurity 23 Sep 2026 6 min read

Subresource Integrity Binds External Assets to Cryptographic Digests

Subresource Integrity Binds External Assets to Cryptographic Digests A web page can load JavaScript and CSS from an origin outside its own deployment boundary. That arrangement is convenient for shared packages and content delivery networks, but it also delegates part of the page’s execution or presentation path to the server that returns those resources. Subresource Integrity (SRI) adds a byte-level constraint to that dependency. The page supplies one or more cryptographic digests in an integrity attribute. A supporting browser fetches the resource, computes a digest with the declared algorithm, and accepts the response only when the bytes satisfy the integrity metadata.

Cybersecurity 23 Sep 2026 5 min read

SSHFP Publishes SSH Host Key Fingerprints Through DNSSEC

SSHFP Publishes SSH Host Key Fingerprints Through DNSSEC SSH clients need a trustworthy basis for deciding whether a server’s host key belongs to the intended host. A local known_hosts entry supplies that basis after a key has been accepted, but the first connection still needs a verification path if the key was not provisioned in advance. SSHFP moves a host-key fingerprint into DNS. RFC 4255 defines the SSHFP resource record so a client can compare the public key presented by an SSH server with a fingerprint published for that hostname. The security property depends on authenticated DNS data: a matching fingerprint from an unauthenticated DNS answer does not provide the trust condition defined for secure SSHFP verification.

Cybersecurity 23 Sep 2026 5 min read

RPKI Origin Validation Checks BGP Prefix Authority

BGP announces reachability, but a route advertisement by itself does not prove that the originating Autonomous System is authorized to originate the prefix. Resource Public Key Infrastructure, or RPKI, adds signed resource authorization data that can be converted into records a router uses for origin validation. The resulting check is deliberately narrow. It compares the route prefix and origin AS with validated ROA payloads, commonly called VRPs. The result can feed routing policy, but it does not authenticate every AS in AS_PATH and does not turn BGP into a path-validation protocol.

Cybersecurity 23 Sep 2026 5 min read

RPKI ASPA Authorizes Transit Relationships for AS_PATH Checks

A valid route origin says little about the relationships represented by the rest of an AS_PATH. A prefix can originate from an authorized AS and still travel through a sequence that conflicts with expected customer-to-provider structure. Autonomous System Provider Authorization, or ASPA, adds a signed RPKI object for that second problem. As of September 2026, ASPA is still specified in active IETF Internet-Drafts rather than a published RFC. The current ASPA profile draft defines the signed object, while the current verification draft defines procedures for applying validated ASPA data to BGP AS_PATHs. That status matters operationally: fields and procedures remain subject to change until the specifications complete the standards process.

Cybersecurity 23 Sep 2026 6 min read

Origin-Agent-Cluster Separates Origin-Keyed JavaScript Heaps

Origin-Agent-Cluster Separates Origin-Keyed JavaScript Heaps Web origins that share a site can still belong to different security principals. app.example.com and admin.example.com, for example, have distinct origins even though both sit beneath the same registrable domain. Browser process architecture has historically allowed related origins to share an agent cluster in some cases, which can place their JavaScript execution environments closer together than an origin-only model suggests. The Origin-Agent-Cluster response header gives a document a way to request origin-keyed clustering:

Cybersecurity 23 Sep 2026 6 min read

OpenSSH Host Certificates Replace Per-Host Key Pinning

OpenSSH Host Certificates Replace Per-Host Key Pinning SSH host authentication protects a client from silently accepting a different server key for a name it intended to reach. The familiar known_hosts model can pin a key directly to a host. That model is simple, but operating it across a large fleet creates a distribution problem: new hosts need trusted entries, planned key rotation changes pins, and stale entries can survive after infrastructure changes.

Cybersecurity 23 Sep 2026 6 min read

NSEC3 Opt-Out Trades Denial Proof for Delegation Scale

DNSSEC needs a cryptographic answer not only when data exists, but also when a requested name or record does not exist. NSEC3 supplies that negative proof through a chain of hashed owner names. For zones dominated by delegations to unsigned children, representing every insecure delegation in that chain can create substantial maintenance work. NSEC3 Opt-Out changes that trade-off. An Opt-Out span may cover insecure delegations without giving each one a matching NSEC3 record. The result can reduce NSEC3-chain updates in large delegation-heavy zones, but the omitted names no longer receive the same authenticated existence or nonexistence statement.

Cybersecurity 23 Sep 2026 5 min read

MTA-STS Enforces Authenticated TLS for SMTP Delivery

MTA-STS Enforces Authenticated TLS for SMTP Delivery SMTP STARTTLS can encrypt mail transport, but ordinary opportunistic TLS permits delivery to continue when encryption is unavailable. That compatibility behavior leaves room for an active intermediary to suppress STARTTLS or redirect delivery toward an unintended server. SMTP MTA Strict Transport Security, defined by RFC 8461, gives a recipient domain a policy channel for conforming sending MTAs. The policy states which MX hosts are acceptable and whether delivery must use TLS with a valid PKIX certificate. In enforce mode, a sender does not silently downgrade when those checks fail.

Cybersecurity 23 Sep 2026 6 min read

HTTP Strict Transport Security Pins HTTPS for Future Visits

HTTP Strict Transport Security Pins HTTPS for Future Visits TLS protects an HTTP connection only after the client is using HTTPS. A user who enters a bare hostname, follows an old http:// link, or reaches a redirecting HTTP endpoint can still begin with an unencrypted request. HTTP Strict Transport Security (HSTS) gives a supporting browser a persistent rule for that host. After receiving a valid Strict-Transport-Security header over HTTPS, the browser records the policy and rewrites later HTTP navigation to HTTPS while the policy remains active.

Cybersecurity 23 Sep 2026 5 min read

Fetch Metadata Adds Request Context to Server-Side Policy

Fetch Metadata Adds Request Context to Server-Side Policy A server often sees the same authenticated cookie on requests created by very different browser actions. A form submitted from another site, a same-origin API call, an image load, and a top-level navigation can all reach the same host. Cookies alone do not describe that request context. Fetch Metadata adds browser-generated request headers that describe where a request came from and how the browser intends to use the response. A server can incorporate those signals into an isolation policy before application logic handles a sensitive route.

Cybersecurity 23 Sep 2026 5 min read

DNS Cookies Limit Off-Path DNS Amplification and Forgery

UDP makes DNS efficient, but its source address can be forged by an off-path sender. A small query carrying a victim’s address can trigger a larger response toward that victim, creating reflection and amplification. Forged replies also matter to resolvers because an attacker may try to inject an answer before the legitimate response arrives. DNS Cookies add a lightweight transaction token to this boundary. RFC 7873 defines the COOKIE EDNS option, while RFC 9018 updates the server-side construction so implementations can interoperate, including in multi-vendor anycast deployments. The mechanism is deliberately limited: it raises the cost of off-path forgery, but it is not encryption, DNS data authentication, or protection from an adversary that can observe traffic on path.

Cybersecurity 23 Sep 2026 5 min read

DMARC Ties Mail Authentication to the Visible From Domain

Email can carry several domain identities at once. The address displayed in the From header can differ from the envelope sender used by SMTP, while a DKIM signature can name yet another domain in its d= tag. SPF and DKIM authenticate identities from those separate protocol layers; neither mechanism alone requires its authenticated domain to match the domain presented to a recipient in From. Domain-based Message Authentication, Reporting, and Conformance (DMARC), specified in RFC 7489, connects those layers. A receiver evaluates SPF and DKIM, tests domain alignment against the RFC5322.From domain, and obtains a policy published by that domain. A message passes DMARC when at least one qualifying SPF or DKIM path both authenticates successfully and aligns.

Cybersecurity 23 Sep 2026 4 min read

DANE TLSA Binds TLS Service Keys Through DNSSEC

DANE TLSA Binds TLS Service Keys Through DNSSEC TLS normally authenticates a server through certificate validation rules defined by the application and its trust model. DANE adds a DNS-based binding: a TLSA resource record associates a service endpoint with certificate or public-key material, while DNSSEC supplies authenticated DNS data for that association. The boundary is strict. A TLSA RRset that is insecure or has an indeterminate DNSSEC state cannot serve as an authenticated DANE association. DANE therefore depends on DNSSEC validation rather than treating ordinary DNS transport as sufficient evidence.

Cybersecurity 23 Sep 2026 5 min read

DANE for SMTP Binds TLS Authentication to DNSSEC

SMTP commonly begins with a plaintext connection and upgrades it with STARTTLS. Opportunistic TLS improves confidentiality when both sides support it, but an unauthenticated upgrade can be suppressed or redirected by an active network attacker. DANE for SMTP, specified in RFC 7672, adds an authentication path rooted in DNSSEC. The sending MTA does not treat every TLSA response as authoritative. It first needs a DNSSEC-secure result for the destination data that drives delivery. When usable TLSA records are securely obtained for the selected MX host, those records constrain the TLS server credentials that the sender accepts.

Cybersecurity 23 Sep 2026 5 min read

Cross-Origin-Resource-Policy Limits No-CORS Embedding

Cross-Origin-Resource-Policy Limits No-CORS Embedding Many browser elements can request resources across origins without using CORS. Images, scripts, media, and other subresources can travel through no-cors fetch paths where the page does not receive normal script-level access to the response body. That restriction is useful, but an unwanted cross-origin load can still expose a resource to embedding or side-channel conditions. The Cross-Origin-Resource-Policy response header, commonly shortened to CORP, lets the resource owner state which site relationship is allowed for those no-cors loads.

Cybersecurity 23 Sep 2026 6 min read

Content Security Policy Nonces Control Script Execution

Content Security Policy Nonces Control Script Execution A Content Security Policy can turn script execution from a broad location rule into an explicit per-response decision. Instead of trusting every script served from an allowed host, the server places a fresh nonce in the policy and copies that value only onto script elements it intends to authorize. Content-Security-Policy: script-src 'nonce-r4nd0mBase64Value' <script nonce="r4nd0mBase64Value" src="/assets/app.js"></script> A script element without the matching nonce is not authorized by that directive. This makes injected markup less useful to an attacker when the injection cannot obtain a valid nonce.

Cybersecurity 23 Sep 2026 4 min read

CAA Records Restrict Certificate Authority Issuance

CAA Records Restrict Certificate Authority Issuance A public certificate authority can issue a certificate only after satisfying its validation and policy requirements. DNS Certification Authority Authorization adds another control: the domain holder can publish a CAA resource record set that states which issuers are authorized for a name. CAA is an issuance constraint, not a replacement for domain-control validation. An authorized CA still has to perform the validation required by its certificate policy. Conversely, successful domain validation does not permit a compliant CA to disregard an applicable CAA restriction.

Cybersecurity 23 Sep 2026 5 min read

BGPsec Signs the AS Path Hop by Hop

BGP route origin authorization protects one narrow statement: which AS may originate a prefix. It does not cryptographically protect every AS hop that appears after the origin. BGPsec, standardized in RFC 8205, addresses that separate boundary by carrying signed path information in BGP UPDATE messages. The mechanism changes more than the validation rule. A BGPsec UPDATE uses BGPsec_PATH instead of the conventional AS_PATH, and participating ASes extend a chain of Secure_Path and Signature Segments as the route moves between BGPsec-capable external peers.

Cybersecurity 23 Sep 2026 4 min read

BGP Roles and OTC Constrain Route Leak Propagation

A BGP route can carry a valid origin and still travel beyond the scope intended by the networks that exchanged it. That distinction matters because origin authorization and route-leak control address different properties. RFC 7908 defines a route leak as propagation of routing announcements beyond their intended scope, commonly in conflict with policies tied to customer, provider, or peer relationships. RFC 9234 adds protocol machinery for that relationship context. BGP Roles identify the relationship at an eBGP session, while the Only to Customer attribute, abbreviated OTC, marks routes whose subsequent propagation is constrained. The mechanism targets route propagation policy; it does not turn BGP into a cryptographically authenticated path protocol.

Cybersecurity 23 Sep 2026 5 min read

Aggressive DNSSEC Caching Reuses Authenticated Denial Proofs

A conventional DNS negative cache remembers a negative result for a specific query. DNSSEC adds richer material to that response: NSEC and NSEC3 records can cryptographically prove that names or record types do not exist. RFC 8198 permits a validating resolver to reuse those cached proofs for later queries that fall inside the proven space. This behavior is called aggressive use of the DNSSEC-validated cache. It can suppress repeated authoritative lookups for names whose nonexistence is already established by validated data. The mechanism is more than a performance optimization: fewer unnecessary queries also reduce exposure of misspelled or random names beyond the recursive resolver and can absorb part of the load created by random-QNAME traffic.

Cybersecurity 22 Sep 2026 4 min read

X-Content-Type-Options Blocks MIME Type Sniffing

X-Content-Type-Options Blocks MIME Type Sniffing HTTP responses carry a Content-Type header that describes the media type of the representation. Browsers also have a history of inferring a type from response bytes when the declared type is absent, incorrect, or ambiguous. That inference can be useful for old content, but it creates an execution boundary that application operators may not intend. X-Content-Type-Options: nosniff narrows that boundary. For request destinations covered by the browser’s MIME checking rules, the response must have an acceptable declared type instead of relying on content sniffing. The header is small, but its effect depends on correct Content-Type values throughout the application.