Зачем же Object Storage?

• ScaleIO — круто, просто, но шаг в сторону — лицензия, а так хочется независимости. И с ходу не нашел возможности обеспечения отказоустойчивости конфигурации для ЦОДов;
• OpenIO — видимо начинающий проект и я не нашел описания нужного мне функционала;
• Ceph — что же, можно попробовать. Изначальным скудным требованиям удовлетворяет.

Вроде все готово! Переходим к установке и настройке самого кластера

As of firefly (v0.80), Ceph Object Gateway is running on Civetweb (embedded into the ceph-radosgw daemon) instead of Apache and FastCGI. Using Civetweb simplifies the Ceph Object Gateway installation and configuration.

And for example a count of 64 total PGs. Honestly, protection group calculations is something that still does not convince me totally, I don’t get the reason why it should be left to the Ceph admin to be manually configured, and then often complain that is wrong. Anyway, as long as it cannot be configured automatically, the rule of thumb I’ve find out to get rid of the error is that Ceph seems to be expecting between 20 and 32 PGs per OSD. A value below 20 gives you this error, and a value above 32 gives another error.
So, since in my case there are 9 OSDs, the minimum value would be 9*20=180, and the maximum value 9*32=288. I chose 256 and configured it dinamically.

PG (Placement Groups) — группа размещения или логическая коллекция объектов в Ceph, которые реплицируются в OSD. Одна группа может сохранять данные на несколько OSD, в зависимости уровня сложности системы. Формула для вычисления групп размещения для Ceph следующая:

Кол-во PG = (кол-во OSD * 100) / кол-во реплик

При этом результат должен быть округлён до ближайшей степени двойки (например, по формуле = 700, после округления = 512).
PGP (Placement Group for Placement purpose) — группы размещения для целей расположения. Количество должно быть равным общему числу групп размещения.

Collection.stream().operation()

Collection.parallelStream().operation()

Source.stream().parallel().operation()

void parallel() {
  int result = IntStream.range(0, 3)
       .parallel()
       .peek(it -> System.out.printf("Thread [%s] peek: %d\n", Thread.currentThread().getName(), it))
       .sum();
  System.out.println("sum: " + result);
}

Thread [ForkJoinPool.commonPool-worker-1] peek: 0
Thread [main] peek: 1
Thread [ForkJoinPool.commonPool-worker-0] peek: 2
sum: 3

ForkJoinPool::makeCommonPool

private static ForkJoinPool makeCommonPool() {
   int parallelism = -1;
   try {  // ignore exceptions in accessing/parsing properties
       String pp = System.getProperty
           ("java.util.concurrent.ForkJoinPool.common.parallelism");
           if (pp != null)
             parallelism = Integer.parseInt(pp);
      } catch (Exception ignore) {
   }
   if (parallelism < 0 && // default 1 less than #cores
       (parallelism = Runtime.getRuntime().availableProcessors() - 1) <= 0)
       parallelism = 1;
   if (parallelism > MAX_CAP)
       parallelism = MAX_CAP;
   return new ForkJoinPool(parallelism, factory, handler, LIFO_QUEUE,
                           "ForkJoinPool.commonPool-worker-");
}

static final int MAX_CAP      = 0x7fff;        // max #workers - 1

-Djava.util.concurrent.ForkJoinPool.common.parallelism=n

Thread t = new Thread(() -> {
   parallel();
}, "MyThread");

t.start();
t.join();

Thread [ForkJoinPool.commonPool-worker-1] peek: 0
Thread [MyThread] peek: 1
Thread [ForkJoinPool.commonPool-worker-0] peek: 2
sum: 3

final long ms = System.currentTimeMillis();
ForkJoinPool commonPool = ForkJoinPool.commonPool();
System.out.println("Parallelism: " + commonPool.getParallelism());
IntStream.range(0, commonPool.getParallelism() + 1).forEach((it) -> commonPool.submit(() -> {
   try {
       System.out.printf("[%d sec] [%s]: #%d start()\n",
               TimeUnit.SECONDS.convert(System.currentTimeMillis() - ms, TimeUnit.MILLISECONDS),
               Thread.currentThread().getName(), it);
       TimeUnit.SECONDS.sleep(5);
   } catch (Exception e) {e.printStackTrace();}
   System.out.printf("[%d sec] [%s]: #%d finish()\n", TimeUnit.SECONDS.convert(System.currentTimeMillis() - ms, TimeUnit.MILLISECONDS), Thread.currentThread().getName(), it);
}));

int result = IntStream.range(0, 3)
       .parallel()
       .peek(it -> System.out.printf("Thread [%s] peek: %d\n", Thread.currentThread().getName(), it))
       .sum();
System.out.println("sum: " + result);
commonPool.awaitTermination(100, TimeUnit.SECONDS);

Parallelism: 2
[0 sec] [ForkJoinPool.commonPool-worker-1]: #0 start()
Thread [main] peek: 1
[0 sec] [ForkJoinPool.commonPool-worker-0]: #1 start()
Thread [main] peek: 2
Thread [main] peek: 0
sum: 3
[0 sec] [main]: #2 start()
[5 sec] [ForkJoinPool.commonPool-worker-0]: #1 finish()
[5 sec] [ForkJoinPool.commonPool-worker-1]: #0 finish()
[5 sec] [main]: #2 finish()

ForkJoinPool custom = new ForkJoinPool(2);
custom.submit(() -> {
           int result = IntStream.range(0, 3)
                   .parallel()
                   .peek(it -> System.out.printf("Thread [%s] peek: %d\n", Thread.currentThread().getName(), it))
                   .sum();
           System.out.println("sum: " + result);
       });

Parallelism: 2
[0 sec] [ForkJoinPool.commonPool-worker-1]: #0 start()
Thread [ForkJoinPool-1-worker-0] peek: 0
Thread [ForkJoinPool-1-worker-1] peek: 1
[0 sec] [main]: #2 start()
[0 sec] [ForkJoinPool.commonPool-worker-0]: #1 start()
Thread [ForkJoinPool-1-worker-0] peek: 2
sum: 3
[5 sec] [ForkJoinPool.commonPool-worker-1]: #0 finish()
[5 sec] [ForkJoinPool.commonPool-worker-0]: #1 finish()
[5 sec] [main]: #2 finish()

Мотивация

В русскоязычном интернете трудно найти информацию об API-библиотеке OpenSSL. Большое внимание уделяется использованию консольных команд для манипуляции с самоподписанными сертификатами для веб-серверов или OpenVPN-серверов.

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

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

Отдельно стоит отметить сетевую составляющую. Если сертификат есть и просто лежит на диске, он бесполезен.

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

Данная статья — компиляция моего опыта по работе с библиотекой OpenSSL при реализации клиент-серверного приложения. Описанные в ней функции будут работать как на десктопе, так и на Android-устройствах. К статье прилагается репозиторий с кодом на C/C++ для того, чтобы вы могли увидеть работу описываемых функций.

Цель

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

Сформируем требования к программе:
Ожидать подключения по порту (SSL-сервер)
При появлении входящего подключения:

• Подключиться к HTTPS-серверу
• Прочитать запрос клиента к серверу
• Передать прочитанные от клиента данные серверу
• Прочитать ответ сервера
• Передать ответ сервера клиенту
• Сбросить соединения

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

Разработка будет вестись на Ubuntu, прочий инструментарий: компилятор GCC 5.4.0, OpenSSL 1.0.2, curl 7.52.1, CMake 3.8.1 (единственный не из пакетов).

Для отправки запросов к нашему приложению будем использовать curl из консоли. Поскольку нам нужно указать CA-сертификат, команда будет выглядеть так:

curl --cacert ca.crt -v https://127.0.0.1:5566 -H "Host: taigasystem.com"

Указание заголовка Host требуется для того, чтобы curl корректно составил HTTP-запрос. Без этого сервер ответит ошибкой.

Начало и завершение работы

Для работы с библиотекой OpenSSL ее нужно инициализировать. Используйте следующий код:

#include bio.h>
#include ssl.h>
#include err.h>
...
void InitOpenSSL()
{
    OpenSSL_add_all_algorithms();
    ERR_load_BIO_strings();
    ERR_load_crypto_strings();
    SSL_load_error_strings();
    SSL_library_init();
}

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

void ClearOpenSSL()
{
    EVP_cleanup();
    CRYPTO_cleanup_all_ex_data();
    ERR_remove_thread_state(NULL);
    ERR_free_strings();
}

Контекст

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

SSL_CTX *SSL_CTX_new(const SSL_METHOD *method);

Список методов, которые можно передать в эту функцию, довольно обширен, но документация говорит нам, что нужно использовать SSLv23_server_method() для сервера и SSLv23_client_method() для клиента.

При этом библиотека автоматически выберет максимально безопасный протокол, поддерживаемый клиентом и сервером.

Вот пример создания контекста для клиента:

SSL_CTX *ctx = NULL;

ctx = SSL_CTX_new(SSLv23_client_method());
if (ctx == NULL)
{
    //Обработка ошибок
}

Для корректного удаления контекста следует использовать функцию SSL_CTX_free.

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

std::shared_ptr m_ctx(ctx, SSL_CTX_free);

Работа с ошибками

Большинство функций библиотеки OpenSSL возвращают 1 как признак успешного выполнения. Вот обычный код с проверкой на возникновение ошибки:

if (SSL_CTX_load_verify_locations(ctx, fileName, NULL) != 1)
{
    //Обработка ошибки
}

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

Сам по себе код ошибки не очень понятен пользователю, поэтому можно использовать функцию ERR_error_string для получения строкового представления о коде ошибки. Если функция возвращает 0, это значит, что ошибки нет.

