Возможности шифрования браузера: что могут современные браузеры

Современные браузеры поставляются со встроенной криптографией, сопоставимой с возможностями специализированных библиотек безопасности. Chrome, Firefox, Safari и Edge реализуют Web Crypto API (crypto.subtle), поддерживают TLS 1.3 с механизмами прозрачности сертификатов, предоставляют WebAuthn/passkeys для фишинго-стойкой аутентификации, изолируют каждый источник через Site Isolation и обеспечивают аппаратное хранение ключей через TPM на Windows и Secure Enclave на macOS/iOS. Для разработчиков зашифрованных инструментов передачи файлов это означает: AES-256-GCM, деривацию ключей через PBKDF2 и аутентификацию FIDO2 — всё это доступно без внешних библиотек. Вот что умеет каждый браузер в 2026 году.

Web Crypto API: общая база

Все четыре основных браузера поддерживают W3C Web Cryptography API практически с идентичной поверхностью API. Основные алгоритмы:

Симметричные: AES-GCM, AES-CBC, AES-CTR, AES-KW (128, 192, 256 бит)
Асимметричные: RSA-OAEP, RSA-PSS, RSASSA-PKCS1-v1_5 (до 4096 бит), ECDSA и ECDH (P-256, P-384, P-521)
Хэширование: SHA-1, SHA-256, SHA-384, SHA-512
Деривация ключей: PBKDF2, HKDF
MAC: HMAC

Чего не хватает: ChaCha20-Poly1305 (нет поддержки в браузерах), Argon2 (нет поддержки), Ed25519/X25519 (Safari 17+ и Firefox 129+ уже имеют поддержку, Chrome догоняет). Для этих алгоритмов по-прежнему нужны библиотеки на JavaScript или WASM — libsodium.js или @noble/curves.

Chrome и Edge используют одну реализацию crypto (BoringSSL через V8). Firefox использует NSS. Safari использует CoreCrypto — FIPS-validated библиотеку Apple. Производительность варьируется: итерации PBKDF2 в Firefox примерно на 20% медленнее, чем в Chrome на одинаковом железе; AES-GCM в Safari с аппаратным ускорением на Apple Silicon примерно вдвое быстрее Chrome на том же Mac.

TLS 1.3 и Certificate Transparency

Все основные браузеры по умолчанию используют TLS 1.3 на поддерживаемых источниках и откатываются на 1.2 только для устаревших серверов. Chrome удалил поддержку TLS 1.0 и 1.1 в Chrome 84 (июль 2020). Firefox — в Firefox 78. Safari отказался от них в macOS 11 / iOS 14.

Certificate Transparency обязателен: сертификаты, выпущенные после апреля 2018 года, должны присутствовать минимум в двух CT-журналах, иначе Chrome и Safari их отклонят. Это позволяет выявлять атаки типа DigiNotar на ранней стадии, делая неправильную выдачу сертификатов CA публично заметной. Mozilla начала применять CT в Firefox 117 (2023).

Пиннинг открытых ключей через заголовок HPKP был устаревшим (Chrome 72 убрал поддержку), поскольку он допускал атаки блокировки. Заголовки Expect-CT выполняли ту же функцию мониторинга, но сами постепенно выводятся из употребления, поскольку CT стал обязательным. Предприятиям, которым нужен пиннинг, по-прежнему доступен пиннинг доверенного корневого сертификата через управляемые конфигурации (MDM на macOS, политики Chrome Enterprise).

Изоляция источников и песочница

Site Isolation в Chrome помещает каждый источник в отдельный процесс ОС начиная с 2018 года (десктоп) и 2019 года (Android). Firefox Fission достигает того же с Firefox 94. Safari использует модель WebKit с выделенными процессами. Что это означает для шифрования: вредоносный кросс-источниковый скрипт не может прочитать расшифрованный файл из памяти вкладки-соседа, поскольку сосед живёт в другом процессе с отдельной кучей.

Cross-Origin-Opener-Policy (COOP), Cross-Origin-Embedder-Policy (COEP) и Cross-Origin-Resource-Policy (CORP) позволяют страницам выбирать ещё более строгую изоляцию. Установка Cross-Origin-Opener-Policy: same-origin и Cross-Origin-Embedder-Policy: require-corp включает кросс-источниковую изоляцию, которая в свою очередь открывает SharedArrayBuffer и высокоточные таймеры. Это актуально для криптографии, поскольку Spectre-подобные атаки по времени против реализаций AES нейтрализуются, когда атакующий не может открыть SAB в вашем источнике.

WebAuthn и passkeys для аутентификации

FIDO2 WebAuthn поддерживается в Chrome 67+, Firefox 60+, Safari 14+ и Edge 18+. Это позволяет приложениям аутентифицировать пользователей через аппаратные ключи (YubiKey, Titan), платформенные аутентификаторы (Face ID, Windows Hello, биометрия Android) или passkeys, синхронизируемые между устройствами через iCloud Keychain, Google Password Manager или 1Password.

