Авторизация  
TEXHO

Принцип Доверия (Trust) в HTTPS.

В теме 1 сообщение

Сейчас уже, наверное, больше половины серверов перебрались с http на https протокол. Зачем? Ну, это мол круто, секъюрно.

 

В чем же заключается эта секъюрность? На эту тему уже написана куча статей, в том числе и на Хабре. Но я бы хотел добавить еще одну.

 

Почему решил написать

 

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

 

Я начал рыться в разных источниках, и оказалось, что в этой теме не так просто разобраться, и тут недостаточно просто прочитать пару статей на Хабре или Вики, при чем я нигде не встретил абсолютно исчерпывающего и понятного источника, чтобы сослаться и сказать — "Вот это Библия". Поэтому у меня это "немного разобраться" заняло кучу времени. Так вот, разобравшись, я решил поделиться этим, и написать статью для таких же новичков, как и я, или просто для людей, которым интересно зачем в строке URL иногда стоит https, а не http.

 

Что значить защищенный канал связи?

 

Чтобы канал передачи данных считался защищенным, должны выполняться 3 основные принципа:

 

Доверие (Trust) — взаимная аутентификацию абонентов при установлении соединения.

Шифрование (Crypting) — защита передаваемых по каналу сообщений от несанкционированного доступа. То есть, говорить и слушать во время диалога можете только вы и ваш собеседник.

Обеспечение целостности — подтверждение целостности поступающих по каналу сообщений, т.е. сообщения не могут подвергаться полной или частичной замене информации.

 

В этой статье я хотел бы рассказать подробно только о механизме Доверия.

 

Что значить Доверие (Trust)?

 

Вы можете доверять вашему собеседнику только если точно знаете, что он — тот, за кого себя выдает.

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

 

Жизненный пример

 

Представим, Вы хотите купить квартиру.

Для этого Вы находите Риэлтора, который занимается продажей квартир.

Риэлтор говорит, что он работает с неким Застройщиком, и предлагает квартиру от этого Застройщика.

Застройщик говорит, что жилье, которое он строит будет, сдано, и те кто заплатил за него деньги Риэлтору, получит его в собственность, и легальность строительства и право собственности будет обеспечена Государством.

Итого у нас есть 4 субъекта Вы, Риэлтор, Застройщик, Государство.

Для того чтобы сделка успешно состоялась и никто никого не обманул Государство создало законы, определяющие документы, которые гарантируют легальность сделок, и механизм печати или подписи, который гарантирует подлинность этих документов.

 

У Вас есть примеры этих документов и печатей, вы можете их взять у Государства.

Вы имеете право требовать у Риэлтора оригиналы документов на строительство.

Риэлтор берет документы Застройщика, которые подкреплены документами Государства и убеждается, что квартиры можно продавать — они легальны.

Застройщик же в свою очередь получает документы у Государства.

Т.е. теперь вы можете смело вести диалог только с Риэлтором, основываясь на его документах, скрепленных печатями Застройщика и Государства!

 

cbe2bc902d2440569d5398c858c51098.png

 

Доверие в HTTPS

 

А теперь поменяем имена действующих лиц из Жизненного примера.

Вы = Клиент (Client)

Риэлтор = Сервер (Server)

Застройщик = Промежуточный Центр Сертификации (Intermediate CA)

Государство = Главный Центр Сертификации (Root CA)

 

d32fc549936c48f8a2a12f156642e32b.png

 

Главный Центр Сертификации (Root Certificate Authority, CA) — общепризнанная известная компания, которой международные организации выдали полномочия заведовать сертификатами и подписями, короче этой компании доверяют все.

 

Она может давать некоторые полномочия Промежуточным центрам Сертификации (Intermediate CA), и они будут подписывать документы от имени Главного Центра.

 

Перейдем к математике

 

Были упомянуты слова: подпись, сертификат и т.д. Как это реализовать? В помощь приходит асимметричное шифрование.

 

Чтобы не вдаваться в подробности и не объяснять дискретную математику и криптографию, уясним пару вещей:

 

1) Коротко и о главном об асимметричном шифровании.