Вот пример получения строки с описанием ошибки по коду ошибки:

#include err.h>

...
//Вызов каких-либо функций библиотеки OpenSSL
std::cerr << ERR_error_string(ERR_get_error(), NULL) << std::endl;
...

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

Стоит отметить, что для каждого отдельного потока создается отдельная очередь сообщений об ошибке.

Ключи

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

Создание

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

EVP_PKEY *pkey = NULL;

pkey = EVP_PKEY_new();
if (pkey == NULL)
{   
    //Обработка ошибки     
}

Подробнее о EVP можно прочитать здесь.

Обратная для EVP_PKEY_new функция EVP_PKEY_free освобождает память и удаляет структуру EVP_PKEY.

Теперь необходимо подготовить BIGNUM структуру для генерации RSA (подробнее об этой структуре можно узнать здесь):

BIGNUM *big = NULL;
big = BN_new();
if (big == NULL)
{
    //Обработка ошибки
}
else if (BN_set_word(big, RSA_F4) != 1)
{
    //Обработка ошибки
    BN_free(big);
}

Функция BN_set_word устанавливает размер для структуры BIGNUM. Допустимыми являются значения RSA_3 и RSA_F4, последний — предпочтительнее.

Настал черед для генерации ключей. Для этого нужно создать структуру RSA:

RSA *rsa = NULL;
rsa = RSA_new();
if (rsa == NULL)
{
    //Обработка ошибки
}

Теперь сама генерация ключей:

if (RSA_generate_key_ex(rsa, 4096, big, NULL) != 1)
{
    //Обработка ошибки
}

4096 это размер ключа, который мы хотим получить.

Заканчиваем генерацию ключей записью новых ключей в структуру EVP_PKEY:

if (EVP_PKEY_assign_RSA(pkey, rsa) !=1)
{
    //Обработка ошибки
}

PEM-формат

PEM — достаточно простой формат для хранения ключей и сертификатов. Он представляет собой текстовый файл, в котором последовательно хранятся записи вида:

-----BEGIN RSA PRIVATE KEY-----
MIIJJwIBAAKCAgEAvNwgYmIyfvY6IsVZwRCkAHTOhwE3Rp/uNcUoTcPl5atOwPVW
JLY3odYmILsa8se7B/aNNzO7AlvXwlzxinQ3AF7l37LqGzf8v16TFVN4kit8vrq0
V9bBXHpiWH+YQT4gBVmSkwqEMZ/wQlUOIxz4Q2M7cXRu4fRe3rt3kGHCPJ66Ybax
yEp6nfdK8IKsyxqAXjBkqfC5rkdw2n7UAd/OnPRCDowyvythDb8jR1LkbJjlIatK
....
yajhmBDpS11hzuWHhDmpjbrV79OMRzKQAWBKRubObtGIsFB2CzbabusV+oq/Y78y
OxriZYqoRv3WB5GH/pPO9w1ptveddLU33NVBSRfFS1jyqyj/1CqXlE4gcQ==
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIFkTCCA3mgAwIBAgIJAMPIqA2oVd/SMA0GCSqGSIb3DQEBCwUAMF8xCzAJBgNV
BAYTAlJVMQ8wDQYDVQQIDAZNb3Njb3cxDzANBgNVBAcMBk1vc2NvdzEUMBIGA1UE
...
bt9NHGnCxYcParG+YqU5UTUrCUGUfnZhJAX+qkgsVSC5c81Tk0VXTQx3EiEvdzV+
wUX9LMRLIxjy1D5AO6a29LkzNAvw+iFm36VO+ssdkJW4Q6MAYA==
-----END CERTIFICATE-----

Тут стоит отметить, что количество символов ----- в начале заголовка и в конце, а также в закрывающей строке должно быть одинаковым.

Более подробно этот формат описан тут:
— RFC1421 Part I: Message Encryption and Authentication Procedures
— RFC1422 Part II: Certificate-Based Key Management
— RFC1423 Part III: Algorithms, Modes, and Identifiers
— RFC1424 Part IV: Key Certification and Related Services

Запись ключей в PEM-формате

Допустим, у нас есть пара открытый/закрытый ключ в структуре EVP_PKEY, тогда для записи их в файл следует использовать функции PEM_write_PrivateKey и PEM_write_PUBKEY.

Вот пример использования этих функций:

FILE *f = fopen("server.pem", "wb");
if (!PEM_write_PrivateKey(f, key, NULL, NULL, 0, 0, NULL))
{
    //Обработка ошибки
    fclose(f);
}
else if (!PEM_write_PUBKEY(f, key))
{
    //Обработка ошибки
    fclose(f);
}
fclose(f);

Стоит дать некоторые пояснения относительно функции

int PEM_write_PrivateKey(FILE *fp, EVP_PKEY *x, const EVP_CIPHER *enc, unsigned char *kstr, int klen, pem_password_cb *cb, void *u);

, где const EVP_CIPHER *enc — это указатель на алгоритм шифрования для шифрования закрытого ключа перед его сохранением.
Например, EVP_aes_256_cbc() значит "AES with a 256-bit key in CBC".

Алгоритмов шифрования очень много, и всегда можно
подобрать что-то по душе. Соответствующие определения можно найти в openssl/evp.h.
unsigned char *kstr ожидает получить указатель на строку с паролем для шифрования ключа, а int klen — длину этой строки.

Если заданы kstr и klen, то параметры cb и u игнорируются, где:— cb — это указатель на функцию вида:

int cb(char *buf, int size, int rwflag, void *u);

— buf — указатель на буфер для записи пароля
— size — максимальный размер пароля (т.е. размер буфера)
— rwflag равен 0 при чтении и 1 при записи

Результат выполнения функции — длина пароля или 0 в случае возникновения ошибки.

Параметр void *u для обеих функций используется для передачи дополнительных данных. Например, как указатель на окно для GUI приложения.

Загрузка ключей из PEM-файла

Загрузка ключей происходит при помощи функций PEM_read_PrivateKey и PEM_read_PUBKEY. Обе функции имеют одинаковые параметры и возвращаемое значение:

EVP_PKEY *PEM_read_PUBKEY(FILE *fp, EVP_PKEY **x, pem_password_cb *cb, void *u);
EVP_PKEY *PEM_read_PrivateKey(FILE *fp, EVP_PKEY **x, pem_password_cb *cb, void *u);

где:
— FILE *fp — открытый для чтения файловый дескриптор
— EVP_PKEY **x — структура, которая должна быть перезаписана
— pem_password_cb *cb — функция для получения пароля расшифровки ключа
— void *u — строка с паролем ключа, завершающаяся \0

Вот пример функции для получения пароля для расшифровки ключа:

int pass_cb(char *buf, int size, int rwflag, void *u)
{
    int len;
    char *tmp;

    if (rwflag == 1)
        std::cout << "Введите пароль для " << (char*)u << ": ";
    else
        std::cout << "Введите пароль для загрузки ключа: ";
    std::string pass;

    std::cin >> pass;
    if (pass.empty() || pass.length() <=0)
        return 0;

    len = pass.length();

    if (len > size) 
    len = size;

    memcpy(buf, pass.c_str(), len);
    return len;
}

Вот пример того, как можно загрузить не зашифрованный закрытый ключ из файла:

FILE *f = NULL;
f = fopen(fileName.c_str(), "rb");
if (f == NULL)
{
    //Обработка ошибки
}

EVP_PKEY *key = NULL;
key = PEM_read_PrivateKey(f, NULL, NULL, NULL);
if (key == NULL)
{
   //Обработка ошибки
}
fclose(f);

Загрузка ключей из памяти

Иногда бывает удобно хранить ключ или сертификат как константу в программе. Для таких случаев можно использовать структуру типа BIO. Эта структура и связанные с ней функции повторяют функционал ввода-вывода для FILE.

Вот так можно загрузить ключ из памяти:

const char *key = "-----BEGIN RSA PRIVATE KEY-----\n"
    "MIIJKAIBAAKCAgEA40vjOGzVpuJv+wIfNBQSr9U/EeRyvSy/L6Idwh799LOPIwjF\n"
    .....
    "zkxvkGMPBY3BcSPjipuydWTt8xE8MOe0SmEcytHZ/DifwF9qyToDlTFOUN8=\n"
    "-----END RSA PRIVATE KEY-----";

BIO *buf = NULL;
buf = BIO_new_mem_buf(key, -1);
if (buf == NULL)
{
    //Обработка ошибки        
}

EVP_PKEY *pkey = NULL;
pkey = PEM_read_bio_PrivateKey(buf, NULL, NULL, NULL);
if (pkey == NULL)
{
    //Обработка ошибки
}

Запрос сертификата

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

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

Создание

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

Для создания CSR нам понадобится ключ EVP_PKEY, созданный ранее. Все начинается с выделения памяти под структуру CSR:

X509_REQ *req = NULL;
req = X509_REQ_new();
if (req == NULL)
{
    //Обработка ошибки
}

Обратной функцией к X509_REQ_new является X509_REQ_free.

Теперь нужно задать версию сертификата. В данном случае версия равна 2:

if (X509_REQ_set_version(req, 2) != 1)
{
    //Обработка ошибки
    X509_REQ_free(req);
}

По стандарту X.509 эта версия должна быть на единицу меньше версии сертификата. Т.е. для версии сертификата 3 следует использовать число 2.

Теперь будем задавать данные создателя запроса. Будем использовать следующие поля:

—С — двухбуквенный код страны, например RU
— ST — область, в нашем случае Moscow
— L — город, снова Moscow
— O — организация, например Taigasystem
— CN — доменное имя, для нас будет taigasystem.com

Вот так эти поля задаются в запрос:

X509_NAME *name = X509_REQ_get_subject_name(req);
if (X509_NAME_add_entry_by_txt(name, "C", MBSTRING_ASC, (const unsigned char *)"RU", -1, -1, 0) != 1)
{
    //Обработка ошибки
    X509_REQ_free(req);
}

if (X509_NAME_add_entry_by_txt(name, "ST", MBSTRING_ASC, (const unsigned char *)"Moscow", -1, -1, 0) != 1)
{
    //Обработка ошибки
}

if (X509_NAME_add_entry_by_txt(name, "L", MBSTRING_ASC, (const unsigned char *)"Moscow", -1, -1, 0) != 1)
{
    //Обработка ошибки
}

if (X509_NAME_add_entry_by_txt(name, "O", MBSTRING_ASC, (const unsigned char *)"Taigasystem", -1, -1, 0) != 1)
{
    //Обработка ошибки
}

if (X509_NAME_add_entry_by_txt(name, "CN", MBSTRING_ASC, (const unsigned char *)"taigasystem.com", -1, -1, 0) != 1)
{
    //Обработка ошибки
}

Заметим, что сначала мы получаем структуру X509_NAME из структуры CSR запроса и задаем значения для нее.

Теперь нужно задать публичный ключ для этого запроса:

if (X509_REQ_set_pubkey(req, key) != 1)
{
    //Обработка ошибки
}

Последний штрих — подпись запроса:

if (X509_REQ_sign(req, key, EVP_sha256()) <= 0)
{
    //Обработка ошибки
}

В отличие от других функций OpenSSL, X509_REQ_sign возвращает
размер подписи в байтах, а не 1, при успешном завершении, и 0 — в случае ошибки.

Теперь запрос сертификата готов.

Сохранение CSR в файл

Сохранить CSR в файл довольно просто. Необходимо открыть файл, а затем — вызвать функцию PEM_write_X509_REQ:

FILE *f = NULL;
f = fopen("server.csr", "wb");
if (PEM_write_X509_REQ(f, csr) != 1)
{
    //Обработка ошибки
    fclose(f);
}
fclose(f);

В результате мы получим такой текст в файле server.csr:

-----BEGIN CERTIFICATE REQUEST-----
MIICnzCCAYcCAQEwWjELMAkGA1UEBhMCUlUxDzANBgNVBAgMBlJ1c3NpYTEPMA0G
...
fbzFJ6EM00mbyr472lEXZpvdZgBCfxpkNDyp9nsiIQf0EyC05MgufOAKDT/fGQfa
4gWK
-----END CERTIFICATE REQUEST-----

Загрузка CSR из файла

Для загрузки CSR следует использовать функции:

X509_REQ *PEM_read_X509_REQ(FILE *fp, X509_REQ **x, pem_password_cb *cb, void *u);
X509_REQ *PEM_read_bio_X509_REQ(BIO *bp, X509_REQ **x, pem_password_cb *cb, void *u);

Первая загружает CSR из файла, вторая позволяет загрузить CSR из памяти.

Параметры данных функция аналогичны загрузке ключей из PEM-файла, за
исключением pem_password_cb и u, которые игнорируются.

Сертификаты

X.509 сертификат

X.509 — это одна из вариаций языка ASN.1, стандартизованная в rfc2459.

Более подробно о формате X.509 можно прочитать здесь и здесь.

Генерация сертификата без CSR

Можно сгенерировать сертификат без использования CSR. Это пригодится для создания CA.

Для генерации сертификата без CSR нам понадобится пара открытый/закрытый ключ в структуре EVP_PKEY. Начинаем с выделения памяти под структуру сертификата:

X509 *x509 = X509_new();
if (!x509)
    //Обработка ошибки

Обратной для X509_new является X509_free.

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

Также нужно использовать другие функции для доступа к данным сертификата:
— X509_set_version вместо X509_REQ_set_version
— X509_get_subject_name вместо X509_REQ_get_subject_name
— X509_set_pubkey вместо X509_REQ_set_pubkey
— X509_sign вместо X509_REQ_sign

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

Теперь можно установить серийный номер сертификата:

ASN1_INTEGER *aserial = NULL;
aserial = M_ASN1_INTEGER_new();
ASN1_INTEGER_set(aserial, 1);
if (X509_set_serialNumber(x509, aserial) != 1)
{
    //Обработка ошибки
}

Для каждого нового сертификата необходимо создавать новый серийный номер.

Теперь пришло время установить время жизни сертификата. Для этого устанавливается два параметра — начало и конец жизни сертификата:

if (!(X509_gmtime_adj(X509_get_notBefore(cert), 0)))
{
    //Обработка ошибки
    X509_free(cert);
}

// 31536000 * 3 = 3 year valid period
if (!(X509_gmtime_adj(X509_get_notAfter(cert), 31536000 * 3)))
{
    //Обработка ошибки
    X509_free(cert);
}

Началом жизни сертификата будет момент его выпуска — значение 0 для функции X509_get_notBefore. Конец жизни сертификата задается функцией X509_get_notAfter.

Последний штрих — подпись сертификата при помощи закрытого ключа:

EVP_PKEY *key; // Not null

if (X509_sign(cert, key, EVP_sha256()) <=0)
{
    long e = ERR_get_error();
    if (e != 0)
    {
        //Обработка ошибки
        X509_free(cert);
    }
}

Здесь есть интересная особенность: функция X509_sign возвращает размер подписи в байтах, если все прошло успешно, и 0 — в случае ошибки. Иногда функция возвращает ноль, даже если ошибки нет. Поэтому здесь приходится вводить дополнительную проверку на ошибку.

Генерация сертификата с CSR

Для генерации сертификата по CSR нам нужен закрытый ключ CA для подписи сертификата, сертификат CA для задания данных издателя и сам CSR-запрос.

Создание самого сертификата и установка версии и номера такие же, как и для сертификата без CSR. Разница появляется, когда нужно извлечь данные издателя из CSR-запроса и установить их в сертификат:

X509_REQ *csr; //not null

X509_NAME *name = NULL;
name = X509_REQ_get_subject_name(csr);
if (name == NULL)
{
    //Обработка ошибки
    X509_free(cert);
}

if (X509_set_subject_name(cert, name) != 1)
{
    //Обработка ошибки
    X509_free(cert);
}

После этого нужно уставить данные издателя сертификата. Для этого требуется сертификат CA:

X509 *CAcert; //not null

name = X509_get_subject_name(CAcert);
if (name == NULL)
{
    //Обработка ошибки
    X509_free(cert);
}

if (X509_set_issuer_name(cert, name) != 1)
{
    //Обработка ошибки
    X509_free(cert);
}

Видно, что данные из CSR мы устанавливаем при помощи X509_set_subject_name, а данные CA — при помощи X509_set_issuer_name.

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

// Get pub key from CSR
EVP_PKEY *csr_key = NULL;
csr_key = X509_REQ_get_pubkey(csr);
if (csr_key == NULL)
{
    //Обработка ошибки
}

// Verify CSR
if (X509_REQ_verify(csr, csr_key) !=1)
{
    //Обработка ошибки
    X509_free(cert);
}

// Set pub key to new cert
if (X509_set_pubkey(cert, csr_key) != 1)
{
    //Обработка ошибки
    X509_free(cert);
}

Теперь можно установить серийный номер сертификата:

ASN1_INTEGER *aserial = NULL;
aserial = M_ASN1_INTEGER_new();
ASN1_INTEGER_set(aserial, 1);
if (X509_set_serialNumber(cert, aserial) != 1)
{
    //Обработка ошибки
}

Последний штрих — следует подписать сертификат при помощи закрытого ключа CA:

EVP_PKEY *CAkey; // Not null
if (X509_sign(cert, CAkey, EVP_sha256()) <=0)
{
    long e = ERR_get_error();
    if (e != 0)
    {
        //Обработка ошибки
        X509_free(cert);
    }
}

После подписи наш новый сертификат готов.

Сохранение X.509 сертификата

Сохранение происходит довольно просто:

X509 *cert;
...
FILE *f = NULL;
f = fopen("server.crt", "wb");
if (!PEM_write_X509(f, cert))
{
    //Обработка ошибки
    fclose(f);
}
fclose(f);

Загрузка X.509 сертификата

Загрузка происходит при помощи двух функций:

X509 *PEM_read_X509(FILE *fp, X509 **x, pem_password_cb *cb, void *u);
X509 *PEM_read_bio_X509(BIO *bp, X509 **x, pem_password_cb *cb, void *u);

Параметры описаны выше.

Сетевая часть

Клиент

Подключение к хосту при помощи SSL-сокетов не очень отличается от обычного TCP-подключения.

Сначала нужно создать TCP-подключение к серверу:

//Попробуем получить IP для хоста
struct hostent *ip = nullptr;
ip = gethostbyname(host.c_str());
if (ip == nullptr)
{
    //Обработка ошибки
}

//Создаем сокет
int sock = socket(AF_INET, SOCK_STREAM, 0);
if (sock == -1)
{
    //Обработка ошибки
}

struct sockaddr_in dest_addr;
memset(&dest_addr, 0, sizeof(struct sockaddr_in));
dest_addr.sin_family      = AF_INET;
dest_addr.sin_port        = htons(port);
dest_addr.sin_addr.s_addr = *(long *)(ip->h_addr);

//Подключаемся:
if (connect(sock, (struct sockaddr *)&dest_addr, sizeof(struct sockaddr)) == -1)
{
    //Подключиться не удалось 
}

Теперь нужно создать клиентский SSL-контекст:

const SSL_METHOD *method = SSLv23_client_method();

SSL_CTX *ctx = NULL;
ctx = SSL_CTX_new(method);

if (ctx == NULL)
    //Обработка ошибки

Теперь нужно установить полученный сокет в SSL-структуру. Она получается из контекста:

SSL *ssl = SSL_new(ctx);
if (ssl == NULL)
{
    //Обработка ошибки
}

if (SSL_set_fd(ssl, sock) != 1)
{
    //Обработка ошибки
}

Последний штрих — само подключение:

if (SSL_connect(ssl) != 1)
{
    //Обработка ошибки
}

Чтение данных

Для чтения данных из SSL-сокета нужно использовать функцию:

int SSL_read(SSL *ssl, void *buf, int num);

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

int SSL_pending(const SSL *ssl);

Т.е. для чтения можно использовать такую конструкцию:

const int size = SSL_pending(ssl);
char *buf = new char[size];
memset(buf, 0, size);

if (SSL_read(ssl, buf, size) <= 0)
{
    //Обработка ошибки
}

В результате в буфере будут находиться уже декодированные данные.

Запись данных

Для записи используется функция:

int SSL_write(SSL *ssl, const void *buf, int num);

На входе она получает указатель на SSL-структуру, которая будет осуществлять запись, сами данные и их размер.

Вот пример такой записи:

char buf[] = "12345678"
if (SSL_write(ssl, buf, strlen(buf)) <= 0)
{
    //Обработка ошибки
}

Сервер

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

Начнем с подготовки контекста:

const SSL_METHOD *method = SSLv23_server_method();

SSL_CTX *ctx = NULL;
ctx = SSL_CTX_new(method);
if (ctx == NULL)
{
    //Обработка ошибки
}

Документация говорит нам, о том, что выбор SSLv23_server_method позволит библиотеке самостоятельно определить максимально безопасную версию протокола из поддерживаемых клиентом.

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

Загрузку X.509 сертификата и загрузку ключей мы рассмотрели чуть раньше, поэтому считаем, что у нас уже есть пара этих структур.

Установим для серверного контекста сертификат и ключ сертификата:

X509 *serverCert; //not null
EVP_PKEY *serverKey; //not null

if (SSL_CTX_use_certificate(ctx, serverCert) != 1)
{
    //Обработка ошибки
}

if (SSL_CTX_use_PrivateKey(ctx, serverKey) != 1)
{
    //Обработка ошибки
}

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

Начинаем с того, что для каждого такого сокета, нам нужна новая SSL-структура:

SSL *ssl = NULL;
ssl = SSL_new(ctx);
if (ssl == NULL)
{
    //Обработка ошибки
}

Теперь устанавливаем в эту структуру наш сокет:

int sock; //accepted tcp socket

if (SSL_set_fd(ssl, sock) != 1)
{
    //Hadle error
}

Сам механизм рукопожатия:

if (SSL_accept(ssl) != 1)
{
    //Обработка ошибки
}

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

int ret = SSL_accept(ssl);
if (ret == 0)
{
    //Обработка ошибки
}
if (ret < 0)
{
    unsigned long error = ERR_get_error();
    if (error == SSL_ERROR_WANT_READ ||
        error == SSL_ERROR_WANT_WRITE ||
        error == 0)
    {
        //Не ошибка, нужно дождаться получения следующего сообщения
        //в протоколе рукопожатия
    }
    else
    {
        //Обработка ошибки
    }
}
if (ret == 1)
{
    //Подключено
}

После установки соединения мы можем использовать описанные ранее функции ввода-вывода для чтения и записи данных в сокет.

Пример работы

Сборка программы

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

mkdir build
cd build
cmake ..
make

Запуск

В папке сборки (build) следует выполнить:

./openssl_api

При этом в этой же папке появится файл ca.crt — созданный программой
сертификат.

Чтобы проверить его работоспособность, нужно выполнить

cppurl --cacert ca.crt -v https://127.0.0.1:5566 -H "Host: taigasystem.com"

Первым параметром мы задаем используемый CA Сертификат, -v показывает нам все переданные и принятые сообщения. -H "Host: taigasystem.com" нужен, чтобы заметить в GET-запросе заголовок Host. Без этого параметра программа отработает, но в ответ на запрос мы получим 404-ю ошибку.

Вывод curl

Вот вывод запроса curl при запросе через нашу программу (не полный):

