Короткий домен Telegram перестал работать

Telegram лишился домена t.me: он разделегирован и больше не работает на уровне регистратора. Платформа срочно переезжает на telegram.me, а владельцам крупных каналов стоит обновить публичные ссылки. Сроки восстановления неизвестны, и есть риск, что t.me не вернётся вовсе на фоне давления на Telegram.

➡️ Читайте на сайте: https://aff.top/blog/korotkii-domen-telegram-perestal-rabotat

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

Youtube тестирует поиск с AI

YouTube начал тестировать Ask YouTube — поиск с ИИ, где можно задавать вопросы обычным языком и получать не список ссылок, а готовую подборку видео и фрагментов.

Фича уже доступна в США и работает на сложные запросы: если нужно, ИИ уточняет вопрос и подсказывает следующий шаг.

Что это значит для поиска на YouTube и когда новинка дойдёт до других…

➡️ Читайте на сайте: https://aff.top/blog/youtube-testiruet-poisk-s-ai

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

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.