Handshake Papers
43 subscribers
64 photos
12 videos
189 links
Long-form deep dives into TLS, certificates, and HTTPS internals. We read the RFCs and CA studies so you understand what actually happens in that handshake.
Download Telegram
Forwarded from AFF.TOP - про арбитраж трафика и CPA рынок!
This media is not supported in your browser
VIEW IN TELEGRAM
Топ 5 PWA-сервисов для залива дейтинга

Статья показывает, что PWA выгодны не только для гемблы: в дейтинге они дают пуш-базу, больше траста и помогают маскировать оффер под бренд. Главный выбор зависит от цены инсталлов и теста GEO: для старта лучше бесплатные или дешёвые решения, а Progressier выделяется как самый практичный вариант для залива дейтинга.

➡️ Читайте на сайте: https://aff.top/blog/top-5-pwa-servisov-dlia-zaliva-deitinga

🧠 Ещё больше инсайтов → в канале AFF.top
How do you build an internal PKI for service-to-service TLS without leaking trust outside your network?

Internal services need TLS, but public CAs publish names to CT logs and cannot issue for non-public hostnames. A private PKI (Public Key Infrastructure) keeps internal names off the public record. Build playbook.

— Create an offline root CA, kept air-gapped, whose only job is signing one or more online intermediate CAs. The root's private key never touches a network-connected host.
— Issue from intermediates, so you can revoke and rotate an intermediate without redistributing the root.
— Distribute only the root certificate to internal trust stores (OS, container base images, language runtimes); never distribute private keys.
— Keep certificate lifetimes short (days to weeks) and automate issuance via an internal ACME server, so compromise windows stay small and revocation matters less.
— Constrain the root with name constraints (RFC 5280 section 4.2.1.10) limiting it to your internal domain, so a leaked intermediate cannot mint certs for public names.

Evidence vs. speculation: name constraints are enforced by validators that support them; older clients ignore the extension, so do not rely on it alone.

Further reading: RFC 5280 sections 4.2.1.9-4.2.1.10; RFC 8555 for internal ACME.

Bottom line: offline root, short-lived leaves, and name constraints keep internal trust internal.
🔥 Новый участник НеТОПа на AffPapa!
https://affpapa.org/netop

🏆 НеТОП на AffPapa — https://affpapa.org/netop/go/27?src=broadcast
Платный рейтинг индустрии: плати больше — стоишь выше. Займи место в топе за USDT.
💰 Ставка: $100 · сейчас #1 в рейтинге
🔥 justbrand_create — новый участник рейтинга НеТОП на AffPapa!

🏆 Своё место в топе честно купил justbrand_create: https://affpapa.org/netop/go/28?src=broadcast

💰 Ставка: $111 · сейчас #1 в рейтинге

Весь рейтинг → https://affpapa.org/netop
How do you tune TLS 1.3 session resumption across a server fleet without leaking forward secrecy?

Resumption via PSK (pre-shared key) tickets, RFC 8446 section 4.6.1, lets a returning client skip the full handshake. Done wrong across many servers, it either fails (each box has its own keys) or undermines forward secrecy (shared static keys). Tuning playbook.

— Decide the model: stateless tickets (server encrypts session state into a ticket) scale across a fleet but require a shared ticket-encryption key, which becomes a single point of secrecy.
— Rotate that ticket key frequently (hours, not weeks) and keep only a short overlap window, so a stolen key exposes a bounded slice of past sessions.
— Never distribute a static, never-rotated ticket key across servers; that retroactively breaks forward secrecy for every resumed session.
— For resumption to work behind a load balancer, all nodes must share the current and previous ticket keys; synchronize via a secret store, not a config file in git.
— Combine resumption with (EC)DHE in the PSK handshake so each resumed session still derives fresh key material.

Evidence vs. speculation: rotation cadence directly bounds exposure; this is arithmetic, not opinion.

Further reading: RFC 8446 sections 2.2 and 4.6.1; RFC 5077 (the stateless-ticket lineage).

Bottom line: short-lived, fleet-synced ticket keys preserve both resumption speed and forward secrecy.
What is the methodical order for diagnosing a TLS handshake that fails for some clients only?