$ curl --cacert ca.crt -v https://127.0.0.1:5566 -H "Host: taigasystem.com"
* Rebuilt URL to: https://127.0.0.1:5566/
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 5566 (#0)
* found 1 certificates in ca.crt
* found 700 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / RSA_AES_128_GCM_SHA256
*        server certificate verification OK
*        server certificate status verification SKIPPED
*        common name: 127.0.0.1 (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: C=RU,CN=127.0.0.1,L=Moscow,O=Taigasystem,ST=Moscow
*        start date: Mon, 28 Aug 2017 07:36:42 GMT
*        expire date: Thu, 27 Aug 2020 07:36:42 GMT
*        issuer: C=RU,CN=127.0.0.1,L=Moscow,O=Taigasystem,ST=Moscow
*        compression: NULL
* ALPN, server did not agree to a protocol
> GET / HTTP/1.1
> Host: taigasystem.com
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.4.6 (Ubuntu)
< Date: Mon, 28 Aug 2017 07:39:18 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Language, Cookie
< X-Frame-Options: SAMEORIGIN
< Content-Language: ru
< Strict-Transport-Security: max-age=604800
<
....

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

Вывод программы

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

$ ./openssl_api
Библиотека OpenSSL инициализирована
Для проверки воспользуйтесь командой 'curl --cacert ca.crt -v https://127.0.0.1:5566 -H "Host: taigasystem.com" '
Структура хранения ключей создана
Создана структура BIGNUM
Изменен размер структуры BIGNUM
Создана RSA структура
Ключи сгенерированы
Ключи убраны в EVP
Сертификат создан. Длина подписи: 512
Структура хранения ключей создана
Создана структура BIGNUM
Изменен размер структуры BIGNUM
Создана RSA структура
Ключи сгенерированы
Ключи убраны в EVP
CSR создан. Длина подписи: 512
Сертификат создан. Длина подписи: 512
Структура для хранения ключей удалена
Сертификат успешно записан в ca.crt
SSL контекст создан
Сокет ожидает подключения на 5566 порту
Новое входящие соединение
Подключаемся к taigasystem.com на порту 443
Подключен к хосту taigasystem.com[188.225.73.237]:443
SSL контекст создан
SSL соединение с taigasystem.com:443 установлено
Цикл чтения/записи данных
#######################################
Прочитано 79 байт от клиента
#######################################
GET / HTTP/1.1
Host: taigasystem.com
User-Agent: curl/7.47.0
Accept: */*

#######################################
Прочитано 4096 байт от сервера
#######################################
HTTP/1.1 200 OK
Server: nginx/1.4.6 (Ubuntu)
Date: Mon, 28 Aug 2017 07:39:18 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Language, Cookie
X-Frame-Options: SAMEORIGIN
Content-Language: ru
Strict-Transport-Security: max-age=604800
...

Т.е. очевидно, что мы получили GET-запрос от клиента (curl) и ответ на него от сервера.

Ссылки

• Traffic Analysis of an SSL/TLS Session
• Документация библиотеки
• Примеры SSL от Wireshark
• Документация от CMake
• Инструкция по сборке библиотеки
• Пример SSL Сервера
• Пример SSL клиента
• Отличный набор примеров по всем аспектам
• Руководство по выживанию — TLS/SSL и сертификаты SSL (X.509)

Огромная благодарность за исследования tomasloh

• Каждый квартал года отправляется свыше 500 млн писем нежелательной почты, содержащих спам и загрузчики программ-шантажистов, которые пытаются автоматически установиться на компьютеры пользователей.
• Загрузчики программ-шантажистов поразили свыше 13,4 млн компьютеров.
• С другой стороны, 4,5 млн компьютеров были заражены вредоносным ПО Meadgive и Neutrino, основным атакующим кодом которых являются программы-шантажисты.
• В 2016 году программы-шантажисты были обнаружены на 3,9 млн ПК.

Блокировка программ-шантажистов в точке проникновения

Трояны-загрузчики, распространяемые через рассылки электронной почты

Эксплойты

Хакеры ищут новые пути

Атаки на серверы

Возможности вирусов-червей

Альтернативные способы оплаты и связи

Новые методы шантажа

Новые семейства программ-шантажистов — лидеры рейтинга

Cerber

Locky

Программы-шантажисты как глобальная угроза

Заключение: растущая угроза требует новых мер противодействия

Защита от заражений программами-шантажистами

Обнаружение программ-шантажистов

Реагирование на атаки программ-шантажистов

Усиленная защита в Windows 10 Creators Update

Описание проблемы

Что имеется на данный момент

Что необходимо

Предполагаемое решение

• горючего газа (на термохимическом принципе измерения);
• наклона (цифровой акселерометр);
• дыма (оптическая камера);
• вибрации (пьезопластина на металлической чушке);
• отрыва от охраняемой поверхности (концевик);
• вскрытия корпуса прибора (концевик).

Датчик газа

Акселерометр

Датчик дыма

To be continued...

Данная публикация носит исключительно информационный характер и призвана обратить внимание руководства крупного российского оператора систем охранной сигнализации "ГОЛЬФСТРИМ Охранные Системы" (далее — ГОЛЬФСТРИМ) на наличие уязвимости информационной системы, ставящей под удар защиту и безопасность граждан, а также федеральных органов исполнительной власти, доверивших защиту своего имущества данной компании.

ВНИМАНИЕ: Рекомендуем читать текст под музыку группы Каста-Скрепы, очень помогает глубже понять всю безнадежность ситуации, описанной ниже...

Предисловие

В нелёгкое время "цифровой экономики" и властных попыток зарегулировать Интернет, хотелось бы внести свою скромную лепту в совершенствование этого Мира и осветить отношение к ИБ со стороны одной частной компании. В нашей публикации мы покажем, как компания ГОЛЬФСТРИМ продемонстрировала свое наплевательское отношение к данному вопросу подставив тем самым не только рядовых пользователей-граждан, но также и органы исполнительной власти.

Некоторое время назад в распоряжении компании "Expocod" оказалась информация о наличии серьёзной уязвимости в информационной системе компании "ГОЛЬФСТРИМ". По имеющимся у нас достоверным данным, уязвимость позволяет получить доступ к персональным данным пользователей системы охранной сигнализации, а также осуществить удалённое управление состоянием сигнализации огромного количества объектов.

С момента получения данной информации нами предпринимались неоднократные попытки связаться с руководством компании "ГОЛЬФСТРИМ", однако до настоящего времени ни одна из таких попыток не увенчалась успехом (4 электронных письма, 3 телефонных звонка, сообщения в Telegram, визит в офис и очное общение с представителями компании). Учитывая то, что компания Expocod ставит своей задачей повышение общего уровня информационной безопасности в России, а также факты игнорирования представителями компании "ГОЛЬФСТРИМ" наших многочисленных сигналов, было принято решение о публикации имеющейся в нашем распоряжении информации в СМИ с раскрытием общих технических подробностей.

Общая информация о компании "ГОЛЬФСТРИМ Охранные Системы"

Исходя из информации, представленной на официальном сайте компании, группа компаний ГОЛЬФСТРИМ работает на рынке охраны без малого 23 года. Реклама с официального сайта гласит, что 23 года работы ГОЛЬФСТРИМ это (цитируем): «решения проверенные временем, 75 тысяч клиентов, качество на каждом этапе, квалификация персонала...».

Беглый поиск по базе сведений о государственной регистрации юридических лиц даёт следующее:

• ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ ЧАСТНАЯ ОХРАННАЯ ОРГАНИЗАЦИЯ "ГОЛЬФСТРИМ СЛУЖБА ОХРАНЫ"
  ОГРН/ИНН 1107746777380/7715829624
  Дата регистрации 23.09.2010
  Уставный капитал 250000р
  Генеральный директор ИВАНОВ АЛЕКСЕЙ ВЛАДИМИРОВИЧ (ИНН 504008784580)
  Учредители ПИСЬМАН ВЕНИАМИН ФОНЕВИЧ (доля 100%)
• ОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ ЧАСТНАЯ ОХРАННАЯ ОРГАНИЗАЦИЯ "ГОЛЬФСТРИМ ОХРАННЫЕ СИСТЕМЫ"
  ОГРН/ИНН 1097746799875/7715787653
  Дата регистрации 14.12.2009
  Уставный капитал 250000р
  Генеральный директор САМОДУМСКИЙ СТАНИСЛАВ АЛЕКСАНДРОВИЧ
  Учредители ПИСЬМАН ВЕНИАМИН ФОНЕВИЧ (доля 99%), САМОДУМСКИЙ СТАНИСЛАВ АЛЕКСАНДРОВИЧ (доля 1%)

Итак, открытые источники подсказывают, что владельцем (и предстедателем совета директоров) компании "ГОЛЬФСТРИМ" является некто Письман Вениамин Фоневич (ИНН 771805121540):

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

Переходя непосредственно к технической части нашего повествования, стоит ещё раз особо отметить, что компания "Expocod" располагает достоверной информацией о наличии уязвимости. Однако, ввиду того что данная уязвимость была обнаружена независимым исследователем безопасности, мы располагаем лишь частичными подробностями и не располагаем данными, которые могли были получены с использованием данной уязвимости. По договорённости с автором и с его разрешения мы публикуем технические подробности без указания важных деталей, знание которых необходимо для успешной эксплуатации.

Описание уязвимости

Уязвимость существует в протоколе взаимодействия мобильного приложения (МП) с центром управления (ЦУ). На момент публикации, исследованным является протокол обмена между приложением для iOS (последняя версия приложения от 29/06/2017). Протокол представляет собой REST-подобный интерфейс, построенный поверх HTTP. Запросы к ЦУ имеют следующий формат:

POST http://195.19.222.170/GulfstreamWebServices/rest/[method] HTTP/1.1
Accept: */*,
Accept-Encoding: gzip, deflate
Accept-Language: en-us
Connection: keep-alive
Content-Type: application/json
Proxy-Connection: keep-alive
User-Agent: SecurityApp/190 CFNetwork/811.5.4 Darwin/16.7.0

{ userID: [userID], userToken: [userToken] }

Первое, что бросается в глаза — отсутствие какого-либо шифрования данных. То есть обмен критичной информацией между МП и ЦУ осуществляется по открытому каналу связи без какой-либо защиты от пассивного прослушивания! Не используется также и технология certificate pinning, которая могла бы способствовать защите от MiTM атак на канал управления. В нашем случае протокол легко анализируется с помощью приложения mitmproxy, использовать который может даже школьник (а ведь приложение управления сигнализацией создано для серьезных вещей).

Следующий шаг следует вероятно начать с описания таких параметров как userID и userToken. Очевидно, что userID представляет собой идентификатор пользователя мобильного приложения, тогда как userToken — токен, позволяющий данному пользователю получить доступ к функциям системы. Рассмотрим подробнее функцию регистрации пользователя в системе:

POST http://195.19.222.170/GulfstreamWebServices/rest/profile/register HTTP/1.1
Accept: */*,
Accept-Encoding: gzip, deflate
Accept-Language: en-us
Connection: keep-alive
Content-Type: application/json
Proxy-Connection: keep-alive
User-Agent: SecurityApp/190 CFNetwork/811.5.4 Darwin/16.7.0

{ contractNumber: [contractNumber], deviceToken: [deviceToken], deviceType: 1 }

Данная функция осуществляет регистрацию МП в системе. Параметрами регистрации являются номер договора и уникальный идентификатор устройства. Ниже представлены ответы системы на попытки регистрации нового устройства для одного и того же договора с разными значениями deviceToken:

deviceToken = E3cDC2DdCdf75afc5865DBE2Ead3a4BB2fdB2CabBD441ADDaaa81ea8Dfd9C9ae
Reply >> {"IsError":false,"ErrorObj":null,"Result":{"userID":71671,"userToken":"dkJCRVg=","contractNumber":"495020xxxx","phone":"7******7007"}}

deviceToken = 7e3280581591Af0e5eaabadbE5b33B0Af84e20CBBd16226a22f5C3570A02B341
Reply >> {"IsError":false,"ErrorObj":null,"Result":{"userID":72033,"userToken":"dkFEQVo=","contractNumber":"495020xxxx","phone":"7******7007"}}

deviceToken = aEd42FB8CBf8Af3E9Ec6Af8cad0C4deF2eaeF200EaBFf4DDFeeDFF4106CC703A
Reply >> {"IsError":false,"ErrorObj":null,"Result":{"userID":72072,"userToken":"dkFERVs=","contractNumber":"495020xxxx","phone":"7******7007"}}

Как видно, ответом на запрос является JSON-структура, содержащая в том числе поля userID и userToken. Кроме того, в ответе есть частично скрытый номер телефона владельца контракта. Также можно видеть, что в данный момент в системе около 72 тысяч пользователей (или попыток регистрации МП, т.к. каждая попытка с новым deviceToken выдаёт новый "уникальный" userID).

Однако самым удивительным открытием является следующее: номера userID выдаются последовательно, а в структуре токена userToken прослеживается некая закономерность… Можно предположить, что userToken каким-то образом зависит от userID, то есть userToken = f(userID). Но что это за функция?

Мы не располагаем информацией каким именно образом исследователю безопасности, который связался с нами и передал данную инфомацию, удалось установить точную функцию, но по его словам этой функцией оказался… обычный XOR!

Таким образом, зная диапазон значений userID (0..72k) и функцию, по которой вычислять userToken, можно получить доступ, например, к следующим REST API системы:

GulfstreamWebServices/rest/profile/updateUserDeviceToken
GulfstreamWebServices/rest/profile/getCustomerDetails
GulfstreamWebServices/rest/profile/getCustomerProfileImage
GulfstreamWebServices/rest/panel/getEstimateArmState
GulfstreamWebServices/rest/panel/setArmState
GulfstreamWebServices/rest/panel/getEventHistory
GulfstreamWebServices/rest/panel/getNotifications
GulfstreamWebServices/rest/panel/getAvailableNotificationExtendedList
GulfstreamWebServices/rest/panel/getNotificationState
GulfstreamWebServices/rest/panel/getRemoteTags
GulfstreamWebServices/rest/panel/updateRemoteTagState
GulfstreamWebServices/rest/panel/getVideo
GulfstreamWebServices/rest/panel/getAllVideos
GulfstreamWebServices/rest/panel/getPanelCameraList

Представленный список отнюдь не является полным. В совокупности с возможностью перебора идентификации пользователей можно получить полную базу данных объектов охраны. Так, например, ниже представлена python-функция, запрашивающая информацию о пользователе:

def gs_api_get_customer_details(u, t):
    r = s.post(
         'http://195.19.222.170/GulfstreamWebServices/rest/profile/getCustomerDetails',
         headers = {
             'Accept': '*/*',
             'Accept-Encoding': 'gzip, '
             'deflate',
             'Accept-Language': 'en-us',
             'Connection': 'keep-alive',
             'Content-Type': 'application/json',
             'Proxy-Connection': 'keep-alive',
             'User-Agent': 'SecurityApp/190 '
             'CFNetwork/811.5.4 '
             'Darwin/16.7.0' },
         json = {
             'userID': u,
             'userToken': t
         }
)
return r.json()

