TLS и сквозное шифрование: что нужно знать
Сравните транспортное шифрование TLS с настоящим сквозным шифрованием, чтобы понять, какое обеспечивает лучшую безопасность для передачи файлов.
TLS (Transport Layer Security) шифрует данные при передаче между вашим устройством и сервером, а затем расшифровывает их по прибытии — это значит, что оператор сервера может читать ваши файлы в открытом виде. Сквозное шифрование (E2EE) шифрует контент на устройстве отправителя ключом, которым владеет только получатель, поэтому серверы никогда не видят незашифрованных данных. При передаче файлов TLS защищает от сетевых перехватчиков, но не от самого провайдера. E2EE защищает от обоих. Замок в браузере не говорит вам, какой из вариантов реально действует.
Что в действительности защищает TLS
TLS 1.3, стандартизированный в RFC 8446, — это протокол, лежащий в основе каждого HTTPS-соединения. Он согласовывает сеансовый ключ с использованием ECDHE и кривых вроде X25519, аутентифицирует сервер через сертификат X.509 и оборачивает HTTP-трафик в AES-128-GCM или ChaCha20-Poly1305. Это отличная защита от атакующего в кофейном Wi-Fi или интернет-провайдера, пытающегося читать ваши запросы.
Что TLS не делает: он завершается на балансировщике нагрузки. Когда вы загружаете видео в 3 ГБ на типичный сервис файлового обмена, TLS расшифровывает его на краю, затем открытый файл попадает в S3-бакет, конвейер транскодирования, возможно задание ML по сканированию контента, и наконец в поток скачивания получателя, который снова шифруется новым сеансом TLS. Сервис имеет полный доступ для чтения на каждом этапе.
Где начинается и заканчивается сквозное шифрование
Настоящий E2EE перемещает границу шифрования с сервера на конечные точки. В браузере или клиенте отправителя в памяти генерируется симметричный ключ (обычно AES-256-GCM). Файл шифруется поблочно до того, как хотя бы один байт покидает устройство. Шифротекст загружается по TLS на сервер, который хранит непрозрачные блобы. Получатель получает ключ дешифрования по отдельному каналу — чаще всего в виде фрагмента URL после символа #, который браузеры никогда не передают на серверы.
В этой модели сервер — тупой слой хранения. Даже полная судебная повестка, злоумышленник-сотрудник с доступом к базе данных или облачный провайдер, читающий снимки дисков, получат только зашифрованные байты. Именно такая архитектура используется в HexaTransfer: AES-256-GCM с ключом на каждую передачу, выведенным на стороне клиента и никогда не переданным на сервер.
Сравнение: только TLS vs сквозное шифрование
| Свойство | Только TLS | E2EE | |---|---|---| | Шифр в пути | AES-128/256-GCM | AES-256-GCM (плюс TLS) | | Сервер видит открытый текст | Да | Нет | | Расположение ключа | Управляется сервером | Устройство отправителя | | Защита от судебной повестки | Никакой | Высокая | | Сканирование контента провайдером | Возможно | Невозможно | | Восстановление при потере ключа | Провайдер может помочь | Данные не восстановить | | Типичные сервисы | Google Drive, Dropbox | HexaTransfer, SwissTransfer E2EE |
Как в реальности происходит обмен ключами
Сложность E2EE — не в шифре: AES надёжен уже 25 лет. Сложность — в доставке ключа от отправителя к получателю без того, чтобы сервер его увидел. Сервисы передачи файлов обычно используют одну из трёх схем.
Первая — трюк с фрагментом URL: ссылка выглядит как https://hexatransfer.com/d/abc123#key=xyz, где всё после # остаётся в браузере. JavaScript читает его локально и дешифрует. Вторая — шифрование на основе пароля: отправитель выбирает парольную фразу, прогоняет её через PBKDF2 (RFC 8018) или Argon2id с 600 000+ итерациями и передаёт пароль вне полосы по Signal или по телефону. Третья — обмен открытым ключом с использованием библиотек вроде crypto_box libsodium, где получатель публикует открытый ключ X25519.
Когда одного TLS достаточно
Не каждый файл требует E2EE. Если вы делитесь пресс-релизом с журналистом, мемом в групповом чате или публичным маркетинговым PDF, TLS-сервисы вполне достаточны. Данные изначально не были конфиденциальными, и прочтение их провайдером не создаёт никакого риска. Вы оптимизируете удобство — превью, миниатюры, редактирование в браузере — а эти функции принципиально требуют серверного доступа к открытому тексту.
Расчёт меняется для медицинских изображений (файлы DICOM, регулируемые HIPAA 45 CFR 164.312(a)(2)(iv)), финансовых отчётов по PCI DSS 4.0 Требование 3.5.1, материалов раскрытия по запросу суда, документов о сделках M&A или всего, что содержит персональные данные граждан ЕС по GDPR статья 32. Здесь «провайдер технически может это прочитать» — это проблема соответствия требованиям, а не просто эстетика конфиденциальности.
Пробел в метаданных, о котором никто не говорит
Даже при идеальном E2EE сервер всё равно видит метаданные: временну́ю метку загрузки, размер файла, IP-адреса отправителя и получателя, строки user-agent, продолжительность передачи. Если ваша модель угроз включает анализ трафика — например, журналист, общающийся с источником, — это имеет значение. Файл в 147 МБ, загруженный в 3:14 ночи из офиса Reuters на номер Signal в Стамбуле, рассказывает историю, даже если содержимое является шифротекстом.
Хорошие E2EE-сервисы минимизируют хранение метаданных. Ищите короткие окна хранения журналов (7 дней или меньше), отсутствие обязательных аккаунтов для базовых передач, отсутствие сторонней аналитики на страницах передачи и в идеале политику, дружественную к onion-маршрутизации или VPN. Набор шифров имеет значение меньше, чем операционная гигиена вокруг него.
Проверка заявления
«Сквозное шифрование» — маркетинговый текст, пока вы не сможете это доказать. Три теста отделяют реальный E2EE от игры слов. Во-первых, откройте DevTools и наблюдайте за вкладкой сети во время загрузки — если тело файла отправляется как открытый текст multipart/form-data, вы наблюдаете только TLS. Во-вторых, проверьте, содержит ли URL скачивания фрагмент (#). Нет фрагмента — нет клиентского ключа. В-третьих, прочитайте политику сервиса в отношении судебных запросов: если они могут предоставить содержимое файлов правоохранительным органам, файлы не являются E2EE-шифрованными. Сервисы, публикующие канареечные заявления и открывающие свой криптографический код (репозитории GitHub с использованием WebCrypto API), дают наиболее весомые гарантии.
Для повседневной отправки больших файлов, где конфиденциальность имеет значение, выбирайте сервис, явно заявляющий о своей модели. Попробуйте на hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.
Безопасная отправка больших файлов со сквозным шифрованием
Передавайте файлы до 10 ГБ бесплатно со сквозным шифрованием. Регистрация не требуется. Ваши файлы шифруются в браузере перед загрузкой — никто другой не может их прочитать.
Отправить файл