Есть 2 ключа — Публичный и Приватный (Public Key and Private Key). Собственно, ключи — это просто большие числа.

Если сообщение шифруется Публичным, то его может расшифровать только соответствующий ему Приватный ключ.

И наоборот:

Если сообщение шифруется Приватным, то его может расшифровать только соответствующий ему Публичный ключ.

Приватный ключ никому не дается, Публичный — собственно, публичный.

 

2) Цифровая подпись (Digital Signature) — это часть документа, зашифрованная Приватным ключем Подписчика (Issuer). Если ее можно расшифровать Публичным Ключем Подписчика, то можно с уверенностью утверждать, что именно Подписчик ее шифровал.

 

3) Сертификат (Digital Certificate) — это обычно файл, чаще всего с расширением .cer или .pem.

В нем содержится:

 

Информация о владельце (Subject)

Инфомация о Подписчике (Issuer)

Информация о подписи (Версия SSL, алгоритм)

Хэш подписи (Certificate Fingerprints)

Public Key

Цифровая подпись (Signature)

Срок годности (Expires)

И еще много информации, в зависимости от версии, но остальное нам пока не нужно.

 

 

[+] Пример Сертификата

Code:
COMODO Certification AuthorityIdentity: COMODO Certification AuthorityVerified by: COMODO Certification AuthorityExpires: 31.12.29Subject NameC (Country): GBST (State): Greater ManchesterL (Locality): SalfordO (Organization): COMODO CA LimitedCN (Common Name): COMODO Certification AuthorityIssuer NameC (Country): GBST (State): Greater ManchesterL (Locality): SalfordO (Organization): COMODO CA LimitedCN (Common Name): COMODO Certification AuthorityIssued CertificateVersion: 3Serial Number: 4E 81 2D 8A 82 65 E0 0B 02 EE 3E 35 02 46 E5 3DNot Valid Before: 2006-12-01Not Valid After: 2029-12-31Certificate FingerprintsSHA1: 66 31 BF 9E F7 4F 9E B6 C9 D5 A6 0C BA 6A BE D1 F7 BD EF 7BMD5: 5C 48 DC F7 42 72 EC 56 94 6D 1C CC 71 35 80 75Public Key InfoKey Algorithm: RSAKey Parameters: 05 00Key Size: 2048Key SHA1 Fingerprint: 11 E4 91 D1 C9 E4 C0 EB 9A CE CF 73 54 5D E1 F1 A8 30 3E C3Public Key: 30 82 01 0A 02 82 01 01 00 D0 40 8B 8B 72 E3 91 1B F7 51 C1 1B 54 04 98 D3 A9 BF C1 E6 8A 5D 3B 87 FB BB 88 CE 0D E3 2F 3F 06 96 F0 A2 29 50 99 AE DB 3B A1 57 B0 74 51 71 CD ED 42 91 4D 41 FE A9 C8 D8 6A 86 77 44 BB 59 66 97 50 5E B4 D4 2C 70 44 CF DA 37 95 42 69 3C 30 C4 71 B3 52 F0 21 4D A1 D8 BA 39 7C 1C 9E A3 24 9D F2 83 16 98 AA 16 7C 43 9B 15 5B B7 AE 34 91 FE D4 62 26 18 46 9A 3F EB C1 F9 F1 90 57 EB AC 7A 0D 8B DB 72 30 6A 66 D5 E0 46 A3 70 DC 68 D9 FF 04 48 89 77 DE B5 E9 FB 67 6D 41 E9 BC 39 BD 32 D9 62 02 F1 B1 A8 3D 6E 37 9C E2 2F E2 D3 A2 26 8B C6 B8 55 43 88 E1 23 3E A5 D2 24 39 6A 47 AB 00 D4 A1 B3 A9 25 FE 0D 3F A7 1D BA D3 51 C1 0B A4 DA AC 38 EF 55 50 24 05 65 46 93 34 4F 2D 8D AD C6 D4 21 19 D2 8E CA 05 61 71 07 73 47 E5 8A 19 12 BD 04 4D CE 4E 9C A5 48 AC BB 26 F7 02 03 01 00 01Subject Key IdentifierKey Identifier: 0B 58 E5 8B C6 4C 15 37 A4 40 A9 30 A9 21 BE 47 36 5A 56 FFCritical: NoKey UsageUsages: Digital signatureCritical: YesBasic ConstraintsCertificate Authority: YesMax Path Length: UnlimitedCritical: YesExtensionIdentifier: 2.5.29.31Value: 30 40 30 3E A0 3C A0 3A 86 38 68 74 74 70 3A 2F 2F 63 72 6C 2E 63 6F 6D 6F 64 6F 63 61 2E 63 6F 6D 2F 43 4F 4D 4F 44 4F 43 65 72 74 69 66 69 63 61 74 69 6F 6E 41 75 74 68 6F 72 69 74 79 2E 63 72 6CCritical: NoSignatureSignature Algorithm: SHA1 with RSASignature Parameters: 05 00Signature: 3E 98 9E 9B F6 1B E9 D7 39 B7 78 AE 1D 72 18 49 D3 87 E4 43 82 EB 3F C9 AA F5 A8 B5 EF 55 7C 21 52 65 F9 D5 0D E1 6C F4 3E 8C 93 73 91 2E 02 C4 4E 07 71 6F C0 8F 38 61 08 A8 1E 81 0A C0 2F 20 2F 41 8B 91 DC 48 45 BC F1 C6 DE BA 76 6B 33 C8 00 2D 31 46 4C ED E7 9D CF 88 94 FF 33 C0 56 E8 24 86 26 B8 D8 38 38 DF 2A 6B DD 12 CC C7 3F 47 17 4C A2 C2 06 96 09 D6 DB FE 3F 3C 46 41 DF 58 E2 56 0F 3C 3B C1 1C 93 35 D9 38 52 AC EE C8 EC 2E 30 4E 94 35 B4 24 1F 4B 78 69 DA F2 02 38 CC 95 52 93 F0 70 25 59 9C 20 67 C4 EE F9 8B 57 61 F4 92 76 7D 3F 84 8D 55 B7 E8 E5 AC D5 F1 F5 19 56 A6 5A FB 90 1C AF 93 EB E5 1C D4 67 97 5D 04 0E BE 0B 83 A6 17 83 B9 30 12 A0 C5 33 15 05 B9 0D FB C7 05 76 E3 D8 4A 8D FC 34 17 A3 C6 21 28 BE 30 45 31 1E C7 78 BE 58 61 38 AC 3B E2 01 65

 

