What actually is a Signed Certificate Timestamp, and what does it prove?

Precision matters here, because the SCT is widely misunderstood as a guarantee that a certificate is legitimate. It is not.

Certificate Transparency (CT, RFC 6962) was built after the 2011 DigiNotar and Comodo breaches, where rogue certificates were issued without the domain owner knowing. CT's premise: make every issued certificate publicly auditable by appending it to an append-only Merkle tree log.

A Signed Certificate Timestamp is the log's signed promise: "I received this certificate and will incorporate it into my tree within the Maximum Merge Delay (typically 24 hours)." Browsers like Chrome require a certificate to carry SCTs from multiple independent logs, delivered via an X.509 extension, the TLS extension, or stapled OCSP.

What the SCT proves is narrow but powerful: that the certificate is publicly visible. It does not prove the certificate was authorized — a misissued cert still gets an SCT. The value is detection, not prevention. Domain owners running CT monitors (or services like crt.sh) can spot certificates they never requested and act.

The Merkle structure is what makes the log trustworthy: anyone can verify an inclusion proof and a consistency proof showing the log never retroactively edited history.

Further reading: RFC 6962, RFC 9162 (CT 2.0); Chrome CT policy.

Bottom line: an SCT proves publication, not authorization — CT shifts the model from preventing misissuance to making it impossible to hide.

Cloudflare запустил функцию Drop

Cloudflare запустил Drop — сервис, который разворачивает временный сайт за несколько секунд прямо из zip-архива.

Без аккаунта можно создавать сколько угодно таких страниц, но ссылка живёт всего 1 час. Потом сайт придётся переносить в аккаунт.

Зачем это нужно арбитражнику и что можно успеть за это время — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/cloudflare-zapustil-funkciiu-drop

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

Open AI выпустила ChatGPT-5.6 и ChatGPT Work

OpenAI выпустила ChatGPT-5.6 и ChatGPT Work: новая модель получила три версии и понятный прайс, а Work стал универсальным инструментом для кодинга, текстов, изображений и анализа данных. Вывод простой: экосистема ChatGPT усиливается, а фокус смещается на многофункциональные сценарии, где один продукт закрывает сразу несколько задач.

➡️ Читайте на сайте: https://aff.top/blog/open-ai-vypustila-chatgpt-5-6-i-chatgpt-work

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

SpacexAI выпустила Grok 4.5

xAI выпустила Grok 4.5 — новую версию флагманской нейросети, доступную в Cursor на всех тарифах и по API за $2 за миллион входных токенов. Бенчмарков пока нет, но модель в 4,2 раза экономнее по токенам на SWE Bench Pro и обучена на данных Cursor, что делает её сильным инструментом для разработки приложений.

➡️ Читайте на сайте: https://aff.top/blog/spacexai-vypustila-grok-4-5

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

ChatGPT ads внедрил функцию автосоздания креативов

OpenAI добавила в ChatGPT Ads автогенерацию креативов: вставляешь ссылку на сайт, ИИ анализирует лендинг и создаёт релевантный креатив. По ощущениям, такие материалы должны легко проходить модерацию, но пока неясно, насколько они поддаются правкам. Источник интересен ещё и тем, что вайт можно сгенерировать тут же через ChatGPT.

➡️ Читайте на сайте: https://aff.top/blog/chatgpt-ads-vnedril-funkciiu-avtosozdaniia-kreativov

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

В Google search console теперь можно добавлять соцсети

Google добавил в Search Console поддержку аккаунтов соцсетей: теперь можно отслеживать ключевые запросы, источники и географию переходов, показы и клики по ссылкам. Функция подключается там же, где и сайты, доступны четыре соцсети на выбор. Rollout постепенный — доступ получают не все сразу.

➡️ Читайте на сайте: https://aff.top/blog/v-google-search-console-teper-mozhno-dobavliat-socseti

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

Google стал помечать креативы, созданные ИИ

Google объявил, что начнёт помечать рекламные креативы, созданные нейросетями. Причина — ИИ-баннеры и видео стали слишком похожи на настоящие.

Формат и заметность маркировки будут зависеть от законов конкретного региона: где-то предупреждение появится прямо на креативе, где-то — в его информации.

Что это значит для арбитражников и когда правила …

➡️ Читайте на сайте: https://aff.top/blog/google-stal-pomechat-kreativy-sozdannye-ii

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

Компания Meta выпустила Muse Spark 1.1

Meta выпустила Muse Spark 1.1 почти одновременно с новой ChatGPT-5.6. Это мультимодальный агент, который сам дробит задачу на подзадачи и распределяет их между субагентами.