A handshake involves ClientHello, ServerHello, certificate, key exchange, and Finished. 'Works here, fails there' means a negotiation mismatch hidden in those messages. Diagnostic playbook, top down.

— Capture the failing ClientHello: a packet capture or openssl s_client -connect host:443 -servername host from the affected client class reveals offered versions, cipher suites, and SNI.
— Check SNI first: a client not sending Server Name Indication on a multi-tenant IP gets the wrong default cert. Old clients and some libraries omit it.
— Compare offered versions: a client capped at TLS 1.2 against a server set to 1.3-only fails at hello, not at the certificate.
— Inspect signature_algorithms and supported_groups: an ECDSA-only server config with an RSA-only client produces a no-shared-cipher alert.
— Read the alert code returned (handshake_failure 40, protocol_version 70, unrecognized_name 112); it names the layer that failed.

Evidence vs. speculation: the TLS alert number is a precise diagnosis; guessing from the error message text is not.

Further reading: RFC 8446 sections 4.1.2 and 6 (alert protocol); RFC 6066 for SNI.

Bottom line: capture the ClientHello and read the alert code; the mismatch is always named in the handshake itself.
Forwarded from AFF.TOP - про арбитраж трафика и CPA рынок!
This media is not supported in your browser
VIEW IN TELEGRAM
Google отменил ручную пессимизацию в Еврозоне

Google перестал пессимизировать крупные новостники за паразитные страницы с казино и другими партнёрскими офферами в ЕЭЗ. Для арбитража вывод простой: в Европе схема с «пирогами» больше не даёт преимущества от траста основного домена, а Google впервые применяет разные правила по GEO под давлением регулятора.

➡️ Читайте на сайте: https://aff.top/blog/google-otmenil-ruchnuiu-pessimizaciiu-v-evrozone

🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP - про арбитраж трафика и CPA рынок!
This media is not supported in your browser
VIEW IN TELEGRAM
Вышел OpenClaw 2.0

OpenClaw вышел на новый уровень: совместная работа, нормальный веб-интерфейс и более простая настройка. Разбираем, зачем это обновление важно и как оно меняет работу с ИИ-агентом.

➡️ Читайте на сайте: https://aff.top/blog/vyshel-openclaw-2-0

🧠 Ещё больше инсайтов → в канале AFF.top
How do you configure CRL-based revocation checking as a deliberate fallback when OCSP is unavailable?

When OCSP responders are down or a client cannot reach them, a CRL (Certificate Revocation List, RFC 5280 section 5) is the older, bulk alternative: a signed, periodically published list of revoked serial numbers. For controlled environments it is a defensible fallback. Configuration playbook.

— Confirm the certificates carry a CRL Distribution Point (CDP) extension pointing to a reachable, signed CRL; without it there is nothing to fetch.
— Decide refresh cadence against the CRL's nextUpdate field. A client caching a stale CRL past nextUpdate is checking against outdated data, the core CRL weakness.
— Size matters: large CAs produce multi-megabyte CRLs. For internal PKI, partition with CRL Distribution Points or use delta CRLs to keep fetches small.
— Set explicit fail behavior: hard-fail in high-security internal contexts where you control connectivity; soft-fail on the public internet to avoid outages from unreachable lists.
— Validate the CRL signature chains to the issuing CA and that the issuer matches the cert's CDP, preventing a substituted list.

Evidence vs. speculation: CRLs give point-in-time-of-publication truth, not real-time status; the freshness gap is structural.

Further reading: RFC 5280 section 5; RFC 5280 section 4.2.1.13 (CDP).

Bottom line: CRLs are a bulk, cacheable fallback whose value is bounded entirely by your refresh discipline.
Forwarded from AFF.TOP - про арбитраж трафика и CPA рынок!
This media is not supported in your browser
VIEW IN TELEGRAM
Павел Дуров анонсировал Gram Wallet

Дуров анонсировал Gram Wallet — нативный некастодиальный криптокошелёк внутри Telegram. Он обещает мгновенные переводы с нулевой комиссией между пользователями и более простые обновления за счёт архитектуры с валидаторами. Запуск уже идёт, а полный релиз ждут в ближайшие недели.

