Openssl for windows x64 как использовать

Время на прочтение14 мин

Количество просмотров43K

Если вы искали руководство по криптографии, лежащей в основе OpenSSL, то вы оказались в правильном месте.

Картинка с сайта: habr.com

Эта статья является первой в серии из двух статей, посвященных основам криптографии, используемой в OpenSSL — библиотеке инструментов промышленного уровня, популярной и в среде Linux, и за ее пределами. (Чтобы установить самую последнюю версию OpenSSL, перейдите сюда.) Что касается взаимодействия с библиотекой, то вы можете вызывать ее функции из кода, а также в вашем распоряжении есть утилиты командной строки. Примеры кода для этой статьи приведены на C — на том же языке, на котором написана сама библиотека OpenSSL.

Две статьи этой серии в совокупности охватывают такие темы, как криптографические хеши, цифровые подписи, цифровые сертификаты, а также шифрование и дешифрование. Вы можете найти код и примеры для командной строки в ZIP-архиве на моем сайте.

Начнем же мы с обзора SSL, которому библиотека OpenSSL обязана своим именем (большей его части).

Краткая история

Secure Socket Layer (SSL, слой защищенных сокетов) — это криптографический протокол, выпущенный Netscape в 1995 году. Этот протокольный уровень может располагаться поверх HTTP, тем самым добавляя в конец букву S (HTTPS), которая означает secure. Протокол SSL предоставляет различные меры обеспечения безопасности, две из которых являются основополагающими в HTTPS:

• Взаимная аутентификация (peer authentication, также известная как mutual challenge): каждая сторона соединения аутентифицирует идентификационные данные другой стороны. Если Алиса и Боб собираются обмениваться сообщениями через SSL, то сначала каждый должен аутентифицировать идентификационные данные своего собеседника.

• Конфиденциальность: отправитель шифрует сообщения перед их отправкой по каналу связи. Затем получатель расшифровывает каждое полученное сообщение. Этот процесс защищает сетевое взаимодействие. Даже если злоумышленник Ева перехватит зашифрованное сообщение от Алисы к Бобу (атака через посредника), то она будет не в состоянии расшифровать это сообщение из-за необходимой для этого вычислительной сложности.

Эти две ключевые меры обеспечения безопасности SSL, в свою очередь, связаны с другими, которые зачастую остаются в тени. Например, SSL поддерживает целостность сообщений, что гарантирует, что полученное сообщение совпадает с отправленным. Эта фича реализована на основе хеш-функций, которые также входят в набор инструментов OpenSSL.

SSL имеет разные версии (например, SSLv2 и SSLv3), а в 1999 году на основе SSLv3 был реализован аналогичный протокол Transport Layer Security (TLS, протокол защиты транспортного уровня). TLSv1 и SSLv3 похожи, но не настолько, чтобы работать друг с другом. Тем не менее, принято называть SSL/TLS одним и тем же протоколом. Например, функции OpenSSL часто содержат SSL в имени, даже если используется TLS, а не SSL. Кроме того, вызов утилит командной строки OpenSSL начинается со строки openssl.

Документация по OpenSSL, к сожалению, достаточно неоднородна в своей полноте, особенно если смотреть за пределами справочных страниц (man pages), которые сами по себе достаточно громоздкие, учитывая, насколько велик инструментарий OpenSSL. В этой статье я  сфокусирую внимание на основных темах посредством примеров кода и командной строки. Начнем мы со знакомого всем нам примера — доступа к веб-сайту по HTTPS — и используем этот пример, чтобы разобрать основополагающие криптографические элементы.

HTTPS-клиент 

Приведенная ниже программа client подключается к Google по HTTPS:

/* компиляция: gcc -o client client.c -lssl -lcrypto */ 

#include <stdio.h>

#include <stdlib.h>

#include <openssl/bio.h> /* Базовые потоки ввода/вывода */

#include <openssl/err.h> /* ошибки */

#include <openssl/ssl.h> /* основная библиотека */

#define BuffSize 1024


void report_and_exit(const char* msg) {
  perror(msg);
  ERR_print_errors_fp(stderr);
  exit(-1);
}

 

void init_ssl() {
  SSL_load_error_strings();
  SSL_library_init();
}

 

void cleanup(SSL_CTX* ctx, BIO* bio) {
  SSL_CTX_free(ctx);
  BIO_free_all(bio);
}

 

void secure_connect(const char* hostname) {
  char name[BuffSize];
  char request[BuffSize];
  char response[BuffSize];

 

  const SSL_METHOD* method = TLSv1_2_client_method();
  if (NULL == method) report_and_exit("TLSv1_2_client_method...");

  SSL_CTX* ctx = SSL_CTX_new(method);
  if (NULL == ctx) report_and_exit("SSL_CTX_new...");

  BIO* bio = BIO_new_ssl_connect(ctx);
  if (NULL == bio) report_and_exit("BIO_new_ssl_connect...");

  SSL* ssl = NULL;

  /* связываем канал bio, сессию SSL и конечную точку сервера */

  sprintf(name, "%s:%s", hostname, "https");
  BIO_get_ssl(bio, &ssl); /* сессия */
  SSL_set_mode(ssl, SSL_MODE_AUTO_RETRY); /* надежность */
  BIO_set_conn_hostname(bio, name); /* подготовка к подключению */

  /* пытаемся подключиться */
  if (BIO_do_connect(bio) <= 0) {
    cleanup(ctx, bio);
    report_and_exit("BIO_do_connect...");
  }


  /* проверяем хранилище доверенных сертификатов и сам сертификат */
  if (!SSL_CTX_load_verify_locations(ctx,
                                      "/etc/ssl/certs/ca-certificates.crt", /* хранилище доверенных сертификатов */


                                      "/etc/ssl/certs/")) /* больше доверенных сертификатов*/


    report_and_exit("SSL_CTX_load_verify_locations...");


  long verify_flag = SSL_get_verify_result(ssl);
  if (verify_flag != X509_V_OK)
    fprintf(stderr,
            "##### Certificate verification error (%i) but continuing...\n",
            (int) verify_flag);

  /* теперь получаем домашнюю страницу в качестве проверочных данных */
  sprintf(request,
          "GET / HTTP/1.1\x0D\x0AHost: %s\x0D\x0A\x43onnection: Close\x0D\x0A\x0D\x0A",
          hostname);
  BIO_puts(bio, request);
 

  /* читаем HTTP-ответ с сервера и выводим через stdout */
  while (1) {
    memset(response, '\0', sizeof(response));
    int n = BIO_read(bio, response, BuffSize);
    if (n <= 0) break; /* 0 — конец потока, < 0 — ошибка */


  puts(response);
  }


  cleanup(ctx, bio);
}


int main() {
  init_ssl();


  const char* hostname = "www.google.com:443";
  fprintf(stderr, "Trying an HTTPS connection to %s...\n", hostname);
  secure_connect(hostname);

return 0;
}

(Прим. переводчика: этот код оказался нерабочим, исправленную версию можно посмотреть здесь)

Эту программу можно скомпилировать и запустить из командной строки (обратите внимание на строчную букву L в -lssl и -lcrypto):

gcc -o client client.c -lssl -lcrypto

Эта программа пытается установить безопасное соединение с сайтом www.google.com. В рамках TLS-рукопожатия с сервером Google программа-клиент получает один или несколько цифровых сертификатов, которые она затем пытается проверить (в моей системе они проверку не проходят). Тем не менее, далее программа-клиент получает по защищенному каналу домашнюю страницу Google. Эта программа полагается на упомянутые ранее артефакты безопасности, хотя в коде можно выделить только цифровой сертификат. Остальные же артефакты пока остаются за кадром, подробнее о них мы поговорим чуть дальше.

Как правило, программа-клиент на C или C++, которая открывает (незащищенный) HTTP-канал, будет использовать такой объект, как файловый дескриптор сетевого сокета, который является конечной точкой в ​​соединении между двумя процессами (например, программой-клиентом и сервером Google). Файловый дескриптор, в свою очередь, представляет собой неотрицательное целочисленное значение, которое идентифицирует внутри программы любую файловую конструкцию, которую эта программа открывает. Такой программе также понадобится структура для указания сведений об адресе сервера.

