What actually happens if you submit a domain to the HSTS preload list and later need to serve plain HTTP?

The honest answer is: you have a problem that can outlive your control of the domain.

HTTP Strict Transport Security (HSTS, RFC 6797) is a response header instructing browsers to only ever reach a host over HTTPS for max-age seconds. Its flaw is the first visit: before the browser has seen the header even once, an attacker can downgrade the initial request. The preload list closes that gap by hardcoding domains into the browser binary itself, so HTTPS is enforced from the very first connection — including the includeSubDomains directive.

The trap is removal latency. Getting onto the list (via hstspreload.org) requires max-age of at least one year and the preload directive. Getting off requires a separate removal request, and the change only reaches users as browsers update and propagate — historically weeks to many months. Older or un-updated browsers may enforce it far longer.

The operational hazard is concrete: includeSubDomains will break any subdomain that cannot serve valid HTTPS — internal tools, legacy hosts, third-party CNAMEs. Operators have shipped preload, then discovered a subdomain they forgot, with no fast escape.

Further reading: RFC 6797 §11, §12; the Chromium HSTS preload submission policy.

Bottom line: preload is a near-irreversible commitment to HTTPS-everywhere including all subdomains — audit your full subdomain inventory before submitting, not after.

What actually changed in the structure of a TLS 1.3 cipher suite name?

The rename is small on screen but reflects a deep redesign worth reading precisely.

A TLS 1.2 suite like ECDHE-RSA-AES128-GCM-SHA256 encodes four independent choices: key exchange (ECDHE), authentication (RSA), bulk cipher (AES-128-GCM), and the hash for the pseudo-random function (SHA-256). The suite negotiated all four together.

TLS 1.3 (RFC 8446) decouples them. Key exchange and authentication are negotiated separately — via supported_groups, key_share, and signature_algorithms — so they no longer belong in the suite name. What remains is the AEAD cipher plus the HKDF hash. Hence the entire TLS 1.3 suite registry is tiny: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, plus two CCM variants.

The word AEAD (Authenticated Encryption with Associated Data, RFC 5116) is the crux. TLS 1.3 mandates AEAD and removed every non-AEAD construction. The old MAC-then-encrypt and CBC-mode suites that enabled Lucky 13, BEAST, and POODLE-class padding-oracle attacks are simply not expressible. There is no RC4, no CBC, no static-RSA key exchange, no compression.

This is why TLS 1.3 has far fewer suites: the insecure combinatorial space was deleted, not merely deprecated.

Further reading: RFC 8446 §B.4, RFC 5116, RFC 7905 (ChaCha20-Poly1305).

Bottom line: a TLS 1.3 suite names only the AEAD cipher and hash because authentication and key exchange moved to their own extensions — and every padding-oracle-prone mode was removed outright.

Российские букмекеры увеличили закуп трафика с мобильных приложений

Российские букмекеры в 1 квартале 2026 года заметно нарастили закупку трафика из мобильных приложений. На фоне ужесточения регулирования они смещают бюджеты в новые каналы, где ещё есть живой трафик.

По данным UMG, доля in-app-рекламы выросла с 3-4% до 5-6% при объёме рынка около 10 млрд рублей. Но это может быть только начало — в блоге разбираем…

➡️ Читайте на сайте: https://aff.top/blog/rossiiskie-bukmekery-uvelichili-zakup-trafika-s-mobilnykh-prilozhenii

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

Mia Khalifa стала амбпссадором 1win

Mia Khalifa снова засветилась рядом с 1win: в Instagram она показала цепочку с логотипом бренда и статус «VIP 1win».

Параллельно всплыла история с ее ставкой на Испанию на ЧМ — по данным поста, выигрыш мог составить 200к$.

Официального подтверждения амбассадорства пока нет, но для арбитражников это уже повод для новых креативов. Что именно здесь…

➡️ Читайте на сайте: https://aff.top/blog/mia-khalifa-stala-ambpssadorom-1win

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

What actually is the difference between blocked mixed content and upgraded mixed content?

The distinction is enforced by the browser, defined in the W3C Mixed Content specification, and it is finer than "the padlock turned grey."

Mixed content is a resource loaded over plain HTTP on a page delivered over HTTPS. The spec splits it into two categories with different treatment.

Active mixed content — scripts, stylesheets, iframes, XMLHttpRequest/fetch — can rewrite the whole page, so it is blocked outright. The browser refuses to load it and logs a console error. There is no "proceed anyway" for these in modern browsers.

Passive (or "optionally-blockable") mixed content — images, audio, video — historically only downgraded the security indicator, because a tampered image can mislead but not execute. That tolerance is now closing: browsers increasingly auto-upgrade passive references to HTTPS and block on failure.

The operator's lever is the upgrade-insecure-requests Content Security Policy directive. It tells the browser to rewrite every http:// subresource on the page to https:// before fetching — a migration aid for sites with thousands of hardcoded HTTP URLs in legacy content. It does not relax security; it tightens it, and it does not affect navigation to other origins.

Note upgrade-insecure-requests differs from block-all-mixed-content, which blocks rather than rewrites.

Further reading: W3C Mixed Content spec; CSP Level 3, upgrade-insecure-requests.

Bottom line: active mixed content is always blocked, passive is increasingly auto-upgraded — and upgrade-insecure-requests rewrites HTTP subresources to HTTPS rather than letting them fail.

Короткий домен 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.