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

[blackedd]

Сейчас уже, наверное, больше половины серверов перебрались с http на https протокол. Зачем? Ну, это мол круто, секъюрно.
В чем же заключается эта секъюрность? На эту тему уже написана куча статей, в том числе и на Хабре. Но я бы хотел добавить еще одну.
Почему решил написать
Я, вообще, по специальности Android разработчик, и не особо шарю в криптографии и протоколах защиты информации. Поэтому когда мне пришлось столкнуться с этим непосредственно, я был немного в шоке от размера пропасти в моих теоретических знаниях.
Я начал рыться в разных источниках, и оказалось, что в этой теме не так просто разобраться, и тут недостаточно просто прочитать пару статей на Хабре или Вики, при чем я нигде не встретил абсолютно исчерпывающего и понятного источника, чтобы сослаться и сказать — "Вот это Библия". Поэтому у меня это "немного разобраться" заняло кучу времени. Так вот, разобравшись, я решил поделиться этим, и написать статью для таких же новичков, как и я, или просто для людей, которым интересно зачем в строке URL иногда стоит https, а не http.
Что значить защищенный канал связи?
Чтобы канал передачи данных считался защищенным, должны выполняться 3 основные принципа:
Доверие (Trust) — взаимная аутентификацию абонентов при установлении соединения.
Шифрование (Crypting) — защита передаваемых по каналу сообщений от несанкционированного доступа. То есть, говорить и слушать во время диалога можете только вы и ваш собеседник.
Обеспечение целостности — подтверждение целостности поступающих по каналу сообщений, т.е. сообщения не могут подвергаться полной или частичной замене информации.
В этой статье я хотел бы рассказать подробно только о механизме Доверия.
Что значить Доверие (Trust)?
Вы можете доверять вашему собеседнику только если точно знаете, что он — тот, за кого себя выдает.
Самый простой пример — вы знаете собеседника лично, более сложный — вы знаете кого-то кто лично знает вашего предполагаемого собеседника и этот кто-то гарантирует что собеседнику можно доверять.
Жизненный пример
Представим, Вы хотите купить квартиру.
Для этого Вы находите Риэлтора, который занимается продажей квартир.
Риэлтор говорит, что он работает с неким Застройщиком, и предлагает квартиру от этого Застройщика.
Застройщик говорит, что жилье, которое он строит будет, сдано, и те кто заплатил за него деньги Риэлтору, получит его в собственность, и легальность строительства и право собственности будет обеспечена Государством.
Итого у нас есть 4 субъекта Вы, Риэлтор, Застройщик, Государство.
Для того чтобы сделка успешно состоялась и никто никого не обманул Государство создало законы, определяющие документы, которые гарантируют легальность сделок, и механизм печати или подписи, который гарантирует подлинность этих документов.
У Вас есть примеры этих документов и печатей, вы можете их взять у Государства.
Вы имеете право требовать у Риэлтора оригиналы документов на строительство.
Риэлтор берет документы Застройщика, которые подкреплены документами Государства и убеждается, что квартиры можно продавать — они легальны.
Застройщик же в свою очередь получает документы у Государства.
Т.е. теперь вы можете смело вести диалог только с Риэлтором, основываясь на его документах, скрепленных печатями Застройщика и Государства!

Доверие в HTTPS
А теперь поменяем имена действующих лиц из Жизненного примера.
Вы = Клиент (Client)
Риэлтор = Сервер (Server)
Застройщик = Промежуточный Центр Сертификации (Intermediate CA)
Государство = Главный Центр Сертификации (Root CA)