Ни один из этих относительно низкоуровневых объектов не встречается в программе-клиенте, поскольку библиотека OpenSSL заключает инфраструктуру сокетов и спецификацию адресов в высокоуровневые объекты безопасности. В результате мы получаем простой API. Вот какие процессы обеспечения безопасности мы можем увидеть в этом примере программы-клиента, не заглядывая под капот:

• Программа начинается с загрузки необходимых библиотек OpenSSL, при этом моя функция init_ssl выполняет два вызова OpenSSL:

SSL_library_init(); SSL_load_error_strings();

• Следующий шаг инициализации пытается получить контекст, информационную структуру, необходимую для установления и поддержания безопасного канала с сервером. В этом примере используется TLS1.2, что  мы можем увидеть в этом вызове функции из библиотеки OpenSSL:

const SSL_METHOD* method = TLSv1_2_client_method(); /* TLS 1.2 */

Если вызов выполнен успешно, то указатель method передается библиотечной функции, создающей контекст типа SSL_CTX:

SSL_CTX* ctx = SSL_CTX_new(method);

Программа-клиент проверяет наличие ошибок в каждом из этих критических библиотечных вызовов, а затем завершает работу, если какой-либо вызов завершается некорректно.

• Теперь в игру вступают два других артефакта OpenSSL: сессия безопасности (security session) типа SSL, которая от начала и до конца управляет безопасным соединением; и защищенный поток типа BIO (базовый ввод/вывод), который используется для связи с сервером. Поток BIO создается с помощью следующего вызова:

BIO* bio = BIO_new_ssl_connect(ctx);

Обратите внимание, что аргументом является наша чрезвычайно важная переменная с контекстом. Тип BIO — это обертка OpenSSL для типа FILE в C. Эта обертка защищает потоки ввода/вывода между программой-клиентом и сервером Google.

• Располагая SSL_CTX и BIO, программа затем связывает их вместе в сессии SSL. Эту работу выполняют три следующих библиотечных вызова:

BIO_get_ssl(bio, &ssl); /* получает сессию TLS */SSL_set_mode(ssl, SSL_MODE_AUTO_RETRY); /* для надежности */BIO_set_conn_hostname(bio, name); /* подготовка к соединению с Google */

Само безопасное соединение устанавливается с помощью этого вызова:

BIO_do_connect(bio);

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

Во время рукопожатия с сервером программа-клиент получает один или несколько цифровых сертификатов, удостоверяющих подлинность сервера. Однако программа-клиент не отправляет собственный сертификат, что означает одностороннюю аутентификацию. (Серверы обычно настроены не ожидать сертификата клиента.) Несмотря на неудачную проверку сертификата сервера, программа-клиент получает домашнюю страницу Google по безопасному каналу с сервером.

Почему проверка сертификата Google не заканчивается успехом? Типичная установка OpenSSL имеет каталог /etc/ssl/certs, который включает файл ca-certificates.crt. Каталог и файл содержат цифровые сертификаты, которым OpenSSL доверяет из коробки и, соответственно, составляют хранилище доверенных сертификатов (truststore). Хранилище доверенных сертификатов можно обновлять по мере необходимости, в частности, включать новые доверенные сертификаты и удалять ненадежные.

Программа-клиент получает три сертификата от сервера Google, но хранилище доверенных сертификатов OpenSSL на моей машине не содержит точных совпадений с ними. Как я в скором времени расскажу, программа-клиент не занимается, например, проверкой цифровой подписи на сертификате Google (подпись, подтверждающая сертификат). Если этой подписи доверяют, то сертификату, содержащему ее, также следует доверять. Тем не менее клиентская программа продолжает загрузку, а затем отображение домашней страницы Google. В следующем разделе мы рассмотрим это более подробно.

Скрытые механизмы безопасности в программе-клиенте

Начнем с артефакта безопасности, который мы видим в примере с клиентом — цифрового сертификата — и рассмотрим, как другие артефакты безопасности с ним связаны. Превалирующим стандартом структуры цифрового сертификата является X509, а сертификат производственного уровня выдаются центром сертификации (CA, certificate authority), таким как Verisign.

Цифровой сертификат содержит различную информацию (например, даты начала и истечения срока действия, а также доменное имя владельца), включая идентификационные данные издателя и цифровую подпись, которая представляет собой зашифрованное криптографическое хеш-значение. Сертификат также имеет незашифрованное хеш-значение, которое служит его идентифицирующим отпечаток (fingerprint).

Хеш-значение получается в результате сопоставления произвольного количества битов с хеш-суммой (digest) фиксированной длины. Что представляют собой биты (бухгалтерский отчет, роман или, может быть, фильм) не имеет значения. Например, хеш-алгоритм Message Digest версии 5 (MD5) отображает входные биты любой длины в 128-битное хеш-значение, тогда как алгоритм SHA1 (Secure Hash Algorithm версии 1) отображает входные биты в 160-битное значение. Различные входные биты приводят к разным — действительно, статистически уникальным — значениям хеш-функции. В следующей статье мы рассмотрим это более подробно и сосредоточимся на том, что именно делает хеш-функцию криптографической.

Цифровые сертификаты различаются по типу (например, корневой/root, промежуточный/intermediate и конечный/end-entity сертификаты) и образуют иерархию, отражающую эти типы. Как следует из названия, корневой сертификат находится на вершине иерархии, а сертификаты под ним наследуют любое доверие, которое имеет корневой сертификат. Библиотеки OpenSSL и большинство современных языков программирования имеют тип X509, как и функции, которые работают с такими сертификатами. Сертификат от Google имеет формат X509, и клиент проверяет, является ли этот сертификат X509_V_OK.

Сертификаты X509 основаны на инфраструктуре открытых ключей (PKI, public-key infrastructure), которая включает в себя алгоритмы (в основном доминирует RSA) для создания пар ключей: публичный ключ и его парный приватный ключ. Публичный ключ — это идентификационные данные (identity): публичный ключ Amazon идентифицирует его, а мой публичный ключ идентифицирует меня. Приватный ключ должен храниться его владельцем в секрете.

Ключи в паре имеют несколько стандартных применений. Публичный ключ можно использовать для шифрования сообщения, а приватный ключ из той же пары затем можно использовать для его расшифровки. Приватный ключ также можно использовать для подписи документа или другого электронного артефакта (например, программы или электронного письма), а затем публичный ключ из пары можно использовать для проверки этой подписи. Рассмотрим два примера.

В первом примере Алиса открывает свой публичный ключ всему миру, включая Боба. Затем Боб шифрует сообщение с помощью публичного ключа Алисы, отправляя ей зашифрованное сообщение. Сообщение, зашифрованное публичным ключом Алисы, расшифровывается ее приватным ключом, который (по идее) есть только у нее, вот так:

	           +------------------+ encrypted msg  +-------------------+
Bob's msg--->|Alice's public key|--------------->|Alice's private key|--->
Bob's msg
				     +------------------+                +-------------------+

Расшифровка сообщения без приватного ключа Алисы в принципе возможна, но на практике нереальна, учитывая надежность криптографической системы парных ключей, такой ​​как RSA.

Теперь в качестве второго примера рассмотрим подписание документа для подтверждения его подлинности. Алгоритм подписи использует приватный ключ из пары для обработки криптографического хеша подписываемого документа:

										+-------------------+
Hash of document--->|Alice's private key|--->Alice's digital signature of the document
										+-------------------+

Предположим, что Алиса подписывает цифровой подписью контракт, отправленный Бобу. Затем Боб может использовать публичный ключ Алисы для проверки подписи:

									             							 +------------------+
Alice's digital signature of the document--->|Alice's public key|--->verified or not
                                             +------------------+

Невозможно подделать подпись Алисы без ее приватного ключа: следовательно, в интересах Алисы сохранить ее приватный ключ в тайне.

Ни один из этих элементов безопасности, за исключением цифровых сертификатов, не является явным в нашей программе-клиенте. В следующей статье подробно описаны примеры, в которых используются утилиты OpenSSL и библиотечные функции.

OpenSSL из командной строки