➡️ Читайте на сайте: https://aff.top/blog/pavel-durov-anonsiroval-gram-wallet

🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP - про арбитраж трафика и CPA рынок!
This media is not supported in your browser
VIEW IN TELEGRAM
Новые ограничение в Instagram для ИИ-профилей

Instagram ужесточает условия для УБТ: аккаунты помечают как созданные ИИ, а без такой маркировки можно словить теневой бан. Если нейросеть лишь улучшает контент, санкций нет. Для арбитражников это значит, что привычные схемы в FB и Инсте будут работать хуже, а обход антифрода станет сложнее.

➡️ Читайте на сайте: https://aff.top/blog/novye-ogranichenie-v-instagram-dlia-ii-profilei

🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP - про арбитраж трафика и CPA рынок!
This media is not supported in your browser
VIEW IN TELEGRAM
Оборот ChatGPT Ads достиг $1 миллиарда

OpenAI вывела ChatGPT Ads в self-service для Индии, Европы, Ближнего Востока и Северной Африки, а оборот платформы уже достиг $1 млрд. Для арбитража это сигнал присмотреться к новому источнику: трафик из нейронок выглядит горячим, но вход дорогой — CPC в tier-1 GEO около $5, поэтому тестировать стоит точечно и с небольшим бюджетом.

➡️ Читайте на сайте: https://aff.top/blog/oborot-chatgpt-ads-dostig-1-milliarda

🧠 Ещё больше инсайтов → в канале AFF.top
Is a self-signed certificate inherently less secure than a CA-issued one?

The common advice — "never use self-signed, it's insecure" — conflates two distinct properties. A certificate does two jobs: it carries a public key for the key exchange, and it carries an identity assertion a relying party can verify. The cryptographic strength of a TLS (Transport Layer Security) session depends on the key and negotiated cipher suite, not on who signed the certificate. A self-signed RSA-3072 or P-256 certificate produces exactly the same handshake confidentiality as one from a public CA (Certificate Authority).

What self-signed certificates lack is third-party identity binding. The signature only attests "this key signed itself," so a relying party with no prior trust anchor cannot distinguish it from an attacker's. That is an authentication gap, not an encryption gap.

The distinction matters operationally. For internal service-to-service traffic where you control both endpoints and pin the certificate (or run a private CA), self-signed or private-CA certificates are entirely appropriate — see RFC 5280 §6 on path validation, which is what public trust automates.

— Encryption: identical
— Identity: absent unless pinned or pre-distributed

Further reading: RFC 5280, §6 (Certification Path Validation).
Bottom line: "insecure" is the wrong word. Self-signed certificates lack delegated identity verification, which only matters when the client has no out-of-band way to trust the key.
Forwarded from AFF.TOP - про арбитраж трафика и CPA рынок!
This media is not supported in your browser
VIEW IN TELEGRAM
Автоматизация в арбитраже трафика: зачем и для кого?

В статье объясняется, какие сервисы автоматизации реально помогают в арбитраже трафика: автозалив, сценарии в антидетект-браузерах и low-code/no-code решения. Главный вывод — автоматизация экономит время и снижает рутину, но не заменяет команду, а ошибки в настройке могут повысить риск бана и лишних затрат.

➡️ Читайте на сайте: https://aff.top/blog/avtomatizaciia-v-arbitrazhe-trafika-zachem-i-dlia-kogo

🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP - про арбитраж трафика и CPA рынок!
This media is not supported in your browser
VIEW IN TELEGRAM
В публичный релиз вышел Fable 5.1

➡️ Читайте на сайте: https://aff.top/blog/v-publichnyi-reliz-vyshel-fable-5-1

🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP - про арбитраж трафика и CPA рынок!
This media is not supported in your browser
VIEW IN TELEGRAM
1xBet перестал спонсировать эмоции

