At what exact byte does a TLS 1.3 handshake start encrypting — and why does it matter?
A defining change in TLS 1.3 versus 1.2 is that most of the handshake itself is encrypted. In 1.2, the server's certificate traveled in cleartext, visible to any observer. In 1.3 it does not. The precise transition point is worth pinning down, because it determines exactly what a passive observer can still see.
The sequence (RFC 8446 §2, §7): ClientHello and ServerHello are unencrypted — they must be, since they carry the key_share values used to derive keys. The moment both Hellos are exchanged, each side runs HKDF (RFC 5869) to derive the handshake traffic secrets via the key schedule. From the ServerHello onward — EncryptedExtensions, Certificate, CertificateVerify, Finished — everything is AEAD-encrypted under those handshake keys. Then a second derivation produces the application traffic secrets for the actual data.
So the observable plaintext shrinks to: the two Hellos and their extensions. The certificate, the server's identity proof, and the negotiated extensions are now hidden. This is why SNI (in the ClientHello) and the chosen group (in the key_share) became the residual leaks that ECH and later work target — they are the last cleartext standing.
Evidence vs. speculation: the encrypted-handshake design and the two-stage key schedule are normative (RFC 8446 §7.1). What an observer infers from the remaining plaintext — fingerprinting via JA3-style ClientHello hashing — is empirical traffic analysis, not a protocol leak.
Further reading: RFC 8446 §2, §7.1; RFC 5869 (HKDF).
Bottom line: Encryption begins immediately after ServerHello, hiding the certificate and identity from observers; the only cleartext left is the two Hellos, which is precisely why SNI and ClientHello fingerprinting are the frontier of TLS privacy work.
A defining change in TLS 1.3 versus 1.2 is that most of the handshake itself is encrypted. In 1.2, the server's certificate traveled in cleartext, visible to any observer. In 1.3 it does not. The precise transition point is worth pinning down, because it determines exactly what a passive observer can still see.
The sequence (RFC 8446 §2, §7): ClientHello and ServerHello are unencrypted — they must be, since they carry the key_share values used to derive keys. The moment both Hellos are exchanged, each side runs HKDF (RFC 5869) to derive the handshake traffic secrets via the key schedule. From the ServerHello onward — EncryptedExtensions, Certificate, CertificateVerify, Finished — everything is AEAD-encrypted under those handshake keys. Then a second derivation produces the application traffic secrets for the actual data.
So the observable plaintext shrinks to: the two Hellos and their extensions. The certificate, the server's identity proof, and the negotiated extensions are now hidden. This is why SNI (in the ClientHello) and the chosen group (in the key_share) became the residual leaks that ECH and later work target — they are the last cleartext standing.
Evidence vs. speculation: the encrypted-handshake design and the two-stage key schedule are normative (RFC 8446 §7.1). What an observer infers from the remaining plaintext — fingerprinting via JA3-style ClientHello hashing — is empirical traffic analysis, not a protocol leak.
Further reading: RFC 8446 §2, §7.1; RFC 5869 (HKDF).
Bottom line: Encryption begins immediately after ServerHello, hiding the certificate and identity from observers; the only cleartext left is the two Hellos, which is precisely why SNI and ClientHello fingerprinting are the frontier of TLS privacy work.
This media is not supported in your browser
VIEW IN TELEGRAM
Новую Google reCapcha прошли статичной картинкой
Google выпустил обновленную reCAPTCHA, требующую движений рук для прохождения, но система оказалась уязвима к обходу. Достаточно транслировать статичное изображение с нужным жестом через виртуальную камеру с помощью простого Python-скрипта, чтобы нейросеть пропустила пользователя. Это создает серьёзный риск для сайтов: защита от ботов, позиционировавшаяся как прорыв, на деле не работает. Баг остается актуальным и позволяет спамерам легко автомат…
➡️ Читайте на сайте: https://aff.top/blog/novuiu-google-recapcha-proshli-statichnoi-kartinkoi
🧠 Ещё больше инсайтов → в канале AFF.top
Google выпустил обновленную reCAPTCHA, требующую движений рук для прохождения, но система оказалась уязвима к обходу. Достаточно транслировать статичное изображение с нужным жестом через виртуальную камеру с помощью простого Python-скрипта, чтобы нейросеть пропустила пользователя. Это создает серьёзный риск для сайтов: защита от ботов, позиционировавшаяся как прорыв, на деле не работает. Баг остается актуальным и позволяет спамерам легко автомат…
➡️ Читайте на сайте: https://aff.top/blog/novuiu-google-recapcha-proshli-statichnoi-kartinkoi
🧠 Ещё больше инсайтов → в канале AFF.top
Why are Let's Encrypt's rate limits structured around the registered domain, not the hostname?
Let's Encrypt's rate limits are often hit by automation gone wrong, and operators misread them as per-certificate caps. They are not. The limits are deliberately keyed to the registered domain — the eTLD+1 derived from the Public Suffix List — and that design choice reveals what the CA is actually defending against.
The headline limit, Certificates per Registered Domain (50 per week historically), counts certificates issued for example.com and every subdomain under it together. Why this granularity? Because the abuse the CA must prevent is a single controlled domain spinning up unlimited subdomains (a.example.com, b.example.com...) to mint unlimited free certificates for phishing or to exhaust CA resources. A per-hostname limit would be trivially evaded by generating new hostnames; the eTLD+1 is the unit of ownership, so it is the unit of accounting.
The Public Suffix List (PSL) is load-bearing here. It encodes that github.io is a public suffix, so user1.github.io and user2.github.io are independent registered domains, not shared — otherwise one popular hosting platform would consume the entire limit for all its users. The PSL is how the CA distinguishes "one owner with many subdomains" from "many owners under one platform."
Evidence vs. speculation: the registered-domain keying and PSL dependence are documented in Let's Encrypt's rate-limit policy; the duplicate-certificate and failed-validation limits exist specifically to absorb buggy automation retry loops.
Further reading: Let's Encrypt rate-limits documentation; publicsuffix.org; RFC 8555 §6.6 (errors).
Bottom line: Limits track the registered domain because that is the true unit of ownership and abuse — design your automation to batch SAN names into fewer certificates and to honor the failed-validation cap, since the CA is counting per-owner, not per-host.
Let's Encrypt's rate limits are often hit by automation gone wrong, and operators misread them as per-certificate caps. They are not. The limits are deliberately keyed to the registered domain — the eTLD+1 derived from the Public Suffix List — and that design choice reveals what the CA is actually defending against.
The headline limit, Certificates per Registered Domain (50 per week historically), counts certificates issued for example.com and every subdomain under it together. Why this granularity? Because the abuse the CA must prevent is a single controlled domain spinning up unlimited subdomains (a.example.com, b.example.com...) to mint unlimited free certificates for phishing or to exhaust CA resources. A per-hostname limit would be trivially evaded by generating new hostnames; the eTLD+1 is the unit of ownership, so it is the unit of accounting.
The Public Suffix List (PSL) is load-bearing here. It encodes that github.io is a public suffix, so user1.github.io and user2.github.io are independent registered domains, not shared — otherwise one popular hosting platform would consume the entire limit for all its users. The PSL is how the CA distinguishes "one owner with many subdomains" from "many owners under one platform."
Evidence vs. speculation: the registered-domain keying and PSL dependence are documented in Let's Encrypt's rate-limit policy; the duplicate-certificate and failed-validation limits exist specifically to absorb buggy automation retry loops.
Further reading: Let's Encrypt rate-limits documentation; publicsuffix.org; RFC 8555 §6.6 (errors).
Bottom line: Limits track the registered domain because that is the true unit of ownership and abuse — design your automation to batch SAN names into fewer certificates and to honor the failed-validation cap, since the CA is counting per-owner, not per-host.
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
DeepSeek представит последнюю версию v4
DeepSeek выпустит v4 в середине июля с новой моделью ценообразования API: токены подорожают в 2 раза в часы пиковой нагрузки (09:00–12:00 и 14:00–18:00 по пекинскому времени). Компания планирует уведомлять пользователей по почте за 24 часа до изменения тарифов. Проблема с ошибками «server busy» останется, но обойдётся дороже — это может существенно повлиять на экономику проектов, которые активно используют API DeepSeek для автоматизации и масшта…
➡️ Читайте на сайте: https://aff.top/blog/deepseek-predstavit-posledniuiu-versiiu-v4
🧠 Ещё больше инсайтов → в канале AFF.top
DeepSeek выпустит v4 в середине июля с новой моделью ценообразования API: токены подорожают в 2 раза в часы пиковой нагрузки (09:00–12:00 и 14:00–18:00 по пекинскому времени). Компания планирует уведомлять пользователей по почте за 24 часа до изменения тарифов. Проблема с ошибками «server busy» останется, но обойдётся дороже — это может существенно повлиять на экономику проектов, которые активно используют API DeepSeek для автоматизации и масшта…
➡️ Читайте на сайте: https://aff.top/blog/deepseek-predstavit-posledniuiu-versiiu-v4
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Anthropic выпустили Sonnet 5
30 июня вышла Claude Sonnet 5 — новая версия позиционируется как самая агентная в линейке и приближается к флагманской Opus 4.8. Модель лучше справляется со сложными многоуровневыми задачами, устойчива к вредоносным запросам и не генерирует эксплойты. Sonnet 5 доступна на Free-тарифе, но тестирование показало скромные улучшения: хотя работает лучше Sonnet 4.6, её обгоняют конкуренты, включая китайские модели, которые дешевле через API при лучшей…
➡️ Читайте на сайте: https://aff.top/blog/anthropic-vypustili-sonnet-5
🧠 Ещё больше инсайтов → в канале AFF.top
30 июня вышла Claude Sonnet 5 — новая версия позиционируется как самая агентная в линейке и приближается к флагманской Opus 4.8. Модель лучше справляется со сложными многоуровневыми задачами, устойчива к вредоносным запросам и не генерирует эксплойты. Sonnet 5 доступна на Free-тарифе, но тестирование показало скромные улучшения: хотя работает лучше Sonnet 4.6, её обгоняют конкуренты, включая китайские модели, которые дешевле через API при лучшей…
➡️ Читайте на сайте: https://aff.top/blog/anthropic-vypustili-sonnet-5
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Clickstar прекращает работу
Clickstar закрывается. Легендарная пуш-сеть прекращает закуп трафика с 1 августа, полная остановка — 20 августа.
Сетка работала почти 8 лет и была одним из лучших источников качественного трафика на Россию и СНГ. Сейчас пуш-трафик стал слишком ботовым из-за гугловских банов на скрипты сбора.
Что это означает для арбитражников — разбираемся в ста…
➡️ Читайте на сайте: https://aff.top/blog/clickstar-prekraschaet-rabotu
🧠 Ещё больше инсайтов → в канале AFF.top
Clickstar закрывается. Легендарная пуш-сеть прекращает закуп трафика с 1 августа, полная остановка — 20 августа.
Сетка работала почти 8 лет и была одним из лучших источников качественного трафика на Россию и СНГ. Сейчас пуш-трафик стал слишком ботовым из-за гугловских банов на скрипты сбора.
Что это означает для арбитражников — разбираемся в ста…
➡️ Читайте на сайте: https://aff.top/blog/clickstar-prekraschaet-rabotu
🧠 Ещё больше инсайтов → в канале AFF.top
Why does a single TLS handshake message sometimes arrive split across several network packets — and is that an attack?
A frequent source of confusion in TLS debugging is the gap between two distinct layers: the handshake protocol (the logical messages — ClientHello, Certificate, Finished) and the record protocol (the actual on-wire framing). They are not the same, and conflating them produces phantom bugs.
TLS messages travel inside records (RFC 8446 §5.1), each with a maximum payload of 2^14 = 16384 bytes. A large handshake message — a Certificate message carrying a long chain, or a post-quantum ClientHello with a kilobyte-scale key share — exceeds one record and is fragmented across multiple records. Conversely, several small handshake messages can be coalesced into one record. So there is no one-to-one mapping between handshake messages and records, and certainly none between records and TCP segments, which the OS may split or merge freely.
This matters for security analysis. The historic SSLv3/TLS 1.0 fragmentation behavior enabled the 1/n-1 record splitting mitigation against BEAST. It also means an implementation must reassemble handshake messages from the record stream before parsing — a parser that assumes "one record = one message" is exploitable. TLS 1.3 explicitly forbids interleaving handshake messages of different types across record boundaries to constrain this.
Evidence vs. speculation: record/handshake-layer separation and the 16 KB limit are normative (RFC 8446 §5.1, §5.2). Whether a given fragmentation is benign or hostile depends on parser robustness — fragmentation itself is expected protocol behavior, not inherently an attack.
Further reading: RFC 8446 §5.1, §5.2; RFC 5246 §6.2 (legacy record layer).
Bottom line: Handshake messages and records are independent layers — one logical message can span many records and many TCP segments, so fragmentation is normal; the only place it becomes a vulnerability is a parser that fails to reassemble before trusting the bytes.
A frequent source of confusion in TLS debugging is the gap between two distinct layers: the handshake protocol (the logical messages — ClientHello, Certificate, Finished) and the record protocol (the actual on-wire framing). They are not the same, and conflating them produces phantom bugs.
TLS messages travel inside records (RFC 8446 §5.1), each with a maximum payload of 2^14 = 16384 bytes. A large handshake message — a Certificate message carrying a long chain, or a post-quantum ClientHello with a kilobyte-scale key share — exceeds one record and is fragmented across multiple records. Conversely, several small handshake messages can be coalesced into one record. So there is no one-to-one mapping between handshake messages and records, and certainly none between records and TCP segments, which the OS may split or merge freely.
This matters for security analysis. The historic SSLv3/TLS 1.0 fragmentation behavior enabled the 1/n-1 record splitting mitigation against BEAST. It also means an implementation must reassemble handshake messages from the record stream before parsing — a parser that assumes "one record = one message" is exploitable. TLS 1.3 explicitly forbids interleaving handshake messages of different types across record boundaries to constrain this.
Evidence vs. speculation: record/handshake-layer separation and the 16 KB limit are normative (RFC 8446 §5.1, §5.2). Whether a given fragmentation is benign or hostile depends on parser robustness — fragmentation itself is expected protocol behavior, not inherently an attack.
Further reading: RFC 8446 §5.1, §5.2; RFC 5246 §6.2 (legacy record layer).
Bottom line: Handshake messages and records are independent layers — one logical message can span many records and many TCP segments, so fragmentation is normal; the only place it becomes a vulnerability is a parser that fails to reassemble before trusting the bytes.
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Facebook запретил рекламу онлайн-казино Mr Vegas
Британский ASA запретил рекламу казино Mr Vegas из-за «слишком милых» мультяшных животных в креативах — регулятор счёл, что такой стиль привлекает детей, в том числе через Facebook. Рекламодатель запустил кампанию в феврале, бан вышел в июле. Логика регулятора вызывает вопросы: дети неплатёжеспособны, а таргетировать их на гемблинг бессмысленно.
➡️ Читайте на сайте: https://aff.top/blog/facebook-zapretil-reklamu-onlain-kazino-mr-vegas
🧠 Ещё больше инсайтов → в канале AFF.top
Британский ASA запретил рекламу казино Mr Vegas из-за «слишком милых» мультяшных животных в креативах — регулятор счёл, что такой стиль привлекает детей, в том числе через Facebook. Рекламодатель запустил кампанию в феврале, бан вышел в июле. Логика регулятора вызывает вопросы: дети неплатёжеспособны, а таргетировать их на гемблинг бессмысленно.
➡️ Читайте на сайте: https://aff.top/blog/facebook-zapretil-reklamu-onlain-kazino-mr-vegas
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
В Whatsapp скамят пользователей с помощью поддельных никнеймов
WhatsApp запустил никнеймы — и почти сразу начался скам. Мошенники регистрируют имена, похожие на бренды, звёзд и политиков, с минимальными опечатками.
Индия, где 500 млн пользователей WhatsApp, потребовала от Meta объяснений за 3 дня. Meta говорит, что точные совпадения заблокированы — но одна буква в другом месте защиту не триггерит.
Похоже, п…
➡️ Читайте на сайте: https://aff.top/blog/v-whatsapp-skamiat-polzovatelei-s-pomoschiu-poddelnykh-nikneimov
🧠 Ещё больше инсайтов → в канале AFF.top
WhatsApp запустил никнеймы — и почти сразу начался скам. Мошенники регистрируют имена, похожие на бренды, звёзд и политиков, с минимальными опечатками.
Индия, где 500 млн пользователей WhatsApp, потребовала от Meta объяснений за 3 дня. Meta говорит, что точные совпадения заблокированы — но одна буква в другом месте защиту не триггерит.
Похоже, п…
➡️ Читайте на сайте: https://aff.top/blog/v-whatsapp-skamiat-polzovatelei-s-pomoschiu-poddelnykh-nikneimov
🧠 Ещё больше инсайтов → в канале AFF.top
What does an attacker learn by watching Certificate Transparency logs in real time?
Certificate Transparency (CT, RFC 6962) is a defensive system: public, append-only logs let anyone detect mis-issued certificates. But the same public-by-design property is a reconnaissance gift, and treating CT purely as a defense misreads its threat surface.
Every time a CA issues a certificate, it is logged within the Maximum Merge Delay (typically 24 hours), with the full set of subject names. An attacker subscribing to CT log feeds (via the get-entries API or aggregators like crt.sh) sees, in near real time, every hostname an organization provisions. Request a certificate for staging-newproduct.example.com or vpn-internal.example.com, and you have just published your internal naming and, often, the existence of unannounced infrastructure to anyone watching.
This is exploited in practice. Automated tooling watches CT for newly-issued certificates on freshly-registered domains and probes them for misconfiguration within minutes of issuance — the certificate's appearance in the log is the starting gun. Subdomain enumeration via crt.sh is a standard first step in penetration testing precisely because CT makes it free and complete.
The mitigation is not opting out — public-trust certificates must be logged. It is to assume names are public the moment a certificate exists: use wildcard certificates to avoid logging individual internal hostnames, and never rely on an unguessable subdomain as a secret.
Evidence vs. speculation: CT logging is mandatory and public (RFC 6962); the recon use is well-documented in offensive security practice. The defensive value and the recon value are two faces of the same transparency guarantee.
Further reading: RFC 6962; crt.sh; RFC 9162 (CT v2).
Bottom line: A certificate is a public announcement — anyone monitoring CT sees your hostnames within a day, so wildcard-issue internal names and never treat a subdomain as a secret, because transparency cuts both ways.
Certificate Transparency (CT, RFC 6962) is a defensive system: public, append-only logs let anyone detect mis-issued certificates. But the same public-by-design property is a reconnaissance gift, and treating CT purely as a defense misreads its threat surface.
Every time a CA issues a certificate, it is logged within the Maximum Merge Delay (typically 24 hours), with the full set of subject names. An attacker subscribing to CT log feeds (via the get-entries API or aggregators like crt.sh) sees, in near real time, every hostname an organization provisions. Request a certificate for staging-newproduct.example.com or vpn-internal.example.com, and you have just published your internal naming and, often, the existence of unannounced infrastructure to anyone watching.
This is exploited in practice. Automated tooling watches CT for newly-issued certificates on freshly-registered domains and probes them for misconfiguration within minutes of issuance — the certificate's appearance in the log is the starting gun. Subdomain enumeration via crt.sh is a standard first step in penetration testing precisely because CT makes it free and complete.
The mitigation is not opting out — public-trust certificates must be logged. It is to assume names are public the moment a certificate exists: use wildcard certificates to avoid logging individual internal hostnames, and never rely on an unguessable subdomain as a secret.
Evidence vs. speculation: CT logging is mandatory and public (RFC 6962); the recon use is well-documented in offensive security practice. The defensive value and the recon value are two faces of the same transparency guarantee.
Further reading: RFC 6962; crt.sh; RFC 9162 (CT v2).
Bottom line: A certificate is a public announcement — anyone monitoring CT sees your hostnames within a day, so wildcard-issue internal names and never treat a subdomain as a secret, because transparency cuts both ways.
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Вышел ZCode - аналог Claude code
Вышел ZCode — десктопный аналог Claude Code от разработчиков GLM-5.2. Работает с API от Anthropic, поддерживает SSH-деплой на сервер, в том числе Linux.
Вместо пошаговых скриптов — система целеполагания Goal: закидываешь сложный промт, агент сам разбивает задачу и выполняет. Плюс управление через Telegram-бота.
Но главная фича — мультиагентность…
➡️ Читайте на сайте: https://aff.top/blog/vyshel-zcode-analog-claude-code
🧠 Ещё больше инсайтов → в канале AFF.top
Вышел ZCode — десктопный аналог Claude Code от разработчиков GLM-5.2. Работает с API от Anthropic, поддерживает SSH-деплой на сервер, в том числе Linux.
Вместо пошаговых скриптов — система целеполагания Goal: закидываешь сложный промт, агент сам разбивает задачу и выполняет. Плюс управление через Telegram-бота.
Но главная фича — мультиагентность…
➡️ Читайте на сайте: https://aff.top/blog/vyshel-zcode-analog-claude-code
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Cloudeflare грозит Google блокировкой трафика
Cloudflare объявил: с 15 сентября 2026 года ИИ-краулеры будут заблокированы по умолчанию на всех сайтах с рекламой — включая Googlebot, Applebot и Bingbot.
Главная претензия — к Google: один и тот же бот индексирует страницы и собирает данные для обучения нейросетей, что даёт поисковику нечестное преимущество.
Но есть нюанс, который меняет всю к…
➡️ Читайте на сайте: https://aff.top/blog/cloudeflare-grozit-google-blokirovkoi-trafika
🧠 Ещё больше инсайтов → в канале AFF.top
Cloudflare объявил: с 15 сентября 2026 года ИИ-краулеры будут заблокированы по умолчанию на всех сайтах с рекламой — включая Googlebot, Applebot и Bingbot.
Главная претензия — к Google: один и тот же бот индексирует страницы и собирает данные для обучения нейросетей, что даёт поисковику нечестное преимущество.
Но есть нюанс, который меняет всю к…
➡️ Читайте на сайте: https://aff.top/blog/cloudeflare-grozit-google-blokirovkoi-trafika
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Гайд: как заработать первые деньги на Pornhub
Pornhub — самый посещаемый адалт-сайт в мире, и на нём действительно можно зарабатывать. Но схема устроена иначе, чем кажется.
Автор залил ролики, набрал 16 000 просмотров — и получил 47 центов встроенной монетизации. Реальные деньги были в другом.
Есть нюансы с верификацией, голосом в роликах и законодательством РФ, которые ломают большинство с…
➡️ Читайте на сайте: https://aff.top/blog/gaid-kak-zarabotat-pervye-dengi-na-pornhub
🧠 Ещё больше инсайтов → в канале AFF.top
Pornhub — самый посещаемый адалт-сайт в мире, и на нём действительно можно зарабатывать. Но схема устроена иначе, чем кажется.
Автор залил ролики, набрал 16 000 просмотров — и получил 47 центов встроенной монетизации. Реальные деньги были в другом.
Есть нюансы с верификацией, голосом в роликах и законодательством РФ, которые ломают большинство с…
➡️ Читайте на сайте: https://aff.top/blog/gaid-kak-zarabotat-pervye-dengi-na-pornhub
🧠 Ещё больше инсайтов → в канале AFF.top
Can TLS session resumption silently break the forward secrecy your ephemeral key exchange just bought you?
TLS 1.3 mandates ephemeral (EC)DHE key exchange so that compromising a server's long-term key cannot retroactively decrypt past sessions — that is forward secrecy. But session resumption via tickets reintroduces a long-lived secret, and a careless deployment quietly undoes the guarantee.
The mechanism: when a server issues a session ticket (NewSessionTicket, RFC 8446 §4.6.1), it typically encrypts the session's resumption secret under a Session Ticket Encryption Key (STEK) and hands the ciphertext to the client to hold. The STEK is a long-term server-side secret. If it is compromised, an attacker who recorded past traffic can decrypt every ticket ever issued under it, recover the resumption PSKs, and unravel the resumed sessions — defeating forward secrecy for exactly those connections.
The magnitude depends entirely on STEK rotation. A server that never rotates its STEK has a single key whose compromise exposes months of resumed sessions; a server rotating hourly bounds the exposure to an hour. This is the under-appreciated cost of the resumption-rate optimization: each cached STEK is a window of non-forward-secret history.
Worse, multi-server deployments often share a static STEK across a fleet so any node can resume any session — turning one extracted key into a fleet-wide, long-horizon decryption capability. The CloudFlare "Keyless" and STEK-rotation discussions documented this tension explicitly.
Evidence vs. speculation: the STEK-compromise risk is inherent to ticket-based resumption (RFC 8446 §8.1, §C.4 advise frequent rotation); the fleet-wide-static-STEK anti-pattern is a documented operational mistake, not a hypothetical.
Further reading: RFC 8446 §4.6.1, §8.1, Appendix C.4; RFC 5077 (legacy tickets).
Bottom line: Resumption tickets reintroduce a long-term secret behind your ephemeral handshake — forward secrecy survives only if STEKs are rotated aggressively and never shared statically fleet-wide, because an unrotated STEK is a master key over all the sessions it ever wrapped.
TLS 1.3 mandates ephemeral (EC)DHE key exchange so that compromising a server's long-term key cannot retroactively decrypt past sessions — that is forward secrecy. But session resumption via tickets reintroduces a long-lived secret, and a careless deployment quietly undoes the guarantee.
The mechanism: when a server issues a session ticket (NewSessionTicket, RFC 8446 §4.6.1), it typically encrypts the session's resumption secret under a Session Ticket Encryption Key (STEK) and hands the ciphertext to the client to hold. The STEK is a long-term server-side secret. If it is compromised, an attacker who recorded past traffic can decrypt every ticket ever issued under it, recover the resumption PSKs, and unravel the resumed sessions — defeating forward secrecy for exactly those connections.
The magnitude depends entirely on STEK rotation. A server that never rotates its STEK has a single key whose compromise exposes months of resumed sessions; a server rotating hourly bounds the exposure to an hour. This is the under-appreciated cost of the resumption-rate optimization: each cached STEK is a window of non-forward-secret history.
Worse, multi-server deployments often share a static STEK across a fleet so any node can resume any session — turning one extracted key into a fleet-wide, long-horizon decryption capability. The CloudFlare "Keyless" and STEK-rotation discussions documented this tension explicitly.
Evidence vs. speculation: the STEK-compromise risk is inherent to ticket-based resumption (RFC 8446 §8.1, §C.4 advise frequent rotation); the fleet-wide-static-STEK anti-pattern is a documented operational mistake, not a hypothetical.
Further reading: RFC 8446 §4.6.1, §8.1, Appendix C.4; RFC 5077 (legacy tickets).
Bottom line: Resumption tickets reintroduce a long-term secret behind your ephemeral handshake — forward secrecy survives only if STEKs are rotated aggressively and never shared statically fleet-wide, because an unrotated STEK is a master key over all the sessions it ever wrapped.
What stops any public CA from issuing a valid certificate for your domain right now?
A uncomfortable property of the WebPKI is that any of the ~100 publicly-trusted CAs can, by default, issue a certificate for any domain — your browser trusts them all equally. Domain validation proves control to one CA, but nothing stops a different CA from being tricked or compromised into issuing for the same name. The mechanism that constrains this is CAA (Certification Authority Authorization, RFC 8659).
A CAA record is a DNS entry naming which CAs are permitted to issue for your domain. Publish CAA 0 issue "letsencrypt.org" and a compliant CA other than Let's Encrypt is obligated to refuse issuance — it must check CAA at validation time and abort if it is not listed. The CA/Browser Forum Baseline Requirements made CAA checking mandatory for all public CAs in 2017, which is what gives the record teeth: it is enforced by audited policy, not by the protocol.
The nuance often missed: CAA is checked by the issuing CA, not by the client. A browser never reads CAA and a present-but-violated CAA record does not make an already-issued certificate invalid to clients. CAA is a preventive control at issuance time, defending against a misbehaving-or-tricked CA, not a runtime check. The iodef property additionally lets you receive an email report when a CA encounters a violating request — a free mis-issuance tripwire.
Evidence vs. speculation: mandatory CAA checking is documented in CA/B Forum Baseline Requirements §3.2.2.8; its limitation to issuance-time is inherent to the design, not a gap to be fixed client-side.
Further reading: RFC 8659 (CAA); RFC 8657 (CAA for ACME); CA/B Forum Baseline Requirements §3.2.2.8.
Bottom line: By default every public CA can issue for your domain — a CAA record is the only standardized way to restrict that, enforced by CAs at issuance under audited policy; add iodef to turn it into a mis-issuance alarm, but remember it gates issuance, not the client.
A uncomfortable property of the WebPKI is that any of the ~100 publicly-trusted CAs can, by default, issue a certificate for any domain — your browser trusts them all equally. Domain validation proves control to one CA, but nothing stops a different CA from being tricked or compromised into issuing for the same name. The mechanism that constrains this is CAA (Certification Authority Authorization, RFC 8659).
A CAA record is a DNS entry naming which CAs are permitted to issue for your domain. Publish CAA 0 issue "letsencrypt.org" and a compliant CA other than Let's Encrypt is obligated to refuse issuance — it must check CAA at validation time and abort if it is not listed. The CA/Browser Forum Baseline Requirements made CAA checking mandatory for all public CAs in 2017, which is what gives the record teeth: it is enforced by audited policy, not by the protocol.
The nuance often missed: CAA is checked by the issuing CA, not by the client. A browser never reads CAA and a present-but-violated CAA record does not make an already-issued certificate invalid to clients. CAA is a preventive control at issuance time, defending against a misbehaving-or-tricked CA, not a runtime check. The iodef property additionally lets you receive an email report when a CA encounters a violating request — a free mis-issuance tripwire.
Evidence vs. speculation: mandatory CAA checking is documented in CA/B Forum Baseline Requirements §3.2.2.8; its limitation to issuance-time is inherent to the design, not a gap to be fixed client-side.
Further reading: RFC 8659 (CAA); RFC 8657 (CAA for ACME); CA/B Forum Baseline Requirements §3.2.2.8.
Bottom line: By default every public CA can issue for your domain — a CAA record is the only standardized way to restrict that, enforced by CAs at issuance under audited policy; add iodef to turn it into a mis-issuance alarm, but remember it gates issuance, not the client.
What actually distinguishes a session ticket from a session ID in TLS 1.3?
A precise question, because TLS 1.3 (RFC 8446) collapsed the older RFC 5077 ticket mechanism and RFC 5246 session-ID caching into a single construct: the pre-shared key (PSK).
In TLS 1.2, two resumption paths coexisted. Session IDs required the server to keep per-session state in a cache. Session tickets (RFC 5077) externalized that state, encrypting it under a Session Ticket Encryption Key (STEK) the client stored opaquely.
TLS 1.3 keeps only the ticket model, but renames it. After the handshake, the server sends one or more NewSessionTicket messages. Each carries a PSK identity and a ticket_nonce; the actual resumption secret is derived via HKDF (HMAC-based Key Derivation, RFC 5869) from the resumption master secret plus that nonce. So two tickets from one connection yield distinct PSKs.
The practical consequence: resumption no longer reuses a literal key. It derives a fresh one per ticket. This matters for forward secrecy — though note that a PSK-only resumption without the optional psk_dhe_ke (Diffie-Hellman) mode sacrifices forward secrecy for the resumed session.
Further reading: RFC 8446 §4.6.1, RFC 5077, RFC 5869.
Bottom line: TLS 1.3 has one resumption primitive (the PSK), derived per-ticket via HKDF; the session-ID cache is gone.
A precise question, because TLS 1.3 (RFC 8446) collapsed the older RFC 5077 ticket mechanism and RFC 5246 session-ID caching into a single construct: the pre-shared key (PSK).
In TLS 1.2, two resumption paths coexisted. Session IDs required the server to keep per-session state in a cache. Session tickets (RFC 5077) externalized that state, encrypting it under a Session Ticket Encryption Key (STEK) the client stored opaquely.
TLS 1.3 keeps only the ticket model, but renames it. After the handshake, the server sends one or more NewSessionTicket messages. Each carries a PSK identity and a ticket_nonce; the actual resumption secret is derived via HKDF (HMAC-based Key Derivation, RFC 5869) from the resumption master secret plus that nonce. So two tickets from one connection yield distinct PSKs.
The practical consequence: resumption no longer reuses a literal key. It derives a fresh one per ticket. This matters for forward secrecy — though note that a PSK-only resumption without the optional psk_dhe_ke (Diffie-Hellman) mode sacrifices forward secrecy for the resumed session.
Further reading: RFC 8446 §4.6.1, RFC 5077, RFC 5869.
Bottom line: TLS 1.3 has one resumption primitive (the PSK), derived per-ticket via HKDF; the session-ID cache is gone.
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Сбер запустит свой криптокошелёк
Сбер готов запустить криптокошелёк — инфраструктура уже есть. Ждут только закона о регулировании крипты, который планируют принять к 1 сентября 2026 года.
Хранить и, судя по всему, обменивать крипту можно будет прямо в приложении — без сторонних обменников.
Но есть один нюанс, из-за которого обменники никуда не денутся. 🔍
➡️ Читайте на сайте: https://aff.top/blog/sber-zapustit-svoi-kriptokoshelek
🧠 Ещё больше инсайтов → в канале AFF.top
Сбер готов запустить криптокошелёк — инфраструктура уже есть. Ждут только закона о регулировании крипты, который планируют принять к 1 сентября 2026 года.
Хранить и, судя по всему, обменивать крипту можно будет прямо в приложении — без сторонних обменников.
Но есть один нюанс, из-за которого обменники никуда не денутся. 🔍
➡️ Читайте на сайте: https://aff.top/blog/sber-zapustit-svoi-kriptokoshelek
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Индия потребовала от Telegram удалять пиратский контент
Индия потребовала от Telegram удалять пиратский контент — претензия в том, что платформа не ограничивает размер файлов, что позволяет свободно распространять фильмы.
Дуров ответил, что Telegram годами работает в Индии без какой-либо коммерческой выгоды для себя.
Почему давление началось именно сейчас — вопрос открытый. Возможный ответ — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/indiia-potrebovala-ot-telegram-udaliat-piratskii-kontent
🧠 Ещё больше инсайтов → в канале AFF.top
Индия потребовала от Telegram удалять пиратский контент — претензия в том, что платформа не ограничивает размер файлов, что позволяет свободно распространять фильмы.
Дуров ответил, что Telegram годами работает в Индии без какой-либо коммерческой выгоды для себя.
Почему давление началось именно сейчас — вопрос открытый. Возможный ответ — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/indiia-potrebovala-ot-telegram-udaliat-piratskii-kontent
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Google ads меняет стратегию по конверсиям
Google меняет логику автоматических стратегий ставок: с 17 августа 2026 года кампании будут строже придерживаться указанного целевого CPA, а не давать лиды по минимально возможной цене.
Если сейчас твоя кампания даёт лиды по $5, а цель стоит $10 — после обновления алгоритм «поднимет» фактическую стоимость лида к целевой, зато отдаст больше трафик…
➡️ Читайте на сайте: https://aff.top/blog/google-ads-meniaet-strategiiu-po-konversiiam
🧠 Ещё больше инсайтов → в канале AFF.top
Google меняет логику автоматических стратегий ставок: с 17 августа 2026 года кампании будут строже придерживаться указанного целевого CPA, а не давать лиды по минимально возможной цене.
Если сейчас твоя кампания даёт лиды по $5, а цель стоит $10 — после обновления алгоритм «поднимет» фактическую стоимость лида к целевой, зато отдаст больше трафик…
➡️ Читайте на сайте: https://aff.top/blog/google-ads-meniaet-strategiiu-po-konversiiam
🧠 Ещё больше инсайтов → в канале AFF.top
What actually makes TLS 1.3 0-RTT early data replayable, and why can't the protocol simply forbid it?
Zero round-trip time (0-RTT) lets a client send application data in its first flight, encrypted under a key derived from a resumption PSK before the server has responded. The latency win is real; the security cost is precise.
The replay problem is structural, not a bug. Early data is protected by a key derived solely from the PSK and the ClientHello — there is no server-contributed randomness mixed in yet (the server's Diffie-Hellman share only protects later data). An attacker who captures the ClientHello plus early-data records can resend the identical bytes to the same or a different server in a cluster. RFC 8446 §8 is explicit: the protocol does not guarantee non-replay for 0-RTT.
Mitigations are defenses, not proofs. RFC 8446 describes two: single-use tickets (server records each ticket and rejects reuse) and a ClientHello recording window keyed by the obfuscated_ticket_age and freshness bounds. Neither is airtight across a distributed front-end where state isn't shared.
The operational rule that follows: only idempotent requests belong in early data. GET, yes; a POST that charges a card, no. Cloudflare and others gate 0-RTT to safe methods for this reason.
Further reading: RFC 8446 §8, §2.3; Fastly's 0-RTT engineering notes.
Bottom line: 0-RTT replay is inherent to sending data before the server adds entropy — treat early data as at-least-once delivery.
Zero round-trip time (0-RTT) lets a client send application data in its first flight, encrypted under a key derived from a resumption PSK before the server has responded. The latency win is real; the security cost is precise.
The replay problem is structural, not a bug. Early data is protected by a key derived solely from the PSK and the ClientHello — there is no server-contributed randomness mixed in yet (the server's Diffie-Hellman share only protects later data). An attacker who captures the ClientHello plus early-data records can resend the identical bytes to the same or a different server in a cluster. RFC 8446 §8 is explicit: the protocol does not guarantee non-replay for 0-RTT.
Mitigations are defenses, not proofs. RFC 8446 describes two: single-use tickets (server records each ticket and rejects reuse) and a ClientHello recording window keyed by the obfuscated_ticket_age and freshness bounds. Neither is airtight across a distributed front-end where state isn't shared.
The operational rule that follows: only idempotent requests belong in early data. GET, yes; a POST that charges a card, no. Cloudflare and others gate 0-RTT to safe methods for this reason.
Further reading: RFC 8446 §8, §2.3; Fastly's 0-RTT engineering notes.
Bottom line: 0-RTT replay is inherent to sending data before the server adds entropy — treat early data as at-least-once delivery.
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
В Codex внедрят GPT-5.6 Ultra
OpenAI добавит в Codex эксклюзивную версию GPT-5.6 Sol Ultra — не ту, что выйдет в паблик, а отдельную, усиленную модель.
Два ключевых режима: расширенные рассуждения (модель думает дольше) и мульти-агентная работа с параллельными субагентами. Релиз ожидается 7–9 июля 2026.
Но есть один нюанс, который OpenAI пока не раскрывает 👀 Подробности — в …
➡️ Читайте на сайте: https://aff.top/blog/v-codex-vnedriat-gpt-5-6-ultra
🧠 Ещё больше инсайтов → в канале AFF.top
OpenAI добавит в Codex эксклюзивную версию GPT-5.6 Sol Ultra — не ту, что выйдет в паблик, а отдельную, усиленную модель.
Два ключевых режима: расширенные рассуждения (модель думает дольше) и мульти-агентная работа с параллельными субагентами. Релиз ожидается 7–9 июля 2026.
Но есть один нюанс, который OpenAI пока не раскрывает 👀 Подробности — в …
➡️ Читайте на сайте: https://aff.top/blog/v-codex-vnedriat-gpt-5-6-ultra
🧠 Ещё больше инсайтов → в канале AFF.top