Шифрування трафіку в мобільних застосунках: 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. Це виходить за рамки стандартного шифрування трафіку, але ми реалізуємо такі заходи на запит.