А пока давайте взглянем на инструменты командной строки OpenSSL: в частности, утилиту для проверки сертификатов с сервера во время  TLS-рукопожатия. Вызов утилит OpenSSL начинается с команды openssl а затем добавляется комбинация аргументов и флагов для указания желаемой операции.

Рассмотрим эту команду:

openssl list-cipher-algorithms

Результатом является список связанных алгоритмов, составляющих набор шифров (cipher suite). Ниже приведено начало списка с комментариями для разъяснения аббревиатур:

AES-128-CBC ## Advanced Encryption Standard, Cipher Block Chaining
AES-128-CBC-HMAC-SHA1 ## Hash-based Message Authentication Code с хешами SHA1 
AES-128-CBC-HMAC-SHA256 ## тоже самое, но с SHA256 вместо SHA1
...

Следующая команда, используя аргумент s_client, открывает безопасное соединение с www.google.com и выводит на экран информацию об этом соединении:

openssl s_client -connect www.google.com:443 -showcerts

Номер порта 443 является стандартным, который используется серверами для приема соединений HTTPS, а не HTTP. (Для HTTP стандартный порт — 80). Сетевой адрес www.google.com:443 также встречается в программе-клиенте. Если попытка подключения успешна, отображаются три цифровых сертификата от Google вместе с информацией о безопасном сеансе, используемом наборе шифров и связанных элементах. Например, вот фрагмент начала вывода, который объявляет о предстоящей цепочке сертификатов. Кодировка сертификатов — base64:

Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com
 i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
-----BEGIN CERTIFICATE-----
MIIEijCCA3KgAwIBAgIQdCea9tmy/T6rK/dDD1isujANBgkqhkiG9w0BAQsFADBU
MQswCQYDVQQGEwJVUzEeMBwGA1UEChMVR29vZ2xlIFRydXN0IFNlcnZpY2VzMSUw
...

Такие крупные сайты как Google, как правило, отправляют несколько сертификатов для аутентификации.

Выходные данные заканчиваются сводной информацией о сессии TLS, включая сведения о наборе шифров:

SSL-Session:
    Protocol : TLSv1.2
    Cipher : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: A2BBF0E4991E6BBBC318774EEE37CFCB23095CC7640FFC752448D07C7F438573
...

В программе-клиенте используется протокол TLS1.2, а Session-ID однозначно идентифицирует соединение между утилитой openssl и сервером Google. Запись Cipher может быть проанализирована следующим образом:

• ECDHE (протокол Диффи-Хеллмана на эллиптических кривых) — эффективный и действенный алгоритм для управления TLS-рукопожатием. В частности, ECDHE решает проблему распределения ключей, гарантируя, что обе стороны соединения (например, программа-клиент и веб-сервер Google) используют один и тот же ключ шифрования/дешифрования, известный как ключ сессии (session key). Следующая часть серии детальнее раскроет эту тему.

• RSA (Rivest Shamir Adleman) — доминирующая криптосистема с публичным ключом, названная в честь трех ученых, впервые описавших эту систему в конце 1970-х годов. Пары ключей генерируются с помощью алгоритма RSA.

• AES128 (Advanced Encryption Standard) — это блочный шифр, который шифрует и расшифровывает блоки битов. (Альтернативой является потоковый шифр, который шифрует и расшифровывает биты по одному.) Шифр ​​является симметричным в том смысле, что для шифрования и дешифрования используется один и тот же ключ, что в первую очередь поднимает проблему распределения ключей. AES поддерживает размеры ключей 128 (используется здесь), 192 и 256 бит: чем больше ключ, тем лучше защита.

Размеры ключей для симметричных криптосистем, таких как AES, как правило, меньше, чем для асимметричных систем (на основе пары ключей), таких как RSA. Например, 1024-битный ключ RSA относительно мал, тогда как 256-битный ключ в настоящее время является самым большим для AES.

• GCM (режим счетчика Галуа) обрабатывает повторное применение шифра (в данном случае AES128) во время защищенного общения. Блоки AES128 имеют размер всего 128 бит, и безопасный обмен данными, скорее всего, будет состоять из нескольких блоков AES128 от одной стороны к другой. GCM эффективен и обычно сочетается с AES128.

• SHA256 (Secure Hash Algorithm с 256 бит) — это популярный криптографический алгоритм хеширования. Создаваемые хеш-значения имеют размер 256 бит, хотя с помощью SHA возможны и большие значения.

Наборы шифров находятся в постоянном развитии. Не так давно, например, Google использовала потоковый шифр RC4 (Ron’s Cipher версии 4 в честь Рона Ривеста из RSA). В RC4 теперь онаружены уязвимости, которые предположительно частично объясняют переход Google на AES128.

Подытожим

Это знакомство с OpenSSL посредством разбора безопасного веб-клиента C и различных примеров для командной строки выдвинуло на передний план несколько тем, нуждающихся в дополнительных пояснениях. Следующая статья посвящена деталям, начиная с криптографических хешей и заканчивая более полным обсуждением того, как цифровые сертификаты решают проблему распространения ключей.

Приглашаем всех желающих на открытое занятие «Встраиваем интерпретатор в приложение на C». На этом открытом уроке мы рассмотрим встраивание интерпретатора и виртуальной машины языка программирования высокого уровня в программу на C на примере скриптового языка Lua. Регистрируйтесь по ссылке.

Картинка с сайта: habr.com

Эта статья — расширенный туториал того, как установить и настроить свой VPN на VLESS с XTLS-Reality с управлением через GUI интерфейс 3x-UI всего за 10 минут.

Почему именно этот протокол?

Особенность VLESS-Reality в том, что: берутся HTTPS-пакеты, и пускаются через наш заранее подготовленный зарубежный сервер (VPS), как через прокси. Однако, стоит учесть, что обращаться к нему мы будем как к какому-нибудь www.google.com, но в стандартной процедуре хэндшейка выполняем скрытую процедуру авторизации — благодаря чему сервер поймёт, что мы его слон. 

А если кто-то (читаем как РКН) попытается обратиться к нашему «‎сайту» без авторизации (атака именуемая как Active Probing) то в ответ лишь получит копию www.google.com со всеми необходимыми сертификатами. РКН подумает, что наш сервер — это просто сервер Google, a никакой не VPN, и ничего блокировать не будет.

— Кроме того, поскольку HTTPS-пакеты, которые будут пропущены через прокси, уже зашифрованы, в дополнительном шифровании не нуждаются, и никакой deep package inspection т.е DPI соответственно нас ни в чём не заподозрит.

• некоторые начнут задаваться вопросом, а почему не AmneziaWG или известный из поднебесья ShadowSocks, а потому что во время масштабных блокировок под нож может пойти всё, что не HTTPS.

Я хочу настроить сервер с XTLS-Reality, как это сделать максимально правильно?

Суть Reality в маскировке под какой-либо популярный сайт, поэтому когда вы решаете это делать, вам нужно добиться того, чтобы ваш IP (IP вашего VPS) вел себя полностью идентично настоящему серверу, которым вы прикидываетесь. Если тот «настоящий» сервер слушает на 80-м порту (plain HTTP), то вам тоже нужно настроить nginx или правило фаервола, чтобы переадресовывать HTTP-запросы на оригинальный сервер. Если «настоящий» сервер не слушает SSH-подключения на стандартном 22-м порту, то ваш тоже не должен.
— Если ваш хостер предоставляет reverse-DNS записи для IP-адреса, убедитесь, что там не осталось значение по умолчанию (обычно с доменом хостера), а лучше задайте такой reverse-DNS, какой виден у IP-адреса ресурса, под который вы маскируетесь.

Правда ли что VLESS не использует шифрование, и поэтому использовать его небезопасно для конфиденциальных данных.

Нет. То, что VLESS не предусматривает шифрования на уровне протокола, не значит, что данные передаются в нешифрованном виде. VLESS всегда работает поверх TLS, трафик шифруется именно механизмами TLS, а не самого VLESS. Никакой проблемы с безопасностью тут нет, все секьюрно.

Что лучше XTLS-Reality, или просто VLESS + XTLS-Vision?

