Хотя я и согласен с @mdeora, я пытаюсь объяснить (долгий путь), что происходит за кулисами, простыми словами, и надеюсь, что это поможет.
Давайте сначала определим несколько терминов
Клиент ("C"): мобильное приложение, которое использует библиотеку SSL / TLS. Также Клиент может быть настроен на распознавание сертификатов, подписанных внутренним Удостоверяющим Центром (CA).
Сервер ("S"): целевой сервер, который обслуживает запрос
Прокси («P») или Прозрачный прокси («TP»): который перехватывает запрос SSL и создает иллюзию для Клиента, что он действительно является целевым сервером, отправляя сертификат от имени «S», но подписан внутренним сертификатом CA, созданным прокси-сервером. Например. Burp Suite, кальмар
DNS-серверы: служба, которая разрешает имя в IP-адрес
Клиентские DNS-серверы: один или несколько IP-адресов DNS-сервера, настроенных на мобильном устройстве, либо из-за явной конфигурации, либо предоставленных сетевым подключением, когда мобильное устройство подключается к сети (телеком или Wi-Fi)
Прокси-DNS-серверы: один или несколько IP-адресов DNS-серверов, настроенных на том же компьютере, на котором настроена прокси-служба
Случай А. Когда между Клиентом и Сервером нет ни прокси, ни прозрачного прокси
- «C» находит IP-адрес (скажем, «IP-S») «S», запрашивая клиентский DNS-сервер.
- «C» использует SSL / TLS для подключения к «IP-S» и завершает связь. Вся связь зашифрована.
В этом случае Burp Suite / Wireshark не видит текстовый трафик.
Случай B. Когда мобильный настроен на использование прокси-сервера "P"
- «C» находит IP-адрес «P», запрашивая клиентский DNS-сервер, например «IP-P».
- «C» подключается к «IP-P» по протоколу HTTP или HTTPS.
- Если «C» подключается к «P» по протоколу HTTP, «P» перехватывает запрос, проверяет URL-адрес и получает имя домена.
- Если «C» подключается к «P» по протоколу HTTPS, «P» будет понимать имя целевого сервера как часть рукопожатия SSL / TLS через SNI - расширение для
SSL / TLS. (https://en.wikipedia.org/wiki/Server_Name_Indication)
- «P» будет использовать прокси-сервер DNS для получения IP (скажем, «IP-S») для «S». «P» подключится к «IP-S».
- В нормальном случае «P» (или «TP») будет передавать побайтный запрос от «C» к «S» и ответ от «S» к «C». «C» всегда получит настоящий сертификат «S», а «P» / «TP» не будет знать ничего, кроме того факта, что «C» связывается с «S».
- Однако, в случае перехватчиков (например, BurpSuite), «P» (или «TP») представит сертификат, подписанный внутренним CA, выдавая себя за «S». Если «C» настроен на распознавание сертификатов, подписанных внутренним CA, библиотека SSL в «C» будет вынуждена предположить, что она действительно взаимодействует с «S».
Без закрепления SSL «C» будет взаимодействовать с «P» (или «TP»), как если бы это было «S». «P» расшифрует трафик и установит соединение с «S», повторно зашифрует трафик и отправит его на «S». Таким же образом, «P» получит ответ от «S» и отправит его обратно в «C». «C» и «S», оба, не будут знать о том факте, что «P» перехватил (и, возможно, изменил) трафик.
С закреплением SSL (https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Pinning_Cheat_Sheet.md), «C» не будет работать, если обнаружит, что сертификат, представленный «P» / «TP», не соответствует реальному сертификату «S».
Случай C. Когда мобильное устройство использует сеть с прозрачным прокси-сервером («TP»)
Здесь «C» пытается подключиться к «S», как в случае A, но «TP», присутствующий в сети, перехватывает трафик точно так же, как «P», а остальные следуют, как и в случае B (4).
Подводя итог, можно сказать, что при использовании закрепления SSL «C» будет связываться с «S», только если полагает, что он связывается по безопасному каналу с реальным «S», а не с прокси.