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.