Преимуществ XTLS-Reality два. Во-первых это простота настройки, не надо никаких доменов, сертификатов, и т.д. Во-вторых, из-за возможности маскировки под любой популярный сайт, с его помощью можно пролезать через белые списки цензоров — например, в Иране долгое время блочили/резали все по малейшему подозрению, но yahoo.com у них был в белых списках, и прокси, маскирующиеся под него работали.

А теперь приступим к установке и минимальной настройке VPN своими руками.

Хостинг для VPN

Есть масса хостингов, некоторые дешевле, но в этом материале разберём установку на aeza.net, его плюсами являются: пополнение по СБП; РФ картами всех мастей; установка сервера c 3x-UI в пару кликов и небольшая настройка пресета по ключам.

Регистрация и оформление сервера

Первым делом необходимо зарегистрироваться (данные для входа продублируются на почту) и войти в панель управления, после чего, пополняем баланс удобными для вас способами, для граждан РФ все условия соблюдены, как и писал ранее пополнение по СБП; РФ картами всех мастей;

Далее в колонке под логотипом aeza выбираем «Виртуальный сервер» (речь о боковой панели) и с этого момента начинается настройка конфигурации нашего будущего сервера.

Название: не имеет значения, по желанию

Выбор локации: Амстердам

Выбор тарифа: Shared — тариф NLs-1

Выбор операционной системы и ПО: предустановленное ПО и ищем 3x-UI Ubuntu 22.04

Выбор периода оплаты и оформление заказа: я выставил помесячную оплату, мало ли, что с хостинг-провайдером станет.

Бэкапы: отключаем (в них нет необходимости под наши нужды)

Картинка с сайта: habr.com

Картинка с сайта: habr.com

Установка

После успешного оформления и оплаты сервера переходим в раздел «Мои услуги» (речь о боковой панели), далее кликаем по нашему названию сервера с флагом попадая на страницу с краткой сводкой о сервере:

Картинка с сайта: habr.com

На данном этапе нас интересует лишь IP-адрес; имя пользователя и пароль.

Подключение по SSH к серверу

Постараюсь разобрать на трёх разных ОС параллельно, указывая для каждой какую команду и на каком этапе необходимо вводить.

Linux:

$ ssh username@ip-address

Где username — это логин администратора на сервере, а IP-address, соответственно, — ее IP-адрес.

Windows:

С некоторых пор подключаться через SSH из операционной системы Windows также стало можно через командную строку. Раньше для этого применялись сторонние приложения (вроде PuTTY или Cygwin и пр.), но в десятой версии ОС был добавлен встроенный OpenSSH клиент, который работает так же, как в Линукс.

Единственное отличие в том, что по умолчанию эта утилита отключена, и чтобы приступить к выполнению команд, необходимо установить ее в настройках.

Для этого совершите несколько шагов:

1. Откройте «Параметры» — «Приложения».

2. Выберите подпункт «Дополнительные компоненты».

3. Найдите в списке «Клиент OpenSSH» и нажмите «Установить». Если этой кнопки нет, значит, служба уже включена.

4. После установки перезагрузите компьютер.

Теперь нужно открыть командную строку. Можно найти ее через поиск или нажать Win+R, ввести в поле «cmd» и Enter. В этом случае процесс подключения по SSH в Windows и Linux будет идентичен.

Mac OS:

ssh username@ip-address

Итак, если в командной строке увидели «Welcome to Ubuntu 22.04.4 LTS (GNU/Linux 5.15.0-113-generic x86_64)» то вы на верном пути и всё хорошо складывается, далее вводим команду:

nano 3x-ui.txt

Картинка с сайта: habr.com

Перед нами появится три важных для нас строки: URL; Login; Password.

Лезем в браузер и вставляем в адресную строку свой ссылку, в моём случае это:

http://77.221.154.202:16068

Картинка с сайта: habr.com

Вводим логин и пароль, который мы получили благодаря команде nano 3x-ui.txt и попадаем в панель управления, следующий шаг это создание ключа и настройка конфигурации.

Картинка с сайта: habr.com

Переходим в раздел «Подключения» — «Добавить подключение»

Картинка с сайта: habr.com

Настройка VLESS с XTLS-Reality

Картинка с сайта: habr.com

Примечание: наименование для более удобной идентификации ключей в панели управления (того стоит, в случае, если собираетесь раздать разные ключи)

Протокол: vless

Порт IP: оставляем пустым, как и на скриншоте выше

Порт: по умолчанию у вас будет выставлено определённое значение, его стираем и выставляем — 443

Ко вкладке «Клиент» вернёмся чуть позже, пока перейдём ниже:

Протокол передачи: TCP (всё, что ниже оставляем по умолчанию)

Безопасность: REALITY

• xVer — оставьте значение 0;

• uTLS— выбираем под какой браузер будет маскироваться VPN соединение. Рекомендую выбирать Chrome, ибо он наиболее популярен;

• Dest — назначение, указываем домен и порт. Я оставил yahoo.com:443;

• SNI — это домен, под который будем маскироваться. Ставим идентично пункту Dest yahoo.com, www.yahoo.com;

• Short ID — приватный ключ сгенерированный автоматически;

• Приватный ключ и Публичный ключ — не трогаем, стоит лишь нажать кнопку Get New Keys и ключи автоматически сгенерируются;

• Sniffing, HTTP, TLS, QUIC, FAKEDNS — оставляем по умолчанию.

Настройка клиента:

Email: аналогично как и с примечанием, наименование для удобства;

Flow: выбираем из списка xtls-rprx-vision.

Остальное не трогаем, оставляем по умолчанию и кликаем на «Создать» (ключ готов)

Для удобства подключения с мобильных устройств жмём на «+» у клиента и перед нами появится иконка QR-кода, кликаем и сохраняем:

Картинка с сайта: habr.com

Для получения текстового ключа кликаем по значку «i»

Ключ готов, теперь необходимо определиться с клиентом для подключения, моя основная ОС — Mac OS, порекомендовать могу FoXray (для тех, у кого macOS 13.1 и новее) в случае если у вас более старые ОС, то рекомендую использовать V2Box; из клиентов на iOS советую поставить также FoXray, но есть и масса других клиентов.

• Windows – InvisibleMan-XRay разворачиваем Assets и выбираем нужный zip х64 для 64 битных систем, x86 для 32 битных систем. Есть и другие клиенты постабильнее.

• Android – NekoBox разворачиваем Assets и там будут apk. Выбираем arm64. На момент написания статьи последний назывался релиз: NB4A-1.3.1-arm64-v8a.ap

В этом руководстве разберемся как с теорией, так и узнаем как работать с сертификатами на практике при помощи утилиты OpenSSL.

Картинка с сайта: wiki.merionet.ru

Про Linux за 5 минут

Что такое сертификат SSL? Как работает SSL?

Сертификат Secure Socket Layer (SSL) — это протокол безопасности, который защищает данные между двумя компьютерами с использованием шифрования.

Проще говоря, сертификат SSL — это файл данных, который в цифровом виде связывает криптографический ключ с сервером или доменом, а также с названием и местонахождением организации.

Как правило, сертификаты SSL используются на веб-страницах, которые передают и получают конфиденциальные данные конечного пользователя, такие как номер социального страхования, данные кредитной карты, домашний адрес или пароль. Онлайн формы оплаты являются хорошим примером и обычно шифруют вышеупомянутую деликатную информацию с использованием 128 или 256-битной технологии SSL.

Сертификаты SSL обеспечивают идентификацию удаленного компьютера, чаще всего сервера, но также подтверждают идентификацию вашего компьютера с удаленным компьютером для установления безопасного соединения. Обеспечение безопасности в Интернете всегда было улицей с двусторонним движением, и благодаря SSL-шифрованию сервер «пожимает руку» вашему персональному компьютеру, и обе стороны знают, с кем они общаются.

В чем разница между TLS и SSL?

Её нет! Transport Layer Security (TLS) — это обновленная версия Secure Socket Layer (SSL). Даже при том, что большинство безопасных соединений через протоколы TLS, люди продолжают называть это SSL.

Как я могу узнать, защищена ли веб-страница с помощью SSL?

