Meta ограничивает расходы на токены для сотрудников

Meta ввела внутренние лимиты на использование ИИ из-за резкого роста расходов: в 2026 году только на сотрудников заложены миллиарды долларов, а общий бюджет на ИИ-инфраструктуру оценивается в 130–145 млрд. Вывод простой: даже у Big Tech ИИ перестал быть бесплатной игрушкой и требует жёсткого контроля затрат.

➡️ Читайте на сайте: https://aff.top/blog/meta-ogranichivaet-raskhody-na-tokeny-dlia-sotrudnikov

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

upgrade-insecure-requests or block-all-mixed-content: which CSP directive fits a migration?

When you move a site to HTTPS but legacy resources still reference http://, which Content Security Policy tool should you reach for? They solve adjacent but distinct problems.

upgrade-insecure-requests rewrites in-document HTTP subresource URLs to HTTPS before the request is made. It is forgiving: if the resource exists over TLS, it loads; the user sees no breakage. This is the migration aid — it papers over hardcoded http:// references during transition.

block-all-mixed-content does the opposite: it refuses to load any mixed content, optionally including the passive kind browsers normally allow. It is the enforcement tool — useful once you believe the site is clean and want a hard guarantee against regression.

Note that browsers now auto-upgrade many mixed requests regardless, and block passive mixed content in stricter modes, so these directives increasingly codify behavior the browser trends toward anyway.

— Use upgrade-insecure-requests during and shortly after migration.
— Switch to block-all-mixed-content once you want regression protection.
— Audit with the browser console's mixed-content warnings before flipping to block mode.

Further reading: W3C Mixed Content specification; CSP Level 3.

Bottom line: upgrade is the gentle migration crutch; block is the strict post-migration guardrail — sequence them, do not pick one forever.

Is SHA-1 still acceptable for internal or non-critical certificates?

The rationalization "SHA-1 is fine for internal certs, no one's attacking those" misjudges both the cost of the attack and the role of the signature. SHA-1 is the hash over which a CA computes a certificate's signature. A collision — two different inputs hashing to the same digest — lets an attacker craft a benign certificate signed by a CA and a malicious one sharing that signature, transplanting the trust.

This stopped being theoretical in 2017 when Stevens et al. produced SHACK/SHAttered, the first practical SHA-1 collision, and in 2020 Leurent and Peyrin demonstrated a chosen-prefix collision for roughly $45,000 of compute — directly applicable to certificate forgery. "Internal" does not change the math; it only changes who you imagine the attacker to be, and chosen-prefix collisions are now within reach of well-resourced adversaries and falling in price.

Browsers stopped accepting publicly-trusted SHA-1 certificates in 2017. The mandated baseline is SHA-256 or stronger (the SHA-2 family). There is no security argument for SHA-1 signatures on any new certificate.

— Chosen-prefix SHA-1 collisions are practical and cheap
— Forged certificates are the direct threat
— SHA-256 is the floor everywhere

Further reading: Leurent & Peyrin, "SHA-1 is a Shambles" (2020).
Bottom line: SHA-1 certificate signatures are forgeable today. "Internal" is not an exemption; use SHA-256.

Claude Cowork, Claude Design объединили в один Claude

➡️ Читайте на сайте: https://aff.top/blog/claude-cowork-claude-design-obedinili-v-odin-claude

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

Microsoft планирует вставлять рекламу в игры

➡️ Читайте на сайте: https://aff.top/blog/microsoft-planiruet-vstavliat-reklamu-v-igry

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

Name Constraints or separate sub-CAs: how should you scope an intermediate's authority?

When you delegate issuance to an intermediate CA, how do you stop it from issuing for domains it should never touch? Two approaches bound the authority differently.

The Name Constraints extension (RFC 5280 §4.2.1.10) embeds permitted and excluded name subtrees directly into the intermediate certificate. A constrained sub-CA limited to .corp.example.com cryptographically cannot issue a trusted certificate outside that namespace — the path-validation algorithm rejects it. One intermediate, hard-scoped, enforced by every conforming client.

Issuing multiple separate sub-CAs instead relies on policy and operational discipline to keep each in its lane, with no cryptographic enforcement of scope. It offers flexibility but trusts process where Name Constraints trusts math.

The historical caveat: Name Constraints enforcement was patchy in older clients, which is why public CAs were slow to rely on it. In controlled internal environments where you know the clients, it is far more dependable.

— Use Name Constraints to cryptographically cage an internal sub-CA.
— Verify your client stack actually enforces the extension before relying on it.
— Reserve multiple sub-CAs for genuinely independent trust domains.

Further reading: RFC 5280 §4.2.1.10; RFC 9618 on constraint clarifications.

Bottom line: Name Constraints enforce scope in cryptography rather than policy — superior where clients honor it, which is most controlled internal fleets.

Is HTTP Public Key Pinning a strong defense you should deploy?

Older hardening guides still recommend "pin your public keys with HPKP for maximum security." Follow that advice and you will deploy a feature browsers removed. HPKP (HTTP Public Key Pinning, RFC 7469) let a site send a header committing browsers to accept only specific public keys for a set period. The intent was to stop misissued certificates from being usable against your domain.

In practice HPKP was a footgun with two failure modes. Hostage attacks: an attacker who briefly compromised a server could pin a key they controlled, locking out the legitimate owner for the pin's lifetime. Suicide: an operator who lost the pinned key, or failed to maintain a backup pin, bricked their own domain for every returning visitor — no recovery, no override. Chrome deprecated HPKP in 2018 and removed it; the broader ecosystem followed.

The properties HPKP aimed for are now served better by Certificate Transparency (detection of misissuance) and, for native apps where you control the client, application-level pinning with a managed update path.

— HPKP enabled hostage and suicide failures
— Browsers removed it in 2018
— CT plus app-level pinning replaced it

Further reading: RFC 7469; Chrome HPKP deprecation notice (2018).
Bottom line: Do not deploy HPKP — it no longer exists in browsers and was dangerous when it did. Rely on CT instead.

Does the order of certificates in your chain not matter?

"Modern clients sort the chain out, order is irrelevant" is half-true in a way that produces intermittent, maddening failures. TLS 1.2 (RFC 5246, §7.4.2) specifies that the server's Certificate message must present the leaf first, then each certificate that signs the previous one, up toward the root — an ordered list. A chain sent out of order, or missing an intermediate, is a protocol violation.

Why does it sometimes work anyway? Some clients are lenient: they reorder, or they fetch a missing intermediate via the AIA (Authority Information Access) extension's caIssuers URL. But AIA fetching is optional and unevenly implemented — OpenSSL historically did not do it, and many non-browser clients (older Java, embedded HTTP libraries, some mobile stacks) do not either. So a misordered or incomplete chain passes in your desktop browser and fails in a partner's API client or an Android app.

The diagnostic tell is "works in my browser, fails in curl / the SDK." Tools like SSL Labs flag "chain issues: incorrect order" or "extra/missing certs."

— Spec requires leaf-first ordered chain
— Browser leniency and AIA mask errors
— Non-browser clients often don't compensate

Further reading: RFC 5246, §7.4.2; RFC 5280 §4.2.2.1 (AIA).
Bottom line: Chain order and completeness do matter. Browser tolerance hides errors that break stricter clients — build the chain correctly.

How should you actually order a TLS cipher suite list rather than copying one from a blog?

A cipher suite names the key exchange, authentication, bulk cipher, and MAC. The order you publish for TLS 1.2 is a policy; in TLS 1.3 the negotiated set is fixed and short. Hardening procedure.

— Separate the two protocols mentally. TLS 1.3 offers only five AEAD suites (AES-GCM and ChaCha20-Poly1305); you cannot reorder them meaningfully, only enable or disable the protocol.
— For TLS 1.2, require ECDHE for forward secrecy and AEAD ciphers; drop CBC-mode and anything with RSA key exchange.
— Place ChaCha20-Poly1305 ahead of AES-GCM only if you serve many clients without AES hardware acceleration; otherwise AES-GCM is faster on modern x86.
— Set ssl_prefer_server_ciphers off for TLS 1.3 (clients choose well) but consider on for TLS 1.2 to enforce your order.
— Validate against the actual negotiated suite with nmap --script ssl-enum-ciphers or testssl.sh, not against your config file's intent.

Evidence vs. speculation: a config can list a suite the library has compiled out; only an active scan proves what is offered.

Further reading: RFC 8446 appendix B.4; Mozilla SSL Configuration Generator (Intermediate profile).

Bottom line: configure TLS 1.2 ordering deliberately and let TLS 1.3 pick for itself.