Chromium-Gost reaches GOST algorithms through msspi, not through BoringSSL

GOST support is delegated to the system crypto provider

Chromium-Gost is a web browser based on Chromium with support for GOST cryptographic algorithms when establishing protected connections through the msspi interface. The architecture has two halves and the split matters. The original Chromium implementation uses the BoringSSL library, which does not support GOST cryptographic algorithms. To make GOST work, the browser uses the msspi interface, which can support the relevant algorithms by using a crypto provider installed in the system. In other words, Chromium-Gost does not implement GOST itself. It borrows it from whatever provider the operating system already has, and that is the reason a fork is needed at all: the algorithms have to be offered during the handshake, and the handshake code lives in BoringSSL. The companion project for the msspi interface lives at github.com/deemru/msspi, and the fork exists to wire the two together.

The negotiation runs twice, once with a failure on purpose

The handshake logic is the interesting mechanism, and it is worth following step by step because it explains both how the tool succeeds and what it costs. At browser startup the presence of a technical possibility to work with GOST algorithms through the msspi interface is determined. If that check succeeds, then when the next protected connection is established, the GOST algorithm identifiers are sent in the packet in addition to the original algorithm identifiers. If the site supports working over GOST, it can react to the presence of those identifiers by offering to work with GOST algorithms. The protected connection within BoringSSL will not be established, since BoringSSL does not support GOST, but a signal about the corresponding error arrives. When that signal appears for a given site, the browser switches to msspi mode for it. If the connection then succeeds through msspi, the site is marked as supporting GOST algorithms, and all subsequent connections to it use msspi. The deliberate failure inside BoringSSL is the detection mechanism. There is no clean way to ask a server which suites it prefers, so the browser offers everything and reads the rejection.

Every site pays the cost of the extra identifiers

The documented benefit of the algorithm is that it is maximally transparent to the user and minimally affects the experience of interacting with a site. That claim is true for the user, and less true for the network. The GOST identifiers are sent in addition to the original identifiers on every protected connection, which means a handshake with a server that has no interest in GOST still carries them and still fails once inside BoringSSL before the msspi path is tried. For any site that does not offer GOST, the browser pays an extra failed handshake attempt before it settles on a normal connection. The documentation describes the per-site marking of GOST support as an optimisation for subsequent connections to that site, which is exactly what it is, and it does not describe any mechanism for avoiding the first attempt. Middleboxes, TLS inspection appliances and servers with unusual cipher configuration are also the places where an extra, unusual set of ClientHello identifiers is most likely to draw attention, and the project does not address that case. The fork is a targeted interoperability tool, not a transparent drop-in replacement for a stock browser.

Binaries are published, and the build is a four step script sequence

Chromium-Gost is available for Windows, Linux and macOS, and the distributions are published on the releases page of the repository, with recent tagged builds numbered 152.0.7977.169 on 2026-10-17, 152.0.7977.149 on 2026-10-01 and 152.0.7977.134 on 2026-09-19. The version numbers track Chromium itself, which tells you the fork is rebased regularly rather than drifting away from upstream. Building from source is a documented four step path that starts with learning to build original Chromium, then extracting the Chromium-Gost sources, then using the scripts from build_linux, build_mac or build_windows depending on the platform. After that come the project's own steps, correcting the paths with chromium-gost-env, preparing the build with chromium-gost-prepare, and assembling the distribution with chromium-gost-build-release. The repository layout matches that process, with patch/, src/, extra/ and a VERSION file at the top level, plus the three platform build directories and a FLAGS file.

What the fork is not: a general purpose GOST browser

There is a clear boundary around the scope, and it is worth stating before anyone installs it. Chromium-Gost does not add GOST cipher suites to BoringSSL, does not ship a crypto provider, and does not make a non-GOST server accept GOST. It works when the server already supports GOST and the operating system already has a provider that msspi can load. On a Windows machine with a Russian crypto provider installed, that is a realistic scenario, and the project is a reasonable answer to it. On a Linux or macOS machine, the same requirement has to be met by whatever provider the msspi implementation can reach on that platform, and the project documentation does not enumerate which providers work. The alternative approach to the same problem is to terminate TLS elsewhere. A reverse proxy that speaks GOST upstream and a standard cipher set downstream sits in front of a service and handles the translation outside the browser entirely. The difference in approach is where the substitution happens: the fork puts it inside the browser process and requires a provider on the client machine, while the proxy puts it on a server you control and leaves the browser untouched.

Upstream tracking, MIT terms, and a forum thread as the support channel

The project is MIT licensed, which permits reuse and modification of the source with the notice retained and no warranty attached, and the LICENSE file sits at the top of the repository alongside the patch directory that applies changes to Chromium sources. Because the fork exists to carry a small, targeted change across many Chromium releases, its real maintenance cost sits in the rebasing work: each upstream version needs the patch set re-applied, and the patch set has to survive changes in the TLS stack of the browser. The release numbering shows this happening on a schedule of days and weeks rather than months, and the last push to the master branch was on 2026-10-18, one day after the 152.0.7977.169 build was tagged, so the repository is not abandoned. Support and discussion are directed to a thread on the CryptoPro forum at cryptopro.ru rather than to the issue tracker, and the homepage of the project points at that same thread. For anyone evaluating it, that forum is where the provider compatibility questions get answered, and it is worth reading before committing to an install.

Editorial conclusion

Chromium-Gost suits users inside networks where a server offers GOST and refuses anything else, and it suits organisations whose compliance requirements name GOST specifically. It does not suit anyone outside that environment, because the extra identifiers change how every TLS handshake is attempted, and it does not suit Linux or macOS users without a system crypto provider that msspi can reach. Before adopting it, confirm that the endpoint you need actually offers GOST, install a provider that msspi can load, and test the site with GOST disabled on the server to see whether the browser falls back cleanly.

Frequently asked questions

Official sources

1. deemru/Chromium-Gost on GitHub
2. License: MIT
3. Project website
4. README
5. Releases