https://en.wikipedia.org/wiki/Certificate_authority — общепризнанная известная компания, которой международные организации выдали полномочия заведовать сертификатами и подписями, короче этой компании доверяют все.
Она может давать некоторые полномочия https://en.wikipedia.org/wiki/Interm...te_authorities, и они будут подписывать документы от имени Главного Центра.
Перейдем к математике
Были упомянуты слова: подпись, сертификат и т.д. Как это реализовать? В помощь приходит https://en.wikipedia.org/wiki/Public-key_cryptography
Чтобы не вдаваться в подробности и не объяснять дискретную математику и криптографию, уясним пару вещей:
1) Коротко и о главном об асимметричном шифровании.
Есть 2 ключа — Публичный и Приватный (Public Key and Private Key). Собственно, ключи — это просто большие числа.
Если сообщение шифруется Публичным, то его может расшифровать только соответствующий ему Приватный ключ.
И наоборот:
Если сообщение шифруется Приватным, то его может расшифровать только соответствующий ему Публичный ключ.
Приватный ключ никому не дается, Публичный — собственно, публичный.
2)https://en.wikipedia.org/wiki/Digital_signature— это часть документа, зашифрованная Приватным ключем Подписчика (Issuer). Если ее можно расшифровать Публичным Ключем Подписчика, то можно с уверенностью утверждать, что именно Подписчик ее шифровал.
3) https://en.wikipedia.org/wiki/Public_key_certificate — это обычно файл, чаще всего с расширением .cer или .pem.
В нем содержится:
Информация о владельце (Subject)
Инфомация о Подписчике (Issuer)
Информация о подписи (Версия SSL, алгоритм)
Хэш подписи (Certificate Fingerprints)
Public Key
Цифровая подпись (Signature)
Срок годности (Expires)
И еще много информации, в зависимости от версии, но остальное нам пока не нужно.
[+] Пример Сертификата
Code:

COMODO Certification Authority

Identity: COMODO Certification Authority

Verified by: COMODO Certification Authority

Expires: 31.12.29

Subject Name

C (Country): GB

ST (State): Greater Manchester

L (Locality): Salford

O (Organization): COMODO CA Limited

CN (Common Name): COMODO Certification Authority

Issuer Name

C (Country): GB

ST (State): Greater Manchester

L (Locality): Salford

O (Organization): COMODO CA Limited

CN (Common Name): COMODO Certification Authority

Issued Certificate

Version: 3

Serial Number: 4E 81 2D 8A 82 65 E0 0B 02 EE 3E 35 02 46 E5 3D

Not Valid Before: 2006-12-01

Not Valid After: 2029-12-31

Certificate Fingerprints

SHA1: 66 31 BF 9E F7 4F 9E B6 C9 D5 A6 0C BA 6A BE D1 F7 BD EF 7B

MD5: 5C 48 DC F7 42 72 EC 56 94 6D 1C CC 71 35 80 75

Public Key Info

Key Algorithm: RSA

Key Parameters: 05 00

Key Size: 2048

Key SHA1 Fingerprint: 11 E4 91 D1 C9 E4 C0 EB 9A CE CF 73 54 5D E1 F1 A8 30 3E C3

Public 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 01

Subject Key Identifier

Key Identifier: 0B 58 E5 8B C6 4C 15 37 A4 40 A9 30 A9 21 BE 47 36 5A 56 FF

Critical: No

Key Usage

Usages: Digital signature

Critical: Yes

Basic Constraints

Certificate Authority: Yes

Max Path Length: Unlimited

Critical: Yes

Extension

Identifier: 2.5.29.31

Value: 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 6C

Critical: No

Signature

Signature Algorithm: SHA1 with RSA

Signature Parameters: 05 00

Signature: 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.
Все это собирается в кучу и получается, так называемый, https://en.wikipedia.org/wiki/Self-signed_certificate
2) Этот Self Signed Certificate раздается клиентам
Пример клиента — браузер. В любом браузере можно посмотреть список сертификатов.
Например в Chrome: Settings -> Manage Certificates -> Authorities.
Теперь клиент знает про существование CA.
3) Подтверждение своей аутентичности
Если не вдаваться в детали, то этот пункт одинаков для Сервера и Промежуточных Центров Аутентификации
Генерируется Private Key
Генерируется Public Key
Добавляется информация о CA, определяется срок годности
Формируется, так называемый, Запрос на Сертификацию https://en.wikipedia.org/wiki/Certif...igning_request
CSR подписывается Приватным Ключем близжайшего по цепи Центра Сертификации. Собственно, так это и называется https://en.wikipedia.org/wiki/Chain_of_trust, когда Центры Сертификации друг за другом подписывают следующий сертификат, вплоть до конечного — Сертификата Сервера.
В итоге, имеем Self Signed Certificate на клиенте и Signed Server Certificate на сервере, т.е. клиент знает и доверяет СА и СА прогарантировал аутентичность сервера.
4) Непосредственно диалог
Теперь глянем что же происходит при обращении клиента к серверу. Для этого используем Network dump от https://wiki.wireshark.org/

