Почему 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()
| Параметр | Android (OkHttp) | iOS (URLSession) |
|---|---|---|
| Минимальная версия TLS | 1.2 (через ConnectionSpec) | 1.2 (NSAppTransportSecurity) |
| Certificate pinning | OkHttp: CertificatePinner | NSURLSession: URLSessionDelegate (didReceive challenge) |
| Блокировка HTTP | network_security_config cleartextTrafficPermitted=false | NSAllowsArbitraryLoads=false, NSExceptionDomains |
| Cipher suites | Список белых (TLS_AES_128_GCM_SHA256 и др.) | По умолчанию безопасные, можно ограничить через ATS |
Certificate pinning снижает риск MITM-атак на 99% по сравнению с обычной валидацией цепочки сертификатов.
Как организовать end-to-end шифрование тела запроса?
Если API доступно через несколько точек (CDN, API gateway, сторонние сервисы), данные могут быть видны на промежуточных узлах. End-to-end шифрование тела запроса решает это: сервер получает зашифрованный blob, промежуточные узлы видят только метаданные.
Схема с libsodium (через wrapper swift-sodium или lazysodium-android):
- Клиент при первом запуске генерирует X25519 keypair, публичный ключ регистрирует на сервере.
- Сервер публикует свой публичный ключ.
- Для каждого запроса:
crypto_box_easy(message, nonce, server_public_key, client_private_key)— ECDH + XSalsa20-Poly1305. - Ответ сервера зашифрован аналогично.
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 при инициализации сессии.
Подробнее о реализации Signal Protocol
// Пример инициализации сессии на 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.
- Документация по управлению ключами и процедуре смены сертификатов.
- Передача доступа к репозиторию и сопровождение в течение месяца.
Свяжитесь с нами для аудита — оценим ваш проект и предложим оптимальную конфигурацию.
| Этап | Описание | Длительность |
|---|---|---|
| Аудит | Анализ текущих сетевых вызовов, TLS-конфигураций, certificate validation | 1 день |
| Проектирование | Выбор алгоритмов шифрования, схемы ключей, threat model | 1 день |
| Реализация | Настройка ATS/NSC, certificate pinning, E2E-шифрование тела запросов | 2–3 дня |
| Тестирование | MITM-симуляция, проверка утечек, нагрузочное тестирование | 1 день |
| Деплой | Выкладка в сторы, мониторинг, передача документации | 0.5 дня |
Сроки — 2–5 дней в зависимости от сложности. Стоимость рассчитывается индивидуально после аудита. Получите консультацию уже сегодня.
Антидетект и обфускация трафика
Для приложений в регионах с глубокой инспекцией пакетов (DPI) — отдельная задача: обфускация TLS fingerprint через изменение порядка TLS extensions, использование QUIC (HTTP/3) или domain fronting. Это выходит за рамки стандартного шифрования трафика, но мы реализуем такие меры по запросу.