Для приложений передачи файлов WebAuthn заменяет пароли как фактор, защищающий доступ к сохранённой ссылке для скачивания. Важно: WebAuthn устойчив к фишингу — подпись привязана к источнику, поэтому сайт-двойник не может перехватить учётные данные. Chrome и Safari перешли на passkey-first-подход по умолчанию в 2023-2024 годах, сняв требование физического ключа для большинства потребительских сценариев.

Аппаратное хранение ключей

На Windows чип TPM 2.0 (обязательный для Windows 11) может хранить ключи Web Crypto, созданные как неизвлекаемые через мост Windows CNG. На macOS и iOS Secure Enclave хранит ключи для Face ID, Touch ID и passkeys. На Android Keystore, поддерживаемый StrongBox (аппаратный) или TEE (Trusted Execution Environment), обеспечивает аналогичную защиту.

Практическое значение: ключ, созданный с extractable: false через Web Crypto на современном ноутбуке, может находиться в TPM или Secure Enclave, а не в основной памяти. Даже полная эксплуатация браузера, дампящая память JavaScript, не даст сырых байтов ключа. Для инструментов передачи файлов это наиболее полезно для долгоживущих ключей получателей; эфемерные AES-ключи на файл в такой защите не нуждаются.

Content Security Policy как усилитель шифрования

Шифрование бесполезно, если вредоносный скрипт может прочитать открытый текст до его шифрования. Заголовки Content Security Policy позволяют сайту объявить, какие скрипты разрешены к запуску. Строгая политика вида:

Content-Security-Policy: default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-abc123';

блокирует встроенные скрипты и сторонний код, не оставляя поверхности атаки для внедрённых полезных нагрузок, крадущих ключи. Все основные браузеры поддерживают CSP Level 3. Для приложений передачи файлов сочетайте CSP с Subresource Integrity (SRI) для любых внешних скриптов, чтобы убедиться в отсутствии несанкционированных изменений.

File System Access API и OPFS

File System Access API (Chrome 86+, Edge 86+, частично Safari 15.2+ через Origin Private File System) позволяет веб-приложениям читать и записывать локальные файлы с разрешения пользователя. Origin Private File System особенно актуален для шифрования: это приватная файловая система на источник, управляемая браузером, используемая для промежуточного хранения больших зашифрованных полезных нагрузок перед загрузкой без загрузки всего содержимого в память.

Firefox медленнее внедрял FSA, но поддерживает OPFS начиная с Firefox 111. Safari поддерживает OPFS повсеместно, но имеет более ограничительное поведение для более широкого File System Access API.

Что браузеры пока не умеют делать хорошо

Остаётся несколько пробелов:

Argon2 для деривации ключей отсутствует в Web Crypto. Используйте WASM-библиотеки для хэширования паролей выше уровня PBKDF2.
ChaCha20-Poly1305 не предоставляется. AES-GCM покрывает большинство потребностей, но ChaCha помог бы на устройствах без AES-NI (старые ARM).
Аттестация ключей для аппаратных ключей ограничена. WebAuthn обеспечивает аттестацию; более широкий Web Crypto API — нет.
Потоковый AEAD ещё не входит в спецификацию. Шифрование больших файлов требует логики чанкования или WASM.
Постквантовые алгоритмы (Kyber, Dilithium) пока не реализованы в браузере. Google включил Kyber в TLS-рукопожатия (Chrome 116+), но JavaScript-крипто на постквантовой основе пока остаётся в области библиотек.

Что использовать сегодня для передачи файлов

Достоверный стек для передачи файлов в браузере в 2026 году:

AES-256-GCM через crypto.subtle.encrypt для содержимого файлов
PBKDF2-SHA-256 с 600 000 итерациями для ключей, производных от паролей
crypto.getRandomValues() для солей и nonce (никогда не Math.random)
Фрагменты URL (#key=...) для передачи ключей на стороне клиента без раскрытия серверу
HTTPS с TLS 1.3 минимум, HSTS включён, COOP/COEP для изоляции
CSP strict-dynamic, без встроенных скриптов
WebAuthn passkeys для любой функциональности с сохранёнными аккаунтами
OPFS для промежуточного хранения больших файлов в Chrome/Edge/Safari 16+

HexaTransfer работает практически на этом стеке. Как и SwissTransfer, Tresorit Send, Cryptpad и Proton Drive Share. Примитивы зрелые и согласованы между браузерами.

Тестирование в разных браузерах

Всегда тестируйте во всех четырёх браузерах. Реальные баги: Firefox выбрасывает OperationError для входных данных PBKDF2, которые Chrome принимает молча. FileReader в Safari медленнее с файлами свыше 2 ГБ. Запись в OPFS в Chrome разбивается на части свыше 4 ГБ в некоторых версиях. Подсказки для подтверждения пользователя WebAuthn существенно различаются (Face ID против Touch ID против Windows Hello против Android biometric). Используйте BrowserStack, Sauce Labs или локальную матрицу реальных устройств для тестирования перед выпуском.

Браузеры незаметно превратились в одну из наиболее полных криптографических платформ. Те же стандартные примитивы, которые лежат в основе банковских приложений, менеджеров паролей и мессенджеров, доступны одним JavaScript-вызовом для всех, кто создаёт зашифрованные инструменты передачи файлов.

Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.