[Из песочницы] Принцип Доверия (Trust) в HTTPS
Сейчас уже, наверное, больше половины серверов перебрались с http на https протокол. Зачем? Ну, это мол круто, секъюрно.
В чем же заключается эта секъюрность? На эту тему уже написана куча статей, в том числе и на Хабре. Но я бы хотел добавить еще одну.
Почему решил написать
Я, вообще, по специальности Android разработчик, и не особо шарю в криптографии и протоколах защиты информации. Поэтому когда мне пришлось столкнуться с этим непосредственно, я был немного в шоке от размера пропасти в моих теоретических знаниях.
Я начал рыться в разных источниках, и оказалось, что в этой теме не так просто разобраться, и тут недостаточно просто прочитать пару статей на Хабре или Вики, при чем я нигде не встретил абсолютно исчерпывающего и понятного источника, чтобы сослаться и сказать — «Вот это Библия». Поэтому у меня это «немного разобраться» заняло кучу времени. Так вот, разобравшись, я решил поделиться этим, и написать статью для таких же новичков, как и я, или просто для людей, которым интересно зачем в строке URL иногда стоит https, а не http.
Что значить защищенный канал связи?
Чтобы канал передачи данных считался защищенным, должны выполняться 3 основные принципа:
- Доверие (Trust) — взаимная аутентификацию абонентов при установлении соединения.
- Шифрование (Crypting) — защита передаваемых по каналу сообщений от несанкционированного доступа. То есть, говорить и слушать во время диалога можете только вы и ваш собеседник.
- Обеспечение целостности — подтверждение целостности поступающих по каналу сообщений, т.е. сообщения не могут подвергаться полной или частичной замене информации.
В этой статье я хотел бы рассказать подробно только о механизме Доверия.
Что значить Доверие (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
Комментарии (32)
grossws
15 июля 2016 в 15:56
+6↑
↓
Если сообщение шифруется Публичным, то его может расшифровать только соответствующий ему Приватный ключ.
И наоборот:
Если сообщение шифруется Приватным, то его может расшифровать только соответствующий ему Публичный ключ.
Приватный ключ никому не дается, Публичный — собственно, публичный.Вам не показалось странным это ваше утверждение? Если говорить про RSA, то сообщение может быть зашифровано с использованием публичного ключа и расшифровано с помощью приватного, но не наоборот. Также RSA позволяет использовать приватный ключ для подписи сообщения, а публичный — для проверки этой подписи. Тот же DSA не предполагает шифрования, но только подпись.
-
grossws
15 июля 2016 в 16:15
+4↑
↓
CSR подписывается Приватным Ключем близжайшего по цепи Центра Сертификации. Собственно, так это и называется Certificate Chain, когда Центры Сертификации друг за другом подписывают следующий сертификат, вплоть до конечного — Сертификата Сервера.
CSR подписывается ключом того, кто делает запрос на сертификат (как подтверждение владения ключом для которого выпускается сертификат). На основе этого CSR (тех полей, которые проверил CA) создаётся сертификат, обогащается нужными полями, включая уже подпись CA.
Mingun
15 июля 2016 в 20:15
–2↑
↓
Мне показалось, что автор как раз это и имел ввиду. Может просто потому, что я тоже как раз сейчас с криптографией разбираюсь и мне механизм уже знаком. С точки зрения человека, выполняющего
openssl x509 -req -in $1.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out $1.crt -days 5000он подписывает csr и получает сертификат.
-
grossws
15 июля 2016 в 16:19
+3↑
↓
Итак, когда обе стороны убедились, что их собеседники — те за кого себя выдают, можно начинать диалог.
Клиентская аутентификация в массе не используется. Обычно достаточно аутентификации сервера. Когда используется — с
ServerHelloпридёт запрос на сертификат клиента и сервер будет так же проверять его цепочку в рамках PKI. -
grossws
15 июля 2016 в 16:24
+3↑
↓
Но в дальнейшем асимметричное шифрование используется только один раз — когда клиент шифрует пароль публичным ключем сервера, и отправляет серверу — KlientKeyExchange. Далее уже этот пароль используется для симметричного шифрования сообщений, так как оно значительно быстрее и проще асимметричного.
Это только один из способов Kx (key exchange). Ещё активно используются схемы DH/ECDH. Редко всякая экзотика типа PSK (pre-shared key), параметров diffie-hellman’а из сертификата.
-
Mingun
15 июля 2016 в 19:58
0↑
↓
Мне не показалось. Технически при подписи осуществляется шифрование, только параметры отличаются от «настоящего» шифрования. Проводить такие различия — демагогия.
-
grossws
15 июля 2016 в 23:09
0↑
↓
Основное отличие подписи и шифрования в случае RSA — семантическое. Технически экспоненты меняются местами и благодаря коммутативности операции возведения в степень по модулю (с соответствующим ограничениями; если правильно помню, она может быть некоммутативна в в общем случае) RSA можно использовать и для подписи.
В тех же DSA и ECDSA нет возможности реализовать шифрование — они могут использоваться только для подписи.
16 июля 2016 в 16:11
0↑
↓
Под подписью в большинстве случаев понимают очень четкую последовательность действий, как то шифрование приватным ключом хэша сообщения. Все равно это шифрование и тот факт, что приватный/публичный ключ в RSA, по сути, это больше семантика, нежели математика, делают все эти придирки больше демагогией.ЗЫ хотя на практике тот формат, в котором хранится приватный ключ, делает его именно что приватным и никаким другим.
-
grossws
17 июля 2016 в 01:45
0↑
↓
А в ElGamal, DSA и ECDSA с вашей точки зрения тоже происходит шифрование?
17 июля 2016 в 02:51 (комментарий был изменён)
0↑
↓
С этими схемами я плохо знаком. Речь про RSA и в нем хочешь шифруй приватным, хочешь публичным. Все только на твое усмотрение, какую ты себе выдумал схему. Никто не мешает тебе сделать гибридную схему шифрования, где ключик AES шифруется приватным ключом RSA. Это прекрасно работает и прекрасно поддерживается библиотеками вроде OpenSSL и PolarSSL, которые делают какие угодно преобразования каким угодно ключом. А вот если ты захочешь именно подпись, то эти самые библиотеки за тебя хэш посчитают и его подпишут. Технически это тоже самое шифрование, только наделили его другим смыслом с очень специфической реализацией.
16 июля 2016 в 01:36
0↑
↓
Если говорить про RSA, то сообщение может быть зашифровано с использованием публичного ключа и расшифровано с помощью приватного, но не наоборот
Наоборот тоже можно — там же возведение в степень по основанию. Возводите в степень d по основанию n (из приватного ключа) и отдаете получателю. тот возводит в степень e по основанию n и получает расшифрованный вариант. Можно гонять в любом направлении, лишь бы сумма d и e была равна функции Эйлера от n.
-
grossws
16 июля 2016 в 01:44
0↑
↓
Как я говорил выше, с моей точки зрения, это не по сути шифрование, а подпись.
Можно гонять в любом направлении, лишь бы сумма d и e была равна функции Эйлера от n.
Произведение d и e должно быть равно единице по модулю phi (n), такое странное ограничение на сумму откуда взялось?
16 июля 2016 в 16:00
+1↑
↓
Произведение d и e должно быть равно единице по модулю phi (n),
Нет, ЛЮБОЕ число (от 0 до n-1) в СТЕПЕНИ phi будет равно единице по модулю N, а соотв. в степени phi+1 будет равно самому себе. Но что бы взять эйлера надо знать разложение числа n. На этом и построен принцип ассиметричного шифрования. Тот кто составлял n — знает его эйлера. И он делит Эйлера на две части — d и e (phi = d + e) — одна часть публичная другая закрытая, и неважно какая из них какая. Как правило открытую делают достаточно маленькой, а закрытую — достаточно большой (что бы нельзя было угадать или перебрать). И независимо от того кто шифрует сообщение, он возводит в какую то степень (d или e), а тот кто получил сообщение — продолжает возводить в то значение которое ему известно. В итоге оба участника возведут число в степень равную функции Эйлера (+1 если быть точным) и получат исходное число. Все операции естественно по модулю n.
16 июля 2016 в 05:13
0↑
↓
Я почему всегда считал точно так же, как и автор: то есть эти ключи работают в обе стороны (взаимно обратны), разве нет? И что есть цифровая подпись, как не шифрование (хэша) сообщения приватным ключом и его последующая проверка методом расшифрования публичным с дальнейшим сопоставлением (хэша) первоначального сообщения?16 июля 2016 в 05:23
0↑
↓
Уже после увидел в диалоге с gearbox, что вы просто оперируете понятиями — мы говорим об одних и тех же вещах, но разными словами.
15 июля 2016 в 17:43
0↑
↓
https даёт вам (при условии отсутствия ошибок и эксплуатируемых уязвимостей) две вещи: уверенность в том, что вы общаетесь именно с тем хостом, который себя заявил, и недоступность вашего диалога для прослушивания посередине. Насколько это увеличивает вашу безопасность — вопрос, зависимый от многих других обстоятельств.В качестве основного минуса, https обычно обеспечивает меньшую пропускную способность, чем http, что особенно критично на медленных линиях типа сотовой телефонии. Кроме того, дальше начинаются вопросы с включением внешних ресурсов в защищённые страницы.
Настолько ли важно пользователю вообще различать малозначимые для него сайты vasya1.com и vasya2.com, чтобы защищать аутентичность одного из них — вопрос дискутируемый. Поэтому массовая миграция не содержащих критичной информации сайтов на https не вполне объяснима с рациональных позиций.
fRoStBiT
16 июля 2016 в 06:31
+1↑
↓
А насколько ему важно, чтобы провайдер и другие третьи лица не видели, что он делает на этих сайтах?16 июля 2016 в 10:06
+1↑
↓
> В качестве основного минуса, https обычно обеспечивает меньшую пропускную способность, чем http, что особенно критично на медленных линиях типа сотовой телефонии.
HTTP2 в большинстве пользовательских программ реализован поверх https, а он обеспечивает большую скорость загрузки страниц.
> Поэтому массовая миграция не содержащих критичной информации сайтов на https не вполне объяснима с рациональных позиций.
ПС выводят сайты с https выше, в страницу нельзя внедрить стороннюю рекламу по пути, например, в бесплатных Wi-Fi или у особо наглых провайдерах. Вполне рационально.17 июля 2016 в 02:42
0↑
↓
> ПС выводят сайты с https выше, в страницу нельзя внедрить стороннюю рекламу по пути, например, в бесплатных Wi-Fi или у особо наглых провайдерах. Вполне рационально.Спорно. Для обывателя замена получаемых по DHCP ДНС серверов является проблемой. А это просто может обернуться в замену хостов популярных рекламщиков на свои, подсовывая свои картинки вместо того же adriver.ru. Я бы не сказал, что проблема здесь именно во внедрении рекламы ибо обывателю под час на нее плевать, если она не занимает 100% пространства страницы.
Скорее проблема шире именно с точки зрения не простого подсовывания рекламы, а замены всего содержимого страницы. Или внедрение в нее вредоносного кода.
nmk2002
15 июля 2016 в 17:47
+3↑
↓
Цифровая подпись (Digital Signature) — это часть документа, зашифрованная Приватным ключем Подписчика (Issuer)
Обычно шифруется хэш документа. Если шифровать часть документа, то и обеспечить получится только целостность этой части документа.Выбирается сообщение для шифровки (Message). Что именно шифровать, определяет алгоритм и версия SSL. Для конечного пользователя это неважно, так как все версии шифрования и хэширования также помещаются в сертификат, и при расшифровке эти же версии и используются.
Откуда у вас такая странная информация про создание самоподписанного сертификата? На всякий случай я посмотрел все ссылки, что у вас в источниках, но, к счастью, ничего подобного там не нашел.-
Mingun
15 июля 2016 в 20:07
0↑
↓
Мне кажется, тут автор имел ввиду, что шифруемый хеш в принципе может быть произвольным («хеш» — «алгоритм» у автора), но в версиях SSL указаны предпочтительные алгоритмы хешей. Автор просто попытался рассказать это простыми словами, «для домохозяек». Хорошо или нет получилось — вопрос спорный, но тут необходимо учитывать, что шифрование — это такой тугой клубок нитей, который расплести с наскока нереально. У меня иногда такое впечатление, словно специально пытались усложнить жизнь тем, кто в этом хочет разобраться.
kloppspb
15 июля 2016 в 22:35
+1↑
↓
>Автор просто попытался рассказать это простыми словами, «для домохозяек»Домохозяйкам это вообще нафиг не упало. Ну узнает баба Глаша рецепт тортика тёти Сары, и что?
А если речь идёт о корпоративной СБ, например (или ты — террорист), то нефиг домохозяек до обмена сообщениями допускать :)
-
Mingun
16 июля 2016 в 00:26
0↑
↓
Ага, ага. Безопасность через незнание?
А если речь идёт о корпоративной СБ, например (или ты — террорист), то нефиг домохозяек до обмена сообщениями допускать :)
Да кто вас спрашивать будет, если они до нее доберутся? Лучше пусть знают основы, а не бездумно вытворяют черти что. Лишнее знание никогда не мешает, если оно не устаревшее.
-
kloppspb
16 июля 2016 в 00:52 (комментарий был изменён)
0↑
↓
Да перестаньте. IRL домохозяйкам глубоко этосамое. Как и прочие детали. Ну зачем им вникать в подробности, если нужно обсудить схему полива кактуса в горшке?>Лучше пусть знают основы
Это для вас они «основы» и то, что вы знаете по определению. Попробуйте вынырнуть из хабромира в реальный — сильно удивитесь :)
Ну или для эксперимента подойдите к произвольному человеку в произвольном месте и в произвольное время, и спросите что он знает про отличия HTTP/1 от HTTP/2.
-
Mingun
16 июля 2016 в 16:26
0↑
↓
Похоже, вы слишком буквально восприняли слово «домохозяйка», а я ведь не зря кавычки поставил. Ну хорошо, заменим его на «чайников».
Ну зачем им вникать в подробности, если нужно обсудить схему полива кактуса в горшке?
Правильно, незачем, если они это не спрашивали. Но если уж заинтересовались и спросили, то как-то не гуманно сразу вываливать на них все эти ASN.1, BER, CER, DER, PKCS, PKI, RSA, DES, DH, KEK, CMS и прочая и прочая, вы не находите? Вы же не думаете, что людям, которым криптография в принципе неинтересна, читали статью?
Это для вас они «основы» и то, что вы знаете по определению. Попробуйте вынырнуть из хабромира в реальный — сильно удивитесь :)
С рождения вы ничего не знаете, но ведь научились же как-то клавиатурой пользоваться и даже этот сайт нашли :). И это — действительно основы, описанные простыми словами. Без всяких частностей, типа как тут упоминали выше, что DSA нельзя использовать для шифрования. Это как раз уже продвинутый уровень. Как в школе. Сначала вам говорят, что из меньшего нельзя вычитать большее. Потом вводят отрицательные числа и обнаруживается, что все-таки можно. Аналогичная история повторяется с дробями и корнями из отрицательных чисел, делением на 0 и т.п.
Зная основы, частности можно вывести. Например, я не знаю, что такое DSA (но знаю RSA), но попробую объяснить, почему шифровать им не годится.
Чтобы не было путаницы, договоримся, что ниже слово «шифрование» будет означать сокрытие информации от чужих глаз, в том время как «преобразование шифрования» — просто техническую процедуру преобразования чистого текста в шифрованный.
- Итак, мы знаем, что это асимметричная криптография, а асимметричная криптография всегда имеет 2 ключа — публичный и приватный. Первый отдаем всем, второй храним у себя.
- Шифрование — это преобразование чистого текста в шифротекст. Расшифровка — в обратную сторону. Для каждого преобразования нужен свой ключ.
- Если мы хотим использовать алгоритм (в данном случае DSA) для шифрования, то получить информацию должен только один участник. Так как он отличается от других только наличием приватного ключа, значит, приватным ключом нужно расшифровывать, а публичным шифровать (проводить преобразование шифрования).
- Если мы хотим использовать алгоритм для подписи, то проверять ее должны все, а создавать только один участник. Так как он отличается от других только наличием приватного ключа, значит, приватным ключом нужно шифровать (проводить преобразование шифрования), а публичным расшифровывать.
- Исходя из вышеперечисленного, можно предположить, что в алгоритм DSA использует какие-то данные из приватного ключа для преобразования шифрования, которых нет в публичном ключе. Этим объясняется, почему его можно использовать только в одном преобразовании. Для шифрования с помощью DSA в шифрующем ключе просто нет необходимых данных
- Но что мешает нам поменять местами приватный и публичный ключ, чтобы шифрование с использованием DSA стало возможным? Просто переназвать их и дело в шляпе! Попробуем это объяснить
