Is TLS 1.3 0-RTT simply a free speed upgrade?

The advice "turn on 0-RTT, it's faster with no downside" omits a real and spec-acknowledged security caveat. 0-RTT (zero round-trip time, RFC 8446 §2.3) lets a client send application data in its very first flight, using a pre-shared key from a prior session. The latency win is genuine — you save a full round trip on resumption.

The cost is replay. Unlike the rest of TLS 1.3, 0-RTT "early data" carries no guarantee against replay: an attacker who captures the early-data flight can resend it, and the server has no transcript-level way to detect the duplicate. RFC 8446 §8 is explicit that anti-replay must be handled at the application layer or by single-use tickets, and that the protocol cannot provide it alone.

The operational rule that follows: only idempotent requests may travel in early data. A GET is safe; a POST that charges a card or mutates state is not. Cloudflare and others restrict 0-RTT to safe methods for exactly this reason.

— 0-RTT saves a round trip on resumption
— Early data is replayable by design
— Confine it to idempotent requests

Further reading: RFC 8446, §2.3 and §8.
Bottom line: 0-RTT is fast but not free of consequence. Without application-layer anti-replay, restrict early data to idempotent operations.

Тем временем подстилка коричневых Кардиналов и лично Кустова главред Максим Огненный завёл собственный канал, где, наверное, опять будет писать стихи и анонсировать вьюхи с ме**дроновыми наркоманами.🤡🤡

Чем вообще известен этот персонаж? Собсна, только порцией отборного кринжа, например, не так давно он выебывался на Иванова в "Письмах кардинала", но недожал и тема осталась нераскрытой. ЕЮ заслужил даже высокоинтеллектуальные выпады, которые тот не понял в силу врождённого аутизма:

Высокохудожественная лексика героя, демонстрируемая им не только на своем канале, но и на любой публичной площадке, настолько пленит любого слушателя, что мало кто может стать собеседником жертвы во второй раз.

Нихуя не разбираясь в аффилке, он на серьёзных щах брал интервью у Мефмедова и пытался построить серьёзный диалог с объёбанной ракетой. Из остальных достижений только нытье в чатиках: персонаж настолько невзрачный, что даже хуесосить его не так интересно.¯\_(ツ)_/¯

А теперь Огненный завёл собственный канал, где собрался выебать всех, но, походу, ебать будет лишь подписоту своей графоманией. Похожей хуйнёй занимался и оунер ФБ Киллы, который так любит рассуждать про экономику и политику. Оно и понятно: что у коричневых, что у киллы, что у партнёркина — один инвестор и одна крыша, поэтому подопечные синхронно занимаются бестолковой хуйнёй. Кому не похуй, подписывайтесь, будет интересно (нет): https://t.me/+dr240TeLtPc2Nzdk

В арбитраже деньги есть, но только у тех, кто с LuckyCards 💵

Do Certificate Transparency logs prevent CAs from misissuing certificates?

"CT stops bad certificates from being issued" is a common but mechanically wrong framing. Certificate Transparency (RFC 6962, updated by RFC 9162) is a detection system, not a prevention one. CT does not sit between a CA and issuance. A CA can still issue a certificate for any domain it is technically able to sign. What CT changes is that browsers require evidence — a Signed Certificate Timestamp (SCT) — that the certificate was submitted to public, append-only logs, or they reject it.

