Что такое безопасность соединения или включите SSL-pinning в вашем мобильном приложении прямо сейчас

В этой статье я кратко расскажу, что означает «безопасное соединение» между клиентом и сервером, что такое SSL-pinning, для чего он нужен и когда его использовать. Так же объясню от каких угроз мы защищаемся с его помощью.

Представим, что у нас есть сайт или мобильное приложение (оба подпадают под определение клиента). При обращении сайта или мобильного приложения к бекенду (сервер) безопасность соединения обеспечивается с помощью протокола SSL (Secure Socket Layer), а если быть точнее, TLS (Transport Layer Security). TLS ставит своей целью создание между двумя узлами сети защищённого от прослушивания и подмены информации канала связи, а также проверку того, что обмен данными происходит между именно теми узлами, т.е. обеспечение конфиденциальности, целостности и аутентификации. Под узлами можно понимать сервер и мобильное приложение, либо сервер и веб-браузер.

Изначально SSL был разработан компанией Netscape для своего одноименного браузера в середине 90-х. Позднее на основании SSL 3.0 был принят RFC-стандарт TLS 1.0. Рекомендованными для применения в 2019 году являются версии TLS не ниже 1.2 (актуальная версия на сегодня — 1.3). На странице в википедии можно посмотреть поддержку версии TLS у всех популярных браузеров.

MITM (Man in the middle) — данный вид атаки направлен на «прослушку» или изменение трафика между двумя узлами (клиентом и сервером). В случае использования незащищенного HTTP это не составляет труда, тогда как в случае HTTPS (HTTP + SSL, или HTTP secure) данные зашифрованы и обычный просмотр пакетов трафика не даст никакой полезной информации злоумышленникам об их содержании. О том, каким образом шифруются данные, поговорим дальше.

Симметричное шифрование — вид шифрования, при котором для шифрования и дешифрования будет использоваться один и тот же ключ. Наиболее стойким на данный момент является шифр AES (Advanced Encryption Standard), длина ключа может быть 128, 192 или 256 бит. Из минусов симметричного шифрования — проблема передача ключа, ведь в случае его утери, им может воспользоваться злоумышленник. В случае TLS используется ассиметричное шифрование — когда для шифрования используется публичный ключ, а для дешифрования приватный. Публичный ключ передаётся от узла 1 к узлу 2, и даже в случае его перехвата злоумышленником, содержимое данных невозможно расшифровать, т.к. закрытый ключ не передается между узлами. Наиболее распространённый шифр этого типа — RSA (Rivest—Shamir—Adleman), размер ключа от 1024 до 4096 бит. Удобство ассиметричных шифров так же в том, что публичный ключ может быть передан большому количеству узлов без угрозы его утечки, как в случае ключа симметричного шифра. Из минусов — асимметричные шифры значительно медленнее симметричных. Поэтому в TLS используется смешанный подход — все данные шифруются симметрично, а набор ключей асимметрично. Но так как узлы шлют информацию в обе стороны, необходимо шифровать трафик с двух сторон. На помощь приходит протокол Диффи-Хеллмана. Первые 2 минуты видео достаточно понятно объясняют принцип его работы. Если мы хотим защитить соединение по HTTP, здесь стоит подумать о SSL-сертификате.

В качестве удостоверяющего хост документа выступает сертификат стандарта X.509. Под сертификатом можно понимать файл, в котором содержится следующая информация:

• Название
• Публичный ключ
  
• Серийный номер
  
• Алгоритм сертификата
  
• Цифровая подпись и др.
  

Сертификаты не существую сами по себе — их выпускают центры сертификации (Certificate Authority), в цепочке сертификатов самым первым является сертификат CA, его еще называют корневой. CA являются общеизвестными и ключи, которые они выпускают являются доверенными по умолчанию. Корневые сертификаты как правило “зашиваются” в операционную систему и обновляются при следующих обновлениях. Сертификаты выстраиваются в цепочку, можно так же назвать термин дерево: сертификаты первого уровня (выпущенные CA), так же могут выпускать сертификаты следующих уровней. В случае компрометации сертификата, он может быть отозван, и тогда автоматически отзываются все дочерние сертификаты.

Кажется, что TLS решает атаку MITM. Тем не менее, возможен вариант, когда между узлами окажется самоподписанный корневой сертификат злоумышленника и каким-то образом этот сертификат попадёт к нам на устройство. Например, если пользователь недостаточно технически образован и ему предлагается установить сертификат для пользования сетью Wi-Fi. После этого данные шифруются сертификатом злоумышленника (которые он легко расшифровывает) и мы не подозреваем о подмене. В данном случае злоумышленник выступает неким прокси-сервером между нашими узлами.

Если мы реализуем проверку сертификата на клиенте, то можем отловить ситуацию, когда сертификат между узлами неподлинный. Технически это выглядит следующим образом: при установлении соединения с хостом на клиенте проверяется, соответствует ли сертификат от сервера тому сертификату, о котором знает клиент. Если нет — соединение считается небезопасным и обмен данных с хостом прекращается. Помимо прослушивания трафика, SSL-pinning так же не раскрывает спецификацию запросов API, что может пригодиться при атаках как на сервер, так и на клиент.

По тому, какой сертификат проверяем:

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

По тому, какие данные из сертификата проверяем:

• Фингерпринт. Это хэш от данных сертификата (можно выбрать, например из SHA-1, SHA-256). Фингерпринт видно в окне браузера при просмотре сертификата. Подход достаточно прост в реализации и обычно в SDK уже есть API по вычислению фингерпринта сертификата. Но к минусам такого подхода могу отнести то, что при истечении сертификата прежний фингерпринт становится невалидным, и его необходимо обновить на клиенте. Невалидным он становится, т.к. у нового сертификата как минимум будет новый приватный ключ.
• Публичный ключ. Данный вид лишён недостатка о перевыпуске сертификата, т.к. если в вашем распоряжении имеется прежний сертификат (пара публичный-приватный ключ), то вы сможете выпустить новый сертификат с тем же публичным ключом даже у другого CA. После истечения текущего не придётся обновлять информацию на клиенте. К недостаткам можно отнести, во-первых, что публичный ключ извлекается чуть сложнее, чем фингерпринт, и во-вторых, сам по себе факт того, что ключ не будет меняется долгое время.

• Хосты сторонних сервисов — сертификат может измениться без нашего ведома. Например, Google-аналитика.
• Нет чувствительных данных — нет никакой угрозы, что данные будут получены третьей стороной. Например, любые открытые сервисы (текущее время, погода).

Раз уж мы обсудили SSL-pinning в контексте мобильных приложений, почему бы не сделать тоже самое с веб-сайтами? Ответ достаточно прост — браузер посещает большое количество сайтов, ровно как и каждый день появляется много новых, и это достаточно проблематично обладать информацией обо всех них. Мобильное приложение же, как правило, обращается к конечному числу доменов, информация о сертификатах хранится внутри него. В 99% случаев не нужно придумывать свои способы шифрования, TLS + SSL-pinning обеспечивают достаточный высокий уровень безопасности для передачи чувствительных данных по сети. Примеры приложений, где SSL-pinning является по-моему мнению обязательным — это мобильные приложения банков, другие приложения из финансового и страхового сектора. Для более подробного погружения в схему работы TLS советую данный ресурс.