Стоимость тоже заметно ниже топовых западных моделей: $1.25 за миллион входных токенов и $4.25 за миллион выходных.

Но главный вопрос — насколько она реально сильна на фоне к…

➡️ Читайте на сайте: https://aff.top/blog/kompaniia-meta-vypustila-muse-spark-1-1

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

What actually happens when a TLS 1.3 client guesses the wrong key-share group?

This is the HelloRetryRequest path, and understanding it explains a measurable latency cost in real handshakes.

TLS 1.3 (RFC 8446) folds key exchange into the first flight. The client doesn't just list supported groups in supported_groups; it speculatively sends actual Diffie-Hellman key shares in the key_share extension for the groups it expects the server to pick — usually X25519 and secp256r1.

If the server's preferred group isn't among the shares the client offered, it cannot complete the exchange from flight one. It returns a HelloRetryRequest (HRR), naming the group it wants. The client then resends a ClientHello with a key share for that group. This adds a full round trip — the very round trip TLS 1.3 was designed to eliminate.

The design tension is explicit: sending shares for every supported group wastes bandwidth and computation, while sending too few risks an HRR. Clients optimize by guessing the most probable group. This is why X25519 (Curve25519, RFC 7748) dominates — it is the near-universal default, so guessing it almost always avoids the retry.

The same machinery now governs post-quantum migration: a client offering X25519MLKEM768 that hits a server wanting classical X25519 eats an HRR.

Further reading: RFC 8446 §4.1.4, RFC 7748, RFC 8422.

Bottom line: HelloRetryRequest is the cost of a wrong key-share guess — one extra round trip, which is why client group-prediction quality directly shapes handshake latency.

What actually happens if you submit a domain to the HSTS preload list and later need to serve plain HTTP?

The honest answer is: you have a problem that can outlive your control of the domain.

HTTP Strict Transport Security (HSTS, RFC 6797) is a response header instructing browsers to only ever reach a host over HTTPS for max-age seconds. Its flaw is the first visit: before the browser has seen the header even once, an attacker can downgrade the initial request. The preload list closes that gap by hardcoding domains into the browser binary itself, so HTTPS is enforced from the very first connection — including the includeSubDomains directive.

The trap is removal latency. Getting onto the list (via hstspreload.org) requires max-age of at least one year and the preload directive. Getting off requires a separate removal request, and the change only reaches users as browsers update and propagate — historically weeks to many months. Older or un-updated browsers may enforce it far longer.

The operational hazard is concrete: includeSubDomains will break any subdomain that cannot serve valid HTTPS — internal tools, legacy hosts, third-party CNAMEs. Operators have shipped preload, then discovered a subdomain they forgot, with no fast escape.

Further reading: RFC 6797 §11, §12; the Chromium HSTS preload submission policy.

Bottom line: preload is a near-irreversible commitment to HTTPS-everywhere including all subdomains — audit your full subdomain inventory before submitting, not after.

What actually changed in the structure of a TLS 1.3 cipher suite name?

The rename is small on screen but reflects a deep redesign worth reading precisely.

A TLS 1.2 suite like ECDHE-RSA-AES128-GCM-SHA256 encodes four independent choices: key exchange (ECDHE), authentication (RSA), bulk cipher (AES-128-GCM), and the hash for the pseudo-random function (SHA-256). The suite negotiated all four together.

TLS 1.3 (RFC 8446) decouples them. Key exchange and authentication are negotiated separately — via supported_groups, key_share, and signature_algorithms — so they no longer belong in the suite name. What remains is the AEAD cipher plus the HKDF hash. Hence the entire TLS 1.3 suite registry is tiny: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, plus two CCM variants.

The word AEAD (Authenticated Encryption with Associated Data, RFC 5116) is the crux. TLS 1.3 mandates AEAD and removed every non-AEAD construction. The old MAC-then-encrypt and CBC-mode suites that enabled Lucky 13, BEAST, and POODLE-class padding-oracle attacks are simply not expressible. There is no RC4, no CBC, no static-RSA key exchange, no compression.

This is why TLS 1.3 has far fewer suites: the insecure combinatorial space was deleted, not merely deprecated.

Further reading: RFC 8446 §B.4, RFC 5116, RFC 7905 (ChaCha20-Poly1305).

Bottom line: a TLS 1.3 suite names only the AEAD cipher and hash because authentication and key exchange moved to their own extensions — and every padding-oracle-prone mode was removed outright.