That shifts the security property from "can't be issued" to "can't be issued secretly." Domain owners and monitors (crt.sh, Meta's monitor, Cert Spotter) watch the logs and can spot an unauthorized certificate for their domain after the fact, then push for revocation and CA sanctions. The famous cases — Symantec's test-certificate misissuance surfaced via CT in 2015, leading to distrust by 2018 — were caught this way, not prevented.

The append-only Merkle tree structure makes the logs themselves tamper-evident, which is what gives the audit trail teeth.

— CT detects, it does not gate issuance
— SCTs are required for browser acceptance
— Monitoring is the domain owner's job

Further reading: RFC 9162; crt.sh.
Bottom line: CT makes misissuance discoverable, not impossible. You still have to watch the logs for your domains.

How does a browser actually verify a certificate was logged in Certificate Transparency?

Certificate Transparency (CT, RFC 6962) requires publicly-trusted certificates to be recorded in append-only logs, so mis-issuance is detectable. But the browser does not query a log at handshake time — that would leak browsing history and add latency. Instead it checks for an SCT (Signed Certificate Timestamp): a log's signed promise to publish.

An SCT can reach the client through three delivery channels, and the distinction is operationally important:

— Embedded in the certificate itself, as an X.509 extension. The CA submits a pre-certificate to logs, collects SCTs, and bakes them in before final issuance. This is the dominant path and requires nothing of the server operator.

— Via a TLS extension (signed_certificate_timestamp) in the handshake. The server supplies SCTs dynamically.

— Via an OCSP stapled response carrying the SCTs.

Chrome's policy historically demanded SCTs from a quorum of logs operated by independent parties, defending against a single compromised log fabricating timestamps. The Maximum Merge Delay (MMD) — typically 24 hours — is the window in which a log commits to actually publishing a promised certificate; a log that breaks this promise is itself distrusted.

Evidence vs. speculation: CT detects mis-issuance after the fact; it does not prevent it. The DigiNotar-class threat is mitigated by monitors watching logs, not by the handshake.

Further reading: RFC 6962; RFC 9162 (CT v2).

Bottom line: Browsers trust a signed promise (the SCT), not a live log query; embedded SCTs make compliance invisible to most server operators.

Antropic раскрыла ферму с нейронными дейтинг-моделями

Anthropic раскрыла кейс китайской студии, которая запустила 20 дейтинг-приложений с нейропрофилями для удержания пользователей. Вместо стандартного слива дейтинг-трафика на чужие смартлинки, вебмастерам стоит присмотреться к разработке собственных LLM-сервисов. Затраты на токены и подключение платежных решений окупаются за счет прямого контроля над монетизацией и забора всей маржи рекламодателя.

➡️ Читайте на сайте: https://aff.top/blog/antropic-raskryla-fermu-s-neironnymi-deiting-modeliami

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

Разработчик игры слил $220 в Google ads на установки ботами

Статья описывает кейс разработчика, потерявшего бюджет в Google Ads из-за фрода и специфики атрибуции. Платформа засчитала конверсии, которые не подтвердились в Google Play Console, так как алгоритм учитывает установки без прямой связи с кликом. Главный вывод: Google Ads может наливать ботов не меньше пуш-сетей. При работе за инсталы важно жестко контролировать качество трафика и сверять аналитику с бэкендом, в то время как Facebook на данный мо…

➡️ Читайте на сайте: https://aff.top/blog/razrabotchik-igry-slil-220-v-google-ads-na-ustanovki-botami

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

Google расширил Data Manager

Google интегрировал инструмент Data Manager в GA и DV360 для удобной передачи first-party данных, что дает рост ROAS до 26%. Для арбитража трафика прямого применения у офлайн-данных нет, однако инструмент можно использовать для манипуляции алгоритмами: отправка синтетических конверсий через API поможет скорректировать оптимизацию и направить автостратегии на поиск нужной аудитории.

➡️ Читайте на сайте: https://aff.top/blog/google-rasshiril-data-manager

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

Can you drop the HTTP-to-HTTPS redirect once HSTS is set?

The optimization "HSTS handles the upgrade, so I can remove my 301 redirect" contains a fatal first-visit gap. HSTS (HTTP Strict Transport Security, RFC 6797) is a Trust On First Use mechanism. The browser only learns your HSTS policy by receiving the Strict-Transport-Security header — and it can only receive that header over a successful HTTPS response. A browser that has never visited you, or whose cached policy expired, has no instruction yet.

So the very first request a new client makes to http://yoursite must still be answered. If you removed the redirect, that plaintext request either fails or is served over HTTP, exactly the window an on-path attacker uses for SSL-stripping. The redirect is what gets that first connection onto HTTPS so the HSTS header can ever be delivered.

The only way to close the first-visit gap entirely is the preload list (compiled into the browser), and even that requires you to keep serving HTTPS correctly. The redirect stays either way.

— HSTS is Trust On First Use over HTTPS
— First plaintext request still needs answering
— Removing the redirect reopens SSL-stripping

Further reading: RFC 6797, §8.3 and §14.6.
Bottom line: Keep the HTTP-to-HTTPS redirect. HSTS protects return visits; the redirect protects the first one.

Why can an HSTS header with the wrong directive be worse than no header at all?

HSTS (RFC 6797) is usually framed as pure upside: force HTTPS, prevent downgrades. But the header is a binding, browser-enforced commitment with a state that outlives the response, and two directives turn it into a foot-gun: includeSubDomains and a long max-age.

Consider the failure mode. You set Strict-Transport-Security: max-age=63072000; includeSubDomains on example.com. Every browser that has seen this header will now refuse plain HTTP — and refuse to bypass certificate errors — for two years, across every subdomain, including ones you do not control today and any you create tomorrow. If a subdomain later needs to serve HTTP (a legacy device, a third-party tool, an acquired property with a broken certificate), it is unreachable for returning visitors. There is no server-side undo for browsers that already cached the policy; you can only serve max-age=0 and hope each affected client revisits the apex over HTTPS to clear it.

The sharper trap is asymmetric reach. The policy is keyed to the host that sent it, but includeSubDomains projects it downward onto hosts that never sent any header and may not be ready. The commitment is made by the parent, paid by the children.

Evidence vs. speculation: the clearing mechanism (max-age=0 on a successful HTTPS response) is normative in RFC 6797 §6.1.1; the operational pain of subdomain lockout is a recurring, documented incident pattern.

Further reading: RFC 6797 §6.1, §8.1, §11.

Bottom line: HSTS state is sticky and client-side — add includeSubDomains only after auditing every present and future subdomain's TLS readiness, because the only rollback is max-age=0 plus a hope that each browser revisits to clear the cached commitment.