TCP 3 way handshake — механизм начала соединения по TCP протоколу. Из dump-а видно, что клиент, с порта 33311 инициировал соединение с сервером, запущенном на порте 8443.
Secure Data Transmission — это уже передача, непосредственно, данных по шифрованному каналу
TLS handshake — это то что нас и интересует. Подробно об этом можно почитать здесь, но мы рассмотрим только работу с сертификатами.
Мы видим сообщения:
Client Hello, Server Hello, Change Cipher Spec, Encrypted Handshake Message
Ниже показано, что эти сообщения с собой несут:

Как видим, вместе с Server Hello Клиенту приходит Цепочка Сертификатов Сервера (Server Certificate).
Как клиент проверяет подлинность Сертификата. Как это происходит:
1) Клиент смотрит, есть ли у него Root CA для верхнего сертификата в цепочке,
если нет — спускается по цепочке ниже, при чем каждый раз перепроверяет, действительно ли подписан сертификат предыдущим в цепочке. (Это просто — цифровая подпись нижнего должна расшифровываться публичным ключем верхнего).
Если не нашел, значить у Клиента и Сервера нет общего знакомого CA, доверять серверу нельзя.
2) если есть — Клиент берет Публичный Ключ своего сертификата и пробует расшифровать подпись сертификата, пришедшего с Сервера.
- если не получилось, значить Сервер подменил сертификат CA и ему нельзя доверять
- ну и, наконец, если все ок, все расшифровалось, сроки годности всех сертификатов валидны, и выполнены еще какие-то условия, которые определяет версия SSL, тогда серверу можно доверять.
Примечание
Протокол TLS также поддерживает механизм доверия Сервера к клиенту. Как видно из рис 5, в ответ на Server Hello, может прийти сертификат клиента, и сервер тоже может удостовериться, что CA гарантировал его аутентичность.
Заключение
Итак, когда обе стороны убедились, что их собеседники — те за кого себя выдают, можно начинать диалог. При чем, сразу же есть все для дальнейшего шифрования сообщений — приватный ключ на стороне сервера, и его публичный ключ на клиенте, который был прислан с сертификатом сервера. Но в дальнейшем асимметричное шифрование используется только один раз — когда клиент шифрует пароль публичным ключем сервера, и отправляет серверу — KlientKeyExchange. Далее уже этот пароль используется для симметричного шифрования сообщений, так как оно значительно быстрее и проще асимметричного. Механизмы выбора протокола шифрования и обеспечения целостности сообщений — это огромная область математики и криптографии, но, к счастью для пользователя, она уже реализована под капотом SSL. Все что надо — чтобы на клиенте и сервере были совместимые версии SLL, шифров, криптопровайдеров.
В конце хотелось бы сказать, что протоколы безопасной коммуникации:
очень сложны и запутаны — есть море версий, протоколов, шифров, при чем никогда не знаешь, когда тебе вылезет сообщение — "NoSuchAlgorithmException — Какие-то версии чего-то не совместимы" или "IllegalBlockSizeException — Размер чего-то слишком большой или маленький"
непостоянны — сегодня браузер нормально заходит на ваш сервер, а завтра уже скажет — что 2048 — это слишком маленькая длина ключа, мол несекьюрно, и не зайдет
вычисления, особенно при асимметрично шифровании, очень ресурсоемки, и на системах всего 5-7 летней давности процесс TLS Handshake может занять 10-20 секунд
Но главный, и пожалуй, достаточный, аргумент за — HTTPS и TLS действительно безопасны, насколько это возможно.
(c) habra