Russian Ministry Certificates Enable Potential State MITM on Foreign Domains

Russian companies facing sanctions have started adopting root certificates issued by the Ministry of Digital Development and Communications to maintain HTTPS access after commercial CAs revoked or refused to renew their certificates. Installing these Ministry certificates allows browsers to trust sites using Russian national CAs but also creates a pathway for man-in-the-middle interception by state-controlled entities. The article details a concrete threat model where a government-linked operator could use the Ministry root to generate on-the-fly certificates for any domain, including foreign services outside Russian jurisdiction. To mitigate this, the author demonstrates how to re-sign the Ministry root with OpenSSL nameConstraints limited to .ru, .su, and .рф domains only. Tests on macOS with Homebrew show that the constrained certificate still validates Russian banking sites such as online.sberbank.ru while correctly rejecting attempts to validate foreign domains like sberbank.com. The technique requires users to maintain their own cross-signed root and never rely on pre-installed Ministry or Yandex Browser roots for full protection.

HabrAugust 17, 2026Translated from Russian

Read at source

Russian organizations under sanctions have begun switching to certificates issued under the Ministry of Digital Development and Communications root after commercial authorities revoked or declined to renew their existing certificates. Users who visit affected sites now encounter browser warnings that the authenticity of the resource cannot be verified.

The article explains that the only practical workarounds are to install the Ministry root certificates system-wide, switch to Yandex Browser which already bundles them, or maintain two separate browsers. Each option carries significant risks: loss of access to services, full system trust in a state-controlled CA, or reduced usability.

Threat Model

The author constructs a detailed threat model focused on a third party operating inside Russian jurisdiction. This actor can legally compel any Russian company to hand over data and can also deploy TLS interception appliances between users and foreign services. Once the Ministry root is trusted, the same infrastructure can silently terminate and re-sign connections to non-Russian domains, capturing session tokens and credentials.

Because the Ministry root currently carries no name constraints, it can issue certificates for any domain. The article therefore recommends re-signing the root with nameConstraints that permit only the national TLDs .ru, .su, and .рф.

Technical Implementation with OpenSSL

All steps are performed using OpenSSL on macOS and Linux. Users first download the Ministry certificate bundle from gosuslugi.ru, extract the non-GOST files, and create a new local root with appropriate basicConstraints, keyUsage, and nameConstraints extensions.

Generate a fresh 4096-bit local root limited to national domains.
Create a temporary CSR and extract the public key from the original Ministry root.
Cross-sign the Ministry root using the local root and a cross_ca_ext configuration that preserves CA capabilities while inheriting the name constraints.

The resulting new_root_ca.crt can then be installed in the system trust store. Verification commands confirm that sites under .ru domains continue to validate while foreign domains such as sberbank.com are rejected when only the constrained root is present.

The author stresses that users must perform these steps themselves; any party holding the private key of a trusted root can still perform interception within the certificate’s permitted scope.

Gosuslugi OpenSSL Sberbank nameConstraints

ShareX Facebook LinkedIn Reddit

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Privacy & Surveillance

Privacy & Surveillance

Maximizing iPhone Privacy: Essential Settings to Enable, Disable, and Verify Immediately

The article provides a detailed guide on strengthening iPhone privacy by limiting unauthorized access to messages, location data, photos, and cloud backups. It explains how to set a strong alphanumeric passcode, enable Stolen Device Protection, and restrict lock screen notifications and widgets. Users are advised to review Apple ID security, enable Advanced Data Protection for iCloud, and minimize app permissions for location, contacts, and camera. Additional steps include turning off cross-app tracking, using private Wi-Fi addresses, and activating Lockdown Mode for high-risk scenarios. The guide emphasizes regular updates, encrypted local backups, and periodic audits of shared access and active sessions to maintain long-term protection.

SecuritylabOct 28, 2026Translated from Russian

Privacy & Surveillance

Top 10 Secure DNS Servers for Privacy, Threat Blocking and Ad Filtering in 2026

Public DNS resolvers differ significantly in their ability to block malicious domains, filter advertising and tracking, respect user privacy, and support modern encryption protocols. The guide evaluates ten services including Quad9, Cloudflare, AdGuard DNS, NextDNS, Control D, CleanBrowsing, Mullvad DNS, DNS4EU, Google Public DNS and DNS.SB, providing IPv4 addresses, DoH and DoT endpoints, and recommended use cases. Key distinctions include Quad9’s focus on phishing and malware blocking without logging, Mullvad’s strict no-logs policy requiring encrypted protocols only, and DNS4EU’s EU-based infrastructure with mandatory court-ordered blocks. The article explains why DNSSEC and encryption alone are insufficient and outlines four practical selection criteria: threat filtering quality, data-handling practices, encryption support, and network stability. Detailed configuration instructions cover Windows 11, Android, iOS, and home routers, along with verification methods and warnings against mixing providers with conflicting policies.

SecuritylabOct 28, 2026Translated from Russian

Privacy & Surveillance

WebRTC IP Leaks Explained: Why Disabling the Protocol Harms Anonymity in Anti-Detect Browsers

The article from Aurorium details how WebRTC technology can leak real IP addresses even when users route traffic through proxies. It explains the peer-to-peer mechanics of WebRTC, the role of STUN servers in generating ICE candidates, and why standard TCP proxies fail to handle UDP traffic. Disabling WebRTC via flags or JavaScript extensions creates detectable anomalies that anti-fraud systems flag as non-standard environments. The recommended approach involves native emulation inside the browser kernel so that STUN requests return proxy IPs while preserving full API integrity across workers. Additional leaks through local network addresses, mDNS candidates, and IPv6 are also covered with practical verification methods using tools like BrowserLeaks and CreepJS.

HabrOct 26, 2026Translated from Russian