Сейчас уже, наверное, больше половины серверов перебрались с http на https протокол. Зачем? Ну, это мол круто, секъюрно.
В чем же заключается эта секъюрность? На эту тему уже написана куча статей, в том числе и на Хабре. Но я бы хотел добавить еще одну.
Почему решил написать
Я, вообще, по специальности Android разработчик, и не особо шарю в криптографии и протоколах защиты информации. Поэтому когда мне пришлось столкнуться с этим непосредственно, я был немного в шоке от размера пропасти в моих теоретических знаниях.
Я начал рыться в разных источниках, и оказалось, что в этой теме не так просто разобраться, и тут недостаточно просто прочитать пару статей на Хабре или Вики, при чем я нигде не встретил абсолютно исчерпывающего и понятного источника, чтобы сослаться и сказать — "Вот это Библия". Поэтому у меня это "немного разобраться" заняло кучу времени. Так вот, разобравшись, я решил поделиться этим, и написать статью для таких же новичков, как и я, или просто для людей, которым интересно зачем в строке URL иногда стоит https, а не http.
Что значит защищенный канал связи?
Чтобы канал передачи данных считался защищенным, должны выполняться 3 основные принципа:
- Доверие (Trust) — взаимная аутентификацию абонентов при установлении соединения.
- Шифрование (Encryption) — защита передаваемых по каналу сообщений от несанкционированного доступа. То есть, говорить и слушать во время диалога можете только вы и ваш собеседник.
- Обеспечение целостности (Data Integrity) — подтверждение целостности поступающих по каналу сообщений, т.е. сообщения не могут подвергаться полной или частичной замене информации.
В этой статье я хотел бы рассказать подробно только о механизме Доверия.
Что значит Доверие (Trust)?
Вы можете доверять вашему собеседнику только если точно знаете, что он — тот, за кого себя выдает.
Самый простой пример — вы знаете собеседника лично, более сложный — вы знаете кого-то кто лично знает вашего предполагаемого собеседника и этот кто-то гарантирует что собеседнику можно доверять.
Жизненный пример
Представим, Вы хотите купить квартиру.
Для этого Вы находите Риэлтора, который занимается продажей квартир.
Риэлтор говорит, что он работает с неким Застройщиком, и предлагает квартиру от этого Застройщика.
Застройщик говорит, что жилье, которое он строит будет, сдано, и те кто заплатил за него деньги Риэлтору, получит его в собственность, и легальность строительства и право собственности будет обеспечена Государством.
Итого у нас есть 4 субъекта Вы, Риэлтор, Застройщик, Государство.
Для того чтобы сделка успешно состоялась и никто никого не обманул Государство создало законы, определяющие документы, которые гарантируют легальность сделок, и механизм печати или подписи, который гарантирует подлинность этих документов.
У Вас есть примеры этих документов и печатей, вы можете их взять у Государства.
Вы имеете право требовать у Риэлтора оригиналы документов на строительство.
Риэлтор берет документы Застройщика, которые подкреплены документами Государства и убеждается, что квартиры можно продавать — они легальны.
Застройщик же в свою очередь получает документы у Государства.
Т.е. теперь вы можете смело вести диалог только с Риэлтором, основываясь на его документах, скрепленных печатями Застройщика и Государства!
Доверие в HTTPS
А теперь поменяем имена действующих лиц из Жизненного примера.
Вы = Клиент (Client)
Риэлтор = Сервер (Server)
Застройщик = Промежуточный Центр Сертификации (Intermediate CA)
Государство = Главный Центр Сертификации (Root CA)
Главный Центр Сертификации (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)
- И еще много информации, в зависимости от версии, но остальное нам пока не нужно.
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.
Все это собирается в кучу и получается, так называемый, Самоподписанный сертификат (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.
- 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 действительно безопасны, насколько это возможно.
Полезные ссылки по теме
http://www.youdzone.com/signature.html
https://habrahabr.ru/post/258285/
https://datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certificate-authority/
http://superuser.com/questions/126121/how-to-create-my-own-certificate-chain
Комментарии (42)
vadimr
15.07.2016 17:43+1https даёт вам (при условии отсутствия ошибок и эксплуатируемых уязвимостей) две вещи: уверенность в том, что вы общаетесь именно с тем хостом, который себя заявил, и недоступность вашего диалога для прослушивания посередине. Насколько это увеличивает вашу безопасность – вопрос, зависимый от многих других обстоятельств.
В качестве основного минуса, https обычно обеспечивает меньшую пропускную способность, чем http, что особенно критично на медленных линиях типа сотовой телефонии. Кроме того, дальше начинаются вопросы с включением внешних ресурсов в защищённые страницы.
Настолько ли важно пользователю вообще различать малозначимые для него сайты vasya1.com и vasya2.com, чтобы защищать аутентичность одного из них – вопрос дискутируемый. Поэтому массовая миграция не содержащих критичной информации сайтов на https не вполне объяснима с рациональных позиций.
fRoStBiT
16.07.2016 06:31+2А насколько ему важно, чтобы провайдер и другие третьи лица не видели, что он делает на этих сайтах?
vadimr
18.07.2016 16:26-1Рациональные основания для такого желания представить тоже сложно. Если пользователь делает что-то противозаконное, то ему, по идее, нужно утаивать сам факт посещения сайта, чего https не обеспечивает. А если нет, тогда какой смысл скрывать свои действия от провайдера?
sumanai
16.07.2016 10:06+1> В качестве основного минуса, https обычно обеспечивает меньшую пропускную способность, чем http, что особенно критично на медленных линиях типа сотовой телефонии.
HTTP2 в большинстве пользовательских программ реализован поверх https, а он обеспечивает большую скорость загрузки страниц.
> Поэтому массовая миграция не содержащих критичной информации сайтов на https не вполне объяснима с рациональных позиций.
ПС выводят сайты с https выше, в страницу нельзя внедрить стороннюю рекламу по пути, например, в бесплатных Wi-Fi или у особо наглых провайдерах. Вполне рационально.
Dexterite
17.07.2016 02:42> ПС выводят сайты с https выше, в страницу нельзя внедрить стороннюю рекламу по пути, например, в бесплатных Wi-Fi или у особо наглых провайдерах. Вполне рационально.
Спорно. Для обывателя замена получаемых по DHCP ДНС серверов является проблемой. А это просто может обернуться в замену хостов популярных рекламщиков на свои, подсовывая свои картинки вместо того же adriver.ru. Я бы не сказал, что проблема здесь именно во внедрении рекламы ибо обывателю под час на нее плевать, если она не занимает 100% пространства страницы.
Скорее проблема шире именно с точки зрения не простого подсовывания рекламы, а замены всего содержимого страницы. Или внедрение в нее вредоносного кода.
farcaller
17.07.2016 12:38тогда сразу будет https://adriver.ru :-) в этом, собственно, и есть смысл https — нельзя просто так взять и подменить хост.
alcohollica
18.07.2016 13:38По поводу https и менее комфортного по сравнению с http сёрфинга хотелось бы заметить следующее: для https достаточно важен исходящий от клиента трафик для обмена ключами и шифрования, а у сотовых операторов обычно исходящий трафик очень мал по сравнению с входящим. Именно поэтому субъективная скорость при https гораздо меньше.
sumanai
19.07.2016 01:04При грамотных настройках веб-вервера установка соединения по полной программе идёт только при первом обращении, далее используется возобновление сессии, где overhead минимален.
nmk2002
15.07.2016 17:47+4Цифровая подпись (Digital Signature) — это часть документа, зашифрованная Приватным ключем Подписчика (Issuer)
Обычно шифруется хэш документа. Если шифровать часть документа, то и обеспечить получится только целостность этой части документа.
Выбирается сообщение для шифровки (Message). Что именно шифровать, определяет алгоритм и версия SSL. Для конечного пользователя это неважно, так как все версии шифрования и хэширования также помещаются в сертификат, и при расшифровке эти же версии и используются.
Откуда у вас такая странная информация про создание самоподписанного сертификата? На всякий случай я посмотрел все ссылки, что у вас в источниках, но, к счастью, ничего подобного там не нашел.
Mingun
15.07.2016 20:07+1Мне кажется, тут автор имел ввиду, что шифруемый хеш в принципе может быть произвольным ("хеш" — "алгоритм" у автора), но в версиях SSL указаны предпочтительные алгоритмы хешей. Автор просто попытался рассказать это простыми словами, "для домохозяек". Хорошо или нет получилось — вопрос спорный, но тут необходимо учитывать, что шифрование — это такой тугой клубок нитей, который расплести с наскока нереально. У меня иногда такое впечатление, словно специально пытались усложнить жизнь тем, кто в этом хочет разобраться.
kloppspb
15.07.2016 22:35>Автор просто попытался рассказать это простыми словами, «для домохозяек»
Домохозяйкам это вообще нафиг не упало. Ну узнает баба Глаша рецепт тортика тёти Сары, и что?
А если речь идёт о корпоративной СБ, например (или ты — террорист), то нефиг домохозяек до обмена сообщениями допускать :)Mingun
16.07.2016 00:26+1Ага, ага. Безопасность через незнание?
А если речь идёт о корпоративной СБ, например (или ты — террорист), то нефиг домохозяек до обмена сообщениями допускать :)
Да кто вас спрашивать будет, если они до нее доберутся? Лучше пусть знают основы, а не бездумно вытворяют черти что. Лишнее знание никогда не мешает, если оно не устаревшее.
kloppspb
16.07.2016 00:52-1Да перестаньте. IRL домохозяйкам глубоко этосамое. Как и прочие детали. Ну зачем им вникать в подробности, если нужно обсудить схему полива кактуса в горшке?
>Лучше пусть знают основы
Это для вас они «основы» и то, что вы знаете по определению. Попробуйте вынырнуть из хабромира в реальный — сильно удивитесь :)
Ну или для эксперимента подойдите к произвольному человеку в произвольном месте и в произвольное время, и спросите что он знает про отличия HTTP/1 от HTTP/2.Mingun
16.07.2016 16:26+1Похоже, вы слишком буквально восприняли слово "домохозяйка", а я ведь не зря кавычки поставил. Ну хорошо, заменим его на "чайников".
Ну зачем им вникать в подробности, если нужно обсудить схему полива кактуса в горшке?
Правильно, незачем, если они это не спрашивали. Но если уж заинтересовались и спросили, то как-то не гуманно сразу вываливать на них все эти ASN.1, BER, CER, DER, PKCS, PKI, RSA, DES, DH, KEK, CMS и прочая и прочая, вы не находите? Вы же не думаете, что людям, которым криптография в принципе неинтересна, читали статью?
Это для вас они «основы» и то, что вы знаете по определению. Попробуйте вынырнуть из хабромира в реальный — сильно удивитесь :)
С рождения вы ничего не знаете, но ведь научились же как-то клавиатурой пользоваться и даже этот сайт нашли :). И это — действительно основы, описанные простыми словами. Без всяких частностей, типа как тут упоминали выше, что DSA нельзя использовать для шифрования. Это как раз уже продвинутый уровень. Как в школе. Сначала вам говорят, что из меньшего нельзя вычитать большее. Потом вводят отрицательные числа и обнаруживается, что все-таки можно. Аналогичная история повторяется с дробями и корнями из отрицательных чисел, делением на 0 и т.п.
Зная основы, частности можно вывести. Например, я не знаю, что такое DSA (но знаю RSA), но попробую объяснить, почему шифровать им не годится.
Чтобы не было путаницы, договоримся, что ниже слово "шифрование" будет означать сокрытие информации от чужих глаз, в том время как "преобразование шифрования" — просто техническую процедуру преобразования чистого текста в шифрованный.
- Итак, мы знаем, что это асимметричная криптография, а асимметричная криптография всегда имеет 2 ключа — публичный и приватный. Первый отдаем всем, второй храним у себя.
- Шифрование — это преобразование чистого текста в шифротекст. Расшифровка — в обратную сторону. Для каждого преобразования нужен свой ключ.
- Если мы хотим использовать алгоритм (в данном случае DSA) для шифрования, то получить информацию должен только один участник. Так как он отличается от других только наличием приватного ключа, значит, приватным ключом нужно расшифровывать, а публичным шифровать (проводить преобразование шифрования).
- Если мы хотим использовать алгоритм для подписи, то проверять ее должны все, а создавать только один участник. Так как он отличается от других только наличием приватного ключа, значит, приватным ключом нужно шифровать (проводить преобразование шифрования), а публичным расшифровывать.
- Исходя из вышеперечисленного, можно предположить, что в алгоритм DSA использует какие-то данные из приватного ключа для преобразования шифрования, которых нет в публичном ключе. Этим объясняется, почему его можно использовать только в одном преобразовании. Для шифрования с помощью DSA в шифрующем ключе просто нет необходимых данных
- Но что мешает нам поменять местами приватный и публичный ключ, чтобы шифрование с использованием DSA стало возможным? Просто переназвать их и дело в шляпе! Попробуем это объяснить. Для RSA известно, что приватный ключ содержит в себе публичный. Т.е. обладая приватным ключом, мы обладаем обоими ключами. Если в DSA дела обстоят также, то нельзя просто поменять ключи местами и переназвать их. Ведь публичный ключ нужно отдавать всех, но не забываем, что изначально это был приватный ключ (мы ведь их переназвали) — таким образом, мы всем раздаем оба ключа. А это нарушает принцип асимметричной криптографии, поэтому шифрование с помощью DSA бессмысленно.
lockywolf
15.07.2016 17:54+2>>Но главный, и пожалуй, достаточный, аргумент за — HTTPS и TLS действительно безопасны, насколько это возможно.
Это кажется очень смелым утверждением, если учесть, что нужно не просто доверять CA, но и всем Intermediate CA. Не в том смысле, доверять, что они — это они (это как раз делает криптография), а доверять в том смысле, что они не будут подписывать левые сертификаты, или что у них где-нибудь не сидит MITM, перешифровывающий трафик и складывающий его в своё хранилище.
И ещё в статье не указано, что всё это относится только к стандарту X.509 (S/MIME), в то время как (теоретически), существуют другие варианты реализации PKI, скажем, WebOfTrust.
sshikov
15.07.2016 18:54Что значить защищенный канал связи?
Поправьте это "значить" при случае ))) никто правда пока не заметил, но все равно режет.
И еще:
Чтобы канал передачи данных считался защищенным, должны выполняться 3 основные принципа:
Доверие (Trust) — взаимная аутентификацию абонентов при установлении соединения. Шифрование (Crypting) — защита передаваемых по каналу сообщений от несанкционированного доступа. То есть, говорить и слушать во время диалога можете только вы и ваш собеседник. Обеспечение целостности — подтверждение целостности поступающих по каналу сообщений, т.е. сообщения не могут подвергаться полной или частичной замене информации.
Вобще говоря, тут нужно понимать, защищенный от чего? Т.е. например, можно себе представить достаточно легко канал, защищенный от модификации, т.е. целостность в наличии, но не защищенный от прослушки. Типичный случай — это скажем репозиторий компонентов. Вы очевидно не хотите установить обновление OS с левого сайта, но при этом вам совершенно не нужно шифровать здоровенные получаемые оттуда архивы. Так что как минимум шифрование тут не является обязательным.
Farxial
16.07.2016 10:06К сожалению, принимаемые в наше время законы изменяют определение безопасности HTTPS. Так, например, раньше информация была защищена действительно ото всех левых лиц, а теперь — только от кулхацкеров, не способных получить ключи или левый сертификат.
Это ни в коем случае не придирка, а лишь замечание для таких же новичков с целью предупреждения у них создания иллюзии, что HTTPS по-настоящему безопасен.
Vinchi
16.07.2016 14:55+1Есть еще немаловажная часть — списки отзывов. Если сертификат был скомпроментирован или просрочен или просто например у кого-то надо забрать права доступа. Протокол их тоже проверяет и списки должны обновляться и быть доступными онлайн.
Насчет доверия корневому центру сертификации — по мне так это и есть самая проблемная часть. Скорее всего службы госбезоапсности имеют доступ к их приватным ключам, а значит и ко всем промежуточным, а значит вполне могут вмешиваться в траффик «защищенный» таким CA.
На данный момент есть технология blockchain, а значит возможно создание и работа с CA, корневые сертификаты которого никому не принадлежат и проверяются в распределенной сети. Если кто-то знает конкретные реализации и кейсы, с которыми сталкивался в этом плане, напишите.
sumanai
16.07.2016 16:48+1> Есть еще немаловажная часть — списки отзывов. Если сертификат был скомпроментирован или просрочен или просто например у кого-то надо забрать права доступа.
Просроченные сертификаты проверяются сверкой текущего времени и строкой «Действителен по» в сертификате. Никто не вносит простроченные в списки отзывов.
Funbit
17.07.2016 04:04Библию криптографии, кстати, сейчас разрабатывает сайт https://www.crypto101.io
Книга уже почти закончена, включает в себя все основные темы криптографии. А самое главное — написана очень простым и понятным языком.
robux
17.07.2016 12:52-1Хоть кто-то пытается разгрести эти «авгиевы конюшни». Похвально.
Но имхо SSL в целом и TLS в частности не просто так усложнены — «законодатели» этих спецификаций ловят рыбку в мутной воде. Во благо «государства», естественно!
Опять же имхо, нужен Геракл, который сметёт это дерьмо новой простой и понятной спецификацией.
daocrawler
17.07.2016 14:41Более половины, вы, конечно, махнули. Статистика использования HTTPS.
10,6% на данный момент используют его по умолчанию. Но тренд, безусловно, хороший.
vagonovozhaty
18.07.2016 10:29+4Вот прочитает кто-нибудь этот пост и будет потом везде писать «ключем» вместо «ключом» и думать, что так правильно, потому что на уважаемом техническом ресурсе так было написано.
grossws
Вам не показалось странным это ваше утверждение? Если говорить про RSA, то сообщение может быть зашифровано с использованием публичного ключа и расшифровано с помощью приватного, но не наоборот. Также RSA позволяет использовать приватный ключ для подписи сообщения, а публичный — для проверки этой подписи. Тот же DSA не предполагает шифрования, но только подпись.
grossws
CSR подписывается ключом того, кто делает запрос на сертификат (как подтверждение владения ключом для которого выпускается сертификат). На основе этого CSR (тех полей, которые проверил CA) создаётся сертификат, обогащается нужными полями, включая уже подпись CA.
Mingun
Мне показалось, что автор как раз это и имел ввиду. Может просто потому, что я тоже как раз сейчас с криптографией разбираюсь и мне механизм уже знаком. С точки зрения человека, выполняющего
он подписывает csr и получает сертификат.
grossws
Клиентская аутентификация в массе не используется. Обычно достаточно аутентификации сервера. Когда используется — с
ServerHelloпридёт запрос на сертификат клиента и сервер будет так же проверять его цепочку в рамках PKI.grossws
Это только один из способов Kx (key exchange). Ещё активно используются схемы DH/ECDH. Редко всякая экзотика типа PSK (pre-shared key), параметров diffie-hellman'а из сертификата.
Mingun
Мне не показалось. Технически при подписи осуществляется шифрование, только параметры отличаются от "настоящего" шифрования. Проводить такие различия — демагогия.
grossws
Основное отличие подписи и шифрования в случае RSA — семантическое. Технически экспоненты меняются местами и благодаря коммутативности операции возведения в степень по модулю (с соответствующим ограничениями; если правильно помню, она может быть некоммутативна в в общем случае) RSA можно использовать и для подписи.
В тех же DSA и ECDSA нет возможности реализовать шифрование — они могут использоваться только для подписи.
creker
Под подписью в большинстве случаев понимают очень четкую последовательность действий, как то шифрование приватным ключом хэша сообщения. Все равно это шифрование и тот факт, что приватный/публичный ключ в RSA, по сути, это больше семантика, нежели математика, делают все эти придирки больше демагогией.
ЗЫ хотя на практике тот формат, в котором хранится приватный ключ, делает его именно что приватным и никаким другим.
grossws
А в ElGamal, DSA и ECDSA с вашей точки зрения тоже происходит шифрование?
creker
С этими схемами я плохо знаком. Речь про RSA и в нем хочешь шифруй приватным, хочешь публичным. Все только на твое усмотрение, какую ты себе выдумал схему. Никто не мешает тебе сделать гибридную схему шифрования, где ключик AES шифруется приватным ключом RSA. Это прекрасно работает и прекрасно поддерживается библиотеками вроде OpenSSL и PolarSSL, которые делают какие угодно преобразования каким угодно ключом. А вот если ты захочешь именно подпись, то эти самые библиотеки за тебя хэш посчитают и его подпишут. Технически это тоже самое шифрование, только наделили его другим смыслом с очень специфической реализацией.
gearbox
Наоборот тоже можно — там же возведение в степень по основанию. Возводите в степень d по основанию n (из приватного ключа) и отдаете получателю. тот возводит в степень e по основанию n и получает расшифрованный вариант. Можно гонять в любом направлении, лишь бы сумма d и e была равна функции Эйлера от n.
grossws
Как я говорил выше, с моей точки зрения, это не по сути шифрование, а подпись.
Произведение d и e должно быть равно единице по модулю phi(n), такое странное ограничение на сумму откуда взялось?
gearbox
Нет, ЛЮБОЕ число (от 0 до n-1) в СТЕПЕНИ phi будет равно единице по модулю N, а соотв. в степени phi+1 будет равно самому себе. Но что бы взять эйлера надо знать разложение числа n. На этом и построен принцип ассиметричного шифрования. Тот кто составлял n — знает его эйлера. И он делит Эйлера на две части — d и e (phi = d + e) — одна часть публичная другая закрытая, и неважно какая из них какая. Как правило открытую делают достаточно маленькой а закрытую — достаточно большой (что бы нельзя было угадать или перебрать). И независимо от того кто шифрует сообщение, он возводит в какую то степень (d или e) а тот кто получил сообщение — продолжает возводить в то значение которое ему известно. В итоге оба участника возведут число в степень равную функции Эйлера (+1 если быть точным) и получат исходное число. Все операции естественно по модулю n.
grossws
Давайте возьмем числа из wiki:
p = 61,q = 53=>n = 3233,phi(n) = 3120. Далее, приe = 17, получимd = 2753. Как легко проверить,d e mod phi(n) = 1, ноd + e != phi(n). QEDВо-первых, не любое. Только взаимнопростое с
n, если вы говорите про теорему Эйлера. Например,p^phin(n) mod nпри указанных выше параметрах будет равно 1220.Во-вторых, какое утверждение вы оспариваете? Что e и d взаимнообратны по модулю
phi(n)? В классическом RSA это так (можете прочитать в патенте). В PKCS1 предлагается другой вариант: e и d взамнообратны по модулю lcm(p-1,q-1) (наименьшее общее кратное).Откуда возник вариант с
e + d = phi(n)— я не ведаю. Выглядит он бредово, т. к. сообщение при шифровании возводится в степеньdпо модулюn. Полученный шифротекст возводится в степеньeи получаетсяm^(d*e) mod nдля которого уже доказывается, что оно равноm mod n. Как легко увидеть, суммаd + eне возникает в этом процессе.Вы что мне хотите продемонстрировать/доказать? Я вполне способен глянуть в википедию/стандарты и произвести элементарные вычисления, чтобы опровергнуть ваши утверждения. Если хотите дальше продолжить разговор — то стоит приводить строгие математические доказательства ваших утверждений или ссылки на работы, где они приведены.
gearbox
Был не прав, вспылил. Я рассматривал ситуацию с точки зрения владельца плейн-текста. С точки зрения получателя шифр текста — совершено верно, он возводит в степень шифртекст, и тогда уже речь идет не о сумме степеней дающих Эйлера а о произведении. Признаю свою вину, меру, степень, глубину. Пойду сожгу Шнайера, посыплю голову пеплом.
hioma
Я почему всегда считал точно так же, как и автор: то есть эти ключи работают в обе стороны (взаимно обратны), разве нет? И что есть цифровая подпись, как не шифрование (хэша) сообщения приватным ключом и его последующая проверка методом расшифрования публичным с дальнейшим сопоставлением (хэша) первоначального сообщения?
hioma
Уже после увидел в диалоге с gearbox, что вы просто оперируете понятиями — мы говорим об одних и тех же вещах, но разными словами.