История о том, как казахстанцы зарегистрировали рекламный слоган 1xBet, а сам бренд оказался в юридической ловушке: после сделки с TonyBet права на товарный знак так и не выкупили. На фоне ареста активов Романа Семиохина и уголовного дела по азартным играм вывод простой: с 1xBet сейчас лучше не строить рекламные связки на рынке Казахстана.

➡️ Читайте на сайте: https://aff.top/blog/1xbet-perestal-sponsirovat-emocii

🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP - про арбитраж трафика и CPA рынок!
This media is not supported in your browser
VIEW IN TELEGRAM
За продажу аккаунтов в мессенджере теперь грозит статья

С 1 сентября 2026 года продажа аккаунтов соцсетей и мессенджеров в России стала уголовно и административно рискованной: штраф до 700 тысяч рублей, принудительные работы или лишение свободы до 2–3 лет. Если через аккаунт украдут деньги, продавца могут записать в соучастники мошенничества по ст. 159 УК РФ с риском до 10 лет.

➡️ Читайте на сайте: https://aff.top/blog/za-prodazhu-akkauntov-v-messendzhere-teper-grozit-statia

🧠 Ещё больше инсайтов → в канале AFF.top
Does moving from RSA-2048 to RSA-4096 meaningfully strengthen your TLS connections?

The advice to "always use 4096-bit RSA for better security" rests on a misreading of where the work happens. In a modern TLS 1.3 handshake the RSA key in your certificate is used only to sign the handshake transcript (authentication). The actual session secrets come from an ephemeral Elliptic Curve Diffie-Hellman (ECDHE) exchange, typically over Curve25519 or P-256. Your certificate key size does not determine forward secrecy or the symmetric key used to encrypt traffic.

NIST SP 800-57 Part 1 Rev. 5 rates RSA-2048 at roughly 112 bits of security, considered adequate well past 2030. RSA-4096 adds marginal headroom while imposing measurably higher CPU cost per signature — a non-trivial penalty on high-connection-rate servers.

The evidence-based upgrade path is not bigger RSA; it is switching the certificate to ECDSA (Elliptic Curve Digital Signature Algorithm) P-256, which delivers ~128-bit security with far smaller signatures and faster operations.

— RSA-2048: ~112-bit, fine to ~2030
— RSA-4096: diminishing return, higher cost
— ECDSA P-256: ~128-bit, faster

Further reading: NIST SP 800-57 Part 1 Rev. 5, Table 2.
Bottom line: For authentication strength per CPU cycle, prefer ECDSA over inflating RSA key length.
Forwarded from AFF.TOP - про арбитраж трафика и CPA рынок!
This media is not supported in your browser
VIEW IN TELEGRAM
Google выпустил в релиз Gemini 3.8 flash

Google выпустил Gemini 3.8 Flash спустя две недели после 3.7: модель обещает сильный кодинг и быстрый отклик, а цена остаётся низкой — $0,75 за млн входящих токенов и $3,75 за млн исходящих. Вывод простой: пока Google демпингует, это выгодный вариант для тех, кому нужны дешёвые и быстрые нейросетевые запросы.

➡️ Читайте на сайте: https://aff.top/blog/google-vypustil-v-reliz-gemini-3-8-flash

🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP - про арбитраж трафика и CPA рынок!
This media is not supported in your browser
VIEW IN TELEGRAM
Яндекс запустил сервис ПроБлогер

Яндекс запустил ПроБлогер — платформу для монетизации небольших каналов и групп во ВКонтакте, Дзене, Максе, Telegram, YouTube и Rutube. Для модерации нужны от 1000 подписчиков, свежие публикации, статус самозанятого, ИП или юрлица и соблюдение закона. Доход доступен через автопостинг с оплатой за просмотры и партнёрские ссылки; CPM можно задать самому или отдать аукциону.

➡️ Читайте на сайте: https://aff.top/blog/iandeks-zapustil-servis-probloger

🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP - про арбитраж трафика и CPA рынок!
This media is not supported in your browser
VIEW IN TELEGRAM
Google ads упростил перенос креативов из Asset Studio

➡️ Читайте на сайте: https://aff.top/blog/google-ads-uprostil-perenos-kreativov-iz-asset-studio

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