AI Weekly Malaysia

OpenSSL patched CVE-2026-84782, a High-severity DTLS bug where a resend timer firing mid-message causes an earlier handshake message to be re-sent with the wrong label, leaking leftover heap bytes to the peer as unencrypted handshake data or crashing the process on unmapped memory reads. Fixes shipped September 29 in OpenSSL 4.0.3, 3.6.5, 3.5.9 and 3.4.8; the older 3.0, 1.1.1 and 1.0.2 branches get fixes only for paying premium-support customers, and 3.0 stopped receiving public security fixes on September 7. CISA scored it CVSS 8.2 (confidentiality Low, availability High); Secorizon's Laurent Gaffie reported it August 17, Ryan Hooper wrote the fix, and OpenSSL reports no known exploitation.

Why: Only code that runs DTLS over OpenSSL is exposed — think WebRTC data channels, TURN/media servers, VoIP key setup, IoT and UDP-based services — so check whether those components are in your stack before treating this as urgent for your whole fleet. The sharper decision is version lifecycle: if you are still on OpenSSL 3.0, 1.1.1 or 1.0.2, this patch is behind premium support, so the choice is pay, migrate to a 3.4+/3.6/4.0 branch, or knowingly run unpatched against this and every future High fix.

Cloudflare added per-connection post-quantum TLS visibility to Logpush, Log Explorer, and the HTTP Traffic Analytics dashboard, exposing the key-exchange algorithm negotiated on every incoming request so customers can audit PQ posture per domain. Its Radar data shows roughly 70% of browser-generated traffic to Cloudflare is already protected with hybrid ML-KEM (FIPS 203), but only about 15% of the origins Cloudflare connects to use it. Cloudflare is targeting full post-quantum security by 2029, and says many customers face quantum-readiness deadlines around 2030; it also recently launched Automatic Key Exchange for the Cloudflare-to-origin connection to reveal which algorithms an origin supports.

Why: The 70% visitor vs 15% origin gap is the actionable number: if you run an origin behind Cloudflare, your visitors are probably already negotiating hybrid ML-KEM while your own origin likely is not, so the weak link is on your side of the connection. You can now pull the negotiated key-exchange field from Logpush or Log Explorer per domain to find which of your origins still fall back to classical cryptography, and check whether outdated origin TLS config is downgrading a connection that could support PQ. There is no Malaysia-specific or regional detail in this post; treat it as a general infrastructure item.

Cloudflare announced it is becoming a certificate authority, and says that CA will support Merkle Tree Certificates (MTCs), targeting early 2027 for inclusion in Chrome's newly launched Quantum-resistant Root Store, with standard MTC issuance offered at no cost. The post frames MTCs as the industry's agreed path forward after an experimental deployment with Chrome, arguing that simply swapping post-quantum cryptography into certificates at Internet scale would cause unacceptable performance degradation. Cloudflare also positions the MTC design as making certificate transparency a first-party property rather than an add-on, alongside a stated industry goal of upgrading to post-quantum cryptography by 2029. The published excerpt cuts off during the background section on today's trust ecosystem, so the detailed MTC mechanics are not in the provided text.

Why: If you terminate TLS through Cloudflare, the concrete change to track is that MTC issuance is promised free and its CA is targeting Chrome's Quantum-resistant Root Store in early 2027 — that is a browser-trust change, not just a Cloudflare feature. For everyone else, the 2029 post-quantum deadline in this post is the thing to plan against: MTCs exist because putting PQ signatures directly into certificates degrades performance at scale, so the decision to make is which part of your stack (load balancer, CDN, ingress, client libraries) will need MTC support versus classical certificate issuance, and when. The post contains no Malaysia- or Southeast Asia-specific detail; any local impact would come only from how widely regional builders use Cloudflare as their TLS terminator, which this text does not establish.

Yash Garg documents routing a PS5's broadcast stream to a local machine instead of Twitch, because the PS5 has no native Discord screen sharing and a capture card costs upwards of $100. The key finding is that the PS5 resolves ingest.twitch.tv via DNS on every broadcast, but that host is only a discovery endpoint — it returns a regional ingest hostname like ap-southeast-1.prod.fi.contribute.live-video.net, where the real stream is pushed. Spoofing that ingest host runs into RTMPS (RTMP over TLS on port 443), and the PS5 validates the certificate against trusted CAs, so a self-signed cert fails.

Why: The practical lesson is that hostname secrecy isn't the control — the discovery-then-ingest split plus CA-validated TLS is. If you build a client that pushes to a vendor endpoint, note that a self-signed cert or a DNS override won't get you past it, and that a two-step discovery call means blocking one hostname isn't enough. The write-up is truncated at the certificate-validation failure, so the actual workaround isn't shown in the text we have.

Cloudflare announced its intent to become a public certificate authority, saying it has applied for inclusion in the Chrome, Apple, Microsoft, and Mozilla root programs and signed a definitive agreement to acquire an established, broadly trusted root from GlobalSign — a root trusted across browsers, OSes, and devices since 2012 — so it can reach older clients on day one. It also says it plans to be one of the first CAs to serve post-quantum certificates, targeting Chrome's recently announced Quantum-resistant Root Program. Cloudflare states it is not issuing certificates yet and gives no date for when it will.

Why: There is nothing to change today: Cloudflare explicitly says it is not issuing certificates yet, so no migration or config work is warranted. The concrete thing to track is the two-track trust strategy — a bought GlobalSign root for old devices versus a brand-new root built for root programs that are starting to cap how old a trusted root may be — plus Chrome's Quantum-resistant Root Program, which is the timeline that will eventually force post-quantum certificate choices on teams that terminate TLS. If you buy or resell certificates through GlobalSign, watch how the root's ownership change lands.

The headline states that Cloudflare plans to issue quantum-safe TLS certificates, but the retrieved Ars Technica page contains only cookie-consent and privacy-policy boilerplate — no publication body. As a result there are no details available here on algorithms, timelines, pricing, or which Cloudflare products are affected.

Why: There is nothing here a builder can act on: no date, no cipher suite, no certificate-authority or API change to plan around. If you were about to add a post-quantum migration item to a sprint based on this headline, hold off until the actual announcement text is readable — the fetched page gives you zero specifics to size the work against.