Проверим, что можно получить используя API profile/getCustomerDetails для пользователя с userID = 296:

{'IsError': False, 'ErrorObj': None, 'Result': {'contractNumber': '71/*****', 'fullName': 'Письман Вениамин Фоневич', 'address': 'обл. Московская, р-н Одинцовский, д. Ж******, тер Ж******-21, уч. *****', 'accountStatus': 1001, 'paidTill': '2017-12-31 00:00', 'debt': '-9560.00', 'hardwareType': 2002, 'hardwareHasAddendum': False, 'hardwareHasNightMode': True, 'panelID': '*****58', 'activationCode': '', 'intercomCode': '', 'email': 'v*****n@gulfstream.ru', 'telephone': '7910*****38', 'homeTelephone': '+7 (495) *****-82', 'workTelephone': '', 'monthlyFee': '2390.0', 'paymentSiteURL': 'http://www.gulfstream.ru/abonents/payment/?from=app&contractID=71/*****&debt=0', 'userID': 296, 'userToken': '*****', 'deviceToken': None, 'deviceType': 0, 'accountName': None, 'averagePanelTime': 25, 'averagePanelTimeEnd': 120, 'shouldShowPaymentInfo': True, 'isPhotoSupported': False, 'isRemoteTagsSupported': False, 'longitude': *****, 'latitude': *****, 'timeZone': 'Europe/Moscow', 'balance': 9560.0, 'smartPlugTimeout': 80, 'isSmartPlugsSupported': False, 'isTemperatureReadingSupported': False, 'temperatureSensorTimeout': 80, 'timeZoneName': 'Москва (GMT+3)', 'timeZoneOffset': 180}}

Как видно, адрес объекта (скрыт намеренно) принажделжит НП "Жуковка-21", соучредителем которого, по информации из открытых источников, является сам
уважаемый Вениамин Фоневич:

Итак, некто с userID = 296 является до невозможности похожим на учредителя компании "ГОЛЬФСТРИМ". Информация, полученная ранее из публичных источников подтверждает подлинность этих данных.

Другим интересным методом API является panel/getVideo. С его помощью можно получить видео с камер, установленных на объекте в случае, если сигнализация оборудована соответствующим оборудованием. Для примера посмотрим видео пользователя с userID = 70072:

{'IsError': False, 'ErrorObj': None, 'Result': {'contractNumber': '******', 'fullName': 'Тетовый Сахарный Андрей Инженерович', 'address': 'г. Москва, ул. Бутырская, д. 62', 'accountStatus': 1001, 'paidTill': '2016-04-26 00:00', 'debt': '0.00', 'hardwareType': 2004, 'hardwareHasAddendum': False, 'hardwareHasNightMode': True, 'panelID': '00146737', 'activationCode': '', 'intercomCode': '', 'email': 'csm_tech@gulfstream.ru', 'telephone': '7926322****', 'homeTelephone': '7495980****', 'workTelephone': '', 'monthlyFee': '690.0', 'paymentSiteURL': 'http://www.gulfstream.ru/abonents/payment/?from=app&contractID=*****&debt=0', 'userID': 70072, 'userToken': '*****', 'deviceToken': None, 'deviceType': 0, 'accountName': 'Мой дом', 'averagePanelTime': 25, 'averagePanelTimeEnd': 120, 'shouldShowPaymentInfo': True, 'isPhotoSupported': True, 'isRemoteTagsSupported': True, 'longitude': 37.583751, 'latitude': 55.803008, 'timeZone': 'Europe/Moscow', 'balance': 0.0, 'smartPlugTimeout': 80, 'isSmartPlugsSupported': True, 'isTemperatureReadingSupported': True, 'temperatureSensorTimeout': 80, 'timeZoneName': 'Москва (GMT+3)', 'timeZoneOffset': 180}}

Вероятно, данный объект представляет собой офис компании "ГОЛЬФСТРИМ".

Ещё одной интересной функцией является функция запроса информации о бесконтактных ключах: panel/getRemoteTags. С оборудованных бесконтактными ключами объектов можно получить информацию не только о серийных номерах ключей (что даст возможность сделать дубликат ключа), но также и отключить те или иные ключи, а также заменить их серийные номера. Следующая картинка демонстрирует использование mitmproxy и отображает серийники ключей для тестового стенда, расположенного в офисе компании (всё тот же userID = 70072, Паше и Коле — привет):

Ну и в завершении отметим, что помимо запроса информации с объектов данный протокол позволяет управлять состоянием сигнализации. Используя panel/setArmState можно включить и выключить сигнализацию на любом из 70 тысяч объектов не вставая с дивана. Занавес.

Основные выводы

Подводя итог нашему сумбурному изложению отметим, что в системе управления сигнализацией, разработанной компанией "ГОЛЬФСТРИМ", существуют ошибки, позволяющие как минимум:

• получать информацию о пользователях системы и объектах, где установлена данная сигнализация
• удалённо управлять сигнализацией — включать и отключать
• удалённо управлять бесконтактными ключами, включая возомжность добавления своих ключей или отключения существующий
• удалённо получать доступ к информации с камер наблюдения

Мы честно пытались довести данную информацию до представителей компании ГОЛЬФСТРИМ, а также до её руководства в течение без малого 2-х месяцев с момента получения нами данной информации. До настоящего времени данная ошибка НЕ исправлена. Можно только предположить, кто, как и в каких целях мог её использовать...

Резонно возникает вопрос — если учредитель компании доверяет охрану свого дома ГОЛЬФСТРИМу, то может ли это являться примером для подражания обычным гражданам, желающим "иметь право на безопасность"?

Наш ответ — НЕТ!

Также занимательно, что в числе объектов охраны ГОЛЬФСТРИМа есть объекты ФСО и УДП, расположенные на Рублево-Успенском шоссе, а также важные коммунальные госкомпании...

Интересно будет ли доволен директор ФСО Кочнев Д.В., узнав что на ряд ведомственных объектов можно пробраться кликнув мышкой? Впрочем добраться ему до господина Письмана и призвать к ответу за халатность, живущего судя по записям (ведь он же патриот собственной системы) рядышком в Жуковке, легко и просто – буквально рукой подать, а еще лучше прислать черный воронок.

P.S. Отдельно стоит отметить стиль общения СБ Гольфстрима и его сотрудников — то самое слово на г. в заголовке, которое первое приходит на ум после разговора (запись имеется).

Источник

В далёком 2002 году одна из самых заметных тогдашних ИТ-компаний пригласила консультантов, чтобы решить страшную проблему: служба эксплуатации не хочет использовать новые версии систем, выпущенные разработчиками. Эксплуатация и разработка регулярно вместо работы ходят на уровень вице-президентов компании и в присутствии высокого начальства пытаются друг друга переспорить.

Если проблема вам знакома и интересна, далее в статье приведён практический способ её решения, опробованный в одной из лучших мировых компаний, с теоретическим обоснованием, примерами расчётов и рекомендациями по автоматизации.

Конфликт

Не бывает конфликтов между администратором ПО и производителем этого ПО, если производитель это гигантская международная мега-корпорация, а администратор работает в компании, которая это ПО купила и использует. Каждый занимается своим делом: производитель выпускает новые версии, администратор следит, чтобы «всё работало». Решение, какую версию эксплуатировать, принимает администратор. Некоторые проверяют новые версии. Некоторые новые версии не используют вообще. Когда средства доставки обновлений были развиты слабее, чем теперь, был известен принцип не использовать новую версию ОС, пока к ней не выйдет второй сервис-пак. Администраторы прекрасно знают принцип, положенный в основу процесса управления изменениями: «Любое изменение опасно». Производителю же всё равно, используют новую версию ПО или старую, лишь бы деньги за поддержку платили.

Всё меняется, если администратор и производитель ПО оказываются сотрудниками одной компании. Теперь стремление администратора к стабильности и стремление производителя выполнять планы реализации пожеланий пользователей — это стремления в противоположные стороны. Бывает, что в КПЭ администратора записана стабильность, а в КПЭ разработчика — количество новых функций. Тогда каждый час простоя из-за (или для?) внедрения новых функций это потеря премии администратором, а каждый отказ от установки новой версии ради сохранения стабильности это потеря премии разработчиком.

Источник

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

В нынешней версии ITIL в томе Service Operation этому конфликту посвящен раздел 3.2.2, Stability versus responsiveness («Стабильность против отзывчивости»). Авторы ITIL пишут, что организации обычно не могут найти баланса между стабильностью и отзывчивостью и склоняются к одной из крайностей, принося второе в жертву. Там же даются рекомендации, как этой стабильности достичь:

1. Использовать более гибкие технологии, например, виртуальные серверы вместо железных.

   
   

2. Создать влиятельный процесс управления уровнем сервисов, который был бы вовлечён во все фазы жизненного цикла сервисов, от проектирования до непрерывного улучшения.

   
   

3. Усилить взаимодействие процесса управления уровнем сервисов с другими процессами фазы дизайна: управлением доступностью, мощностью, непрерывностью.

   
   

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

   
   

5. Добиться вовлечения ИТ-подразделения в процесс управления изменениями бизнеса.

   
   

6. На фазе проектирования сервисов использовать информацию от процессов фазы эксплуатации.

   
   
7. Документировать договорённости между ИТ бизнесом, не допускать неформальных соглашений.

ITIL написан для администраторов, а для разработчиков ПО создан DevOps, который даёт следующие рекомендации по решению того же самого конфликта:

1. Унифицировать и заставить сильно взаимодействовать процессы разработки и эксплуатации ПО.

   
   

2. Автоматически выполнять (роботизировать?) операции интеграции, тестирования, выпуска и развёртывания новых версий ПО.

   
   
