| 1.1, нах. (?), 12:44, 22/05/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– | |
ага, тут одни уже sshными ключами доподписывались. Теперь ключи от всего есть еще и у тех, других васянов.
Сколько ж раз твердили миру - не надо совать свой ...й во все подходящие по диаметру дырки, даже если он туда помещается.
| | |
| |
| 2.2, Anonim (??), 14:31, 22/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ну, как бы в сторону владельца закрытого ключа якобы-типа-что-то зашифрованное можно отправить))))
Владелец (там у себя) в обратную же без опубликования развернуть-то сможет.
Зачем сразу по голове ТС то... ))))
| | |
| |
| 3.3, нах. (?), 15:18, 22/05/2024 [^] [^^] [^^^] [ответить]
| –2 +/– | |
нет. Вся суть экспертизы опеннета. Ты нечитатель даже местных горе-новостей.
Одна меееееееленькая ашипочка - и закрытый ключ (бережно хранимый в записной книжечке и зачитываемый вслух только в ночь на ивана кидалу при черных свечах при этом!) стал народным достоянием.
А почему? А вот потому что те кто придумывали технологию - предназначали ЭТОТ ключ строго для одного конкретного применения - и больше ни для какого. И краевые эффекты - за ненадобностью ИМ - не исследовали. Ну а потом уже и некогда было, смузи ж не ждет.
Поэтому добрый совет - используйте криптографию - только и исключительно в той позе, для которой она была предназначена.
Особенно такую сложную и плохо изученную как tls. Достаточно вспомнить массовый факап с дефолтными конфигами openvpn. Тоже tls и тоже сертфикаты. Вот вроде даже - по назначению используемые. И кто бы мог подумать и было ли чем?
В сертификате, если что, есть пункт Extended Key Usages Purposes (НЕ НАДО смотреть на non-extended, это до-v3, диды которые им пользовались уже как их зовут-то не очень помнят, а тем более зачем придумали и что на самом деле оно тогда означало - как водится, совсем не то что написано) - вот если там написано
Server Authentication, Client Authentication - то больше ни для чего такой использовать и не надо.
И выписывать себе сертификаты "Можна всьо" - тоже не надо.
| | |
| |
| 4.4, КриоМух (ok), 06:10, 24/05/2024 [^] [^^] [^^^] [ответить]
| +5 +/– |
 Товарищ Нах, объясни пожалуйста подробно, в чём проблема использования сертификатов под веб-сервер для подписывания или шифрования произвольных данных? Для неспеца в криптографии даже близко.
А то чувствую, что за тобой правда, но для общего развития хочется ещё и подробно понять.
| | |
| |
| 5.8, Аноним (8), 10:48, 27/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Да нет там никакой правды, понятие отрытого-закрытого ключа в криптографии универсальное, и сфера их применения ничем не ограничена, можно серты для сайта генерить, а можно что угодно другое, другой вопрос к алгоритмам генерации ключей факапы бывают везде
| | |
|
| 4.10, Sem (??), 17:00, 29/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Не смотря на название, автор использует не сами сертификаты, а приватный/публичный ключи. Вполне нормальное решение в условиях, когда PGP не взлетело.
| | |
| 4.15, Аноним (15), 15:23, 31/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> выписывать себе сертификаты "Можна всьо" - тоже не надо.
Интересное заявление. А как тогда вообще выписывать сертификаты? Там же постфактум определяется для чего пара ключей сгенерирована.
Ну конкретно в этом примере уязвимость будет уровня - при взломе HTTP-сервера и утечке закрытого ключа для шифрования никому ненужного обмена "сайт-браузер"... в том числе и будут скомпрометированы все выпущенные пакеты какого-нибудь репозитория (который был подписан той же парой ключей). Как бы к
> используйте криптографию - только и исключительно в той позе, для которой она была предназначена.
мало отношения имеет. Тут скорее надо понимать что делаешь и какие будут side-эффекты. Что-то на уровне административной ошибки.
| | |
| |
| 5.16, нах. (?), 21:09, 31/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Интересное заявление. А как тогда вообще выписывать сертификаты?
в смысле? Вот по инструкции и выписывать - Extended Purposes:
Server Authentication, Client Authentication (нет, не спрашивайте меня зачем в серверном сертификате второе поле. "тут так принято")
А если сертификат не для этого - то и из дидового нерасширенного списка что-нибудь лишнее выкидывать (это успешно предотвратит попытку использовать такой сертификат в вебне).
> Ну конкретно в этом примере уязвимость будет уровня - при взломе HTTP-сервера и утечке закрытого
> ключа для шифрования никому ненужного обмена "сайт-браузер"
угу. тем более что модные-молодежные скриптовые автогенераторы обращаются с этими ключами не особенно бережно.
> Тут скорее надо понимать что делаешь и какие будут side-эффекты.
ну вот авторы аж самого putty (с миллионами пользователей) - ну недопоняли и недоучли. Много шансов не ошибиться у отдельного местного васяна занятого в обычной жизни вовсе не криптографией?
Вот и мне кажется что ноль.
| | |
|
|
| 3.5, 1 (??), 15:26, 24/05/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
он не понимает, о чём пишет, не обращай внимания
| | |
| 3.17, Аноним (17), 06:37, 02/06/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>Владелец (там у себя) в обратную же без опубликования развернуть-то сможет.
Обычно к ключу имеют доступ: CDN (ок, допустим CDN'а нет или он собственный), любой человек с доступом веб-сервера на сервере (ок, отправляем на личный сайт, допустим нет сотрудников, но личные сайты обычно и не слишком следят за безопасностью, любой хакер получивший доступ к доступному 24x7 сайту получает и всю переписку), хостер (то есть ничего политического писать не стоит), любой человек который может получить доступ к учетке сертификатора (т.е. хостер почтового ящика/сотовый оператор), удостоверяющий центр.
Т.е. сверхсекретные тайны нацистов от которых зависит чья-то жизнь не отправишь.
Чувствительные для финансов данные тоже.
Котиков конечно можно шифровать, но их лучше шифровать тем же чем и тайны нацистов, иначе легко будет понять что котики закончились.
| | |
|
|
| 1.6, ананас (-), 23:36, 24/05/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
симметрично шифруем любые файлы паролем: openssl enc -in "шифруемое" -out "зашифрованное" -e -salt -aes-256-cbc -md sha256
для расшифровки: -d -aes-256-cbc -md sha256
можно выбрать другой алгоритм шифрования, дайджеста и других параметров в заивисимости от версии утилиты.
openssl enc --help список алгоритмов
openssl dgst -help дайджесты.
| | |
| |
| 2.9, нах. (?), 13:45, 28/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> симметрично шифруем
в статейке речь не о симметричном шифровании (с которым все просто и сравнительно безобидно), а о шифровании/подписи с двумя ключами.
При этом вместо PKI у нас - сертификатик васян-сайтика (проверкой хотя бы его подписанности trusted authority автор то ли не стал заморачиваться вовсе, то ли оставил это студентам для домашнего задания).
| | |
| |
| 3.11, Sem (??), 17:04, 29/05/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ему просто надо зайти на сайт Васяна браузером, что бы понять, можно ли доверять сертификату.
| | |
|
|
| 1.12, Аноним (12), 13:09, 30/05/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Для шифрования и подписей есть GPG. Получить публичный ключ получателя можно с любого PGP keyserver. И консольные команды попроще, и интеграции есть с почтовыми программами и даже мессенджерами. Детские болезни преодолены более 20 лет назад.
Нет ни одной рациональной причины переиспользовать ключи от HTTPS для других применений. Чисто психологически, человеку хочется иметь один ключ для всего. Один пароль для всех сайтов. Так как-будто легче. Но с точки зрения безопасности это абсурд.
| | |
| |
| 2.13, Аноним (13), 14:20, 30/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
А осадочек от преодоления недетской болезни со "слишком большим числом подписей подписи" у вас точно не остался?
(нет, разумеется это не повод использовать ключи https не по назначению. Просто обратите внимание - на той полянке тоже не только цветочки и единороги. Можно вступить в лепеху.)
| | |
| |
| 3.14, Аноним (14), 23:23, 30/05/2024 [^] [^^] [^^^] [ответить]
| +/– | |
WOT конечно утопическая немного история и ее на практике невероятно сложно построить, но это все равно лучше, чем по факту ничего в SSL.
Для подписывания сообщений в рассылке или чате PGP подходит вполне. Модель доверия к продолжительно добросовестному подписанту вполне имеет место, часто ее достаточно.
Главный минус PGP и его инфраструктуры в том, что их редко используют правильно. Люди плохо понимают проблематику обращения ключей и их использования. И тем не менее, это отличная отправная точка, чтобы научиться работать с криптографией. Разобраться в этом не займет так много времени.
| | |
|
|
|