What actually does Encrypted Client Hello encrypt, and which metadata still leaks?

A precise question, because ECH is often oversold as making TLS "fully private." It closes one specific gap.

For years, the last plaintext identifier in an HTTPS handshake was the Server Name Indication (SNI, RFC 6066): the hostname the client puts in the clear so a server hosting many sites knows which certificate to present. A network observer reading SNI learns exactly which site you're visiting, even though the rest is encrypted.

Encrypted Client Hello (ECH, the draft successor to ESNI) encrypts the sensitive ClientHello — including SNI and ALPN — under a public key the client fetches via DNS in an HTTPS resource record (the ech field of the SVCB/HTTPS RR, RFC 9460). The client sends an "outer" ClientHello naming a shared, generic public server, with the real "inner" ClientHello encrypted via HPKE (Hybrid Public Key Encryption, RFC 9180). The fronting provider decrypts and routes internally.

What still leaks: the destination IP address, and the DNS lookup itself unless it runs over DNS-over-HTTPS or DNS-over-TLS. ECH's privacy therefore depends on many sites sharing one front (a large anonymity set) and on encrypted DNS — without both, traffic analysis can still narrow the target.

Further reading: draft-ietf-tls-esni (ECH), RFC 9180 (HPKE), RFC 9460 (SVCB/HTTPS RR).

Bottom line: ECH hides SNI and ALPN via HPKE, but the destination IP and unencrypted DNS still leak — it needs a big shared front and encrypted DNS to actually anonymize.

Z.ai анонсировала новую GLM-5.5

Z.ai готовит релиз флагманской GLM-5.5: модель обещают показать в августе 2026 года.

Главная интрига — рост до 1 трлн параметров при том же контекстном окне в 1 млн токенов. Новинка снова будет заточена под код и агентные задачи.

Почему версия сразу 5.5, без 5.3 и 5.4, и что это может означать для рынка — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/z-ai-anonsirovala-novuiu-glm-5-5

🧠 Ещё больше инсайтов → в канале AFF.top

Telegram запустил собственный сервер для ботов

Telegram запустил собственный сервер для ботов и мани-приложений: теперь backend можно размещать прямо внутри инфраструктуры мессенджера.

Сервер работает на JavaScript/TypeScript, через вебхуки, и позволяет подключать SQL-базу для сбора контактов без посредников.

Пока неясны цена и ограничения — что именно уже можно тестировать, а где скрыт подв…

➡️ Читайте на сайте: https://aff.top/blog/telegram-zapustil-sobstvennyi-server-dlia-botov

🧠 Ещё больше инсайтов → в канале AFF.top

What actually stops a Certificate Transparency log from quietly rewriting its own history?

The answer is the consistency proof, and it is the cryptographic spine of CT's trust model (RFC 6962).

A CT log is an append-only Merkle tree: each certificate is a leaf, and every node hashes its two children. The root hash is a fixed-size fingerprint of the entire tree. The log periodically signs its current root as a Signed Tree Head (STH).

Two proofs make the structure trustworthy. An inclusion proof shows a specific certificate is in the tree under a given STH, by supplying the sibling hashes along the path to the root — logarithmic in the tree size. A consistency proof is the stronger guarantee: given an older STH and a newer one, it provides the minimal set of hashes proving the new tree is a strict superset of the old, append-only, with nothing removed or altered.

Why this matters: a malicious or compromised log could otherwise present one view to a domain owner (cert absent) and another to a victim (cert valid) — a split-view attack. Auditors and monitors gossip STHs and demand consistency proofs between them, making any divergent history detectable.

The property is detection, again, not prevention — but a log caught failing a consistency proof loses trust and is removed from browser lists.

Further reading: RFC 6962 §2.1.2, RFC 9162; the "gossip" drafts on STH sharing.

Bottom line: append-only is enforced socially via consistency proofs between signed tree heads — a log cannot rewrite history without producing detectable, non-repudiable evidence.

Google картинки станут конкурентом Pinterest

Google Картинки начали превращать в полноценную платформу с персональной лентой по прошлым запросам — по сути, в аналог Pinterest.

Во вкладке For you уже тестируют подборки, а ещё обещают коллекции и генерацию изображений во встроенной Nano Banana.

Как это будет работать и когда новинка дойдёт до других стран — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/google-kartinki-stanut-konkurentom-pinterest

🧠 Ещё больше инсайтов → в канале AFF.top

What actually lets a Certificate Authority delegate issuance for one domain without risking the whole Web?

The mechanism is the Name Constraints extension (RFC 5280 §4.2.1.10), and it is one of the most underused safety tools in the WebPKI.

The core danger of the certificate hierarchy is that any publicly-trusted CA can, technically, sign a certificate for any domain. A subordinate (intermediate) CA delegated to a third party inherits that unrestricted power — which is how a single compromised intermediate becomes a global threat.

Name Constraints scope that power. Placed in a CA certificate, the extension's permittedSubtrees and excludedSubtrees limit which names any certificate beneath it may bear. An intermediate constrained to permittedSubtrees: example.com can only issue for example.com and its subdomains; a certificate it signs for victim.org fails path validation at the client, regardless of the intermediate's signature being valid.

The critical detail is the criticality flag. To be enforced reliably, Name Constraints should be marked critical, so a client that doesn't understand the extension rejects the certificate rather than ignoring the constraint. Historically, incomplete client support and IP-address-constraint bugs limited deployment, but support is now broad.

