# Module #7

## HTTPS

Расширение протокола HTTP. Позволяет добавлять дополнительный уровень безопасности в виде шифрования. До 2015 года в качестве основной прослойки использовался механизм SSL.

Начиная с 2015 предпочтительна прослойка - механизм TLS.

Протокол ничем не отличается от оригинала, который являлся до 2 версии текстовым протоколом.

Основные атаки на HTTPS:

- SideChannel атаки, которые основываются на характеристиках передаваемых данных;
- MiTM атаки, которые направлены на прослушивание канала и модификацию содержимого.

С точки зрения реализации шифрования используется openSSL библиотека.

* Детальный разбор протоколов SSL / TLS и их работы

Общая схема взаимодействия:


Более подробно можно рассмотреть на примере:

openssl s_client -connect yandex.ru:443

## TLS/SSL

Протоколы TLS/SSL работают на основе "ассиметричной" криптографии. Чтобы проще было делиться информацией о ключах используются сертификаты.

Сертификат - набор данных, который может помочь участникам индентифицировать оппонента и одновременно механизм для начала взаимодействия и обмена ключами. Как правило открытыми.

Стоит понимать, что ассиметричная криптография используется только для того чтобы обменяться ключами. Остальные данные шифруются за счет использования симметричных алгоритмов.

Сертификат может быть получен на первых этапах взаимодействия, однако, чтобы он мог действительно быть доверенным, нужно чтобы независимая сторона могла подтвердить уникальность участника взаимодействия.

Сертификаты могут выпускаться для доменов, но в таком случае может возникнуть проблема - владелей домена может не знать о том, что кто-то создал сертификат. Чтобы этого не происходило, существует `Certificate Transparency`.

Все данные по выпущенным сертификатам могут быть записаны в специальный лог, который доступен для обозрения всем.

`Perfect Forward Secrecy` - механизм, который позволяет генерировать уникальный ключ для каждой сессии взаимодействия по сети. При условии использования механизма, даже если злоумышленник получит доступ к приватному ключу, то он не сможет ничего расшифровать.

Протоколы, которые могут использовать PFS:

- IPSec - опционально
- SSH - обязательно
- до TLS 1.3 опционально, после обязательно

## HTTPS/TLS в iOS

Начиная с iOS 12.0 предоставляет Network framework и класс URLSession, которые предоставляют функции для синхронной и асинхронной загрузки данных. Более старые версии iOS могут использовать Sockets API. Интересная особенность iOS - существование доступа к Legacy коду, который не рекомендуется для использования. Пример: NSURLConnection.

- Network Framework:

- Фреймворк был представлен в 2018 году. По-умолчанию использует TLS 1.3.

- URLSession:

`URLSession` - построен поверх Network framework. Использование TLS 1.3 по-умолчанию, если сервер работает через HTTPS.

`URLSession` - предпочтительный механизм для взаимодействие по HTTP, HTTPS протоколу. Класс работает со схемами и предоставляет уже готовые сниппеты.

## ATS

App Transport Security - набор проверок ОС, которые включаются при взаимодействии по сети. При этом взаимодействие может осуществляться через:

- NSURLConnection
- NSURLSession
- CFURL

ATS работает по-умолчанию для приложений, которые собираются с использованием iOS SDK 9 версии и выше.

ATS применяется только если осуществляется взаимодействие с публичными серверами. Все соединения, которые осуществляются через IP адреса, имена с суффиксом .local не защищаются ATS.

Обобщенный список правил для безопасного взаимодействия:

- Никаких HTTP соединений
- X.509 сертификат должен использовать SHA256 fingerprint и должен быть подписан как минимум 2048-bit RSA ключом или 256-bit Elliptic-Curve Cryptography (ECC) ключом.
- Transport Layer Security (TLS) версия должна быть минимально 1.2 или выше. При этом выше версии обязаны поддерживать Perfect Forward Secrecy (PFS) через Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) алгоритм обмена ключами и AES-128 или AES-256 алгоритмы шифрования.

В качестве алгоритмов шифрования должны использоваться:

- `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`
- `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`
- `TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384`
- `TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA`
- `TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256`
- `TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA`
- `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`
- `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`
- `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384`
- `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256`
- `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA`

## ATS Исключения

Настраиваются через специально сгенерированный Info.plist, который должен содержать `NSAppTransportSecurity` ключ. Исключения могут быть применены:

- использование HTTP
- минимальная версия TLS
- отключение PFS
- допуск потключения к локальным адресам или доменам

Тонкое место использования исключений - возможность применять исключения глобально или для отдельных доменов.

Список исключений, которые могут быть использованы глобально:

| Key | Description |
| -----| ------------|
| `NSAllowsArbitraryLoads` | Отключить ATS ограничения глобально, за исключением доменов, которые указаны в ключе `NSExceptionDomains` |
| `NSAllowsArbitraryLoadsInWebContent` | Отключить ATS ограничения для подключений через web view |
| `NSAllowsLocalNetworking` | Позволить подключаться к локальным адресам и .local доменам |
| `NSAllowsArbitraryLoadsForMedia` | Отключить все ограничения ATS для загружаемого медиа через AV Foundations framework |

Список исключений для конкретных доменов:

| Key | Description |
| -----| ------------|
| `NSIncludesSubdomains` | позволяет установить применяются ли ATS исключения для поддоменов |
| `NSExceptionAllowsInsecureHTTPLoads` | Позволяет использовать HTTP к домену, но при этом не изменяет требования в TLS глобально |
| `NSExceptionMinimumTLSVersion` | Позволяет взаимодействовать с серверами, которые поддерживают версии TLS ниже чем 1.2 |
| `NSExceptionRequiresForwardSecrecy` | Отключение PFS |

Начиная с 1.01.2017 App Store ревью требует обоснования для исключений:

- `NSAllowsArbitraryLoads`
- `NSAllowsArbitraryLoadsForMedia`
- `NSAllowsArbitraryLoadsInWebContent`
- `NSExceptionAllowsInsecureHTTPLoads`
- `NSExceptionMinimumTLSVersion`

## Что еще важно

Взаимодействие по HTTPS несмотря на все настройки все равно может быть под угрозой. При использовании приложения на jailbreak устройствах, злоумышленник может расшифровать любое взаимодействие.

Для предотвращения расшифровки можно использовать SSL Pinning.

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

Существую недостатки SLL Pinning:

- необходимость поддерживать сертификат в актуальном состоянии
- правильность проверки сертификата влияет на доступность сервиса

## URLCache

Считается одним из способов небезопасного хранения данных. Что интересно для нас?

NSURLSession хранит данные по запросам/ответам HTTP в Cache.db базе. Эта база может содержать конфиденциальную информацию:

- токены
- имена пользователей

Кэш можно найти здесь: `/var/mobile/Containers/Data/Application/<UUID> -> /Library/Caches/<Bundle Identifier>.`

Кэш от WebKit так же попадает в базу Cache.db это просто SQLite база.

Отключить кэширование можно, например через Cache Policy, если поставить значение на .notAllowed. Это отключит хранение кэша впринципе.

## Практика

1. Протестировать сетевое взаимодействие приложения
2. Обойти SSL Pinnig с помощью инструментов динамической инструментации
3. Настроить проксирование трафика