Что же происходит на каждом из субъектов

 

1) Начнем с Root CA

 

Генерируется Private Key

Генерируется Public Key

Добавляется информация о CA, задается срок годности

Сертификат подписыватся своим же Приватным Ключем:

Выбирается сообщение для шифровки (Message). Что именно шифровать, определяет алгоритм и версия SSL. Для конечного пользователя это неважно, так как все версии шифрования и хэширования также помещаются в сертификат, и при расшифровке эти же версии и используются.

Message шифруется, и получается цифровая подпись

Message хэшируется, и получается FingerPrint.

Все это собирается в кучу и получается, так называемый, Самоподписанный сертификат (Self Signed Certificate).

 

2) Этот Self Signed Certificate раздается клиентам

 

Пример клиента — браузер. В любом браузере можно посмотреть список сертификатов.

Например в Chrome: Settings -> Manage Certificates -> Authorities.

Теперь клиент знает про существование CA.

 

3) Подтверждение своей аутентичности

 

Если не вдаваться в детали, то этот пункт одинаков для Сервера и Промежуточных Центров Аутентификации

 

Генерируется Private Key

Генерируется Public Key

Добавляется информация о CA, определяется срок годности

Формируется, так называемый, Запрос на Сертификацию (Certificate Signing Request, CSR)

CSR подписывается Приватным Ключем близжайшего по цепи Центра Сертификации. Собственно, так это и называется Certificate Chain, когда Центры Сертификации друг за другом подписывают следующий сертификат, вплоть до конечного — Сертификата Сервера.

 