This is the technical foundation for safely giving an enterprise its own constrained intermediate without granting it the entire namespace.

Further reading: RFC 5280 §4.2.1.10; the Mozilla Root Store Policy on technically-constrained sub-CAs.

Bottom line: Name Constraints turns an all-powerful intermediate into one scoped to specific domains — enforced at path validation, ideally marked critical so unaware clients fail closed.

Россияне не смогут покупать стейблкоины

Россиянам могут закрыть доступ к покупке стейблкоинов: в новой версии закона их приравняли к иностранным активам.

Купить такие токены смогут только квалифицированные инвесторы — например, с активами от 24 млн рублей или доходом от 12 млн в год.

Что это значит для обычных пользователей и когда правило заработает — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/rossiiane-ne-smogut-pokupat-steiblkoiny

🧠 Ещё больше инсайтов → в канале AFF.top

What actually prevents an attacker from forcing a TLS 1.3 client down to TLS 1.2?

The defense is a clever sentinel hidden in the server's random field, and it is worth reading precisely because version downgrade was a recurring class of attack.

TLS version negotiation is vulnerable because the ClientHello is sent in the clear. A network attacker can tamper with the offered versions, tricking peers into a weaker protocol — the lineage of FREAK, Logjam, and POODLE all involve forced downgrade or weak-parameter coercion.

TLS 1.3 (RFC 8446 §4.1.3) adds an integrity-checked tripwire. When a server that supports TLS 1.3 is nonetheless negotiating TLS 1.2 or below — whether legitimately or because an attacker stripped the supported_versions extension — it writes a specific 8-byte sentinel into the last bytes of its ServerHello Random field: 44 4F 57 4E 47 52 44 01 for 1.2, ending 00 for older. ("DOWNGRD" in ASCII.)

Because the ServerHello Random is covered by the handshake's signature/Finished verification, a genuine TLS 1.3 client that ends up on 1.2 will see this sentinel and know a real 1.3-capable server was on the other end. If it expected 1.3, it aborts — the attacker cannot remove the sentinel without breaking the authenticated handshake transcript.

Further reading: RFC 8446 §4.1.3; the Logjam and FREAK papers (2015).

Bottom line: TLS 1.3 embeds a signed "DOWNGRD" sentinel in ServerHello.Random so a downgraded-but-1.3-capable handshake is cryptographically detectable and aborted.

Pairs well with this channel

@NetworkMythHQ — We pressure-test what Ezoic, Mediavine and Raptive actually pay versus what their… Quietly one of the better feeds in the space.

What actually makes short-lived certificates a substitute for revocation rather than a complement?

The reasoning is quantitative, and it explains why the CA/Browser Forum is steering the industry toward 47-day maximum lifetimes by 2029.

Revocation exists to answer one question: has this certificate's trust been withdrawn before its expiry? Every revocation system — CRLs (RFC 5280), OCSP (RFC 6960), CRLite — is a mechanism to propagate that "trust withdrawn" signal faster than the certificate would naturally expire. All of them are imperfect: CRLs are stale, OCSP soft-fails, and propagation lags.

Short-lived certificates attack the premise. If a certificate is valid for, say, 7 days, then the worst-case window between compromise and natural expiry is 7 days — comparable to, or better than, the real-world propagation delay of revocation infrastructure. The certificate revokes itself by expiring. This is only feasible because ACME (RFC 8555) made issuance fully automatic; you cannot renew a 90-day cert by hand every week.

The trade-off is explicit. Revocation handles the rare emergency precisely; short lifetimes handle it statistically. Below a certain validity period, maintaining OCSP for the residual window costs more than it buys — which is why Let's Encrypt began phasing out OCSP in 2025 in favor of CRLs plus short lifetimes.

Further reading: CA/Browser Forum ballot SC-081; Let's Encrypt's OCSP deprecation announcement (2024–2025).

Bottom line: short-lived certs make expiry itself the revocation channel — once lifetime approaches revocation's propagation delay, running OCSP for the gap stops paying for itself.

What actually grows when you add post-quantum key exchange to a TLS 1.3 handshake?

The honest answer is bytes — and the byte count has measurable network consequences worth examining.

The migration target is hybrid key exchange: combine a classical curve with a post-quantum KEM (Key Encapsulation Mechanism) so the session stays secure if either survives. The deployed default is X25519MLKEM768, pairing X25519 with ML-KEM-768 (the standardized form of Kyber, FIPS 203).

The cost is in the key_share extension. A classical X25519 share is 32 bytes. An ML-KEM-768 public key is 1,184 bytes and its ciphertext 1,088 bytes. So the client's combined key share jumps from tens of bytes to over 1,200, and the server's response similarly. The ClientHello, which used to comfortably fit in a single network packet, now often spans multiple TCP segments.

This matters beyond bandwidth. Google's and Cloudflare's 2023–2024 measurement work found a real-world failure mode: middleboxes and TLS stacks that assumed the ClientHello fits in one packet, or that capped record sizes, broke on the larger hello — a phenomenon dubbed "protocol ossification." The fix is partly TCP-level (ensuring the larger ClientHello is handled across segments) and partly fixing intolerant implementations.

Further reading: FIPS 203 (ML-KEM); Cloudflare and Google PQC deployment reports (2023–2024); draft-ietf-tls-hybrid-design.

Bottom line: PQC inflates the key_share from ~32 bytes to over a kilobyte, pushing the ClientHello past one packet — the surprising cost isn't CPU, it's middlebox and stack intolerance to a larger hello.