How does TLS 1.3 detect a downgrade attack using nothing but the server's random value?
Downgrade attacks force a connection to a weaker protocol the attacker can break — the lineage runs from FREAK to Logjam to POODLE. TLS 1.3 added a clever, low-cost defense that hides inside a field everyone overlooks: the ServerHello random.
The server's 32-byte random is supposed to be unpredictable. RFC 8446 §4.1.3 carves out the last 8 bytes as a sentinel. If a server that supports TLS 1.3 is negotiated down to TLS 1.2 (because an attacker tampered with the ClientHello to strip 1.3 support), the server sets those 8 bytes to a fixed value: the ASCII string "DOWNGRD\x01" for 1.2, or "DOWNGRD\x00" for 1.1 and below.
The trick is that the random is covered by the Finished MAC and, for 1.2, by the server's signature over the handshake transcript. A client that itself supports 1.3 but finds itself in a 1.2 handshake checks for the sentinel. If it sees "DOWNGRD", it knows a genuine 1.3-capable server is on the other end and the version was forced down by tampering — and it aborts. An attacker cannot forge the random without breaking the server's signature.
Evidence vs. speculation: this is a precise normative mechanism (RFC 8446 §4.1.3), not a heuristic. It only protects pairs where both endpoints support 1.3.
Further reading: RFC 8446 §4.1.3; Logjam paper (Adrian et al., 2015).
Bottom line: Eight reserved bytes of the server random act as a signed downgrade canary — a 1.3 client landing in a 1.2 handshake checks for "DOWNGRD" and aborts, turning a forced downgrade into a detectable, authenticated tamper.
Downgrade attacks force a connection to a weaker protocol the attacker can break — the lineage runs from FREAK to Logjam to POODLE. TLS 1.3 added a clever, low-cost defense that hides inside a field everyone overlooks: the ServerHello random.
The server's 32-byte random is supposed to be unpredictable. RFC 8446 §4.1.3 carves out the last 8 bytes as a sentinel. If a server that supports TLS 1.3 is negotiated down to TLS 1.2 (because an attacker tampered with the ClientHello to strip 1.3 support), the server sets those 8 bytes to a fixed value: the ASCII string "DOWNGRD\x01" for 1.2, or "DOWNGRD\x00" for 1.1 and below.
The trick is that the random is covered by the Finished MAC and, for 1.2, by the server's signature over the handshake transcript. A client that itself supports 1.3 but finds itself in a 1.2 handshake checks for the sentinel. If it sees "DOWNGRD", it knows a genuine 1.3-capable server is on the other end and the version was forced down by tampering — and it aborts. An attacker cannot forge the random without breaking the server's signature.
Evidence vs. speculation: this is a precise normative mechanism (RFC 8446 §4.1.3), not a heuristic. It only protects pairs where both endpoints support 1.3.
Further reading: RFC 8446 §4.1.3; Logjam paper (Adrian et al., 2015).
Bottom line: Eight reserved bytes of the server random act as a signed downgrade canary — a 1.3 client landing in a 1.2 handshake checks for "DOWNGRD" and aborts, turning a forced downgrade into a detectable, authenticated tamper.
Why did CRLs — the technology OCSP was meant to replace — quietly make a comeback?
The CRL (Certificate Revocation List, RFC 5280 §5) is the original revocation mechanism: a CA publishes a signed, downloadable list of revoked serial numbers. It was deemed obsolete because lists grew to megabytes and clients had to download the whole thing. OCSP promised a lightweight per-certificate query. Yet the modern browser revocation story is circling back to list-based designs.
The reason is that OCSP's per-query model failed on privacy and reliability (soft-fail, responder outages, and the responder learning every site you visit). Browsers responded by building proprietary, aggressively-compressed pushed lists: Chrome's CRLSet and Mozilla's CRLite. CRLite in particular is a research-grade comeback — it uses cascading Bloom filters to compress the entire WebPKI revocation state into a few hundred kilobytes, pushed to the browser, queryable offline, with zero per-handshake network traffic and zero information leak to the CA.
The structural insight: revocation is a set-membership problem, and a probabilistic filter that the client downloads periodically beats a real-time query that leaks data and can be blocked. CRLite tunes the filter so false positives (a valid certificate flagged revoked) are eliminated by design via the cascade, not merely made rare.
Evidence vs. speculation: CRLite is published research (Larisch et al., IEEE S&P 2017) shipping in Firefox; CRLSet behavior is documented by Chrome. The performance numbers are measured, not projected.
Further reading: Larisch et al., "CRLite" (2017); RFC 5280 §5; Mozilla CRLite blog.
Bottom line: Revocation came full circle — not to classic CRLs, but to compressed, pushed, offline-queryable filters that fix OCSP's privacy and availability failures while keeping the list model's freedom from per-handshake network dependence.
The CRL (Certificate Revocation List, RFC 5280 §5) is the original revocation mechanism: a CA publishes a signed, downloadable list of revoked serial numbers. It was deemed obsolete because lists grew to megabytes and clients had to download the whole thing. OCSP promised a lightweight per-certificate query. Yet the modern browser revocation story is circling back to list-based designs.
The reason is that OCSP's per-query model failed on privacy and reliability (soft-fail, responder outages, and the responder learning every site you visit). Browsers responded by building proprietary, aggressively-compressed pushed lists: Chrome's CRLSet and Mozilla's CRLite. CRLite in particular is a research-grade comeback — it uses cascading Bloom filters to compress the entire WebPKI revocation state into a few hundred kilobytes, pushed to the browser, queryable offline, with zero per-handshake network traffic and zero information leak to the CA.
The structural insight: revocation is a set-membership problem, and a probabilistic filter that the client downloads periodically beats a real-time query that leaks data and can be blocked. CRLite tunes the filter so false positives (a valid certificate flagged revoked) are eliminated by design via the cascade, not merely made rare.
Evidence vs. speculation: CRLite is published research (Larisch et al., IEEE S&P 2017) shipping in Firefox; CRLSet behavior is documented by Chrome. The performance numbers are measured, not projected.
Further reading: Larisch et al., "CRLite" (2017); RFC 5280 §5; Mozilla CRLite blog.
Bottom line: Revocation came full circle — not to classic CRLs, but to compressed, pushed, offline-queryable filters that fix OCSP's privacy and availability failures while keeping the list model's freedom from per-handshake network dependence.
If TLS encrypts everything, why can a network observer still see which website you visited?
TLS encrypts the application data, but the handshake leaks. The single largest plaintext leak is SNI (Server Name Indication, RFC 6066 §3): the client puts the target hostname, in cleartext, in the ClientHello so a server hosting many sites on one IP knows which certificate to present. A passive observer reads it directly.
This is the chicken-and-egg problem encrypted SNI was meant to solve, and why the first attempt (ESNI) failed. You cannot encrypt SNI under the server's certificate key, because you need SNI to know which certificate to use. ESNI patched the symptom; the maturated design, ECH (Encrypted Client Hello), patches the structure.
ECH splits the ClientHello into an "outer" handshake addressed to a shared, public client-facing server, and an "inner" ClientHello — containing the real SNI and other sensitive extensions — encrypted with an HPKE (Hybrid Public Key Encryption, RFC 9180) public key the client fetches in advance via a DNS HTTPS resource record. The observer sees only the outer name (e.g. a CDN's front), not the inner target.
The dependency is the catch: ECH's confidentiality leans on the client retrieving the ECH config from DNS, which is why ECH and encrypted DNS (DoH/DoT) are complementary — leaking the hostname via plaintext DNS would defeat encrypting it in TLS.
Evidence vs. speculation: ECH is an active IETF draft with shipping CDN and browser support; its anonymity-set guarantee depends on many domains sharing one client-facing server — a deployment property, not a protocol guarantee.
Further reading: draft-ietf-tls-esni (ECH); RFC 9180 (HPKE); RFC 6066 §3.
Bottom line: SNI is the handshake's main plaintext leak; ECH closes it by encrypting an inner ClientHello under a DNS-published key, but its privacy is only as strong as the size of the anonymity set behind the shared client-facing server.
TLS encrypts the application data, but the handshake leaks. The single largest plaintext leak is SNI (Server Name Indication, RFC 6066 §3): the client puts the target hostname, in cleartext, in the ClientHello so a server hosting many sites on one IP knows which certificate to present. A passive observer reads it directly.
This is the chicken-and-egg problem encrypted SNI was meant to solve, and why the first attempt (ESNI) failed. You cannot encrypt SNI under the server's certificate key, because you need SNI to know which certificate to use. ESNI patched the symptom; the maturated design, ECH (Encrypted Client Hello), patches the structure.
ECH splits the ClientHello into an "outer" handshake addressed to a shared, public client-facing server, and an "inner" ClientHello — containing the real SNI and other sensitive extensions — encrypted with an HPKE (Hybrid Public Key Encryption, RFC 9180) public key the client fetches in advance via a DNS HTTPS resource record. The observer sees only the outer name (e.g. a CDN's front), not the inner target.
The dependency is the catch: ECH's confidentiality leans on the client retrieving the ECH config from DNS, which is why ECH and encrypted DNS (DoH/DoT) are complementary — leaking the hostname via plaintext DNS would defeat encrypting it in TLS.
Evidence vs. speculation: ECH is an active IETF draft with shipping CDN and browser support; its anonymity-set guarantee depends on many domains sharing one client-facing server — a deployment property, not a protocol guarantee.
Further reading: draft-ietf-tls-esni (ECH); RFC 9180 (HPKE); RFC 6066 §3.
Bottom line: SNI is the handshake's main plaintext leak; ECH closes it by encrypting an inner ClientHello under a DNS-published key, but its privacy is only as strong as the size of the anonymity set behind the shared client-facing server.
Neighbor spotlight: @RPMReceipts. They go deep on site monetization — the kind of channel you actually keep notifications on for.
Forwarded from Потрачено! Клуб спящих бизнесменов!
This media is not supported in your browser
VIEW IN TELEGRAM
🚀 aff.top — вся индустрия арбитража в одном месте
🧠 Блог про арбитраж и ИИ — как нейросети меняют залив и антифрод
🚨 База спамеров — ежедневно собираем спамеров и ведём рейтинг
🛠 70+ инструментов — от клоаки до антифрод-чека
🎬 1000+ видео — весь YouTube про трафик в одной ленте
👤 2400+ персон — байеры и фаундеры с контактами напрямую
Без регистрации, без платных «премиумов».
👇 Подписывайся на канал
🧠 Блог про арбитраж и ИИ — как нейросети меняют залив и антифрод
🚨 База спамеров — ежедневно собираем спамеров и ведём рейтинг
🛠 70+ инструментов — от клоаки до антифрод-чека
🎬 1000+ видео — весь YouTube про трафик в одной ленте
👤 2400+ персон — байеры и фаундеры с контактами напрямую
Без регистрации, без платных «премиумов».
👇 Подписывайся на канал
This media is not supported in your browser
VIEW IN TELEGRAM
Алиса AI будет конкурировать с Google AI Studio
Яндекс разворачивает экосистему AI-агентов на базе Алисы с доступом сначала для компаний, затем для всех. Агенты уже работают в Яндекс Такси и Лавке, скоро появятся в браузере и студии разработки. Платформа интегрирует стандартные функции — заказ такси, покупки, анализ данных. Алиса AI показывает неплохие результаты: менее известна, чем конкуренты, поэтому предлагает щедрые лимиты на видеогенерацию и работу с контентом. Яндекс планирует внедрить…
➡️ Читайте на сайте: https://aff.top/blog/alisa-ai-budet-konkurirovat-s-google-ai-studio
🧠 Ещё больше инсайтов → в канале AFF.top
Яндекс разворачивает экосистему AI-агентов на базе Алисы с доступом сначала для компаний, затем для всех. Агенты уже работают в Яндекс Такси и Лавке, скоро появятся в браузере и студии разработки. Платформа интегрирует стандартные функции — заказ такси, покупки, анализ данных. Алиса AI показывает неплохие результаты: менее известна, чем конкуренты, поэтому предлагает щедрые лимиты на видеогенерацию и работу с контентом. Яндекс планирует внедрить…
➡️ Читайте на сайте: https://aff.top/blog/alisa-ai-budet-konkurirovat-s-google-ai-studio
🧠 Ещё больше инсайтов → в канале AFF.top
This media is not supported in your browser
VIEW IN TELEGRAM
В Zennoposter добавили ИИ-помощник
Zennolab добавил в Zennoposter встроенный ИИ-кубик с доступом к четырём моделям (Gemini, DeepSeek, Claude, ChatGPT) — 50 бесплатных запросов в сутки. Есть режимы Assistant (чтение) и Agent (автоматическое создание скриптов), плюс новый GET-запрос по API. Нейросети хорошо справляются с регистрацией, постингом, фармингом аккаунтов и простым кодированием, но требуют проверки при парсинге динамических сайтов и диагностике ошибок. В связке с Zennoobr…
➡️ Читайте на сайте: https://aff.top/blog/v-zennoposter-dobavili-ii-pomoschnik
🧠 Ещё больше инсайтов → в канале AFF.top
Zennolab добавил в Zennoposter встроенный ИИ-кубик с доступом к четырём моделям (Gemini, DeepSeek, Claude, ChatGPT) — 50 бесплатных запросов в сутки. Есть режимы Assistant (чтение) и Agent (автоматическое создание скриптов), плюс новый GET-запрос по API. Нейросети хорошо справляются с регистрацией, постингом, фармингом аккаунтов и простым кодированием, но требуют проверки при парсинге динамических сайтов и диагностике ошибок. В связке с Zennoobr…
➡️ Читайте на сайте: https://aff.top/blog/v-zennoposter-dobavili-ii-pomoschnik
🧠 Ещё больше инсайтов → в канале AFF.top
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.