Перейти к содержанию
HexaTransfer
Вернуться к блогу
Шифрование и безопасность

Сквозное шифрование простым языком: руководство для новичков

Что такое сквозное шифрование и почему оно важно? Узнайте, как E2EE защищает ваши файлы при обмене.

Обновлено

Опубликовано HexaTransfer, сервисом Gaprod — Groupe Dwenola SAS. Руководства рассматривают наш сервис и другие продукты. Об издателе

Сквозное шифрование (E2EE) означает, что файл шифруется на вашем устройстве ключом, который может восстановить только получатель. Сервис передачи перемещает шифротекст, но никогда не держит ключ расшифровки — ни сотрудники компании, ни злоумышленники, ни судебные повестки не могут прочитать содержимое. На практике: браузер генерирует случайный 256-битный AES-ключ, шифрует файл локально, загружает шифротекст и помещает ключ в ссылку для скачивания после символа # — который браузеры никогда не отправляют на сервер. В этом и весь механизм, отделяющий подлинную конфиденциальность от маркетинговых слоганов.

Что на самом деле означает «сквозное»

Два «конца» — это вы и получатель. Всё между ними: роутеры провайдера, узлы CDN, серверы компании-сервиса, провайдер получателя — находится посередине. При E2EE все промежуточные узлы видят только зашифрованные байты. Сравните с шифрованием только на транспортном уровне (TLS): TLS защищает данные от браузера до сервера, затем сервер расшифровывает их, хранит в открытом виде и повторно шифрует, когда получатель скачивает. Стандартный тариф WeTransfer работает именно так. Компания может (и по законодательству США и ЕС иногда обязана) предоставить файлы по запросу.

При E2EE даже при наличии ордера прокурора провайдер не может передать ничего, кроме случайных на вид байтов. Именно поэтому журналисты, юристы и врачи всё настойчивее требуют E2EE.

Почему одного TLS недостаточно

TLS 1.3 превосходно справляется со своей задачей: защищает от злоумышленника в кофейне или недобросовестного провайдера, перехватывающего соединение. Но TLS завершается на сервере. Как только зашифрованный туннель заканчивается, сервер обрабатывает исходный файл. Если этот сервер взломан — как произошло с Dropbox в 2022 году, когда утекли исходный код и часть данных клиентов — TLS не даёт никакой защиты файлам, хранящимся там.

E2EE добавляет второй слой, который выдерживает компрометацию сервера. Файл шифруется до того, как коснётся провода, и остаётся зашифрованным до тех пор, пока браузер получателя не расшифрует его. Даже полный дамп базы данных раскроет только шифротекст и метаданные.

Проблема обмена ключами — и её решение

Сложная часть E2EE — передать ключ получателю так, чтобы сервер его не увидел. Современные браузерные сервисы решают это с помощью трюка с фрагментом URL. Ссылка для скачивания выглядит так:

https://hexatransfer.com/download/abc123#k=base64-encoded-256-bit-key

Браузеры рассматривают всё после # как клиентский фрагмент. При переходе по ссылке сервер получает только /download/abc123 в HTTP-запросе — фрагмент никогда не покидает браузер. JavaScript затем читает ключ из фрагмента через window.location.hash, загружает шифротекст и расшифровывает его локально, используя crypto.subtle.decrypt() из Web Crypto API.

Это проще, чем обмен ключами RSA или Diffie-Hellman, и работает для любого человека с браузером. Компромисс: кто угодно, получивший ссылку, получает и файл — поэтому ссылки по-прежнему нужно передавать по защищённому каналу (Signal, лично, зашифрованное письмо).

Что видит сервер и чего не видит

При правильно реализованном E2EE в логах сервера обычно содержится: случайный идентификатор файла, размер шифротекста, IP загрузки, временная метка и SHA-256-хеш шифротекста для дедупликации. Сервер не видит: имя файла, содержимое файла, личность получателя или ключ расшифровки. Имена файлов нередко шифруются вместе с содержимым и хранятся как часть заголовка шифротекста.

Полезная проверка: спросите провайдера, что он передаст по судебной повестке. Честный E2EE-сервис ответит: «зашифрованные блобы и IP-логи». Если они могут предоставить файлы в открытом виде — шифрование не сквозное.

Алгоритмы под капотом

Настоящие E2EE-стеки сходятся на коротком списке хорошо проверенных примитивов:

  • AES-256-GCM — для массового шифрования файлов. GCM обеспечивает одновременно конфиденциальность и аутентификацию: изменённый шифротекст не расшифровывается, а выдаёт ошибку.
  • PBKDF2 не менее чем с 100 000 итерациями или Argon2id — для получения ключей из паролей, когда добавляется защита паролем.
  • SHA-256 — для хешей целостности.
  • TLS 1.3 — как внешний транспортный уровень, потому что многоуровневая защита обходится дёшево.

Избегайте сервисов, всё ещё использующих AES-CBC без HMAC (уязвим к атакам), MD5 или SHA-1 (взломаны) или PBKDF2 с менее чем 10 000 итерациями (подбирается на современных GPU).

E2EE для передачи файлов и для мессенджеров

Signal популяризировал E2EE для чатов, используя протокол Double Ratchet, ротирующий ключи после каждого сообщения для прямой секретности. Передача файлов не нуждается в такой сложности, потому что она разовая — вы не ведёте продолжающийся диалог. Один симметричный ключ на файл, сгенерированный заново для каждой загрузки, одновременно проще и легче поддаётся аудиту.

Что нужно передаче файлов и не нужно мессенджерам: возобновляемые загрузки по частям (файлы могут весить 10 ГБ), проверка целостности по фрагментам и ссылки, работающие без аккаунта получателя. Tresorit, Proton Drive, SwissTransfer и HexaTransfer придерживаются этого подхода с незначительными вариациями.

Как проверить, что сервис действительно использует E2EE

Четыре практических теста перед тем, как доверить провайдеру свои файлы:

  1. Откройте DevTools → Сеть при загрузке небольшого тестового файла. Если тело запроса содержит открытый текст — шифрование не клиентское.
  2. Поищите ключ в фрагменте URL (после #). Если фрагмента нет — ключ скорее всего хранит сервер.
  3. Прочитайте политику конфиденциальности: там должна быть фраза «мы не можем получить доступ к вашим файлам» с техническим объяснением причины.
  4. Проверьте, доступен ли код клиента для проверки — открытый исходный код или хотя бы документированный. Закрытые бинарники с заявлениями об E2EE — жёлтый флаг.

Сервисы, прошедшие все четыре проверки: SwissTransfer (уровень с клиентским шифрованием), Tresorit Send, ссылки для обмена Proton Drive и HexaTransfer.

Чего E2EE не защищает

E2EE — не панацея. Оно не защищает от:

  • Скомпрометированной конечной точки. Если на вашем ноутбуке вредоносная программа, злоумышленник читает файлы до их шифрования.
  • Утечки ссылки. Кто угодно с ссылкой может скачать и расшифровать файл.
  • Слабых паролей на защищённых паролем передачах. PBKDF2 замедляет перебор, но «summer2024» падёт за секунды.
  • Корреляции метаданных. Временны́е метки, размеры файлов и IP-адреса по-прежнему могут многое рассказать.

Дополняйте E2EE истекающими ссылками (24 часа — разумный стандарт), лимитами на число загрузок (обычно 1–10) и надёжными паролями для чувствительных передач.

Как применить знания на практике

Для быстрой проверки: загрузите тестовый файл размером 5 МБ, откройте ссылку для скачивания в приватном окне без фрагмента (удалите всё после #) и попробуйте скачать. Настоящий E2EE-сервис не сможет расшифровать файл. Если файл открывается — ключ всё это время хранил сервер.

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

Безопасная отправка больших файлов со сквозным шифрованием

До 50 GiB бесплатно со сквозным шифрованием, без аккаунта и электронной почты. Выберите срок от 1 до 30 дней; по умолчанию 14 дней.

Отправить файл