В итоге, имеем Self Signed Certificate на клиенте и Signed Server Certificate на сервере, т.е. клиент знает и доверяет СА и СА прогарантировал аутентичность сервера.

 

4) Непосредственно диалог

 

Теперь глянем что же происходит при обращении клиента к серверу. Для этого используем Network dump от Wireshark.

 

1c80e7a89a3347f899756eeba3bfcbc4.png

 

TCP 3 way handshake — механизм начала соединения по TCP протоколу. Из dump-а видно, что клиент, с порта 33311 инициировал соединение с сервером, запущенном на порте 8443.

Secure Data Transmission — это уже передача, непосредственно, данных по шифрованному каналу

TLS handshake — это то что нас и интересует. Подробно об этом можно почитать здесь, но мы рассмотрим только работу с сертификатами.

 

Мы видим сообщения:

Client Hello, Server Hello, Change Cipher Spec, Encrypted Handshake Message

 

Ниже показано, что эти сообщения с собой несут:

 

03950a2683314141883ff69b0772f953.png

 

Как видим, вместе с Server Hello Клиенту приходит Цепочка Сертификатов Сервера (Server Certificate).

Как клиент проверяет подлинность Сертификата. Как это происходит:

1) Клиент смотрит, есть ли у него Root CA для верхнего сертификата в цепочке,

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

Если не нашел, значить у Клиента и Сервера нет общего знакомого CA, доверять серверу нельзя. 4a7577fcff5a4038a3b6e89f5d26e3c9.png

2) если есть — Клиент берет Публичный Ключ своего сертификата и пробует расшифровать подпись сертификата, пришедшего с Сервера.

 

- если не получилось, значить Сервер подменил сертификат CA и ему нельзя доверять 4a7577fcff5a4038a3b6e89f5d26e3c9.png

- ну и, наконец, если все ок, все расшифровалось, сроки годности всех сертификатов валидны, и выполнены еще какие-то условия, которые определяет версия SSL, тогда серверу можно доверять.ee7cdb80711f4709b485a07b605e6fdd.png

 

Примечание

 

Протокол TLS также поддерживает механизм доверия Сервера к клиенту. Как видно из рис 5, в ответ на Server Hello, может прийти сертификат клиента, и сервер тоже может удостовериться, что CA гарантировал его аутентичность.

 

Заключение

 

Итак, когда обе стороны убедились, что их собеседники — те за кого себя выдают, можно начинать диалог. При чем, сразу же есть все для дальнейшего шифрования сообщений — приватный ключ на стороне сервера, и его публичный ключ на клиенте, который был прислан с сертификатом сервера. Но в дальнейшем асимметричное шифрование используется только один раз — когда клиент шифрует пароль публичным ключем сервера, и отправляет серверу — KlientKeyExchange. Далее уже этот пароль используется для симметричного шифрования сообщений, так как оно значительно быстрее и проще асимметричного. Механизмы выбора протокола шифрования и обеспечения целостности сообщений — это огромная область математики и криптографии, но, к счастью для пользователя, она уже реализована под капотом SSL. Все что надо — чтобы на клиенте и сервере были совместимые версии SLL, шифров, криптопровайдеров.

 

В конце хотелось бы сказать, что протоколы безопасной коммуникации:

 

очень сложны и запутаны — есть море версий, протоколов, шифров, при чем никогда не знаешь, когда тебе вылезет сообщение — "NoSuchAlgorithmException — Какие-то версии чего-то не совместимы" или "IllegalBlockSizeException — Размер чего-то слишком большой или маленький"

непостоянны — сегодня браузер нормально заходит на ваш сервер, а завтра уже скажет — что 2048 — это слишком маленькая длина ключа, мол несекьюрно, и не зайдет

вычисления, особенно при асимметрично шифровании, очень ресурсоемки, и на системах всего 5-7 летней давности процесс TLS Handshake может занять 10-20 секунд

 

Но главный, и пожалуй, достаточный, аргумент за — HTTPS и TLS действительно безопасны, насколько это возможно.

 

© habra

Поделиться сообщением


Ссылка на сообщение

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти
Авторизация