OpenSSL
OpenSSL — инструмент разработки, который предназначен для реализации криптографических протоколов SSL и TLS в ваших проектах.
Описание:
При помощи OpenSSL вы можете значительно повысить уровень защиты своих проектов, благодаря внедрению поддержки протоколов TLS и SSL. Эти протоколы широко используются для обеспечения безопасности интернет-соединения с использованием шифрования данных, а также путём создания сложных ключей аутентификации.
При этом, поддерживаются практически все низкоуровневые алгоритмы хеширования, шифрования и электронной подписи. А также OpenSSL позволит создавать ключи RSA, DH, DSA, сертификаты X.509, подписывать их, формировать CSR и CRT, шифровать данные и тестировать SSL/TLS соединения. Стоит отметить, что инструменты, входящие в состав пакета, могут использоваться только в консоли. Это делает использование OpenSSL затруднительным для начинающих пользователей. Тем не менее, в сети можно найти подробную информацию о реализации алгоритмов и ответы на прочие интересующие вопросы.
Как обеспечить конфиденциальность: шифрование и расшифровку данных с помощью OpenSSL
Источник: freesoft.ru
Советы и трюки по работе с OpenSSL
Скорее всего, вы уже знакомы с OpenSSL как с библиотекой, которая дает возможность работать по протоколу SSL. Помимо библиотеки в составе OpenSSL идет полезная утилита для работы с командной строкой, которая используется при администрировании SSL/PKI. Сам этот инструмент плохо задокументирован, и цель данной статьи — немного рассказать о полезных советах и трюках по работе с OpenSSL в виде «поваренной книги».
Команда для подписания запроса:
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Смотрим обновленное содержимое директории:
$ ls
ca.cnf certs index.txt.attr serial
cacert.pem index.txt.old serial.old
cakey.pem index.txt signed.pem
Были добавлены новые файлы: index.txt.attr, index.txt.old и serial.old
Также в директории certs появилась копия подписанного сертификат:
Этот файл идентичен файлу signed.pem.
Следует отметить на поле subject у подписанного сертификата:
$ openssl x509 -in signed.pem -noout -subject
subject= /CN=Joshua Davies
Оно не совпадает с тем же самым полем из запроса:
Причина в содержимом раздела [ policy ], который находится в конфигурационном файле. Там я указал, чтобы выводился только атрибут commonName. Если бы я заходил отобразить другие атрибуты, то указал бы их отдельно:
countryName = optional
stateOrProvinceName = optional
Важно отметить, что поле subject подписанного сертификата необязательно будет совпадать с полем subject у запроса. Идентичным является лишь публичный ключ.
В этой минимальной конфигурации нашего центра сертификации отсутствуют другие важные возможности. Например, я не добавил поддержку аннулирования сертификатов. В данном случае моей целью было продемонстрировать вам на наглядном примере, как происходит процесс подписи, а не показать стабильное рабочее решение готового центра сертификации.
Что такое SSL-сертификат, зачем он нужен и где его взять
Подписание сертификата с начальной прошлой датой
При работе с сертификатами я столкнулся с проблемой, связанной с часовыми поясами. По умолчанию при подписании сертификата используется часовой пояс сервера. Бывали случаи, когда сертификат, созданный в часовом поясе восточном побережья, не устанавливался на сервере, находящимся на западном. Конечно, проблема не столь критична, но слегка раздражает. В OpenSSL команда ca позволяет указать начальную дату задним числом:
$ openssl ca -in csr.pem -startdate 140529000000Z
Передача информации для поля subject через командную строку
Если у вас уже есть некоторый опыт по созданию тестовых сертификатов (или даже отправки запроса в центр сертификации), то, возможно, вы заметили, что немного раздражает постоянно указывать поля country, state, locality, и т. д. Вы можете передать эту информацию через командную строку при помощи следующего скрипта:
if [$# -ne 1]
then
echo «Usage: $0 »
exit
fi
openssl req -subj /C=US/ST=Texas/L=Plano/O=2xoffice/OU=Architecture/CN=$1
Источник: www.securitylab.ru
Основы OpenSSL: SSL-сертификаты, закрытые ключи и запросы на подпись
OpenSSL – это многофункциональный инструмент командной строки, предназначенный для управления инфраструктурой открытых ключей (PKI) и HTTPS.
Данное руководство предлагает вам краткий обзор команд OpenSSL, а также примеры использования и генерирования закрытых ключей, запросов на подпись сертификатов и изменения формата сертификата.
Запросы на подпись сертификатов (CSR)
Чтобы получить SSL-сертификат от центра сертификации (ЦС), нужно сначала создать запрос на подпись сертификата (CSR). CSR включает в себя открытый ключ и некоторые дополнительные данные. При подписи эти данные добавляются в сертификат.
Чтобы сгенерировать запрос на подпись сертификата, нужно предоставить данные о сертификате. В частности важно правильно заполнить поле Common Name (CN) в разделе Distinguised Name, в котором нужно указать FQDN хоста, для которого предназначается сертификат. Чтобы обойти интерактивные подсказки, можно передать все запрашиваемые данные через командную строку.
Другие поля в разделе Distinguised Name запрашивают данные об организации или компании. Если вы заказываете сертификат в ЦС, эти поля, как правило, нужно обязательно заполнить.
Запрос на подпись сертификата имеет такой вид:
—
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:New York
Locality Name (eg, city) []:Brooklyn
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example Brooklyn Company
Organizational Unit Name (eg, section) []:Technology Division
Common Name (e.g. server FQDN or YOUR name) []:examplebrooklyn.com
Email Address []:
Чтобы ответить на запросы CSR в неинтерактивном режиме, добавьте в команду опцию –subj, например:
-subj «/C=US/ST=New York/L=Brooklyn/O=Example Brooklyn Company/CN=examplebrooklyn.com»
Ознакомившись с запросами на подпись сертификата, вы можете перейти к любому другому разделу руководства.
Генерирование запроса на подпись сертификата
Генерирование закрытого ключа и запроса
Этот метод позволяет вам подписать сертификат в ЦС и защитить веб-сервер Apache или Nginx с помощью HTTPS. Сгенерированный запрос на подпись можно отправить в ЦС, чтобы получить подписанный сертификат. Если ЦС поддерживает SHA-2, добавьте опцию -sha256.
Следующая команда создаст 2048-битный закрытый ключ (domain.key) и CSR (domain.csr):
openssl req
-newkey rsa:2048 -nodes -keyout domain.key
-out domain.csr
Заполните поля в запросе на подпись.
Опция -newkey rsa:2048 создаст 2048-битный RSA-ключ. Опция –nodes отключает пароль для закрытого ключа.
Генерирование запроса для существующего закрытого ключа
Если у вас уже есть закрытый ключ, но нет сертификата, вы можете сгенерировать запрос для этого ключа.
Следующая команда создаст запрос сертификата (domain.csr) для существующего ключа (domain.key):
openssl req
-key domain.key
-new -out domain.csr
Ответьте на запросы программы, чтобы продолжить. Опция –new указывает, что запрос нужно сгенерировать.
Генерирование запроса для существующего сертификата и ключа
Этот метод позволяет обновить существующий сертификат, если оригинальный запрос на подпись сертификата был утерян.
Следующая команда создаст запрос (domain.csr) на основе существующего сертификата (domain.crt) и закрытого ключа (domain.key):
openssl x509
-in domain.crt
-signkey domain.key
-x509toreq -out domain.csr
Опция -x509toreq создаст сертификат X509.
Генерирование SSL-сертификата
Если вы хотите защитить свой сервис, но не хотите подписывать его в ЦС, вы можете создать и подписать сертификат самостоятельно.
Такие сертификаты называются самоподписанными.
По сути, самоподписанный сертификат – это сертификат, подписанный своим собственным закрытым ключом. Такие сертификаты тоже шифруют соединения, однако они не подтверждают подлинности сайта, потому пользователи, которые открывают сайт, увидят предупреждение.
Если вам ненужно подтверждать подлинность сайта, вы можете спокойно использовать самоподписанные сертификаты.
Генерирование самоподписанного сертификата
Этот метод позволяет защитить веб-сервер Apache или Nginx с помощью HTTPS.
Следующая команда создаст 2048-битный закрытый ключ (domain.key) и CSR (domain.csr):
openssl req
-newkey rsa:2048 -nodes -keyout domain.key
-x509 -days 365 -out domain.crt
Заполните запрос на подпись.
Опция -x509 создаёт самоподписанный сертификат. Опция -days 365 задаёт срок действия сертификата в днях.
Создание сертификата для существующего закрытого ключа
Если у вас уже есть закрытый ключ, но нет сертификата, вы можете сгенерировать сертификат для этого ключа.
Следующая команда создаст сертификат (domain.csr) для существующего ключа (domain.key):
openssl req
-key domain.key
-new
-x509 -days 365 -out domain.crt
Ответьте на запросы программы, чтобы продолжить.
- Опция -x509 создаёт самоподписанный сертификат. Опция -days 365 задаёт срок действия сертификата в днях.
- Опция –new запускает запрос данных для создания CSR.
Генерирование запроса для существующего сертификата и ключа
Этот метод позволяет создать сертификат, если у вас уже есть закрытый ключ и запрос на подпись сертификата.
Следующая команда создаст сертификат (domain.crt) на основе существующего запроса (domain.csr) и закрытого ключа (domain.key):
openssl x509
-signkey domain.key
-in domain.csr
-req -days 365 -out domain.crt
Опция -days 365 задаёт срок действия сертификата в днях.
Просмотр сертификатов
Файлы сертификатов и запросов на подпись закодированы в формате PEM, который не может быть прочитан человеком.
Данный раздел научит вас читать такие файлы с помощью ряда команд.
Просмотр CSR
Эта команда позволяет просмотреть содержимое файла запроса на подпись сертификата в виде простого текста:
openssl req -text -noout -verify -in domain.csr
Просмотр сертификата
Следующая команда позволяет просмотреть содержимое сертификата в виде простого текста:
openssl x509 -text -noout -in domain.crt
Проверка подписи сертификата
Чтобы убедиться, что сертификат был подписан в ЦС, введите:
openssl verify -verbose -CAFile ca.crt domain.crt
Закрытые ключи
Создание закрытого ключа
Чтобы создать закрытый 2048-битный ключ, защищённый паролем, введите:
openssl genrsa -des3 -out domain.key 2048
По запросу введите пароль, чтобы продолжить.
Проверка закрытого ключа
Эта команда подтвердит валидность закрытого ключа:
openssl rsa -check -in domain.key
Если ключ зашифрован, программа запросит парольную фразу. Предоставьте пароль от ключа, чтобы просмотреть его в незашифрованном формате.
Совпадение ключа с сертификатом и запросом
Эта команда позволяет узнать, относится ли закрытый ключ (domain.key) к тому или иному сертификату (domain.crt) и запросу (domain.csr):
openssl rsa -noout -modulus -in domain.key | openssl md5
openssl x509 -noout -modulus -in domain.crt | openssl md5
openssl req -noout -modulus -in domain.csr | openssl md5
Если команды вернули одинаковый вывод, то, скорее всего, этот ключ, запрос и сертификат связаны.
Шифрование закрытого ключа
Следующая команда возьмёт незашифрованный ключ (unencrypted.key) и зашифрует его (encrypted.key):
openssl rsa -des3
-in unencrypted.key
-out encrypted.key
Введите пароль, чтобы зашифровать ключ.
Дешифровка закрытого ключа
Эта команда может расшифровать зашифрованный ключ:
openssl rsa
-in encrypted.key
-out decrypted.key
Enter the pass phrase for the encrypted
Введите пароль, чтобы расшифровать ключ.
Форматы сертификатов
До этого в руководстве рассматривались только сертификаты X.509 с кодированием ASCII PEM. Однако существует множество других форматов. Некоторые форматы позволяют объединить компоненты – ключ, запрос, сертификат – в один файл.
Конвертация PEM в DER
Чтобы конвертировать PEM в DER, используйте такую команду:
openssl x509
-in domain.crt
-outform der -out domain.der
Формат DER обычно использует Java.
Конвертация DER в PEM
Для этого введите:
openssl x509
-inform der -in domain.der
-out domain.crt
Конвертация PEM в PKCS7
Чтобы добавить сертификаты PEM (domain.crt и ca-chain.crt) в файл PKCS7 (domain.p7b), введите:
openssl crl2pkcs7 -nocrl
-certfile domain.crt
-certfile ca-chain.crt
-out domain.p7b
Файлы PKCS7 (также известные как P7B) часто используются в Java Keystores и Microsoft IIS (Windows).
Конвертация to PKCS7 в PEM
Чтобы конвертировать PKCS7 в PEM, введите:
openssl pkcs7
-in domain.p7b
-print_certs -out domain.crt
Обратите внимание: файл PKCS7 содержит много компонентов, а именно сертификат и промежуточный сертификат ЦС.
Конвертация PEM в PKCS12
Следующая команда позволяет объединить закрытый ключ и сертификат в файл PKCS12.
openssl pkcs12
-inkey domain.key
-in domain.crt
-export -out domain.pfx
Программа запросит пароль. Файл PKCS12 позволяет объединить несколько сертификатов в один PEM-файл (domain.crt).
Файлы PKCS12 (или PFX) обычно используются для перемещения наборов сертификатов в Micrsoft IIS (Windows).
Конвертация PKCS12 в PEM
Чтобы конвертировать файл PKCS12 в формат PEM, введите:
openssl pkcs12
-in domain.pfx
-nodes -out domain.combined.crt
Если в файле PKCS12 было несколько объектов (например, ключ и сертификат), все они переместятся в файл PEM.
Версии OpenSSL
Чтобы проверить версию OpenSSL, используйте команду openssl version.
Следующая команда выведет версию OpenSSL и все параметры, с которыми она была скомпилирована.
openssl version -a
В данном руководстве используется бинарный файл OpenSSL со следующими подробностями:
OpenSSL 1.0.1f 6 Jan 2014
built on: Mon Apr 7 21:22:23 UTC 2014
platform: debian-amd64
options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector —param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,—noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: «/usr/lib/ssl»
Теперь вы знакомы с основными методами и командами OpenSSL.
Источник: www.8host.com
Теория и практика OpenSSL
Алгоритмы, использующие ключи длиной до 128 бит, считаются алгоритмами низкой безопасности, 128 бит – средней, более 128 бит – высокой. Алгоритмы симметрического шифрования могут работать в нескольких режимах, обычно используется режим cbc, когда ключ динамически высчитывается на основании предыдущего блока данных, т.е. в режиме cbc ключ постоянно меняется, что затрудняет атаки.
При использовании клиентов, работающих на безопасных каналах связи (SSL – secure socket layer), часто можно видеть запрос на подтверждение публичного ключа для связи или сертификата (подписанного публичного ключа, как было описано ранее). Как я уже говорил, публичный ключ могут подменить, но если вы доверяете своим каналам связи и не думаете, что кто-то охотится персонально за вашими данными, то можно доверять публичному ключу удалённого сервера, так как подмена ключа – занятие довольно трудоёмкое, а если у вас есть некие подозрения на этот счёт, то лучше не доверять ключу, не получив подтверждения от нужного лица или организации (не вздумайте использовать электронную почту: уж если смогли подделать ключ, то подменить письмо не составляет труда).
Генерация ключей клиента происходит на лету и они автоматически удаляются после окончания сеанса связи, публичный ключ удалённого сервера помещается в специальное хранилище, что избавляет вас от риска пересылки публичного ключа. Основные атаки на системы асимметрического шифрования связаны с тем, что злоумышленник может угадать содержимое части зашифрованных данных (например, письма часто начинаются со слов «Здравствуйте, »), и это знание облегчает подбор секретного ключа.
Ещё очень опасна атака на подмену ключей (man-in-the-middle), когда злоумышленник перехватывает публичные ключи двух людей, затем генерирует две пары ключей и направляет свои публичные ключи обеим сторонам. Теперь первый человек посылает злоумышленнику своё письмо, которое тот расшифровывает своим ключом, читает, зашифровывает публичным ключом второго человека и отправляет ему послание. Таким образом, у людей создается иллюзия защищённой переписки, но читает их сообщения и третий (который, как известно, лишний). Выходом из такой ситуации является сертификация публичных ключей. Существует два способа сертификации ключей:
- ключ может быть подписан только ключом одного из доверенных источников сертификации (обычно это организации, которые имеют привеллегии сертификации, переданные им правительством страны);
- ключ может быть подписан одним из ключей, которым вы доверяете (обычно это ваш собственный ключ и ключи организаций, занимающихся выдачей сертификатов).
Второй механизм, называемый сетью доверия, используется чаще, так как позволяет добавлять новые ключи к доверенным. Оба механизма предусматривают механизм цепного подписывания, например, если ключ А был подписан ключом Б, который подписан ключом С, который подписан вашим ключом, то ключ А считается доверенным. При этом число таких «шагов» наследования обычно ограничено. Такой механизм сети доверия реализован, например, в системе PGP и в системе OpenSSL. Этим обеспечивается безопасность клиента.
Безопасность сервера необходима лишь в случае удаленной беспарольной аутентификации, тогда администратор удалённой системы помещает ваш ключ в список известных ключей системы. Примечание для администраторов: если вы не хотите, чтобы все могли использовать данный ключ, объясните пользователю опасность доступа посторонних лиц к его секретному ключу и убедите его зашифровать секретный ключ паролем, который, кстати, можно удобно хранить в памяти и не вводить лишний раз, но об этом я расскажу в статье об SSH. И ещё: не забывайте убедиться в том, что ключ пришёл от того, кого предполагалось, для этого лучше попросить пользователя принести ключик на дискетке, а потом её дезинтегрировать или оставить в эпицентре ядерного взрыва (жаль этого нельзя проделать с некоторыми «пользователями», хотя почему нельзя? Мария Францевна, подойдите-ка на минутку. )
И наконец, скажу ещё вот что: асимметрическое шифрование используется для подписи и зашифровывания почтовых сообщений, удалённой аутентификации и ЭЦП в любых её применениях. Но для передачи большого количества данных через сеть использовать асимметрическое шифрование очень печально – всё загнется окончательно и бесповоротно: уж больно много времени надо для использования подобных алгоритмов.
Поэтому при передаче данных по сети используют симметрическое шифрование (3DES, IDEA, Blowfish). Но ключ симметрического шифрования очень опасно передавать в открытом виде (ведь он используется для шифрования и дешифрования), и вначале устанавливается связь асимметрическим шифрованием, как было описано выше.
После установления связи клиент генерирует ключ симметрического шифрования и шифрует его публичным ключом сервера, затем отправляет его собственно серверу (также выполняется подписывание симметрического ключа для удостоверения в его неизменности). Сервер расшифровывает своим секретным ключом ключ симметрического шифрования и использует его для общения с клиентом. Красота!
Но есть ещё один способ – алгоритм Дифлемана-Хельмана, позволяющий использовать одни и те же ключи как для симметрического, так и для асимметрического шифрования. Он заключается в нехитрых математических законах степенной функции (я не буду на этом заострять внимание, так как вряд ли это пригодится на практике).
Оказывается, имея пару – публичный ключ A и секретный ключ B, можно вычислить ключ симметрического шифрования С, который также получается при наличии пары ключей секретный А и публичный B. Говоря проще, ключ С однозначно могут вычислить обе машины, обменявшиеся публичными ключами. Этот ключ можно далее использовать для шифрования/дешифрования данных по стандартному алгоритму симметрического ключа.
Такой способ достаточно безопасный, но он пока ещё не получил достаточного распространения и поэтому сейчас чаще используется первый способ. Любопытные тут же поинтересуются: почему, когда я говорил о симметрическом шифровании, я сказал, что 128-и битный ключ теоретически несокрушим, а говоря об асимметрическом шифровании, сказал, что ключ длиной 1024 бит считается пока ещё более-менее безопасным. Тут дело вот в чём: при асимметрическом шифровании выбираются 2 больших простых числа и на их основе создаются секретный и публичный ключи. Не вдаваясь в математику (для математической стороны алгоритмов шифрования можете зайти на лучший алгоритмический ресурс в рунете http://algolist.manual.ru), скажу только одно: для вычисления секретного ключа на основании публичного необходимо выполнить задачу разложения на множители, которая пропорциональна логарифму по модулю большого целого числа (это реализовать намного проще, чем прямой перебор).
Ну вот, с теорией покончено, можно приступить к практике.
OpenSSL – это система защиты и сертификации данных, название SSL переводится как система безопасных сокетов. OpenSSL используется практически всеми сетевыми серверами для защиты передаваемой информации. Существует API SSL, позволяющее создавать безопасные сокеты с шифрованием передаваемых данных. Но в данной статье я бы хотел рассказать о самой системе OpenSSL, вызываемой через командную строку.
Так как OpenSSL поддерживает очень много различных стандартов сертификации, шифрования, хеширования, то использование данной команды достаточно сложно. Внутри OpenSSL существуют отдельные компоненты, отвечающие за то или иное действие. Для получения списка доступных компонентов можно вызвать openssl с параметрами list-standart-commands. Можно также получить список доступных алгоритмов хеширования (list-message-digest-commands) и алгоритмов шифрования (list-cipher-commands). Итак, с помощью команд OpenSSL можно делать следующее:
- Создавать и управлять ключами RSA и DSA – команды rsa, dsa, dsaparam;
- Создавать сертификаты формата x509, запросы на сертификацию, восстановление – команды x509, req, verify, ca, crl, pks12, pks7;
- Зашифровывать данные с помощью симметрического или асимметрического шифрования – команды enc, rsautl;
- Высчитывать хеши различных типов – команда dgst;
- Работать с S/MIME – команда s/mime;
Проверять работы серверов и клиентов ssl – команды s_client, s_server.
Cуществует также несколько вспомогательных утилит ssl:
- openssl speed [список_алгоритмов_хеширования_или шифрования]: тестирование скорости различных алгоритмов, если запускать без параметров, то тестируются все алгоритмы; алгоритмы внутри списка разделяются пробелом, например:
openssl speed md5 rsa idea blowfish des 3des sha1
В конце выводится общая скорость работы различных алгоритмов (в 1000-х байт в секунду), для обработки различной длины блоков. Вот результат работы тестов скорости на моём домашнем компе (Celeron 366), на других компах значения будут другими:
Источник: samag.ru