The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Использование HTTPS-сертификатов для шифрования и подписи произвольных данных
Созданные для 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
 
22.05.2024 , Автор: Dennis Yurichev , Источник: https://yurichev.com/n/HTTPS_certs/...
Ключи: https, cert, crypt, sign, openssl
Раздел:    Корень / Безопасность / Шифрование, PGP

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, нах. (?), 12:44, 22/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    ага, тут одни уже sshными ключами доподписывались. Теперь ключи от всего есть еще и у тех, других васянов.

    Сколько ж раз твердили миру - не надо совать свой ...й во все подходящие по диаметру дырки, даже если он туда помещается.


     
     
  • 2.2, Anonim (??), 14:31, 22/05/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, как бы в сторону владельца закрытого ключа якобы-типа-что-то зашифрованное можно отправить))))
    Владелец (там у себя) в обратную же без опубликования развернуть-то  сможет.
    Зачем сразу по голове ТС то... ))))
     
     
  • 3.3, нах. (?), 15:18, 22/05/2024 [^] [^^] [^^^] [ответить]  
  • –5 +/
    нет Вся суть экспертизы опеннета Ты нечитатель даже местных горе-новостей Одн... большой текст свёрнут, показать
     
     
  • 4.4, КриоМух (ok), 06:10, 24/05/2024 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Товарищ Нах, объясни пожалуйста подробно, в чём проблема использования сертификатов под веб-сервер для подписывания или шифрования произвольных данных? Для неспеца в криптографии даже близко.
    А то чувствую, что за тобой правда, но для общего развития хочется ещё и подробно понять.
     
     
  • 5.8, Аноним (8), 10:48, 27/05/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да нет там никакой правды, понятие отрытого-закрытого ключа в криптографии универсальное, и сфера их применения ничем не ограничена, можно серты для сайта генерить, а можно что угодно другое, другой вопрос к алгоритмам генерации ключей факапы бывают везде
     
     
  • 6.21, gogo (?), 08:57, 12/06/2024 [^] [^^] [^^^] [ответить]  
  • +/
    так-то оно так. но нах про другое говорит.
    вот кто-то подписал тебе письмо. чтобы его расшифровать, тебе нужно либо на веб-сервер лезть и там от рута (ключ обычно только рут читать может) с чужими данными манипуляции производить, или копировать закрытый ключ с сервера, чтобы расшифровать у себя в рабочем окружении.
    и то, и то есть снижением уровня безопасности. не сказать, что это прям дыра-дырища, но вполне годно как звено в какую-то цепочку эксплойта.
     
  • 5.35, iav (ok), 19:00, 12/10/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 (с миллионами пользователей) - ну недопоняли и недоучли. Много шансов не ошибиться у отдельного местного васяна занятого в обычной жизни вовсе не криптографией?

    Вот и мне кажется что ноль.

     
     
  • 6.31, Бублик (?), 15:15, 29/08/2024 [^] [^^] [^^^] [ответить]  
  • +/
    а что не так с путти-ным? пользуюсь им 20+ лет уже... неужели утечка ключей? о_о
     
     
  • 7.33, Аноним (33), 11:28, 31/08/2024 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.opennet.ru/opennews/art.shtml?num=60998
     
  • 3.5, 1 (??), 15:26, 24/05/2024 [^] [^^] [^^^] [ответить]  
  • +2 +/
    он не понимает, о чём пишет, не обращай внимания
     
  • 3.17, Аноним (17), 06:37, 02/06/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >Владелец (там у себя) в обратную же без опубликования развернуть-то  сможет.

    Обычно к ключу имеют доступ: CDN (ок, допустим CDN'а нет или он собственный), любой человек с доступом веб-сервера на сервере (ок, отправляем на личный сайт, допустим нет сотрудников, но личные сайты обычно и не слишком следят за безопасностью, любой хакер получивший доступ к доступному 24x7 сайту получает и всю переписку), хостер (то есть ничего политического писать не стоит), любой человек который может получить доступ к учетке сертификатора (т.е. хостер почтового ящика/сотовый оператор), удостоверяющий центр.

    Т.е. сверхсекретные тайны нацистов от которых зависит чья-то жизнь не отправишь.
    Чувствительные для финансов данные тоже.
    Котиков конечно можно шифровать, но их лучше шифровать тем же чем и тайны нацистов, иначе легко будет понять что котики закончились.

     
  • 2.36, Аноним (36), 08:07, 07/11/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Не в курсе истории.
     

  • 1.6, ананас (-), 23:36, 24/05/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    симметрично шифруем любые файлы паролем: 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 [^] [^^] [^^^] [ответить]  
  • +/
    Ему просто надо зайти на сайт Васяна браузером, что бы понять, можно ли доверять сертификату.
     
  • 3.22, gogo (?), 09:01, 12/06/2024 [^] [^^] [^^^] [ответить]  
  • +/

    > При этом вместо PKI у нас

    чем pki такой кошерный?
    x509 точно также можно зашифровать.

     
  • 3.30, Бублик (?), 15:13, 29/08/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Вы интересную проблему затронули. Особенно с учётом того, что 80% масс-интернета (и даже корпоративки и муниципалки) шифруется от издателя Letsencrypt. Который, ВНЕЗАПНО, может стать дырявым горшком и тыквой в определённый лунный час ... хм...
     

  • 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 и его инфраструктуры в том, что их редко используют правильно. Люди плохо понимают проблематику обращения ключей и их использования. И тем не менее, это отличная отправная точка, чтобы научиться работать с криптографией. Разобраться в этом не займет так много времени.

     
  • 2.18, Аноним (18), 22:48, 05/06/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Для шифрования и подписей есть GPG.

    Есть-то он есть, но в то же самое время его как бы и нет. Такой вот кот Шрёдингера. Есть в том смысле, что софт написан, алгоритмы известны и проверены, и даже сервера ключей существуют пока ещё. А нет его в банальном практическом смысле: пользователей меньше, чем у десктопного Линукса. И интеграций с реально используемыми в мире почтовыми программами (Gmail, Gmail, Outlook365, Gmail и ещё Gmail) не существует. Но три с половиной гика пользуются, а то и больше! Я даже на Key Signing Party как-то раз был, где люди на полном серьёзе проверяли друг у друга паспорта, а у кого паспорта с собой не было — верили ксерокопии, а то и даже на слово. Мне тогда ключ на имя Брюса Вейна заверил какой-то худощавый парень в очках. Но с точки зрения безопасности это абсурд.

     
     
  • 3.19, Аноним (19), 00:04, 06/06/2024 [^] [^^] [^^^] [ответить]  
  • +/
    >пользователей меньше, чем у десктопного Линукса

    Ну и что теперь? Вам или нужно пользоваться криптографией, или не нужно и вы вместе со стадом не пользуетесь вообще никакой.
    Интеграция на самом деле не требуется, gpg работает и с простым текстом, скопированным туда-сюда. Было бы желание!

    >верили ксерокопии, а то и даже на слово. Мне тогда ключ на имя Брюса Вейна заверил какой-то худощавый парень в очках

    Лучше, чем ничего. Альтернативы какие? Верить государству, верить сотовым операторам, верить корпорациям с их датой. Я лучше буду верить людям.
    >проверяли друг у друга паспорта

    Осуждаю, кстати. Любой человек может сменить ФИО на произвольные и потом с паспортом выдать себя за кого-то еще. Паспорт страны-помойки можно купить за несколько сотен баксов.

     
     
  • 4.20, Аноним (20), 10:38, 11/06/2024 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Верить государству, верить сотовым операторам, верить корпорациям с их датой.

    жрать захочешь - поверишь кому угодно. компьютеры (к сожалению или наоборот - тот еще вопрос) пока еще не съедобные.

     
  • 3.23, Vikarti Anatra (ok), 12:01, 20/06/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Mailvelope, FlowCrypt
    И все работает с Gmail (то что надо расширение к браузеру ставить - ну так gmail ж)
    Если есть возможность поставить нормальные софт а не браузер - Thunderbird или eM Client на десктопе (и с gmail тоже работает)(ладно - emM client под Linux не работает и платный), и Aqua Mail и eM client на Android.

     
  • 2.28, ffsdmad (ok), 14:43, 19/08/2024 [^] [^^] [^^^] [ответить]  
  • +/
    Допустим, нужно побыстрому встроить шифрование в программу на esp32 и качнуть доступный pkey и зашифровать сильно проще чем заморачиваться с gpg
     
  • 2.34, Аноним (34), 12:59, 03/10/2024 [^] [^^] [^^^] [ответить]  
  • +/
    > Для шифрования и подписей есть GPG.

    Может и есть, но с развитием аппаратного шифрования его архитектура становится неудобной.

     


     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру