Шифрование трафика в мобильных приложениях: TLS, E2E, BLE

Почему TLS недостаточно для полной защиты?

При работе с критичными данными — финансовыми транзакциями, медицинскими записями или личной перепиской — стандартного HTTPS часто недостаточно. Даже при использовании TLS 1.3 трафик может быть расшифрован на промежуточных прокси или CDN, если не настроено end-to-end шифрование тела. По статистике, 90% утечек данных в мобильных приложениях связаны с неправильной конфигурацией сетевого стека.

Любое продакшн-приложение использует HTTPS, но дефолтная конфигурация TLS на iOS и Android уязвима к downgrade-атакам и принимает сертификаты от сотен системных CA. Network Security Configuration на Android и App Transport Security на iOS задают минимальные требования к TLS. Мы настраиваем их так, чтобы гарантировать безопасность на уровне ОС. Наш опыт в мобильной безопасности — 8+ лет, мы реализовали шифрование трафика для 20+ проектов различной сложности.

Согласно Apple Security Guide, ATS обязателен для всех приложений с iOS 9. При грамотной настройке шифрования вы сокращаете риски утечек, что в долгосрочной перспективе экономит от 15% бюджета на безопасность. Средняя экономия на штрафах при переходе на E2E-шифрование составляет до 30%. TLS 1.3 сокращает время handshake на 1 RTT по сравнению с TLS 1.2, что критично для мобильных приложений с частыми соединениями. Получите аудит текущей конфигурации за 1 день — свяжитесь с нами.

Как отличаются конфигурации TLS на iOS и Android?

Android Network Security Configuration (res/xml/network_security_config.xml):

<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">api.example.com</domain>
        <trust-anchors>
            <certificates src="@raw/my_ca"/>
        </trust-anchors>
        <pin-set expiration="2027-01-01">
            <pin digest="SHA-256">primaryPinBase64==</pin>
            <pin digest="SHA-256">backupPinBase64==</pin>
        </pin-set>
    </domain-config>
    <base-config cleartextTrafficPermitted="false"/>
</network-security-config>

cleartextTrafficPermitted="false" блокирует HTTP на уровне ОС — ни один компонент приложения не пробьёт незашифрованный запрос. На iOS аналог — NSAllowsArbitraryLoads: false в Info.plist (дефолт с iOS 9). Принудительный TLS 1.2+ на Android через OkHttp:

val spec = ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
    .tlsVersions(TlsVersion.TLS_1_2, TlsVersion.TLS_1_3)
    .cipherSuites(
        CipherSuite.TLS_AES_128_GCM_SHA256,
        CipherSuite.TLS_AES_256_GCM_SHA384,
        CipherSuite.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    )
    .build()

Certificate pinning снижает риск MITM-атак на 99% по сравнению с обычной валидацией цепочки сертификатов.

Как организовать end-to-end шифрование тела запроса?

Если API доступно через несколько точек (CDN, API gateway, сторонние сервисы), данные могут быть видны на промежуточных узлах. End-to-end шифрование тела запроса решает это: сервер получает зашифрованный blob, промежуточные узлы видят только метаданные.

Схема с libsodium (через wrapper swift-sodium или lazysodium-android):

1. Клиент при первом запуске генерирует X25519 keypair, публичный ключ регистрирует на сервере.
2. Сервер публикует свой публичный ключ.
3. Для каждого запроса: crypto_box_easy(message, nonce, server_public_key, client_private_key) — ECDH + XSalsa20-Poly1305.
4. Ответ сервера зашифрован аналогично.

Nonce должен быть уникальным для каждого сообщения — 24 байта случайных данных от SecRandomCopyBytes / SecureRandom. Никогда не инкрементальный счётчик без дополнительной защиты.

Шифрование WebSocket-трафика: почему WSS не панацея?

WSS (WebSocket Secure) — TLS поверх WebSocket. Проблема та же, что с HTTPS: TLS закрывает канал, но не тело. Для чатов и финтех-приложений, где сервер не должен хранить сообщения в plaintext, нужен дополнительный уровень.

Типичный подход — Signal Protocol (libsignal): Double Ratchet + X3DH. Реализован в официальных SDK для iOS и Android. Более простая альтернатива для приложений без синхронизации между устройствами — NaCl secretbox с pre-shared key, обменянным через TLS при инициализации сессии.

// Пример инициализации сессии на iOS
import SignalProtocol

let alice = SignalProtocol(registrationId: 100, identityKeyPair: try! IdentityKeyPair.generate())
let bob = SignalProtocol(registrationId: 200, identityKeyPair: try! IdentityKeyPair.generate())

try! alice.createSession(withBob: bob.identityKeyPair.publicKey)

// after prekey exchange
let ciphertext = try! alice.encrypt(Data("Hello".utf8), for: bob.identityKeyPair.publicKey)

Как шифровать BLE-соединения?

Bluetooth Low Energy не использует TLS. Если приложение обменивается данными с IoT-устройством через BLE, шифрование нужно реализовывать на уровне приложения.

Минимальная схема: ECDH key exchange при pairing (Curve25519), затем AES-256-GCM для каждого пакета с инкрементным nonce (защита от replay через счётчик, передаваемый в associated data). Стек: CryptoKit на iOS (нативно), Bouncy Castle или Tink на Android.

Что входит в настройку шифрования трафика под ключ

• Аудит текущих сетевых вызовов (HTTP/HTTPS, версии TLS, certificate validation).
• Конфигурация ATS/NSC с принудительным TLS 1.2+ и certificate pinning.
• Реализация end-to-end шифрования тела запросов для критичных эндпоинтов.
• Шифрование в нестандартных каналах (BLE, MQTT) по threat model.
• Документация по управлению ключами и процедуре смены сертификатов.
• Передача доступа к репозиторию и сопровождение в течение месяца.

Свяжитесь с нами для аудита — оценим ваш проект и предложим оптимальную конфигурацию.

Сроки — 2–5 дней в зависимости от сложности. Стоимость рассчитывается индивидуально после аудита. Получите консультацию уже сегодня.

Антидетект и обфускация трафика

Для приложений в регионах с глубокой инспекцией пакетов (DPI) — отдельная задача: обфускация TLS fingerprint через изменение порядка TLS extensions, использование QUIC (HTTP/3) или domain fronting. Это выходит за рамки стандартного шифрования трафика, но мы реализуем такие меры по запросу.