Вы, вероятно, заметили, что в вашем браузере в адресной строке загорелся зеленый значок замка, а протокол соединения — это https. Ваш браузер сообщает вам, что веб-сайт защищен с использованием шифрования SSL. Если щелкнуть информационную панель сайта, появится дополнительная информация о подключении, а также информация о самом сертификате SSL.

Зачем мне нужен SSL-сертификат?

Давайте возьмем реальный пример. Допустим являетесь владельцем сайта интернет-магазина, м вы хотите, чтобы ваши посетители чувствовали себя в безопасности при посещении вашего интернет-магазина и, прежде всего, не стеснялись войти в систему и совершить покупку. Сертификат SSL и соединение HTTPS внушают доверие потребителей. Индустрия электронной коммерции тесно связана с доверием потребителей, и мы можем даже сказать, что ваш бизнес зависит от того, насколько ваши клиенты чувствуют себя в безопасности в течение всего процесса покупки.

Помимо очевидных причин безопасности, SSL-сертификат увеличивает SEO вашего сайта и рейтинг в Google, а также повышает доверие клиентов и, следовательно, повышает общий коэффициент конверсии. Если этого недостаточно, чтобы заставить вас задуматься о получении сертификата SSL для вашего домена, Google обязательно убедит вас. А именно, с июля 2018 года Google помечает каждый сайт без SSL как небезопасный.

Где получить сертификат SSL?

Сертификаты SSL проверяются и выдаются Центром сертификации (CA — Certificate Authorities). Вы подаете заявку, генерируя CSR (Certificate Signing Request — запрос на получение сертификата) с парой ключей на вашем сервере, которая в идеале будет содержать сертификат SSL. CSR содержит важные организационные детали, которые CA проверяет.

1. Сгенерируйте CSR и пару ключей локально на вашем сервере. Пара ключей состоит из открытого (public key) и закрытого (private key) ключей.
2. Отправьте CSR и открытый ключ в центр сертификации, который проверит вашу личность, а также владеете ли вы доменом, указанным в заявке. Центр сертификации проверяет вашу организацию и проверяет, зарегистрирована ли организация в расположении, указанном в CSR, и существует ли домен.
3. После проверки организация получает копию своего сертификата SSL, включающего бизнес данные, а также открытый ключ. Теперь организация может установить сертификат на своем сервере.
4. Когда центр сертификации выдает сертификат, он связывается с сертификатом «доверенного корня» (trusted root) центра сертификации. Корневые сертификаты встроены в каждый браузер и связаны с индивидуально выданными сертификатами для установления HTTPS-соединения.

Нередко популярные браузеры не доверяют всем сертификатам, выпущенным одним центром сертификации. Например, Google Chrome не доверяет корневым сертификатам Symantec, поскольку Symantec несколько раз нарушала отраслевые политики. Это означает, что все сертификаты, укоренившиеся в Symantec, стали недействительными независимо от даты их действия.

Типы SSL-сертификатов

Убедитесь, что вы выбрали центр сертификации, который поддерживает необходимый вам тип сертификата. Для вашего удобства ниже приведено описание каждого типа сертификата:

• Однодоменный SSL-сертификат (Single Domain SSL Certificate) — Этот тип предназначен для использования в одном домене и не поддерживает субдомены. Например, если сертификат будет использоваться для wiki.merionet.ru, он не будет поддерживать любое другое доменное имя.
• Несколько доменов (сертификаты SAN / UC) — Несколько сертификатов домена используются для многочисленных доменов и поддоменов. Помимо полного доменного имени, вы можете добавить поддержку других поддоменов, добавив их в поле «Альтернативное имя субъекта». Например, сертификат SAN может включать домен wiki.merionet.ru, его поддомен asterisk.merionet.ru, а также другой домен (например, shop.merionet.ru).
• Wildcard сертификат — Сертификаты могут использоваться для домена, включая все его поддомены. Основное отличие состоит в том, что вместо выдачи для определенного полного доменного имени сертификаты с подстановочными знаками используются для широкого диапазона поддоменов. Например, сертификат подстановочного знака, выданный *.merionet.ru, может использоваться для широкого диапазона поддоменов в основном домене

Уровни проверки SSL-сертификатов

Центры сертификации имеют различные уровни проверки сертификатов в ответ на растущий спрос на сертификаты. Некоторые организации используют SSL только для шифрования, в то время как другие хотят показать своим клиентам, что они являются доверенной компанией. Различные потребности привели к различным уровням проверки сертификата.

Проверка домена (DV SSL — Domain Validation)

Этот тип сертификата SSL идеально подходит для защиты блогов, приложений социальных сетей и личных веб-сайтов. Центр сертификации не гарантирует идентичность организации, и проверяется только владение доменом.

Расширенная проверка (EV SSL — Extended Validation)

Центр сертификации проверяет право собственности на домен и проводит тщательное расследование организации, связанной с сертификатом EV. При рассмотрении расширенного запроса проверки соблюдаются строгие правила, и центр сертификации должен проверить следующее:

1. Информация об организации соответствует официальным данным
2. Физическое, юридическое и эксплуатационное существование субъекта
3. Организация имеет исключительные права на использование домена, указанного в сертификате SSL
4. Организация надлежащим образом санкционировала выдачу сертификата EV SSL

Как создать сертификат SSL

То, как сгенерировать запрос на подпись сертификата (CSR), зависит исключительно от платформы, которую вы используете, и конкретного выбранного вами инструмента.

Мы будем генерировать CSR с использованием OpenSSL.

OpenSSL — это широко используемый инструмент для работы с CSR-файлами и SSL-сертификатами, который можно загрузить с официального сайта OpenSSL. Это инструмент реализации с открытым исходным кодом для SSL/TLS, который используется примерно на 65% всех активных интернет-серверов, что делает его неофициальным отраслевым стандартом.

Установка OpenSSL в Debian и Ubuntu

Сначала проверим, установлена ли у нас утилита OpenSSL при помощи команды:

dpkg -l |grep openssl

Если пакет OpenSSL установлен, мы получим следующий результат:

ii libgnutls-openssl27:amd64   2.12.23-12ubuntu2.4   amd64   GNU TLS library - OpenSSL wrapper

ii openssl   1.0.1f-1ubuntu2.16   amd64   Secure Sockets Layer toolkit - cryptographic utility

Если вы не видите такого результата, выполните следующую команду для установки OpenSSL:

apt-get install openssl

Установка OpenSSL в Red Hat и CentOS

Red Hat (версия 7.0 и более поздние) должна поставляться с предустановленной ограниченной версией OpenSSL. Он предлагает только ограниченную поддержку для IDEA, RC5 и MDC2, поэтому вы можете установить недостающие функции.

Чтобы проверить, установлен ли OpenSSL на сервере yum (например, Red Hat или CentOS), выполните следующую команду:

rpm -qa | grep -i openssl

Эта команда должна вернуть следующий результат:

openssl-1.0.1e-48.el6_8.1.x86_64
openssl-devel-1.0.1e-48.el6_8.1.x86_64
openssl-1.0.1e-48.el6_8.1.i686

Если ваш формат вывода отличается, это означает, что OpenSSL не установлен на вашем сервере. Выполните следующую команду для установки OpenSSL:

yum install openssl openssl-devel

Что такое запрос на подпись сертификата (CSR)?

Запрос на подпись сертификата (CSR — Certificate Signing Request) содержит наиболее важную информацию о вашей организации и домене. Это зашифрованный блок текста, который включает информацию о вашей организации, такую как страна, адрес электронной почты, полное доменное имя и так далее Он отправляется в центр сертификации при подаче заявки на сертификат SSL.

Обычно вы генерируете пару CSR и ключ локально на сервере, где будет установлен сертификат SSL. Однако это не строгое правило. Вы можете сгенерировать пару CSR и ключ на одном сервере и установить сертификат на другом. Однако это усложняет ситуацию. Мы рассмотрим и этот сценарий.

SSL использует две длинные строки случайно сгенерированных чисел, которые известны как закрытые и открытые ключи. Открытый ключ доступен для публичного домена, так как он является частью вашего SSL-сертификата и сообщается вашему серверу.

Закрытый ключ должен соответствовать CSR, с которым он был создан, и, в конечном счете, он должен соответствовать сертификату, созданному из CSR. Если закрытый ключ отсутствует, это может означать, что сертификат SSL не установлен на том же сервере, который сгенерировал запрос на подпись сертификата.

CSR обычно содержит следующую информацию:

Обратите внимание, что существуют определенные соглашения об именах, которые необходимо учитывать. Название организации и название организационной единицы не должны содержать следующие символы: < > ~! @ # $% ^ * / ()?., &

Как создать CSR

Запросы на подпись сертификата (CSR) создаются с помощью пары ключей — открытого и закрытого ключа. Только открытый ключ отправляется в центр сертификации и включается в сертификат SSL, и он работает вместе с вашим личным ключом для шифрования соединения. Любой может иметь доступ к вашему открытому ключу, и он проверяет подлинность SSL-сертификата.

Закрытый ключ — это блок закодированного текста, который вместе с сертификатом проверяет безопасное соединение между двумя компьютерами. Он не должен быть общедоступным, и его не следует отправлять в ЦС.

Целостность сертификата зависит от того, что только вы знаете закрытый ключ. Если вы когда-либо скомпрометированы или утеряны, как можно скорее введите новый сертификат с новым закрытым ключом. Большинство ЦС не взимают плату за эту услугу.

Большинство пар ключей состоят из 2048 битов. Хотя пары ключей длиной 4096 бит более безопасны, они замедляют SSL-рукопожатия и создают нагрузку на серверные процессоры. Из-за этого большинство сайтов по-прежнему используют 2048-битные пары ключей.

Вариант 1: создать CSR

Первое, что нужно сделать, — это создать 2048-битную пару ключей RSA локально. Эта пара будет содержать как ваш закрытый, так и открытый ключ. Вы можете использовать инструмент Java key или другой инструмент, но мы будем работать с OpenSSL.

Чтобы создать открытый и закрытый ключ с запросом на подпись сертификата (CSR), выполните следующую команду OpenSSL:

openssl req –out certificatesigningrequest.csr -new -newkey rsa:2048 -nodes -keyout privatekey.key

Что эта команда означает:

• openssl — активирует программное обеспечение OpenSSL
• req — указывает, что мы хотим CSR
• –out — указывает имя файла, в котором будет сохранен ваш CSR. У нас в примере это certificatesigningrequest.csr
• –new –newkey — создать новый ключ
• rsa:2048 — cгенерировать 2048-битный математический ключ RSA
• –nodes — нет DES, то есть не шифровать закрытый ключ в PKCS#12 файл
• –keyout — указывает домен, для которого вы генерируете ключ

Далее ваша система должна запустить текстовую анкету для заполнения, которую мы описывали в таблице выше:

Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

После завершения работы программы вы сможете найти файл CSR в вашем рабочем каталоге. Запрос на подпись сертификата, сгенерированный с помощью OpenSSL, всегда будет иметь формат файла .csr. Чтобы найти в папке все файлы этого формата используйте команду

ls *.csr

Тут будет список всех сертификатов, останется только найти тот, что мы только что сгенерировали.

Также вы можете открыть файл .csr в текстовом редакторе, например nano, чтобы просмотреть сгенерированный буквенно-цифровой код.

sudo nano your_domain.csr

Картинка с сайта: wiki.merionet.ru

После того, как вы сгенерировали CSR с парой ключей, сложно увидеть, какую информацию она содержит, поскольку она не будет в удобочитаемом формате. Вы можете легко декодировать CSR на своем сервере, используя следующую команду OpenSSL:

openssl req -in server.csr -noout -text

Далее можно декодировать CSR и убедиться, что он содержит правильную информацию о вашей организации, прежде чем он будет отправлен в центр сертификации. В Интернете существует множество CSR-декодеров, которые могут помочь вам сделать то же самое, просто скопировав содержимое файла CSR, например sslshopper.

Вариант 2. Создание CSR для существующего закрытого ключа

Рекомендуется выдавать новый закрытый ключ всякий раз, когда вы генерируете CSR. Если по какой-либо причине вам необходимо сгенерировать запрос на подпись сертификата для существующего закрытого ключа, используйте следующую команду OpenSSL:

openssl req -out CSR.csr -key privateKey.key -new

Вариант 3. Создание CSR для существующего сертификата и закрытого ключа

openssl x509 -x509toreq -in certificate.crt -out CSR.csr -signkey privateKey.key

Один маловероятный сценарий, в котором это может пригодиться, — это если вам нужно обновить существующий сертификат, но ни у вас, ни у вашего центра сертификации нет первоначального CSR. Это позволит извлечь информацию о вашем домене и организации из сертификата SSL и использовать его для создания нового CSR, что позволит вам сэкономить время. Параметр -x509toreq преобразует сертификат в запрос сертификата.

Вариант 4: Генерация самоподписанного(self-signed) сертификата

Самозаверяющий сертификат обычно используется для сред тестирования и разработки, а также в интрасети. Давайте создадим самозаверяющий сертификат, используя следующую команду OpenSSL:

openssl req -newkey rsa:2048 -nodes -keyout domain.key-x509 -days 365 -out domain.crt

Параметр –days установлен на 365, что означает, что сертификат действителен в течение следующих 365 дней. Параметр x509 указывает, что это будет самозаверяющий сертификат. Временный CSR генерируется, и он используется только для сбора необходимой информации. Если вы не хотите защищать свой закрытый ключ паролем, вы можете добавить параметр –nodes.

Центры сертификации не проверяют самоподписанные сертификаты. Таким образом, они не так безопасны, как проверенные сертификаты. Если ЦС не подписал сертификат, каждый основной браузер отобразит сообщение об ошибке «Ненадежный сертификат», как показано на рисунке ниже.

Картинка с сайта: wiki.merionet.ru

Вариант 5: Генерация самоподписанного сертификата из существующего закрытого ключа и CSR

Если у вас уже есть CSR и закрытый ключ и вам нужно создать самозаверяющий сертификат, используйте следующую команду:

openssl x509 -signkey domain.key -in domain.csr -req -days 365 -out domain.crt

Параметр –days установлен на 365, что означает, что сертификат действителен в течение следующих 365 дней.

Как скопировать содержимое файла CSR

Откройте каталог, в котором находится ваш CSR-файл. Введите следующую команду:

sudo cat domain.csr

Замените domain параметром FQDN вашего CSR. Эта команда отобразит содержимое файла CSR. Скопируйте весь контент, начиная с BEGIN CERTIFICATE REQUEST и заканчивая END CERTIFICATE REQUEST.

Продление сертификата — не используйте старые CSR повторно

То, что некоторые веб-серверы позволяют использовать старые CSR для обновления сертификатов, не означает, что вы должны их использовать. В качестве меры безопасности всегда генерируйте новый CSR и закрытый ключ при обновлении сертификата. Привязка к одному и тому же секретному ключу — это дорога, вымощенная уязвимостями безопасности.

Также рекомендуется обновить SSL-сертификат до истечения срока его действия. В противном случае потребуется покупать новый сертификат.

Как проверить свой CSR, SSL-сертификат и ключ

Как мы уже упоминали, было бы разумно проверить информацию, представленную в CSR, прежде чем подавать заявку на сертификат. Используйте следующие команды для проверки вашего запроса на подпись сертификата, SSL-сертификата и ключа:

CSR

Эта команда проверит CSR и отобразит данные, указанные в запросе:

openssl req -text -noout -verify -in server.csr

Ключ

Следующая команда проверит ключ и его действительность:

openssl rsa -in server.key -check

SSL сертификат

Когда вам нужно проверить сертификат, дату его истечения и кто его подписал, используйте следующую команду OpenSSL:

openssl x509 -in server.crt -text –noout

Закрытый ключ

Закрытый ключ кодируется и создается в формате PEM на основе Base-64, который не читается человеком. Вы можете открыть его в любом текстовом редакторе, но все, что вы увидите, это несколько десятков строк, которые кажутся случайными символами, заключенными в открывающие и закрывающие заголовки. Ниже приведен пример закрытого ключа:

-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQCVqGpH2S7F0CbEmQBgmbiDiOOGxhVwlG+yY/6OBQoPKcx4Jv2h
vLz7r54ngjaIqnqRNP7ljKjFLp5zhnAu9GsdwXbgLPtrmMSB+MVFHTJvKjQ+eY9p
dWA3NbQusM9uf8dArm+3VrZxNHQbVGXOIAPNHTO08cZHMSqIDQ6OvLma7wIDAQAB
AoGAbxKPzsNh826JV2A253svdnAibeSWBPgl7kBIrR8QWDCtkH9fvqpVmHa+6pO5
5bShQyQSCkxa9f2jnBorKK4+0K412TBM/SG6Zjw+DsZd6VuoZ7P027msTWQrMBxg
Hjgs7FSFtj76HQ0OZxFeZ8BkIYq0w+7VQYAPBWEPSqCRQAECQQDv09M4PyRVWSQM
S8Rmf/jBWmRnY1gPPEOZDOiSWJqIBZUBznvOPOOQSH6B+vee/q5edQA2OIaDgNmn
AurEtUaRAkEAn7/65w+Tewr89mOM0RKMVpFpwNfGYAj3kT1mFEYDq+iNWdcSE6xE
2H0w3YEbDsSayxc36efFnmr//4ljt4iJfwJAa1pOeicJhIracAaaa6dtGl/0AbOe
f3NibugwUxIGWkzlXmGnWbI3yyYoOta0cR9fvjhxV9QFomfTBcdwf40FgQJAH3MG
DBMO77w8DK2QfWBvbGN4NFTGYwWg52D1Bay68E759OPYVTMm4o/S3Oib0Q53gt/x
TAUq7IMYHtCHZwxkNQJBAORwE+6qVIv/ZSP2tHLYf8DGOhEBJtQcVjE7PfUjAbH5
lr++9qUfv0S13gXj5weio5dzgEXwWdX2YSL/asz5DhU=
-----END RSA PRIVATE KEY-----

В большинстве случаев вам не нужно импортировать код закрытого ключа в файловую систему сервера, так как он будет создан в фоновом режиме, пока вы создаете CSR, а затем автоматически сохраняется на сервере. Во время установки SSL-сертификата система извлекает ключ.

Проверьте, совпадают ли сертификат и закрытый ключ

Для проверки вам нужно вывести контрольные суммы md5 и сравнить их. Выполните следующую команду:

openssl x509 -noout -modulus -in server.crt| openssl md5

openssl rsa -noout -modulus -in server.key| openssl md5

Устранение проблем с SSL

Система не извлекает закрытый ключ автоматически

Некоторые системы не автоматизируют процедуру извлечения закрытого ключа. Кроме того, если вам нужно установить существующий сертификат на другом сервере, вы, очевидно, не можете ожидать, что он получит закрытый ключ. Основная сложность здесь заключается в том, как найти точное местоположение ключа. Способ получения ключа зависит от используемой ОС сервера и от того, использовался ли интерфейс командной строки или панель управления веб-хостинга определенного типа для генерации CSR.

Как найти свой ранее установленный закрытый ключ?

Если дело в том, что ваш сертификат уже установлен, выполните следующие действия, которые помогут вам найти свой закрытый ключ в популярных операционных системах.

Nginx

Вы сможете найти местоположение личного ключа вашего сервера в файле виртуального хоста вашего домена.

Перейдите к местоположению корневого сервера сайта (обычно это каталог /var/www/) и откройте основной файл конфигурации сайта. Найдите директиву ssl_certificate_key, которая предоставит путь к файлу закрытого ключа.

Если вы не можете найти директиву ssl_certificate_key, возможно, существует отдельный файл конфигурации для деталей SSL. Ищите что-нибудь вроде ssl.conf.

Apache

При использовании библиотеки OpenSSL в Apache закрытый ключ по умолчанию сохраняется в /usr/local/ssl. Запустите openssl version –a, команду OpenSSL, которая определяет, какую версию OpenSSL вы используете.

Выходные данные будут отображать каталог, который содержит закрытый ключ. Смотрите пример выходных данных ниже:

OpenSSL 1.0.2g  1 Dec 2016

built on: reproducible build, date unspecified

platform: debian-amd64

options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)

compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -

D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fstack-protector-

strong -Wformat -Werror=format-security -Wdate-time -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 -DECP_NISTZ256_ASM

OPENSSLDIR: "/usr/lib/ssl"

Последняя строка OPENSSLDIR определяет путь к файлу. В приведенном примере это местоположение по умолчанию /usr/lib/ssl.

Если вы не создавали CSR с OpenSSL, вам нужно найти и получить доступ к вашему основному файлу конфигурации Apache, который является apache2.conf или httpd.conf. Директива SSLCertficateKeyFile будет указывать путь к файлу закрытого ключа.

Windows (IIS)

На серверах, работающих под управлением Windows Internet Information Services, операционная система сохраняет закрытый ключ в скрытой папке, так же как любая обычная ОС Windows хранит важные системные данные.

Однако, экспортируя файл .pfx, вы можете получить закрытый ключ и сертификаты. Для этого выполните следующие действия:

1. Откройте консоль управления MMC (Microsoft Management Console).
2. Разверните дерево Сертификаты (локальный компьютер), расположенное в корне консоли.
3. Ваш сертификат находится либо в личной папке, либо в папке веб-хостинга. Вы можете идентифицировать каждый сертификат по его Common name (домену)
4. Щелкните правой кнопкой мыши сертификат, который вы хотите экспортировать, и выберите Все задачи -> Экспорт.
5. Следуйте инструкциям мастера для экспорта файла .pfx.

Теперь у вас есть то, что вам нужно, если вы хотите сохранить резервную копию или установить сертификат на другом сервере Windows.

Если вам нужно установить сертификат на другом сервере, который не работает под управлением Windows (например, Apache), вам необходимо сконвертировать файл .pfx и разделить файлы .key и .crt или .cer. Вы можете сделать это с OpenSSL.

Как переместить SSL-сертификат с сервера Windows на сервер, отличный от Windows?

Чтобы переместить сертификат с сервера Windows на сервер, отличный от Windows, необходимо извлечь закрытый ключ из файла .pfx с помощью OpenSSL.

1. После скачивания файла .pfx, как описано в разделе выше, выполните следующую команду OpenSSL, чтобы извлечь закрытый ключ из файла:

   openssl pkcs12 -in mypfxfile.pfx -out privatekey.txt –nodes

   Где mypfxfile.pfx— это резервная копия сертификатов вашего сервера Windows.

2. Эта команда создаст выходной файл privatekey.txt. Используйте текстовый редактор, чтобы открыть файл, и вы увидите закрытый ключ в верхней части списка в стандартном формате:

   -----BEGIN RSA PRIVATE KEY-----
   (Encrypted Text Block)
   -----END RSA PRIVATE KEY-----
   		

3. Скопируйте закрытый ключ, включая теги BEGIN и END, и вставьте его в новый текстовый файл. Сохраните текстовый файл как Your_Domain_Name.key.

Команды OpenSSL для конвертации CSR

Если вы работаете с серверами Apache, запросы на подпись сертификатов (CSR) и ключи хранятся в формате PEM. Но что, если вы хотите перенести CSR на сервер Tomcat или Windows IIS? Вам придется конвертировать стандартный файл PEM в файл PFX. Следующие команды помогут вам сделать это.

Примечание: Используйте параметр -nodes, если вы не хотите шифровать файл .key. Если вы не используете этот параметр, вам нужно будет указать пароль.

Преобразовать PEM CSR и закрытый ключ в PKCS12 (.pfx .p12)

Файлы FKCS12 используются для экспорта или импорта сертификатов в Windows IIS.

openssl pkcs12 -inkey domain.key -in domain.crt -export -out domain.pfx

Эта команда возьмет закрытый ключ и CSR и преобразует его в один файл .pfx. Вы можете настроить экспортную фразу-пароль, но также можете оставить это поле пустым. Обратите внимание, что, объединив строки символов сертификата в конец одного файла PEM, вы можете экспортировать цепочку сертификатов в формат файла .pfx.

Конвертировать PKCS12 в PEM CSR

openssl pkcs12 -in domain.pfx -nodes -out domain.combined.crt

Если файл .pfx содержит цепочку сертификатов, файл .crt PEM также будет содержать несколько элементов.

Конвертировать PEM в DER

DER — это двоичный формат, обычно используемый с Java. Чтобы преобразовать файл ASCII PEM в DER, используйте следующую команду OpenSSL:

openssl x509 -in domain.crt -outform der -out domain.der

Конвертировать DER в PEM

Если вам нужно преобразовать файл .der в PEM, используйте следующую команду OpenSSL:

openssl x509 -inform der -in domain.der -out domain.crt

Зашифровать незашифрованный закрытый ключ

Следующая команда OpenSSL возьмет незашифрованный закрытый ключ и зашифрует его с помощью определенной вами парольной фразы.

openssl rsa -des3 -in unencrypted.key -out encrypted.key

Определите ключевую фразу для шифрования закрытого ключа.

Расшифровать зашифрованный закрытый ключ

Следующая команда OpenSSL возьмет зашифрованный закрытый ключ и расшифрует его.

openssl rsa -in encrypted.key -out decrypted.key

При появлении запроса введите кодовую фразу для расшифровки закрытого ключа.

Проверить версию OpenSSL

Эта команда отображает версию OpenSSL, и ее параметры, с которыми она была скомпилирована:

openssl version -a

Получим примерно такой вывод:

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, а также устранить наиболее распространенные ошибки.

Дескриптор защиты

Объекты, к которым могут получать доступ процессы, имеют специальный атрибут – дескриптор защиты (security descriptor), содержащий информацию обо всех пользователях, которым разрешен или запрещен доступ к объекту.

Структура данных SECURITY_DESCRIPTOR, представляющая дескриптор защиты, описана в файле public\sdk\inc\ntseapi.h (строка 1173) и включает следующие основные поля:

• Owner – SID владельца;
• Dacl – список управления избирательным доступом;
• Sacl – системный список управления доступом.

Списки управления доступом (ACL, Access-Control List) в системе представлены заголовком (ACL Header) и последовательностью элементов списка (ACE, Access-Control Entry) (рис.13.3).

Картинка с сайта: intuit.ru

Рис.
13.3.
Внутреннее представление списка управления доступом ACL

Заголовок списка описывается структурой ACL (файл public\sdk\inc\ntseapi.h, строка 658), в которой хранятся количество элементов списка ACL (поле AceCount) и общий размер списка без заголовка (поле AclSize).

Элементы ACE имеют заголовок (ACE Header), описываемый структурой ACE_HEADER (тот же файл, строка 687), маску доступа и идентификатор безопасности SID. В заголовке указывается тип ACE (поле AceType); множество значений этого поля приведены в строках 699–728. Основными являются ACCESS_ALLOWED_ACE_TYPE (доступ разрешен) и ACCESS_DENIED_ACE_TYPE (доступ запрещен).

Маска доступа (Access Mask) описывает разнообразные виды доступа к объектам (строки 72–166). В маске выделяются стандартные права доступа (Standard Access Rights), применимые к большинству объектов, и специфичные для объектов права доступа (Object-Specific Access Rights).

Стандартными являются следующие права доступа:

• DELETE – право на удаление объекта;
• READ_CONTROL – право на просмотр информации о дескрипторе защиты объекта;
• SYNCHRONIZE – право на использование объекта для синхронизации;
• WRITE_DAC – право на изменение списка DACL;
• WRITE_OWNER – право на смену владельца объекта.

Списки управления доступом бывают двух видов: DACL и SACL. Список управления избирательным доступом (DACL, Discretionary Access-Control List) определяет пользователей, которые могут получать доступ к объекту, а также указывает тип доступа. В системном списке управления доступом (SACL, System Access-control List) перечислены пользователи и операции, которые должны учитываться в журнале аудита безопасности (security audit log).

Схема получения доступа процесса к объекту показана на рис.13.4.

Картинка с сайта: intuit.ru

Рис.
13.4.
Схема получения доступа процесса к объекту

За проверку возможности доступа процесса к объекту отвечает функция SeAccessCheck (файл base\ntos\se\accessck.c, строка 3391). На вход функции поступают следующие параметры:

• дескриптор защиты объекта (SecurityDescriptor);
• маркер доступа процесса (элемент структуры SubjectSecurityContext);
• маска запрашиваемого доступа (DesiredAccess);
• маска ранее предоставленного доступа (PreviouslyGrantedAccess);
• режим работы процессора (AccessMode);

Функция возвращает TRUE, если процессу возможно предоставить доступ к объекту, а также маску предоставленного доступа (GrantedAccess). Если доступ запрещен, функция возвращает FALSE.

Функция SeAccessCheck осуществляет следующие действия:

• Сначала анализируется режим работы процессора – если это режим ядра, доступ предоставляется без дальнейшего анализа (строки 3396–3416).
• В случае пользовательского режима проверяется дескриптор защиты: если он отсутствует (SecurityDescriptor == NULL), в доступе отказывается (строки 3423–3428).
• Если маска запрашиваемого доступа равна нулю (DesiredAccess == 0), возвращается маска ранее предоставленного доступа (строки 3442–3454).
• Если запрашивается доступ на изменение списка DACL (WRITE_DAC) или на чтение информации в дескрипторе защиты (READ_CONTROL), то при помощи функции SepTokenIsOwner проверяется, не является ли процесс владельцем объекта, к которому требуется получить доступ (строки 3477–3483). Если является, то ему предоставляются указанные права (3485–3492), а если запрашиваются только эти права, то функция успешно возвращает требуемую маску доступа (строки 3498–3506).
• Вызывается функция SepAccessCheck (определенная в том же файле, строка 1809), которая просматривает список DACL объекта в поисках соответствия идентификаторов безопасности SID в маркере доступа процесса. В том случае, если список DACL пустой, процессу предоставляется доступ (строка 3510–3527).

Права и привилегии

Кроме операций с объектами система должна контролировать множество других действий пользователей, например, вход в систему, включение/выключение компьютера, изменение системного времени, загрузка драйверов и т.д.

Для управления такими действиями, не связанными с доступом к конкретным объектам, система использует два механизма – права учетных записей и привилегии.

Право учетной записи (account right) – разрешение или запрет на определенный вид входа в систему.

Различают следующие виды входа:

• интерактивный (локальный) вход;
• вход из сети;
• вход через службу удаленных рабочих столов (ранее называлось – «через службу терминалов»);
• вход в качестве службы;
• вход в качестве пакетного задания.

Проверка прав учетных записей осуществляется не в ядре, а в процессах Winlogon.exe и Lsass.exe.

Привилегия (privilege) – разрешение или запрет определенных действий в системе, например, включение/выключение компьютера или загрузка драйверов. Привилегии хранятся в поле Privileges структуры маркера доступа TOKEN (см. выше).

Список всех привилегий в системе можно посмотреть в оснастке MMC «Локальная политика безопасности» (Local Security Policy), раздел «Локальные политики» – «Назначение прав пользователей» (Local Policies – User Rights Assignment) (см. рис.13.5). Вызывается оснастка через Панель управления – Администрирование. (Control Panel – Administrative Tools).

Картинка с сайта: intuit.ru

Рис.
13.5.
Оснастка «Локальная политика безопасности»

Следует отметить, что в оснастке не различаются права учетных записей и привилегии, но это легко можно сделать самостоятельно: право учетной записи всегда содержит слово «вход» (например, «Вход в качестве пакетного задания»).

Резюме

В лекции описываются требования к безопасности, предъявляемые к операционным системам Windows, и то, каким образом эти требования реализуются. Рассматривается схема проверки прав доступа процесса к объекту, которая заключается в сравнении параметров маркера доступа процесса и дескриптора защиты объекта. Также приводится информация о правах и привилегиях учетных записей.

Следующая лекция посвящена вопросам взаимодействия Windows с внешними устройствами.

Контрольные вопросы

1. Какие требования к безопасности предъявляются к Windows?
2. Что такое идентификатор защиты (SID)? Как его узнать?
3. Что такое дескриптор защиты (security descriptor)? Где он хранится?
4. Что такое маркер доступа (access token)? Где он хранится?
5. Опишите схему получения доступа процесса к объекту.
6. Что такое права и привилегии учетных записей? Чем они отличаются?