3. Встраивать в разрабатываемое ПО средства мониторинга.

Оба источника дают дельные советы, которые не только не противоречат, но порой идеально друг друга дополняют, как последний пункт из второго списка и шестой пункт из первого. Однако, советам недостаёт конкретности. Например, про DevOps непонятно, что этот термин значит и какой смысл за ним стоит: «С момента появления в 2008 году значение термина DevOps так и не устоялось. Поэтому, чтобы ни с кем не спорить, мы называем наш подход к управлению сервисами Site Reliability Engineering (SRE). Принципы SRE не противоречат DevOps.» Так пишут в выпущенной в 2016 году книге сотрудники одной крупной компании, известной своим сервисом поиска в интернете, а теперь ещё и беспилотными автомобилями.

Заметим, что в книге про SRE один за другим рассматриваются, в ключе «а вот как это сделано у нас», процессы из ITIL: управление инцидентами, проблемами, изменениями, уровнем сервисов и др., хотя сама библиотека не упомянута ни разу за все 550 страниц («Сервис» на первых 10 страницах книги упомянут 50 раз, а «менеджмент» — 20).

Что такое «4 девятки» доступности

На минуту отвлечёмся, так как практика показывает, что и представители бизнеса, и представители ИТ с трудом понимают, что такое «доступность %». Обычно понимание упрощается, если от процентов перейти к часам и минутам. Вот как выглядят цифры для некоторых требуемых уровней доступности для режима работы сервиса 9x5. Расчётный период — 1 месяц, в нём 189 рабочих часов.

Бюджет простоев

Одна из простейших, мощнейших и действенных идей SRE — «бюджет простоев». Исходя из требований заказчика к доступности сервиса, вычисляется допустимое время простоя системы за период, «бюджет простоев». Из этого бюджета берётся время и на устранение инцидентов, и на проведение изменений. В том числе на проведение изменений по внедрению новых функций. Если система работает стабильно, то на проведение изменений и, если потребуется, на устранение последствий этих изменений время есть. Если система работает нестабильно, то бюджет простоев «съедают» инциденты, и времени на проведение изменений в отчётном периоде остаётся мало или не остаётся совсем.

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

Бюджет простоев автоматически регулирует выпуск новых релизов: пока он не исчерпан, релизы возможны. Для организаций, работающих в режиме push on green (если релиз прошёл все тесты, он выпускается в производственную среду автоматически), процесс может автоматизирован полностью.

Быстрое исчерпание бюджета простоев подсказывает ИТ-руководителям, что нужно больше ресурсов направить на тестирование или проектирование сервиса.

Бюджет простоев ставит для разработки и эксплуатации единые цели и единые КПЭ, решая таким образом конфликт, о котором написана эта статья.

Примеры

При жёстких требованиях к доступности времени на установку новых версий и на борьбу с последствиями почти нет. Например, если установлен режим

24x7, доступность 99,99 % в месяц

то бюджет простоев составляет 43 минуты 12 секунд в месяц. Скорее всего, в течение месяца получится установить только одну-две новые версии программы. Любой инцидент, даже решаемый без раздумий, перезагрузкой, моментально «съест» примерно 20 % бюджета, поэтому, если от сервиса требуется высокий уровень доступности, то ИТ-служба обязана обеспечить высокий уровень тестирования.

Ситуация упрощается, если SLA допускает регламентный простой, то есть если какое-то количество часов зарезервировано именно для установок патчей и новых версий, и простой сервиса в это время не влияет на расчёт доступности. Время проведения регламентного простоя заранее определено, и любые остановки сервиса за его пределами рассматриваются, как инциденты. Крайний случай регламентного простоя это режим 9x5, когда работа сервиса не требуется, скажем, с 18:00 до 9:00 следующего дня, и у ИТ-службы есть 15 часов в сутки на установку новых версий.

Что происходит с бюджетом доступности, если ночью сервис не работает? Из-за того, что количество часов работы сервиса сокращается с 720 часов в месяц при круглосуточном режиме работы до 189 часов при режиме 9x5, бюджет простоев заметно сокращается. На установку новых версий теперь есть целая ночь, но сколько есть времени на борьбу с проблемами, которые новая версия может принести? Для режима

9x5, доступность 99,99 % в месяц

бюджет простоев сокращается до 11 минут 20 секунд. Это, по-большому счёту, один инцидент в месяц.

Снижение требований к доступности увеличивает бюджет простоев, давая ИТ-службе больше времени на проведение изменений и на устранение инцидентов. Так, при популярной в российских SLA требуемой доступности в 97,5 % бюджет простоев составит комфортные 18 часов в месяц для режима 24x7 и чуть меньше 5 часов в месяц для режима 9x5.

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

Реализации в информационной системе

Для реализации бюджета простоев нужны система мониторинга и ИТСМ-система. Рассмотрим, что предлагает ИТСМ-система ServiceNow в «коробочной» конфигурации для решения такой задачи. На сегодняшний день ServiceNow занимает лидирующие позиции в сфере ITSM-решений и именно его мы предлагаем своим клиентам в собственной облачной платформе Техносерв Cloud.

1.Зафиксируем согласованный с бизнесом требуемый уровень доступности сервиса.

2.Будем записывать перебои в работе сервиса (outages, периоды недоступности), как вызванные сбоями, так и запланированные остановки сервиса для установки новых версий и патчей. Конечно, лучше, если перебои-инциденты будет записывать интегрированная с ServiceNow система мониторинга.

3.Когда разработчики подготовят новый релиз к установке в производственную среду, посмотрите, сколько осталось времени в бюджете простоев. На картинке бюджет потрачен всего лишь на 20 %, ответственный за сервис в такой ситуации разрешит установку нового релиза.

Подведём итоги:

1. Бюджет простоев решает конфликт между эксплуатацией и разработкой.

   
   

2. Размер бюджета простоев, и следовательно, степень свободы ИТ-организации в проведении изменений, определяется в первую очередь требованиями к доступности сервиса, а регламентный простой на него не влияет.

   
   
3. Бюджет простоев легко реализовать в ИТСМ-системе ServiceNow даже в коробочной конфигурации.

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

1. Конструктор сайтов

2. Shared-хостинг

3. Облачные сервисы

4. Виртуальные машины

5. Аренда выделенного сервера

6. Покупка собственного железа

Резюме

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

Однажды мы в компании EastBanc Technologies устали бороться с теми архитектурными проблемами, которые возникают в Android-разработке и решили все исправить:). Мы хотели найти решение, которое удовлетворит всем нашим требованиям.

И, как это часто бывает, готового решения тогда не нашлось и нам пришлось сделать собственную библиотеку, которая уже приносит счастье нам, и может помочь и вам.

Какие проблемы решали:

• Уйти от жизненного цикла экранов, будь то Activity, Fragment или View
• Уйти от необходимости писать код для сохранения и восстановления состояния для каждого экрана
• Повысить стабильность: защититься от досадных крешей и утечек памяти
• Повысить переиспользуемость кода между телефонным UI и планшетным UI

Лирическое отступление. Почему Reamp?
Это же вроде такая приблуда для записывания электрогитар?
Конечно, в нашем случае Reamp к звукозаписи никакого отношения не имеет. Изначально мы думали что это будет аббревиатура, потому что там есть M и P (model и presenter), A — уже и не помним зачем, RE — потому что это было на реактиве написано. Но реактив мы уже выкинули, и осталось просто прикольное название.

В процессе реализации мы старались следовать манифесту, который сами же и придумали:

• Библиотека должна быть очень простой в освоении
• Библиотека должна быть очень простой в исполнении: минимум зависимостей, никакой манипуляции с байт-кодом и никакой кодогенерации
• Библиотека должна быть расширяемой
• Библиотека должна легко интегрироваться с другими популярными сопутствующими решениями

В результате у нас получилась MVP/MVVM библиотека, которую мы с успехом используем уже больше года и пока не собираемся менять. Мы считаем, что теперь пришло время поделиться ей с общественностью!

Зачем?

Давайте рассмотрим решение самой типовой задачи практически любого мобильного приложения – авторизация.

У нас есть поля ввода логина и пароля, кнопка входа, ProgressBar для отображения хода операции и TextView, чтобы показать результат.

Требования к поведению такого экрана довольно типичны:

• Кнопка входа должна быть заблокирована пока поля ввода не заполнены
• Кнопка входа должна быть заблокирована пока выполняется запрос к серверу
• При повороте экрана пользователь не должен вводить все заново, а операция входа не должна сбрасываться

Давайте проанализируем, о чем должен подумать разработчик при решении такой задачи.

Валидация

А что тут сложного? На loginEditText вешаем changeListener, который включает или выключает кнопку, когда login пустой или не пустой!

loginEditText.addTextChangeListener = { text -> button.setEnabled(text.length() > 0) }

Да, но это будет работать только для одного поля. А у нас еще есть пароль:

loginEditText.addTextChangeListener = { text -> validate() }
passwordEditText.addTextChangeListener = { text -> validate() }

private void validate() {
    boolean loginValid = loginEditText.getText().toString().lenght() > 0
    boolean passwordValid = passwordEditText.getText().toString().lenght() > 0
    button.setEnabled(loginValid && passwordValid)
}

Ну теперь то точно все! Не а, есть еще асинхронная операция входа, в процессе которой кнопка должна быть заблокирована.
Ок, просто выключаем кнопку перед выполнением запроса и… тогда ее можно будет включить, поменяв текст в loginEditText или passwordEditText.
Правильнее будет добавить проверку наличия активного запроса внутрь метода validate().
Наверное вы уже догадались, к чему этот пункт. Нужно помнить о куче вещей и их связей, которые могут влиять на UI.
О них легко забыть, когда нужно добавить и провалидировать еще одно поле ввода или Switch.

Вот, новый поворот

Для входа нам нужна асинхронная операция, будь то AsyncTask или RxJava + Scheduler, неважно.
Важно то, что мы не можем написать ее внутри нашей Activity, ведь мы не хотим останавливать ее при повороте экрана.
Нужно вынести задачу за рамки Activity, при ее запуске придумать и запомнить какой-то ее идентификатор,
чтобы позднее иметь возможность проверить статус этой задачи или получить ее результат.
И нужно будет написать какой-то менеджер подобных операций или взять из готовых, благо таковых много.

Состояние

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

Какое решение предлагает Reamp?

В Reamp мы используем Presenter для реализации поведения экрана и StateModel для хранения тех данных, которые этому экрану нужны.

Все довольно просто. Presenter практически не зависит от жизненного цикла экрана.
Выполняя какие-то операции, которые от него требуются, Presenter заполняет объект StateModel разными нужными данными.
Каждый раз, когда Presenter считает, что свежие данные нужно показать на эране, он сообщает об этом своей View.

Show me the code!

На практике это работает следующим образом:

LoginState – класс, содержащий информацию о том, что должно отображаться на экране:
нужно ли показывать ProgressBar, какое состояние должно быть у кнопки входа, что написано в текстовых полях ввода и т.п.

LoginPresenter получает события от LoginActivity (ввели текст, нажали кнопку),
выполняет нужные операции, заполняет класс LoginState нужными данными и отправляет в LoginActivity на “рендеринг”.

LoginActivity получает событие о том, что данные в LoginState изменились и настраивает свой layout в соответствии с ними.

//LoginState
public class LoginState extends SerializableStateModel {
    public String login;
    public String password;
    public boolean showProgress;
    public Boolean loggedIn;

    public boolean isSuccessLogin() {
        return loggedIn != null && loggedIn;
    }
}

//LoginPresenter
public class LoginPresenter extends MvpPresenter {
    @Override
    public void onPresenterCreated() {
        super.onPresenterCreated();
        //настраиваем отображение при свежем старте
        getStateModel().setLogin("");
        getStateModel().setPassword("");
        getStateModel().setLoggedIn(null);
        getStateModel().setShowProgress(false);
        sendStateModel(); //отправляем LoginState на "отрисовку"
    }

    // вызывается классом View, когда требуется выполнить логин
    public void login() {

        getStateModel().setShowProgress(true); // экран должен показать индикатор прогресса
        getStateModel().setLoggedIn(null); // результат входа пока неизвестен
        sendStateModel(); // отправляем текущее состояние экрана на "отрисовку"

        // эмулируем пятисекундный запрос на вход
        new Handler()
                .postDelayed(new Runnable() {
                    @Override
                    public void run() {
                        getStateModel().setLoggedIn(true); // сообщаем об успешном входе
                        getStateModel().setShowProgress(false); // убираем индикатор прогресса
                        sendStateModel(); // отправляем текущее состояние экрана на "отрисовку"
                    }
                }, 5000);
    }

    public void loginChanged(String login) {
        getStateModel().setLogin(login); // запоминаем то, что ввел пользователь
    }

    public void passwordChanged(String password) {
        getStateModel().setPassword(password); // запоминаем то, что ввел пользователь
    }
}

//LoginActivity
public class LoginActivity extends MvpAppCompatActivity {

     /***/

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_login);

        /***/

        loginActionView.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                getPresenter().login(); // сообщаем о событии презентеру
            }
        });

        // следим за тем, что ввел пользователь
        loginInput.addTextChangedListener(new SimpleTextWatcher() {
            @Override
            public void afterTextChanged(Editable s) {
                getPresenter().loginChanged(s.toString()); // сообщаем о событии презентеру
            }
        });

        // следим за тем, что ввел пользователь
        passwordInput.addTextChangedListener(new SimpleTextWatcher() {
            @Override
            public void afterTextChanged(Editable s) {
                getPresenter().passwordChanged(s.toString()); // сообщаем о событии презентеру
            }
        });
    }

    // вызывается библиотекой, когда требуется создать свежий экземпляр модели LoginState
    @Override
    public LoginState onCreateStateModel() {
        return new LoginState();
    }

    // вызывается библиотекой, когда требуется создать свежий экземпляр презентера LoginPresenter
    @Override
    public MvpPresenter onCreatePresenter() {
        return new LoginPresenter();
    }

    // вызывается библиотекой каждый раз, когда состояние экрана поменялось
    @Override
    public void onStateChanged(LoginState stateModel) {
        progressView.setVisibility(stateModel.showProgress ? View.VISIBLE : View.GONE); // устанавливаем нужное состояние индикатора прогресса
        loginActionView.setEnabled(!stateModel.showProgress); // пока происходит запрос, кнопка входа недоступна
        successView.setVisibility(stateModel.isSuccessLogin() ? View.VISIBLE : View.GONE); // устанавливаем нужное состояние "успешного" виджета
    }
}

На первый взгляд все, что мы сделали – это вынесли значимые динамические данные в LoginState, перенесли часть кода (такую как запрос на вход) из Activity в Presenter и больше ничего. На второй взгляд — это действительно так :) Потому, что всю скучную работу за нас делает Reamp:

• Если мы повернем экран, то это никак не повлияет на работу презентера и запроса на вход. При пересоздании LoginActivity она сразу получит последнее состояние LoginState. Если запрос все еще выполняется, LoginState будет содержать информацию о том, что кнопка входа неактивна, а индикатор загрузки показывается. Если же операция входа успеет завершиться как раз в момент поворота экрана, презентер заполнит LoginState результатом входа и будущая LoginActivity сразу получит этот результат.
• Все данные, находящиеся в LoginState попадают в Bundle savedState, когда система просит сохранить состояние экрана. Разумеется, Reamp умеет восстанавливать LoginState из Bundle, если наша программа была выгружена из памяти ранее. По умолчанию для сохранения LoginState используется механизм сериализации объектов, но вы всегда можете написать свой, если нужно.
• Нет необходимости проверять savedState на null при старте LoginActivity, так же как и нет вероятности забыть показать ProgressBar, если запрос на вход уже в процессе. Весь код, отвечающий за отображение текущего состояния сосредоточен в одном месте и всегда учитывает данные из LoginState целиком. Такой подход обеспечивает консистентность данных на UI.
• Нет необходимости проверять доступность нашей Activity перед тем, как что-то сделать с UI, как это делается в некоторых других MVP-библиотеках. Другими словами, нет бесконечных проверок if (view != null). В презентере мы работаем напрямую с состоянием, которое доступно в любой момент времени.

Мы перечислили, как Reamp помогает избавиться от boilerplate-кода, но это далеко не весь профит от использования библиотеки. С помощью Reamp мы повышаем стабильность работы приложения:
Reamp позаботится о том, чтобы вызов метода onStateChanged(...) всегда происходил в главном потоке.

Все исключения, возникающие внутри вызова onStateChanged(...) не роняют процесс приложения. Правильная работа с исключениями в Java это высокий скилл, но исключения, возникающие на самом верхнем UI уровне (при настройке layout), чаще оказываются досадными недоразумениями, чем преднамеренным событием и аварийное завершение программы здесь абсолютно лишнее.
С Reamp можно не бояться утечек Activity, т.к. вы всегда работаете напрямую с классами презентера и состояния.

Last but not least, с помощью Reamp мы повышаем качество кода:

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

Класс состояния – это отличный кандидат для хранения UI логики. Если наш LoginStateзнает о прогрессе входа, введенных логине и пароле, то он уже имеет все исходные данные, чтобы решить нужно ли включить кнопку входа

public class LoginState extends SerializableStateModel {
   /***/
    public boolean isLoginActionEnabled() {
        return !showProgress
                && (loggedIn == null || !loggedIn)
                && !TextUtils.isEmpty(login)
                && !TextUtils.isEmpty(password);
    }
}

Такой подход хорошо согласуется с принципом разделения ответственности и сильно разгружает код класса нашей LoginActicity.

Код становится переиспользуемым. LoginPresenter можно использовать и в других проектах, где нужно реализовать похожий экран, просто поменяв UI составляющую этого экрана.

Сравнение с похожими решениями

Безусловно, Reamp – не единственная MVP/MVVM библиотека, тысячи их!
Когда мы начинали делать Reamp мы сознательно хотели написать то, что нужно именно нам.
И, конечно, мы изучали имеющиеся на то время альтернативы, чтобы взять лучшее и избежать того, что нам не понравится :)
Не хочется устраивать холивар и тем более тыкать в кого-то пальцем, просто резюмируем то, что нам нравится в Reamp, а чего мы стараемся в нем избегать.

Во-первых, Reamp очень простой в использовании.
Мы не используем генерацию кода и стараемся вводить минимум новых классов, которые нужны лишь для работы самой библиотеки.
В отличие, к примеру, от новых Android Architecture Components, нам не требуется целого зоопарка вспомогательных технических классов и аннотаций,
чтобы решить те же проблемы.

Второй пункт является отчасти следствием первого.
Имея неперегруженную архитектуру и минимум зависимостей можно легко интегрироваться со многими популярными современными технологиями.
Например, с DataBinding, ведь StateModel уже и есть квинтэссенция тех данных, которые нужны DataBinding-у для работы.
Еще один пример, не имея никакой магии с байт-кодом, мы без всяких проблем используем Reamp программируя на Kotlin.

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

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

Ссылки

Reamp на GitHub — https://github.com/eastbanctechru/Reamp

Демо-приложение — https://github.com/eastbanctechru/Reamp/tree/master/sample

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