Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Раздел полезных советов: Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
Сообщение от auto_tips (?), 22-Май-24, 12:44
Созданные для HTTPS сертификаты вполне можно использовать для формирования цифровых подписей к произвольным данным, а также для шифрования по открытым ключам. ++ Создание подписи. Имеем следующие файлы с сертификатами от Let's Encrypt:    /etc/letsencrypt/live/site.com# ls -la    ...    lrwxrwxrwx  1 root root   42 May  22 8:11 cert.pem -> ../../archive/site.com-0001/cert43.pem    lrwxrwxrwx  1 root root   43 May  22 8:11 chain.pem -> ../../archive/site.com-0001/chain43.pem    lrwxrwxrwx  1 root root   47 May  22 8:11 fullchain.pem -> ../../archive/site.com-0001/fullchain43.pem    lrwxrwxrwx  1 root root   45 May  22 8:11 privkey.pem -> ../../archive/site.com-0001/privkey43.pem    ... Для заверения цифровой подписью файла msg.txt можно использовать закрытый ключ из файла privkey.pem:    openssl dgst -sha256 -sign privkey.pem -out msg.txt.sig msg.txt После чего полученную подпись можно преобразовать в текстовое представление в кодировке Base64:    openssl base64 -in msg.txt.sig -out msg.txt.sig.asc Далее можно опубликовать файлы msg.txt и msg.txt.sig.asc, а сторонние пользователи могут воспользоваться открытым ключом от домена site.com для верификации неизменности содержимого msg.txt: Загружаем открытый ключ сайта site.com  в файл pubkey.pem:    openssl s_client -connect site.com:443 -showcerts | openssl x509 -pubkey -noout > pubkey.pem Преобразуем цифровую подпись в бинарный формат и верифицируем открытым ключом:    openssl base64 -d -in msg.txt.sig.asc -out msg.txt.sig    openssl dgst -keyform pem -verify pubkey.pem -signature msg.txt.sig msg.txt    Verified OK ++ Шифрование Сторонний пользователь может воспользоваться открытым ключом от домена site.com для шифрования данных, которые следует передать владельцу домена site.com, имеющему доступ к закрытому ключу.    openssl pkeyutl -in msg.txt -out msg.enc -pubin -inkey pubkey.pem -encrypt Преобразуем зашифрованный бинарный файл в текстовое представление для передачи по электронной почте или через мессенджер:    openssl base64 -in msg.enc -out msg.enc.asc Владелец закрытого ключа может расшифровать сообщение используя команды:    openssl base64 -d -in msg.enc.asc -out msg.enc    openssl pkeyutl -in msg.enc -out msg.txt -inkey privkey.pem -decrypt URL: https://yurichev.com/n/HTTPS_certs/ Обсуждается: http://www.opennet.me/tips/info/3251.shtml
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	–7 +/–
Сообщение от нах. (?), 22-Май-24, 12:44
ага, тут одни уже sshными ключами доподписывались. Теперь ключи от всего есть еще и у тех, других васянов. Сколько ж раз твердили миру - не надо совать свой ...й во все подходящие по диаметру дырки, даже если он туда помещается.
Ответить | Правка | Наверх | Cообщить модератору

	2. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от Anonim (??), 22-Май-24, 14:31
	Ну, как бы в сторону владельца закрытого ключа якобы-типа-что-то зашифрованное можно отправить)))) Владелец (там у себя) в обратную же без опубликования развернуть-то  сможет. Зачем сразу по голове ТС то... ))))
	Ответить | Правка | Наверх | Cообщить модератору

	3. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	–5 +/–
	Сообщение от нах. (?), 22-Май-24, 15:18
	нет. Вся суть экспертизы опеннета. Ты нечитатель даже местных горе-новостей. Одна меееееееленькая ашипочка - и закрытый ключ (бережно хранимый в записной книжечке и зачитываемый вслух только в ночь на ивана кидалу при черных свечах при этом!) стал народным достоянием. А почему? А вот потому что те кто придумывали технологию - предназначали ЭТОТ ключ строго для одного конкретного применения - и больше ни для какого. И краевые эффекты - за ненадобностью ИМ - не исследовали. Ну а потом уже и некогда было, смузи ж не ждет. Поэтому добрый совет - используйте криптографию - только и исключительно в той позе, для которой она была предназначена. Особенно такую сложную и плохо изученную как tls. Достаточно вспомнить массовый факап с дефолтными конфигами openvpn. Тоже tls и тоже сертфикаты. Вот вроде даже - по назначению используемые. И кто бы мог подумать и было ли чем? В сертификате, если что, есть пункт Extended Key Usages Purposes (НЕ НАДО смотреть на non-extended, это до-v3, диды которые им пользовались уже как их зовут-то не очень помнят, а тем более зачем придумали и что на самом деле оно тогда означало - как водится, совсем не то что написано) - вот если там написано Server Authentication, Client Authentication - то больше ни для чего такой использовать и не надо. И выписывать себе сертификаты "Можна всьо" - тоже не надо.
	Ответить | Правка | Наверх | Cообщить модератору

	4. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+6 +/–
	Сообщение от КриоМух (ok), 24-Май-24, 06:10
	Товарищ Нах, объясни пожалуйста подробно, в чём проблема использования сертификатов под веб-сервер для подписывания или шифрования произвольных данных? Для неспеца в криптографии даже близко. А то чувствую, что за тобой правда, но для общего развития хочется ещё и подробно понять.
	Ответить | Правка | Наверх | Cообщить модератору

	8. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+2 +/–
	Сообщение от Аноним (8), 27-Май-24, 10:48
	Да нет там никакой правды, понятие отрытого-закрытого ключа в криптографии универсальное, и сфера их применения ничем не ограничена, можно серты для сайта генерить, а можно что угодно другое, другой вопрос к алгоритмам генерации ключей факапы бывают везде
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от gogo (?), 12-Июн-24, 08:57
	так-то оно так. но нах про другое говорит. вот кто-то подписал тебе письмо. чтобы его расшифровать, тебе нужно либо на веб-сервер лезть и там от рута (ключ обычно только рут читать может) с чужими данными манипуляции производить, или копировать закрытый ключ с сервера, чтобы расшифровать у себя в рабочем окружении. и то, и то есть снижением уровня безопасности. не сказать, что это прям дыра-дырища, но вполне годно как звено в какую-то цепочку эксплойта.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от iav (ok), 12-Окт-24, 19:00
	Например, ключ может поменяться по каким-то неочевидным и неожиданным причинам. А старый не сохранится. Просто потому, что — а зачем бы его сохранять? Или потому, что одно доменное имя обслуживается несколькими серверами, и у разных серверов эти ключи и сертификаты разные. Просто потому, что — ну вот так было удобнее, а почему нет-то?
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	10. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от Sem (??), 29-Май-24, 17:00
	Не смотря на название, автор использует не сами сертификаты, а приватный/публичный ключи. Вполне нормальное решение в условиях, когда PGP не взлетело.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	15. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от Аноним (15), 31-Май-24, 15:23
	> выписывать себе сертификаты "Можна всьо" - тоже не надо. Интересное заявление. А как тогда вообще выписывать сертификаты? Там же постфактум определяется для чего пара ключей сгенерирована. Ну конкретно в этом примере уязвимость будет уровня - при взломе HTTP-сервера и утечке закрытого ключа для шифрования никому ненужного обмена "сайт-браузер"... в том числе и будут скомпрометированы все выпущенные пакеты какого-нибудь репозитория (который был подписан той же парой ключей). Как бы к > используйте криптографию - только и исключительно в той позе, для которой она была предназначена. мало отношения имеет. Тут скорее надо понимать что делаешь и какие будут side-эффекты. Что-то на уровне административной ошибки.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	16. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от нах. (?), 31-Май-24, 21:09
	> Интересное заявление. А как тогда вообще выписывать сертификаты? в смысле? Вот по инструкции и выписывать - Extended Purposes: Server Authentication, Client Authentication (нет, не спрашивайте меня зачем в серверном сертификате второе поле. "тут так принято") А если сертификат не для этого - то и из дидового нерасширенного списка что-нибудь лишнее выкидывать (это успешно предотвратит попытку использовать такой сертификат в вебне). > Ну конкретно в этом примере уязвимость будет уровня - при взломе HTTP-сервера и утечке закрытого > ключа для шифрования никому ненужного обмена "сайт-браузер" угу. тем более что модные-молодежные скриптовые автогенераторы обращаются с этими ключами не особенно бережно. > Тут скорее надо понимать что делаешь и какие будут side-эффекты. ну вот авторы аж самого putty (с миллионами пользователей) - ну недопоняли и недоучли. Много шансов не ошибиться у отдельного местного васяна занятого в обычной жизни вовсе не криптографией? Вот и мне кажется что ноль.
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от Бублик (?), 29-Авг-24, 15:15
	а что не так с путти-ным? пользуюсь им 20+ лет уже... неужели утечка ключей? о_о
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от Аноним (33), 31-Авг-24, 11:28
	https://www.opennet.me/opennews/art.shtml?num=60998
	Ответить | Правка | Наверх | Cообщить модератору

	5. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+2 +/–
	Сообщение от 1 (??), 24-Май-24, 15:26
	он не понимает, о чём пишет, не обращай внимания
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	17. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от Аноним (17), 02-Июн-24, 06:37
	>Владелец (там у себя) в обратную же без опубликования развернуть-то  сможет. Обычно к ключу имеют доступ: CDN (ок, допустим CDN'а нет или он собственный), любой человек с доступом веб-сервера на сервере (ок, отправляем на личный сайт, допустим нет сотрудников, но личные сайты обычно и не слишком следят за безопасностью, любой хакер получивший доступ к доступному 24x7 сайту получает и всю переписку), хостер (то есть ничего политического писать не стоит), любой человек который может получить доступ к учетке сертификатора (т.е. хостер почтового ящика/сотовый оператор), удостоверяющий центр. Т.е. сверхсекретные тайны нацистов от которых зависит чья-то жизнь не отправишь. Чувствительные для финансов данные тоже. Котиков конечно можно шифровать, но их лучше шифровать тем же чем и тайны нацистов, иначе легко будет понять что котики закончились.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	36. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от Аноним (36), 07-Ноя-24, 08:07
	Не в курсе истории.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

6. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+2 +/–
Сообщение от ананас (-), 24-Май-24, 23:36
симметрично шифруем любые файлы паролем: openssl enc -in "шифруемое" -out "зашифрованное" -e -salt -aes-256-cbc -md sha256 для расшифровки: -d -aes-256-cbc -md sha256 можно выбрать другой алгоритм шифрования, дайджеста и других параметров в заивисимости от версии утилиты. openssl enc --help список алгоритмов openssl dgst -help дайджесты.
Ответить | Правка | Наверх | Cообщить модератору

	9. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от нах. (?), 28-Май-24, 13:45
	> симметрично шифруем в статейке речь не о симметричном шифровании (с которым все просто и сравнительно безобидно), а о шифровании/подписи с двумя ключами. При этом вместо PKI у нас - сертификатик васян-сайтика (проверкой хотя бы его подписанности trusted authority автор то ли не стал заморачиваться вовсе, то ли оставил это студентам для домашнего задания).
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от Sem (??), 29-Май-24, 17:04
	Ему просто надо зайти на сайт Васяна браузером, что бы понять, можно ли доверять сертификату.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от gogo (?), 12-Июн-24, 09:01
	> При этом вместо PKI у нас чем pki такой кошерный? x509 точно также можно зашифровать.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	30. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от Бублик (?), 29-Авг-24, 15:13
	Вы интересную проблему затронули. Особенно с учётом того, что 80% масс-интернета (и даже корпоративки и муниципалки) шифруется от издателя Letsencrypt. Который, ВНЕЗАПНО, может стать дырявым горшком и тыквой в определённый лунный час ... хм...
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

12. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+1 +/–
Сообщение от Аноним (12), 30-Май-24, 13:09
Для шифрования и подписей есть GPG. Получить публичный ключ получателя можно с любого PGP keyserver. И консольные команды попроще, и интеграции есть с почтовыми программами и даже мессенджерами. Детские болезни преодолены более 20 лет назад. Нет ни одной рациональной причины переиспользовать ключи от HTTPS для других применений. Чисто психологически, человеку хочется иметь один ключ для всего. Один пароль для всех сайтов. Так как-будто легче. Но с точки зрения безопасности это абсурд.
Ответить | Правка | Наверх | Cообщить модератору

	13. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от Аноним (13), 30-Май-24, 14:20
	А осадочек от преодоления недетской болезни со "слишком большим числом подписей подписи" у вас точно не остался? (нет, разумеется это не повод использовать ключи https не по назначению. Просто обратите внимание - на той полянке тоже не только цветочки и единороги. Можно вступить в лепеху.)
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от Аноним (14), 30-Май-24, 23:23
	WOT конечно утопическая немного история и ее на практике невероятно сложно построить, но это все равно лучше, чем по факту ничего в SSL. Для подписывания сообщений в рассылке или чате PGP подходит вполне. Модель доверия к продолжительно добросовестному подписанту вполне имеет место, часто ее достаточно. Главный минус PGP и его инфраструктуры в том, что их редко используют правильно. Люди плохо понимают проблематику обращения ключей и их использования. И тем не менее, это отличная отправная точка, чтобы научиться работать с криптографией. Разобраться в этом не займет так много времени.
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от Аноним (18), 05-Июн-24, 22:48
	> Для шифрования и подписей есть GPG. Есть-то он есть, но в то же самое время его как бы и нет. Такой вот кот Шрёдингера. Есть в том смысле, что софт написан, алгоритмы известны и проверены, и даже сервера ключей существуют пока ещё. А нет его в банальном практическом смысле: пользователей меньше, чем у десктопного Линукса. И интеграций с реально используемыми в мире почтовыми программами (Gmail, Gmail, Outlook365, Gmail и ещё Gmail) не существует. Но три с половиной гика пользуются, а то и больше! Я даже на Key Signing Party как-то раз был, где люди на полном серьёзе проверяли друг у друга паспорта, а у кого паспорта с собой не было — верили ксерокопии, а то и даже на слово. Мне тогда ключ на имя Брюса Вейна заверил какой-то худощавый парень в очках. Но с точки зрения безопасности это абсурд.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	19. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от Аноним (19), 06-Июн-24, 00:04
	>пользователей меньше, чем у десктопного Линукса Ну и что теперь? Вам или нужно пользоваться криптографией, или не нужно и вы вместе со стадом не пользуетесь вообще никакой. Интеграция на самом деле не требуется, gpg работает и с простым текстом, скопированным туда-сюда. Было бы желание! >верили ксерокопии, а то и даже на слово. Мне тогда ключ на имя Брюса Вейна заверил какой-то худощавый парень в очках Лучше, чем ничего. Альтернативы какие? Верить государству, верить сотовым операторам, верить корпорациям с их датой. Я лучше буду верить людям. >проверяли друг у друга паспорта Осуждаю, кстати. Любой человек может сменить ФИО на произвольные и потом с паспортом выдать себя за кого-то еще. Паспорт страны-помойки можно купить за несколько сотен баксов.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+1 +/–
	Сообщение от Аноним (20), 11-Июн-24, 10:38
	> Верить государству, верить сотовым операторам, верить корпорациям с их датой. жрать захочешь - поверишь кому угодно. компьютеры (к сожалению или наоборот - тот еще вопрос) пока еще не съедобные.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от Vikarti Anatra (ok), 20-Июн-24, 12:01
	Mailvelope, FlowCrypt И все работает с Gmail (то что надо расширение к браузеру ставить - ну так gmail ж) Если есть возможность поставить нормальные софт а не браузер - Thunderbird или eM Client на десктопе (и с gmail тоже работает)(ладно - emM client под Linux не работает и платный), и Aqua Mail и eM client на Android.
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	28. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от ffsdmad (ok), 19-Авг-24, 14:43
	Допустим, нужно побыстрому встроить шифрование в программу на esp32 и качнуть доступный pkey и зашифровать сильно проще чем заморачиваться с gpg
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	34. "Использования HTTPS-сертификатов для шифрования и подписи произвольных данных"	+/–
	Сообщение от Аноним (34), 03-Окт-24, 12:59
	> Для шифрования и подписей есть GPG. Может и есть, но с развитием аппаратного шифрования его архитектура становится неудобной.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема