new_year

До бесплатного семинара в Москве осталось

  • 2
  • 2
дня

До бесплатного семинара в Самаре осталось

  • 2
  • 0
дней

Форум

ГлавнаяВзаимодействие с ГИС ЖКХ: XLSX vs. SOAP

Взаимодействие с ГИС ЖКХ: XLSX vs. SOAP

RSS
Взаимодействие с ГИС ЖКХ: XLSX vs. SOAP
 
Ну у меня тоже еще все на начальном уровне, но попробую сделать "дайджест". Не очень понятны подробности до чего процесс дошел и с какой целью они прислали сертификат обратно, да еще и со своей подписью (.p7s - это файл отсоединенной подписи, проверить можно через бесплатную версию программы КриптоАрм или на сайте [url:1jrulhzi]https://crypto.kontur.ru/[/url:1jrulhzi] указав оба файла, а вот для создания подписи нужна платная версия). Как я понял, ИС "доработана" (допустим, генерирует сразу каноническую форму XML) и зарегистрирована в тестовом контуре. Подписывать XML ИС уже умеет? Delphi чуть ли не на раз высчитывает значение хэша и подписи через библиотеки MS CryptoAPI и КриптоПро, остается только перевернуть порядок байтов, закодировать в base64 и все правильно соединить.

Далее нужно разрешить доступ к данным своей организации со стороны ИС (то есть видимо надо зайти на ГИС от имени своей ИС и запросить разрешение от своей УК, потом зайти как УК и подтвердить). Далее построить защищенный канал до тестового сервера ГИС. Как я понимаю https://217.107.108.156:10081/ это один из тестовых серверов с шифрованием, чаще всего используют stunnel на основе OpenSSL. По идее можно найти модули для Delphi с поддержкой HTTPS - как через системные библиотеки TLS, так и через библиотеки OpenSSL. Однако наверно придется залезать куда-то глубоко в дерево классов, что бы указать ГОСТ как алгоритм шифрования. Еще где-то в документации должен быть корневой сертификат ГИС - он также потребуется для построения канала, чтобы ИС не обрывала соединение по причине, что у ГИС не доверенный сертификат.

Далее запулить тестовое сообщение. В декабре там был "косяк" в описании - нужно было указывать организацию совсем не так, как было в документации, не знаю, исправили или нет.
 
СПАСИБО two_oceans!

Цитата
two_oceans пишет:
Еще где-то в документации должен быть корневой сертификат

Я понимаю, что это файлы pem...

1) Если у меня лицензионный КриптоПро, то какие-нибудь проблемы из вышеперечисленных снимаются?

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

3) Вот я сгенерировал PAS из WSDL. Какие дальнейшие действия? Надо ли авторизоваться на ГИС из программы. В какой момент можно передавать данные? Мрак! Методичек нет и не предвидится.
 
Пожалуйста.
Цитата
Я понимаю, что это файлы pem...
Скорее всего. Вообще PEM это формат ("текстовая" кодировка в base64 данных + текстовые заголовки) и расширение может быть разным. Для сертификатов в PEM общепринято .crt и windows его понимает. Если после изменения .pem на .crt отобразится сертификат, то можно посмотреть чей и все прояснится.

Отправлено спустя 15 минуты 22 секунды:
Цитата
1) Если у меня лицензионный КриптоПро, то какие-нибудь проблемы из вышеперечисленных снимаются?
В принципе да. Конечно смотря какая именно лицензия.
Во-первых, по подписи XML. Краем глаза видел где-то на сайте КриптоПро xml-dsign-addin. По названию эта штука как раз для подписи XML, но как я понял для него нужна дополнительная лицензия, поэтому не стал разбираться к чему он addin (дополнение) и подходит ли подписанный файл к ГИС. Почему-то мне кажется, что дополнение к MS Office и к ГИС не очень подходит (предположил что потребует сохранения файла на диск, подписания, потом отправки файла, то есть нарушит "поточность" внутри программы), поэтому не стал докупать, но может быть у кого-то получится настроить и приспособить.

Если все же не допиливать чужое, а делать свое, то Delphi может обратиться к КриптоПро через майкрософтовские функции. Тут ориентиром служит модуль JwaWinCrypt (есть какой-то стандартный Crypt2 WCrypt32.pas, но в нем как я понял несколько устаревшие описания функций и без учета 64-битности) и заголовочный файл от криптопро с описанием констант. Заголовочный файл желательно посвежее от той же версии КриптоПро, что установлена. Обычно они идут с лицензией криптопро для разработчиков. У меня такой нет, нашел явно "несвежий" заголовочный файл. Впрочем скорее всего из всего файла понадобятся только 3-4 константы. В заголовочном файле констант намного больше и комментарии к ним наводят на мысль что таким же образом наверно и зашифрованный канал можно поднять, но я пока не вникал в подробности. Вот 4 константы для получения хэша и подписи, бросившиеся в глаза.[code:d1hqgczn]const PROV_GOST_2001_DH=75; //Тип Криптопровайдера. для ГОСТ большинство криптопровайдеров использует этот, исключение vipnet для него значение типа равно 2
szOID_CP_GOST_R3411='1.2.643.2.2.9'; //Функция хэширования ГОСТ Р 34.11-94
szOID_CP_GOST_R3411_R3410EL='1.2.643.2.2.3'; //Алгоритм цифровой подписи ГОСТ Р 34.10-2001
szOID_CP_GOST_R3410EL='1.2.643.2.2.19'; //Алгоритм ГОСТ Р 34.10-2001, используемый при экспорте/импорте ключей[/code:d1hqgczn]Первая - это тип криптопровайдера, указывается в CryptAcquireContext. Одновременно можно указать nil вместо имени криптопровайдера (тогда программа подхватит почти любой гостовский (кроме vipnet), выставленный "по умолчанию" для типа 75, не обязательно криптопро) или указать полное наименование криптопро (тогда другие гостовские не подхватятся, но сможет подхватится криптопро даже если криптопро не "по умолчанию" для типа 75). Наименование и выставлен ли по умолчанию можно посмотреть в настройках криптопро (там где обычно сертификат устанавливаем, на соседней вкладке).
Вторая - идентификатор функции хэширования, используется вместо szOID_RSA_MD5 в примерах. Смущает, что 94, но похоже та самая. Третья- четвертая - алгоритм подписи, пока я не понял какой именно нужен.
Если программа будет 64 разрядная, то скорее все нужно будет подправить некоторые типы в объявлениях функций.

Вычисленное криптопро значение хэша или подписи нужно будет "перевернуть". Как я понял, фокус здесь в том, что криптопро возвращает результат не в том endian, который требуется стандартом XML-DSIGN и потому приходится первый байт менять местами с последним, второй с предпоследним и так далее. Затем закодировать в base64 (это относительно легко, модулей кодировщиков много, обычно они тесно связаны с модулями для работы с XML или HTML). Далее все полученное соединить в нужном порядке. Это заслуживает отдельного освещения, условно говоря на этом с подписью все.

Во-вторых, защищенный канал. Криптопро сделала собственную версию stunnel. Как я понял, отдельной лицензии не требуется, скачивание бесплатно с сайта криптопро. Для нее можно также переделать ключ и сертификат в pem формат как и для обычной. При этом вылезут те же самые грабли с неэкспортом .p12 из криптопро.
Однако внимания заслуживает факт, что вместо имени файла ключа в криптопрошном stunnel можно специальным образом указать ссылку на криптопро и считать ключ из криптопро. Немного неясно, что в этом случае происходит с пин-кодом ключа - на всякий случай лучше бы скопировать контейнер, а то не дай Бог рабочий контейнер заблочится от неправильных пин-кодов.
Как работает пока не проверял, но если не придется возиться с переделкой ключа, все значительно упростится. Правда меня "терзают смутные сомнения", что если прописать криптопрошную gost_capi.dll к обычному stunnel выйдет то же самое. Хотя сертификат все также потребуется в pem, но с этим проблем нет легко переводится через openssl.
Если настроить такой stunnel, то в программе можно не заморачиваться на собственную реализация HTTPS со вкусом ГОСТ, а просто стандартными модулями HTTP соединяться с локальным портом stunnel, а уже stunnel будет соединяться с серверами ГИС, накладывать шифрование, предъявлять сертификат серверу.

Отправлено спустя 20 минуты 11 секунды:
Цитата
2) В данный момент, насколько я понял, достаточно предоставления доступа организацией к собственной тестовой ИС. То есть, ИС не должна просить доступа у организации.
Скорее всего именно так, тестовый позволяет срезать "углы", я не очень подробно изучал этот момент. Однако важно помнить, что: а) для рабочего режима доступ все равно придется запрашивать; б) если срезать много углов и не протестировать все моменты в тестовом режиме, то в рабочем вылезет немало "сюрпризов" и "подводных камней". Читал, что в СМЭВ многие удивились когда рабочий контур проверил электронные подписи и "завернул" с ошибкой сообщения, которые в тестовом контуре проходили успешно. Оказалось тестовый контур игнорирует ошибки в подписи. Поэтому даже если тестовый сервер чего-то не требует, это не значит что нужно это спокойно пропустить.

Отправлено спустя 5 минуты 23 секунды:
Можете считать это перестраховкой с моей стороны, но я все равно бы пострался максимально придерживаться процедуры рабочего режима. Раз уж зашла об этом речь, в тестовом режиме еще используется специальный признак тестового режима, при указании которого в рабочем запрос будет отклонен.

Отправлено спустя 14 минуты 4 секунды:
Цитата
3) Вот я сгенерировал PAS из WSDL. Какие дальнейшие действия? Надо ли авторизоваться на ГИС из программы. В какой момент можно передавать данные? Мрак! Методичек нет и не предвидится.
Да, вот так и собираем истину по крупицам. :)
Как я понимаю, в данном случае зашифрованный канал требует предъявления сертификата клиента, при этом часть данных шифруется при помощи ключа клиента, сервер расшифровывает их ключом проверки из предъявленного сертификата и так доказывается, что у клиента есть ключ, соответствующий сертификату. То есть процедура установления зашифрованного канала по сути аналогична входу по сертификату на ЕСИА. Соответственно, дополнительная авторизация из программы не нужна - ГИС определит пользователя по сертификату защищенного соединения.
Получается передавать данные можно сразу после установления соединения - в смысле сначала заголовки протокола HTTP уточняющие: адрес страницы куда соединяемся, метод (POST я полагаю), тип, кодировку и длину "тела запроса", потом собственно данные в виде "тела запроса". Как-то так, заголовки наверняка описаны в документации, но сложно навскидку найти 1 нужный абзац среди сотен страниц текста.

Отправлено спустя 59 минуты 54 секунды:
Цитата
Вот я сгенерировал PAS из WSDL.
Как-то это меня настораживает. Непохожие языки, как они перегенерятся? Да и вообще вроде XML должен на выходе программы получаться.
Цитата
Какие дальнейшие действия?
Надеюсь немного пролил свет - дальше настроить stunnel, сделать xml, подписать, коннектиться по http на stunnel, передать данные и получить ответ ГИС
Цитата
с какой целью они прислали сертификат обратно
Родилось безумное предположение, что ГИС не принимает сертификаты аккредитованных удостоверяющих центров и они перевыпустили сертификат на своем удостоверяющем центре. Совпадает ли издатель в исходном сертификате и полученном от них?
 
Приветствую всех.
Шлю запросы по https с подписью.
Кратко опишу свой путь.
Использовал Delphi 7(лиценз.),
P12FromGostCSP для получения *.key (закрытый ключ для подписи).
SoapUI для получения и отладки запросов.
Статья на Хабре "Взаимодействие с ГИС ЖКХ с помощью stunnel и openssl по ГОСТу".
OpenSSL с гост, по ссылке той статьи.
Python + Eclipse для изучения алгоритма подписи.
Компоненты Indy поддерживают OpenSSL, т.о. защищенный канал "из коробки".
Каждый метод ГИСа, реализовал отдельным классом, с генерацией каноникализированного xml ручками. Для удобства наследовал от интерфейса.
Для подписи, по алгоритму статьи, написал класс для подписи, процедуры шифрования вызываю из dll, скачал заголовочный файл libeay32.pas, каноникализации в Delphi 7 нет, но т.к. запросы сами каноникализированы, то разобрался с namespace и всё, готов класс.
Парсинг ответных сообщений с помощью SimpleXML.pas, для логирования - LDSLogger.pas.
Задача с ГИСом пока фоновая, есть поважнее проекты.
КриптоПро не использую, это тот же самый OpenSSL + сервисные функции, и за деньги.
stunnel также не нужен использую Indy

Отправлено спустя 11 минуты 42 секунды:
Шифрование по ГОСТу (алгоритм)
[code:fs2tuymr]function SignGOST(const Data, KeyFN: string): string;
var
dlen: Integer;
slen: Cardinal;
md: pEVP_MD;
Key: pEVP_PKEY;
mdctx: pEVP_MD_CTX;
memout, Base64: pBIO;
b64Length: Integer;
outBuf: array[0..4095] of Char;
mdValue: array[0..EVP_MAX_MD_SIZE] of byte;
begin
dlen := Length(Data);
Key := ReadPrivateKey(KeyFN); // читаем файл закрытого ключа
slen := EVP_PKEY_size(Key); // определяем размер ключа
SetLength(Result, slen); // размер подписи будет таким же
md := EVP_get_digestbyname('md_gost94'); // получаем доступ к хэш-функции
New(mdctx); // формируем контекст подписи
EVP_SignInit(mdctx, md); // устанавливаем хэш-функцию, которая буддет использована
EVP_SignUpdate(mdctx, PChar(Data), dlen); // подписываем данные
EVP_SignFinal(mdctx, @mdValue, slen, Key); // завершаем формирование подписи
EVP_PKEY_free(Key); // освобождаем ресурсы
Dispose(mdctx);
// вывод в Base64
Base64 := BIO_new(BIO_f_base64); // BIO типа base64
memout := BIO_new(BIO_s_mem); // BIO в памяти для чтения-записи
Base64 := BIO_push(Base64, memout);
BIO_write(Base64, @mdValue, slen); // Пытается записать в Base64 sLen байт из буфера Result. Возвращает количество записанных байт
BIO_flush(Base64);
b64Length := BIO_read(memout, @outbuf, 4096);
outbuf[b64Length - 1] := #0;
Result := StrPas(@outbuf);
end;[/code:fs2tuymr]

Отправлено спустя 2 минуты 23 секунды:
Заголовок класса подписи
[code:fs2tuymr]unit Xades;

interface

//{$DEFINE TEST}

uses
Classes;

(*
Класс TXades подписывает XML,
пример:
x: TXades;
создание при указании файла ключа -> x := TXades.Create('C:\cert.key');
создание при передаче параметров -> x := TXades.Create(key, digest2, x509_issuer_name, x509_sn);
возврат текста подписанного XML -> mmo1.Text := x.GetSignXML(XML, SignedId);
*)

type
TXades = class
private
FItemXML: TStringList; // элементы сообщения
FBodyXML: TStringList; // тело сообщения
FSignXML: TStringList; // подписанный XML
FNameSpace: TStringList; // пространство имен
FSignedInfo: TStringList;// информация о подписи
Fsignature_id: string; // генерируются
Fsigned_id: string; // ID запроса, который указываем, как хотим и на который ориентируемся, подписывая запрос
Fdigest1: string; // Берётся содержимое тега <ns1:Body>), канонизируется алгоритмом C14N (exclusive=True), считается от неё хеш-сумма по ГОСТу и выводится в виде BASE64
Fdigest2: string; // Берётся сертификат в x509, декодируется из BASE64, считается от него хеш-сумма и вывод кодируется в BASE64
Fdigest3: string; // Формируется содержимое тега <xades:SignedProperties>, канонизируется алгоритмом C14N (exclusive=False) и от содержимого считается
Fsignature_value: string; // Формируется блок <ds:SignedInfo>, канонизируется алгоритмом C14N (exclusive=False), подписывается и кодируется в BASE64.
Fx590_cert: string; // x509 ключ из файла
Fsigning_time: string; // запоминается текущее время
Fx509_issuer_name: string; // Данные УЦ, выпустившего сертификат
Fx509_sn: string; // номер сертификата
Fkey: string; // имя и путь ключа
procedure GetDigest1(); // Вычисление Fdigest1
procedure GetDigest3(); // Вычисление Fdigest3
procedure LoadNameSpace(); // Поиск и загрузка пространства имен
procedure SetSignatureId(); // Генерация Id
procedure SetTextSignXML(); // Все полученные значения вносятся в шаблон XML-документа формата XAdES-BES
procedure Signature(); // Вычисление Fsignature_value
public
constructor Create(const key, digest2, x509_issuer_name, x509_sn: string); overload;
constructor Create(const Key: string); overload;
destructor Destroy; override;
function GetSignXML(const XML, SignedId: string): string;
{$IFDEF TEST}
function GetDigests(const XML, SignedId: string): string; // значения: Fdiges1, Fdiges2, Fdiges3
{$ENDIF}
end;

implementation[/code:fs2tuymr]

Отправлено спустя 2 минуты 14 секунды:
Один из классов для ГИСа
[code:fs2tuymr]{*------------------------------------------------------------------------------
Экспорт сведений об организациях
-------------------------------------------------------------------------------}

unit ExportOrgRegistry;

interface

uses
GIS_Interface;

type
TExportOrgRegistry = class(TInterfacedObject, IGIS)
private
FOGRN: string; /// ОГРН
FAsync: Boolean;
FDate: string;
FGUID: string;
FXML: string;
function Header(): string;
public
constructor Create(const orgPPAGUID, OGRN: string; Async: Boolean = False);
function Async(): Boolean;
function Command(): string;
function Date(): string;
function HeaderAction(): string;
function GetObject: TObject;
function GUID(): string;
function WebService(): string;
function XML(): string;
end;

implementation

uses
GIS_Query, GIS_Const;

{ TExportOrgRegistry }

function TExportOrgRegistry.Async: Boolean;
begin
Result := FAsync;
end;

function TExportOrgRegistry.Command: string;
begin
Result := 'exportOrgRegistry';
if FAsync then
Result := Result + '(Async)';
end;

constructor TExportOrgRegistry.Create(const orgPPAGUID, OGRN: string; Async: Boolean = False);
begin
FAsync := Async;
FOGRN := OGRN;
FDate := SetDate;
FGUID := SetGUID_Message(orgPPAGUID, metExportOrgRegistry);
FXML := Concat(Header(),
MakeXMLnode('soapenv:Body', '', BeginNode),
MakeXMLnode('org:exportOrgRegistryRequest', cVer_ExportOrgRegistry, '', BeginNode),
MakeXMLnode('org:SearchCriteria', '', BeginNode),
MakeXMLnode('org1:OGRN', FOGRN, FullNode),
MakeXMLnode('org:SearchCriteria', '', EndNode),
MakeXMLnode('org:exportOrgRegistryRequest', '', EndNode),
MakeXMLnode('soapenv:Body', '', EndNode),
MakeXMLnode('soapenv:Envelope', '', EndNode));
end;

function TExportOrgRegistry.Date: string;
begin
Result := FDate;
end;

function TExportOrgRegistry.GetObject: TObject;
begin
Result := Self;
end;

function TExportOrgRegistry.GUID: string;
begin
Result := FGUID;
end;

function TExportOrgRegistry.Header: string;
begin
Result := Concat(cHeader, cNS_ExportOrgRegistry, #10,
MakeXMLnode('soapenv:Header', '', BeginNode),
MakeXMLnode('base:ISRequestHeader', '', BeginNode),
FDate, #10, FGUID, #10,
MakeXMLnode('base:ISRequestHeader', '', EndNode),
MakeXMLnode('soapenv:Header', '', EndNode));
end;

function TExportOrgRegistry.HeaderAction: string;
begin
Result := '"urn:exportOrgRegistry"';
end;

function TExportOrgRegistry.WebService: string;
begin
Result := 'ext-bus-org-registry-common-service/services/OrgRegistryCommon';
if FAsync then
Result := Result + 'Async';
end;

function TExportOrgRegistry.XML: string;
begin
Result := FXML;
end;

end.
[/code:fs2tuymr]

Отправлено спустя 8 минуты 58 секунды:
Важно! Загрузка ГОСТа из dll (последняя строка)
[code:fs2tuymr](*
инициализация библиотеки
*)
procedure LoadSSL;
begin
OpenSSL_add_all_algorithms;
OpenSSL_add_all_ciphers;
OpenSSL_add_all_digests;
ERR_load_crypto_strings;
ERR_load_RSA_strings;
// используется имя файла, указанное в OPENSSL_CONF
OPENSSL_config(PChar(GetDOSEnvVar('OPENSSL_CONF')));
end;
[/code:fs2tuymr]

Отправлено спустя 14 минуты 20 секунды:
Из ИндиЛога заголовок запроса на https (по http похожий):
POST /ext-bus-org-registry-common-service/services/OrgRegistryCommon HTTP/1.0
Content-Type: text/xml; charset=UTF-8
Content-Length: 6333
SOAPAction: "urn:exportOrgRegistry"
Authorization: Basic c2l0OnJaX0dHNzJYU15WZjU1Wlc=
X-Client-Cert-Fingerprint: cb.... (тут мой отпечаток серт.)
Host: 217.107.108.156:10081
Accept: text/html, */*
Accept-Encoding: gzip,deflate, identity
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)


Отправлено спустя 5 минуты 19 секунды:
Для изучения шифрования по ГОСТу помогло изучение "Библиотека libcrypto.Руководство программиста" от КриптоКома.
Всех с наступающим 23 февраля, вспомним как служили!
 
Ура, еще немного и пряморукие люди смогут настроить обмен данными.
 
Цитата
RatWar пишет:
Компоненты Indy поддерживают OpenSSL, т.о. защищенный канал "из коробки".
Огромное спасибо! Все замечательно, разве что КриптоПро остался не при делах, а OpenSSL везде или относительно устаревший в котором есть ошибки или не сертифицированный. Ну отдельный класс для каждого отчета править после смен версий ГИС это немного чересчур.

Вставлю 5 копеек о соединении криптопро и OpenSSL, тогда отпадет необходимость в P12FromGostCSP (у меня она вообще вытаскивает непонятно что, пришлось конвертировать через privkey).
1) Как я понял OpenSSL умеет ключ и из памяти брать, так что можно считать закрытый ключ из хранилища сертификатов стандартным криптопровайдером, потом передать OpenSSL.
2) стандартную gost.dll из OpenSSL можно без особых потерь заменить в конфиге на криптопрошную gost_capi.dll (нужно только закомментировать выбор параметров A (кстати у нас все ключи на параметрах exA, так что наверно так правильнее )) и тогда можно из OpenSSL работать с ключами в контейнерах криптопро.
 
ГОСПОДИ! Откуда Вы все это знаете?
 
OpenSSL не сертифицирован это да, насчет устаревания, всегда можно скачать свежую версию и собрать.
КриптоПро использует ту же OpenSSL, сертифицирует и продает, у них то как раз версия будет устаревшая, т.к. на сертификацию требуется время.
Для подписи ключ не нужен, нужны лишь его параметры, которые можно один раз получить и хранить например, в ini-файле. Для IdSSLIOHandlerSocketOpenSSL нужны ключи, в формате *.key и *.pem

Отправлено спустя 3 минуты 2 секунды:
В заголовке класса подписи видно, что у меня реализовано 2 конструктора, с параметрами и с чтением ключа

Отправлено спустя 1 минуту 51 секунды:
Цитата
Programmer пишет:
ГОСПОДИ! Откуда Вы все это знаете?
Опыт сын ошибок трудных...
 
Цитата
two_oceans пишет:
Ну отдельный класс для каждого отчета править после смен версий ГИС это немного чересчур.
В примере класса можно увидеть, что сама версия ГИС обозначается константой cVer_xxx..., константы эти собраны в отдельном файле. Ну если метод измениться, то придется корректировать класс. На каждый метод свой класс, в главном классе вызов методов класса идет по интерфейсной переменой, что упрощает управление памятью и не трогает основную логику.
 
Цитата
Programmer пишет:
... так как с XLSX запарился работать.
Цитата
Programmer пишет:
ГОСПОДИ! Откуда Вы все это знаете?
Вам всё еще кажется трудной работа с ёксель-файлом ?
 
Цитата
Дамир пишет:
Вам всё еще кажется трудной работа с ёксель-файлом ?

Трудности с Ёксель преодолел - "рисую" их программным методом. Не нравится загружать их.
 
Цитата
КриптоПро использует ту же OpenSSL
вот как раз про само ядро криптопро что-то не замечал следов использования openssl, слишком уж разное хранение контейнера закрытого ключа (не думаю, что кто-то стырит чужой код и решит абсолютно новый контейнер изобрести) - это то, что собственно продается. Хотя stunnel однозначно из OpenSSL подправили и переходник к OpenSSL естественно не построить без исходников OpenSSL - но эти добавки или бесплатны или используют основную лицензию.
С остальными криптопровайдерами вроде магпро, сигнал ком и компании полностью согласен. В демо магпро версия 1.0.1с, в то время как в мае прошлого года уже была в сети скомпиленная 1.0.2h. Собрать поновее все никак не соберусь - лениво с компиляторов Си возиться ради одной проги.
Цитата
Для подписи ключ не нужен, нужны лишь его параметры, которые можно один раз получить и хранить например, в ini-файле.
Так, стоп. Что-то я не понял, наверно терминология отличается. По идее для вычисления хеша не нужен закрытый ключ, но для вычисления SignatureValue закрытый ключ потребуется. Не говорите мне что закодировали в строку pem и сохранили в ini файл. Если же там только параметры, то в них наверняка указан путь к ключу и он достается неявно. С другой стороны, сертификат (содержащий открытый ключ) можно хранить хоть как и он потребуется при сборке тега Signature.
Цитата
На каждый метод свой класс, в главном классе вызов методов класса идет по интерфейсной переменой, что упрощает управление памятью и не трогает основную логику.
Интересный подход, я больше склоняюсь к другому - хранить список нужных для версии данных и форматов, потом передавать в некий универсальный класс-построитель эти списки и сами значения данных. Выгода в том, что изменить список гораздо проще чем каждый раз переписывать логику, а недостаток в том, что работать будет медленнее, так как на анализ списка потребуется дополнительное время. Но в общем это тесно завязано с выборкой данных из самой ИС, так что дело автора ИС, что выбрать.
Цитата
Вам всё еще кажется трудной работа с ёксель-файлом ?
Прошу заметить, что тут еще ненавязчиво выкинули приведение к каноническому виду (дескать наша вручную высеченная ИС сразу дает канонический вид). А если писать с нуля процентов 60 всей работы это как раз написать полностью соответствующий стандарту каноникализатор. Серьезно, почитал стандарт приведения к каноничному виду, в XML открылись такие возможности о которых я даже не подозревал и вряд ли кто в своем уме их вообще использует, но тем не менее их надо поддерживать при приведении. :)
 
Цитата
two_oceans пишет:
По идее для вычисления хеша не нужен закрытый ключ, но для вычисления SignatureValue закрытый ключ потребуется.
Да, один раз вычисляю дайджест и сохраняю его. Если сертификат не меняется, то дайджест тоже не меняется. Потому то в дальнейшем не нужен *.key.
Fdigest2: string; // Берётся сертификат в x509, декодируется из BASE64, считается от него хеш-сумма и вывод кодируется в BASE64
 
Ясно, все же про разное говорим. Дайджест(он же хэш, хеш) от сертификата сохраняется, но говорю не про него, так как он в идеале вообще никак с закрытым ключом не пересекается.
Видимо у Вас ключевая пара после переведения в .p12 затем в .key осталась в одном файле и поэтому возникла путаница, где открытый ключ, а где закрытый ключ - так как в данном случае они в одном и том же файле.
Но при вычислении содержимого тега SignatureValue откуда-то же берется нужный закрытый ключ?

Отправлено спустя 2 минуты 21 секунды:
я вообще расширение .key стараюсь не использовать - редактор реестра на него срабатывает, что несколько раздражает. А на .pem настроил блокнот - удобно смотреть что в файле содержится.

Отправлено спустя 36 минуты 45 секунды:
Цитата
ГОСПОДИ! Откуда Вы все это знаете?
Полагаю, немного приберусь в файлах и выложу подборку статей по которым все изучал на общедоступный сайт. Сейчас они у меня сохранены на локальном сайте - на случай если исходная удалится. Подчищаю рекламу, посторонние функции и читать становится легче (особенно статьи с хабра - на самом хабре и реклама и куча других отвлекающих статей). Однако локальный сайт на обычной (не серверной) Windows поэтому нормально просмотреть извне не получится.
Для начала cтатья про SSL/TLS, сертификаты, УЦ, ключи, форматы PEM и DER, различия открытых-закрытых ключей. Программистам прочитать однозначно советую, чтобы не выглядеть дубом при обсуждении сертификатов. Сайт вообще про службы каталогов, но статья достаточно полно освещает тему сертификатов. Проблема в том, что информации там слишком много и в том числе напрямую не относящейся к "нашим баранам". Поэтому "не-программистам" будет крайне скучно. Если начнете на уровне новичка, то вряд ли дочитаете все за первый раз. По мере надобности не раз еще вернетесь. Ну хотя бы как словарик используйте.
 
Цитата
Programmer пишет:
Цитата
Дамир пишет:
Вам всё еще кажется трудной работа с ёксель-файлом ?
Трудности с Ёксель преодолел - "рисую" их программным методом. Не нравится загружать их.
От ГИС-овцев всего-то требуется дать возможность автоматизировать загрузку/выгрузку ёкселевских файлов.
Т.е. некий сервис (почта, ftp, да тот же соап - загружают же они сканы документов).
нет жеж... соап для каждой операции с уникальным форматом xml-данных на вход/выход.
С этого вся ветка началась - 'нафига этот соап, автоматизируйте обмен ёксель-файлами'
 
Цитата
Дамир пишет:
От ГИС-овцев всего-то требуется дать возможность автоматизировать загрузку/выгрузку ёкселевских файлов.

Было бы здорово. Надо, например,отправить почтой файл abc.xlsx, копируешь электронную подпись в файл abc.key, и отправляешь оба файла автоматом: abc.xlsx и abc.key.
 
Цитата
Programmer пишет:
Надо, например,отправить почтой файл abc.xlsx
Насчет конкретно почты идея не очень удачная. Я как-то разбирался можно ли отправлять данные между подразделениями с ЭП и оказалось не так все просто.
1) По идее как канал шифруется так надо будет и отправляемые почтой файлы зашифровать. Просто шифрование канала от клиента до сервера не решит проблему, так как обычная почта соединяется со своим сервером, а не с Гисовским и тогда данные будут не зашищены между серверами. Либо надо создавать каждому пользователю учетку на гисовском почтовом сервере - тогда шифрования канала достаточно.
Шифрование файлов (как и подписание) можно сделать какой-то программой (консольной командой openssl или КриптоАрм) до отправки либо самим почтовым клиентом.
Если шифровать почтовыми клиентами, то там в сертификате ЭП должны быть строго определенные поля - назначение сертификата keyUsage (цифровая подпись, шифрование данных) и расширенное использование ключа extended key Usage(Защита электронной почты) плюс к тому адрес почты в сертификате должен совпадать с адресом с которым отправляется почта. А если шифровать по ГОСТ, то нужно еще поле "возможности SMIME" с указанием алгоритма ГОСТ. Про наличие криптопровайдера не говорю - почтовые программы в основном поддерживают openssl, но там придется морочиться с преобразование ключа.Это реальная головная боль - на текущий момент у нас всего 2 сертификата в которых есть шифрование данных. Почтовые адреса тоже указаны наобум. И уж точно ни в одном действующем сертификате нет ничего про возможности SMIME. (Нашлись сертификаты 2012 года с этими возможностями и после перевода времени в 2012 год почтовик TheBat! согласился их использовать, но по факту они истекли, так что реально использовать не выйдет).2) Все передаваемые по почте данные кодируются в base64, что повышает размер на 30-40%. А шифрование не даст эффективно сжать. Представляете какой ГИС надо иметь почтовый ящик чтобы письма со всей страны его не переполняли.
3) такой единый ящик наверняка засветится (на форумах вроде этого) и будет получать тонны спама. Значит будет спам-фильтр - значит будут срезаться и почта с данными.
С FTP идея получше, но это тоже сводится к созданию учетки для каждого пользователя и chroot. Иначе будут затираться файлы у всех кто "креативно" назвал файл abc.xml или 111.xml. Но можно называть файл через guid. Из плюсов - можно результат выкладывать тоже на FTP. Минусы - FTP относительно медленный протокол (из-за кучи служебных команд) и съедает кириллицу в названиях файлов (это можно обойти если подобрать совместимые клиент и сервер, но лучше кириллицу вообще избегать при работе с FTP), файл с данными испортится если передать в текстовом режиме (обычно можно настроить автопереключение на двоичный режим при передаче файлов), дата изменения по FTP передается крайне безобразно (часто округленно до суток или часов).
Еще есть примерно той же с FTP направленности WebDAV (дополнительное расширение протокола HTTP для изменения файлов на сервере) - тоже создание учетки для каждого пользователя и chroot. Но поудобнее чем FTP в плане кириллицы, передачи времени, выбора режима и есть встроенная поддержка от Windows - можно подключить как сетевой диск. Просто скопировал файл и подпись в папку приема на сетевом диске и ждешь результата в папке результатов. Большинство программ прекрасно работают с сетевыми дисками (пока только cmd и dism на удивление отказались). FTP тоже можно подключить как сетевой диск, но придется залезть вглубь настроек системы - "из коробки" принимаются имена локальной сети. Для сервера поудобнее тем, что папка с результатами может находиться на совершенно другом сервере чем папка для приема данных, но клиент не этого даже заметит. Так что я бы скорее предпочел этот вариант.
С SOAP идея тоже хороша - если и данные и подпись как отдельные вложения в унифицированном SOAP конверте с указанием id шаблона, но без использования xmldsign на SOAP. Все эти способы могут работать через настроенный по сегодняшним требованиям защищенный канал.
Цитата
Programmer пишет:
копируешь электронную подпись в файл abc.key
Все же .key расширение для ключей (в *nix) и называть так файл подписи не очень хорошо. Важно их не путать - ключ один и тот же на все время действия сертификата (и закрытый и открытый), а подпись создается для каждого файла данных отдельно. Общепринято отсоединенный файл подписи называть как .sig или .p7s, то есть если файл c данными назывался abc.xlsx , то автоматическое средство проверки в первую очередь будет искать его подпись в abc.xlsx.sig или abc.xlsx.p7s
 
Цитата
two_oceans пишет:

С SOAP идея еще лучше - если и данные и подпись как отдельные вложения в унифицированном SOAP конверте с указанием id шаблона, но без использования xmldsign на SOAP.
id шаблона содержится внутри самого ёксель-файла на скрытой вкладке CONF.
Итого в остатке: от ГИСовцев нужна программа-транспорт (по соап, с шифрацией и прочей только им нужной фигней), которая будет забирать из указанного каталога ёксель-файлы и выгружать в указанный каталог ёксель-файлы.
фсё! Пользователю телевизора не нужно знание принципа работы полевого транзистора.
 
Цитата
Дамир пишет:
Пользователю телевизора не нужно знание принципа работы полевого транзистора.
Дописал про WebDAV - там даже отдельную программу не надо. Настроил stunnel (можно собрать архивчик, достающий ключ из системы, останется только сертификат воткнуть и его прописать), подключил сетевой диск и вперед.
 
Цитата
two_oceans пишет:
... подключил сетевой диск и вперед.
А как бы мысль до ГИСовцев донести ?
чтоб работать могли все, а не только с 10 годами опыта веб-программирования.
 
Цитата
Дамир пишет:
А как бы мысль до ГИСовцев донести ?

А гис - ОВЦАМ по фигу. Они сами себе на уме.
 
Цитата
Дамир пишет:
чтоб работать могли все, а не только с 10 годами опыта веб-программирования

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

Я занимаюсь программированием неполных 25 лет.
За это время изучил и использовал на практике несколько языков программирования. Свой выбор 10 лет назад остановил на Pascal, разработкой занимаюсь в Delphi, в основном - коммунальные платежи, несколько программ для АСУ (Pascal и Assebler).
За все это время в области интернет - технологий достиг немногого, только то, что требовалось по работе:
отправка и получение SMS;
отправка и получение почты с вложениями;
отслеживание изменений на сайте;
обмен по FTP.
Вдруг откуда ни возьмись появились ГИС и ИС.
Разработал заполнение шаблонов, но в процессе их выгрузки понял, что нужно осваивать SOAP, но мои знания в этой области на нуле, если не ниже. И вот, благодаря таким асам как two_oceans, AlcorVol и RatWar (может быть еще какой-нибудь ас объявится), появилась надежда в освоении этого зверя. Надеюсь, коллеги меня поймут.
 
Спасибо большое за лестный отзыв. Сам себя к асам наверно относить не стану, хватаю всего помаленьку, но постепенно кое-что накапливается. За неполных 20 лет программирования еще ни одной крупной программы, зато куча мелких или одноразовых. На наш отдел сваливают все что что хоть как-то с компьютерами связано, за месяц более 100-200 разных обращений от мелких "мышка не бегает", "картридж нужно заправить", перезагрузить 1С, опубликовать новость на сайте, переустановить Windows до таких необъятных как взаимодействие по соап с разными ФГИС. С ЭП впервые столкнулся лет 6 назад, наблюдал за действиями коллеги. 3 года как занимаюсь ЭП вплотную. Openssl, разбор сертификатов на байты, собственный УЦ на openssl уже около года в работе, а соап и ГИС месяца 4. Короче интересов много, на все времени не хватает, тем более что очень часто отвлекают не по делу, весь январь доставали с отчетами.
Из февральского - в 2005 и 2015 году были приняты законы по концессионных соглашениям в сфере ЖКХ, в начале февраля внезапно в ГАС "Управление" сделали возможность заполнения информации по ним и дали сроку до... 22 февраля. Прям зло берет - сами делали пару лет, а нам дали 20 дней. Причем возможность загружать xls файлы включили за 5 дней до срока. Пришлось все бросать и набивать вручную данные, о которых мы вообще как-то без понятия - реальные или красивая сказка на бумаге. На получение реальных нужно немало времени, так что скорее второе.В свою очередь мне было бы интересно узнать про SMS (для внутреннего сайта приема обращений от коллег) и почту (теоретические наметки есть, даже свой мини клиент-сервер POP3 когда-то писал, больше интересно как не спамить сообщениями и про вложения).

Отправлено спустя 19 минуты 3 секунды:
Очень надеюсь, что все же доведем совместными усилиями СОАП до ума. Пока для себя все представляю в том же ключе - модуль генерации соап, модуль подписания XML-DSIGN, модуль отправки, модуль обмена настроек генерации через сайт, модуль анализа шаблонов, типовой сайт обмена настроек. Естественно, еще куча "подмодулей" и возможность выбора криптоядра. Про обмен настройками я тут подробно еще не расписывал, но есть "альфа версия" описания в Word.
Возможно, имеет смысл вообще начать осваивать git и создать проект на github для совместной работы. Если конечно коллеги согласятся объединить усилия хотя средства разработки у всех отличаются. На форуме выкладывать несколько неудобно, но очевидно, что чем больше глаз будет наблюдать, тем проще выловить потенциальные ошибки и улучшить код.
 
Цитата
Programmer пишет:
И вот, благодаря таким асам как two_oceans, AlcorVol и RatWar
Хотя мой программистский стаж и приближается потихоньку к 40 годам, сам себя в "асы" записывать не стал бы. :) Осваиваю только то, что жизненно необходимо. А вот two_oceans - это просто джип-универсал! :) Нет такой программистской области, где он не разбирался бы на уровне хорошего спеца. Балдею просто!
 
Может быть не по теме,
но для тех, кто интересуется отправкой писем
с вложениями, выкладываю рабочую демо (Delphi).
Внутри архива файл READ.ME, прочтите.
 
Цитата
Programmer пишет:
Может быть не по теме,
но для тех, кто интересуется отправкой писем
с вложениями, выкладываю рабочую демо (Delphi).
Внутри архива файл READ.ME, прочтите.
Что это? Выглядит, как вирусы для ГИСа :)
 
Это не вирусы, а часть моей программы для рассылки отчетов для председателей ТСЖ, адаптированная под демо.
 
Цитата
Programmer пишет:
Может быть не по теме,
но для тех, кто интересуется отправкой писем
с вложениями, выкладываю рабочую демо (Delphi)
Спасибо, но у меня эта задача давно уже решена - по-своему. ;) FoxPro позволяет вызывать командой RUN любые консольные приложения. Откопал в Интернете простенькую консольную утилиту blat, позволяющую отправлять email'ы по протоколу SMTP через почтовые сервера (вроде mail.ru или gmail.com). Но сия программа использует фиксированные адреса портов, давно устаревшие. Пришлось освоить и программу stunnel, позволяющую делать переадресацию портов. В итоге - могу посылать клиентам ПД, а также любые другие документы, так как всякие attachments этот blat прекрасно отрабатывает. Если кому-то интересно, могу и более подробной информацией поделиться.
 
Цитата
Не успеешь глазом моргнуть как наступит ответственность...
Спасибо. Классный текст сообщения, однако. Судя по тому, что я вижу в папке synapse... там уже половина исходников для соап есть. DLL ки правда 10+ летней давности. А еще по названию синапс припомнился фильм "Опасная правда".
Цитата
AlcorVol пишет:
FoxPro позволяет вызывать командой RUN любые консольные приложения.
На PHP принцип такой же и куча консольных программ отправки, правда большинство для Linux. Еще я как-то пробовал отправлять через Яндекс себе от своего домена, на котором не установлено ограничений с каких адресов почта допустима через программу Kerio Mail Server. Обычно Яндекс без своей авторизации от клиента письма не принимает. Как ни удивительно, оказалось что если другой почтовый сервер в заголовках письма пишет "авторизация пройдена, зуб даю", Яндекс дает отправить через себя 1 письмо в 15 минут с левым адресом. Естественно если авторизоваться нормально, то можно побольше и почаще, но только от своих адресов.
А поводу ограничения спама есть какие-то задумки? Допустим, прикручу отправку письма (или смс) к добавлению заявки на сайте, но это же будет ужас если на каждую заявку письмо. Думал сделать планировщиком (раз в 3 часа, например) проверять есть ли заявки и высылать письмо, но так потеряется оперативность первой заявки (допустим в 9-05 отработает и ничего не обнаружит, а кто-то заявку сделает в 9-06 и три часа провисит).
К слову, отправка смс, Android и мобильные приложения - пример области, в которой я только смутно разбираюсь - что наверно надо что-то как-то отправить на смс-шлюз, но без понятия что, как и где шлюз брать, с Ростелекомом договариваться наверно? и что можно мобильное приложение самому написать и скидывать на телефон вручную, не через магазин. Все. Наверно еще можно установить дешевый тарифный план на телефон, подключить к компьютеру и отправлять смс через телефон, но как это сделать программно - не в курсе.
 
Цитата
two_oceans пишет:
Обычно Яндекс без своей авторизации от клиента письма не принимает.
Ну, и на mail.ru мне тоже пришлось завести специальный "служебный" аккаунт. От его имени и посылаю всё. Можно было и gmail.com использовать, но там все мессаджи в папку "Отправленные" складируются. :) А мне совсем не хотелось ни следов оставлять, ни дисковое пространство переполнять. :) В этом смысле - mail.ru меня устроил полностью. Никаких ограничений на частоту отправок не обнаружил. Всё сразу обрабатывает, ни на что не жалуется.
Цитата
two_oceans пишет:
А поводу ограничения спама есть какие-то задумки?
Не совсем понял вопрос. Моя программа посылает что-то только явно, по запросу "оператора". Никаких автоматических рассылок нет. Если клиент позвонит и попросит отправить ему ПД - то оператор (бухгалтер) пошлёт. Никто ещё не позволил оставлять жильца без бумажного документа. А если вдруг потеряется - то пожалуйста, можно и через SMTP продублировать.
Цитата
two_oceans пишет:
К слову, отправка смс, Android и мобильные приложения - пример области, в которой я только смутно разбираюсь
С ума сойти! Нашлась-таки такая область, где ты не очень хорошо разбираешься. :D Но я-то - ещё меньше! :D
#61
0 0
Ну у меня тоже еще все на начальном уровне, но попробую сделать "дайджест". Не очень понятны подробности до чего процесс дошел и с какой целью они прислали сертификат обратно, да еще и со своей подписью (.p7s - это файл отсоединенной подписи, проверить можно через бесплатную версию программы КриптоАрм или на сайте [url:1jrulhzi]https://crypto.kontur.ru/[/url:1jrulhzi] указав оба файла, а вот для создания подписи нужна платная версия). Как я понял, ИС "доработана" (допустим, генерирует сразу каноническую форму XML) и зарегистрирована в тестовом контуре. Подписывать XML ИС уже умеет? Delphi чуть ли не на раз высчитывает значение хэша и подписи через библиотеки MS CryptoAPI и КриптоПро, остается только перевернуть порядок байтов, закодировать в base64 и все правильно соединить.

Далее нужно разрешить доступ к данным своей организации со стороны ИС (то есть видимо надо зайти на ГИС от имени своей ИС и запросить разрешение от своей УК, потом зайти как УК и подтвердить). Далее построить защищенный канал до тестового сервера ГИС. Как я понимаю https://217.107.108.156:10081/ это один из тестовых серверов с шифрованием, чаще всего используют stunnel на основе OpenSSL. По идее можно найти модули для Delphi с поддержкой HTTPS - как через системные библиотеки TLS, так и через библиотеки OpenSSL. Однако наверно придется залезать куда-то глубоко в дерево классов, что бы указать ГОСТ как алгоритм шифрования. Еще где-то в документации должен быть корневой сертификат ГИС - он также потребуется для построения канала, чтобы ИС не обрывала соединение по причине, что у ГИС не доверенный сертификат.

Далее запулить тестовое сообщение. В декабре там был "косяк" в описании - нужно было указывать организацию совсем не так, как было в документации, не знаю, исправили или нет.
#62
0 0
СПАСИБО two_oceans!

Цитата
two_oceans пишет:
Еще где-то в документации должен быть корневой сертификат

Я понимаю, что это файлы pem...

1) Если у меня лицензионный КриптоПро, то какие-нибудь проблемы из вышеперечисленных снимаются?

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

3) Вот я сгенерировал PAS из WSDL. Какие дальнейшие действия? Надо ли авторизоваться на ГИС из программы. В какой момент можно передавать данные? Мрак! Методичек нет и не предвидится.
#63
0 0
Пожалуйста.
Цитата
Я понимаю, что это файлы pem...
Скорее всего. Вообще PEM это формат ("текстовая" кодировка в base64 данных + текстовые заголовки) и расширение может быть разным. Для сертификатов в PEM общепринято .crt и windows его понимает. Если после изменения .pem на .crt отобразится сертификат, то можно посмотреть чей и все прояснится.

Отправлено спустя 15 минуты 22 секунды:
Цитата
1) Если у меня лицензионный КриптоПро, то какие-нибудь проблемы из вышеперечисленных снимаются?
В принципе да. Конечно смотря какая именно лицензия.
Во-первых, по подписи XML. Краем глаза видел где-то на сайте КриптоПро xml-dsign-addin. По названию эта штука как раз для подписи XML, но как я понял для него нужна дополнительная лицензия, поэтому не стал разбираться к чему он addin (дополнение) и подходит ли подписанный файл к ГИС. Почему-то мне кажется, что дополнение к MS Office и к ГИС не очень подходит (предположил что потребует сохранения файла на диск, подписания, потом отправки файла, то есть нарушит "поточность" внутри программы), поэтому не стал докупать, но может быть у кого-то получится настроить и приспособить.

Если все же не допиливать чужое, а делать свое, то Delphi может обратиться к КриптоПро через майкрософтовские функции. Тут ориентиром служит модуль JwaWinCrypt (есть какой-то стандартный Crypt2 WCrypt32.pas, но в нем как я понял несколько устаревшие описания функций и без учета 64-битности) и заголовочный файл от криптопро с описанием констант. Заголовочный файл желательно посвежее от той же версии КриптоПро, что установлена. Обычно они идут с лицензией криптопро для разработчиков. У меня такой нет, нашел явно "несвежий" заголовочный файл. Впрочем скорее всего из всего файла понадобятся только 3-4 константы. В заголовочном файле констант намного больше и комментарии к ним наводят на мысль что таким же образом наверно и зашифрованный канал можно поднять, но я пока не вникал в подробности. Вот 4 константы для получения хэша и подписи, бросившиеся в глаза.[code:d1hqgczn]const PROV_GOST_2001_DH=75; //Тип Криптопровайдера. для ГОСТ большинство криптопровайдеров использует этот, исключение vipnet для него значение типа равно 2
szOID_CP_GOST_R3411='1.2.643.2.2.9'; //Функция хэширования ГОСТ Р 34.11-94
szOID_CP_GOST_R3411_R3410EL='1.2.643.2.2.3'; //Алгоритм цифровой подписи ГОСТ Р 34.10-2001
szOID_CP_GOST_R3410EL='1.2.643.2.2.19'; //Алгоритм ГОСТ Р 34.10-2001, используемый при экспорте/импорте ключей[/code:d1hqgczn]Первая - это тип криптопровайдера, указывается в CryptAcquireContext. Одновременно можно указать nil вместо имени криптопровайдера (тогда программа подхватит почти любой гостовский (кроме vipnet), выставленный "по умолчанию" для типа 75, не обязательно криптопро) или указать полное наименование криптопро (тогда другие гостовские не подхватятся, но сможет подхватится криптопро даже если криптопро не "по умолчанию" для типа 75). Наименование и выставлен ли по умолчанию можно посмотреть в настройках криптопро (там где обычно сертификат устанавливаем, на соседней вкладке).
Вторая - идентификатор функции хэширования, используется вместо szOID_RSA_MD5 в примерах. Смущает, что 94, но похоже та самая. Третья- четвертая - алгоритм подписи, пока я не понял какой именно нужен.
Если программа будет 64 разрядная, то скорее все нужно будет подправить некоторые типы в объявлениях функций.

Вычисленное криптопро значение хэша или подписи нужно будет "перевернуть". Как я понял, фокус здесь в том, что криптопро возвращает результат не в том endian, который требуется стандартом XML-DSIGN и потому приходится первый байт менять местами с последним, второй с предпоследним и так далее. Затем закодировать в base64 (это относительно легко, модулей кодировщиков много, обычно они тесно связаны с модулями для работы с XML или HTML). Далее все полученное соединить в нужном порядке. Это заслуживает отдельного освещения, условно говоря на этом с подписью все.

Во-вторых, защищенный канал. Криптопро сделала собственную версию stunnel. Как я понял, отдельной лицензии не требуется, скачивание бесплатно с сайта криптопро. Для нее можно также переделать ключ и сертификат в pem формат как и для обычной. При этом вылезут те же самые грабли с неэкспортом .p12 из криптопро.
Однако внимания заслуживает факт, что вместо имени файла ключа в криптопрошном stunnel можно специальным образом указать ссылку на криптопро и считать ключ из криптопро. Немного неясно, что в этом случае происходит с пин-кодом ключа - на всякий случай лучше бы скопировать контейнер, а то не дай Бог рабочий контейнер заблочится от неправильных пин-кодов.
Как работает пока не проверял, но если не придется возиться с переделкой ключа, все значительно упростится. Правда меня "терзают смутные сомнения", что если прописать криптопрошную gost_capi.dll к обычному stunnel выйдет то же самое. Хотя сертификат все также потребуется в pem, но с этим проблем нет легко переводится через openssl.
Если настроить такой stunnel, то в программе можно не заморачиваться на собственную реализация HTTPS со вкусом ГОСТ, а просто стандартными модулями HTTP соединяться с локальным портом stunnel, а уже stunnel будет соединяться с серверами ГИС, накладывать шифрование, предъявлять сертификат серверу.

Отправлено спустя 20 минуты 11 секунды:
Цитата
2) В данный момент, насколько я понял, достаточно предоставления доступа организацией к собственной тестовой ИС. То есть, ИС не должна просить доступа у организации.
Скорее всего именно так, тестовый позволяет срезать "углы", я не очень подробно изучал этот момент. Однако важно помнить, что: а) для рабочего режима доступ все равно придется запрашивать; б) если срезать много углов и не протестировать все моменты в тестовом режиме, то в рабочем вылезет немало "сюрпризов" и "подводных камней". Читал, что в СМЭВ многие удивились когда рабочий контур проверил электронные подписи и "завернул" с ошибкой сообщения, которые в тестовом контуре проходили успешно. Оказалось тестовый контур игнорирует ошибки в подписи. Поэтому даже если тестовый сервер чего-то не требует, это не значит что нужно это спокойно пропустить.

Отправлено спустя 5 минуты 23 секунды:
Можете считать это перестраховкой с моей стороны, но я все равно бы пострался максимально придерживаться процедуры рабочего режима. Раз уж зашла об этом речь, в тестовом режиме еще используется специальный признак тестового режима, при указании которого в рабочем запрос будет отклонен.

Отправлено спустя 14 минуты 4 секунды:
Цитата
3) Вот я сгенерировал PAS из WSDL. Какие дальнейшие действия? Надо ли авторизоваться на ГИС из программы. В какой момент можно передавать данные? Мрак! Методичек нет и не предвидится.
Да, вот так и собираем истину по крупицам. :)
Как я понимаю, в данном случае зашифрованный канал требует предъявления сертификата клиента, при этом часть данных шифруется при помощи ключа клиента, сервер расшифровывает их ключом проверки из предъявленного сертификата и так доказывается, что у клиента есть ключ, соответствующий сертификату. То есть процедура установления зашифрованного канала по сути аналогична входу по сертификату на ЕСИА. Соответственно, дополнительная авторизация из программы не нужна - ГИС определит пользователя по сертификату защищенного соединения.
Получается передавать данные можно сразу после установления соединения - в смысле сначала заголовки протокола HTTP уточняющие: адрес страницы куда соединяемся, метод (POST я полагаю), тип, кодировку и длину "тела запроса", потом собственно данные в виде "тела запроса". Как-то так, заголовки наверняка описаны в документации, но сложно навскидку найти 1 нужный абзац среди сотен страниц текста.

Отправлено спустя 59 минуты 54 секунды:
Цитата
Вот я сгенерировал PAS из WSDL.
Как-то это меня настораживает. Непохожие языки, как они перегенерятся? Да и вообще вроде XML должен на выходе программы получаться.
Цитата
Какие дальнейшие действия?
Надеюсь немного пролил свет - дальше настроить stunnel, сделать xml, подписать, коннектиться по http на stunnel, передать данные и получить ответ ГИС
Цитата
с какой целью они прислали сертификат обратно
Родилось безумное предположение, что ГИС не принимает сертификаты аккредитованных удостоверяющих центров и они перевыпустили сертификат на своем удостоверяющем центре. Совпадает ли издатель в исходном сертификате и полученном от них?
#64
0 0
Приветствую всех.
Шлю запросы по https с подписью.
Кратко опишу свой путь.
Использовал Delphi 7(лиценз.),
P12FromGostCSP для получения *.key (закрытый ключ для подписи).
SoapUI для получения и отладки запросов.
Статья на Хабре "Взаимодействие с ГИС ЖКХ с помощью stunnel и openssl по ГОСТу".
OpenSSL с гост, по ссылке той статьи.
Python + Eclipse для изучения алгоритма подписи.
Компоненты Indy поддерживают OpenSSL, т.о. защищенный канал "из коробки".
Каждый метод ГИСа, реализовал отдельным классом, с генерацией каноникализированного xml ручками. Для удобства наследовал от интерфейса.
Для подписи, по алгоритму статьи, написал класс для подписи, процедуры шифрования вызываю из dll, скачал заголовочный файл libeay32.pas, каноникализации в Delphi 7 нет, но т.к. запросы сами каноникализированы, то разобрался с namespace и всё, готов класс.
Парсинг ответных сообщений с помощью SimpleXML.pas, для логирования - LDSLogger.pas.
Задача с ГИСом пока фоновая, есть поважнее проекты.
КриптоПро не использую, это тот же самый OpenSSL + сервисные функции, и за деньги.
stunnel также не нужен использую Indy

Отправлено спустя 11 минуты 42 секунды:
Шифрование по ГОСТу (алгоритм)
[code:fs2tuymr]function SignGOST(const Data, KeyFN: string): string;
var
dlen: Integer;
slen: Cardinal;
md: pEVP_MD;
Key: pEVP_PKEY;
mdctx: pEVP_MD_CTX;
memout, Base64: pBIO;
b64Length: Integer;
outBuf: array[0..4095] of Char;
mdValue: array[0..EVP_MAX_MD_SIZE] of byte;
begin
dlen := Length(Data);
Key := ReadPrivateKey(KeyFN); // читаем файл закрытого ключа
slen := EVP_PKEY_size(Key); // определяем размер ключа
SetLength(Result, slen); // размер подписи будет таким же
md := EVP_get_digestbyname('md_gost94'); // получаем доступ к хэш-функции
New(mdctx); // формируем контекст подписи
EVP_SignInit(mdctx, md); // устанавливаем хэш-функцию, которая буддет использована
EVP_SignUpdate(mdctx, PChar(Data), dlen); // подписываем данные
EVP_SignFinal(mdctx, @mdValue, slen, Key); // завершаем формирование подписи
EVP_PKEY_free(Key); // освобождаем ресурсы
Dispose(mdctx);
// вывод в Base64
Base64 := BIO_new(BIO_f_base64); // BIO типа base64
memout := BIO_new(BIO_s_mem); // BIO в памяти для чтения-записи
Base64 := BIO_push(Base64, memout);
BIO_write(Base64, @mdValue, slen); // Пытается записать в Base64 sLen байт из буфера Result. Возвращает количество записанных байт
BIO_flush(Base64);
b64Length := BIO_read(memout, @outbuf, 4096);
outbuf[b64Length - 1] := #0;
Result := StrPas(@outbuf);
end;[/code:fs2tuymr]

Отправлено спустя 2 минуты 23 секунды:
Заголовок класса подписи
[code:fs2tuymr]unit Xades;

interface

//{$DEFINE TEST}

uses
Classes;

(*
Класс TXades подписывает XML,
пример:
x: TXades;
создание при указании файла ключа -> x := TXades.Create('C:\cert.key');
создание при передаче параметров -> x := TXades.Create(key, digest2, x509_issuer_name, x509_sn);
возврат текста подписанного XML -> mmo1.Text := x.GetSignXML(XML, SignedId);
*)

type
TXades = class
private
FItemXML: TStringList; // элементы сообщения
FBodyXML: TStringList; // тело сообщения
FSignXML: TStringList; // подписанный XML
FNameSpace: TStringList; // пространство имен
FSignedInfo: TStringList;// информация о подписи
Fsignature_id: string; // генерируются
Fsigned_id: string; // ID запроса, который указываем, как хотим и на который ориентируемся, подписывая запрос
Fdigest1: string; // Берётся содержимое тега <ns1:Body>), канонизируется алгоритмом C14N (exclusive=True), считается от неё хеш-сумма по ГОСТу и выводится в виде BASE64
Fdigest2: string; // Берётся сертификат в x509, декодируется из BASE64, считается от него хеш-сумма и вывод кодируется в BASE64
Fdigest3: string; // Формируется содержимое тега <xades:SignedProperties>, канонизируется алгоритмом C14N (exclusive=False) и от содержимого считается
Fsignature_value: string; // Формируется блок <ds:SignedInfo>, канонизируется алгоритмом C14N (exclusive=False), подписывается и кодируется в BASE64.
Fx590_cert: string; // x509 ключ из файла
Fsigning_time: string; // запоминается текущее время
Fx509_issuer_name: string; // Данные УЦ, выпустившего сертификат
Fx509_sn: string; // номер сертификата
Fkey: string; // имя и путь ключа
procedure GetDigest1(); // Вычисление Fdigest1
procedure GetDigest3(); // Вычисление Fdigest3
procedure LoadNameSpace(); // Поиск и загрузка пространства имен
procedure SetSignatureId(); // Генерация Id
procedure SetTextSignXML(); // Все полученные значения вносятся в шаблон XML-документа формата XAdES-BES
procedure Signature(); // Вычисление Fsignature_value
public
constructor Create(const key, digest2, x509_issuer_name, x509_sn: string); overload;
constructor Create(const Key: string); overload;
destructor Destroy; override;
function GetSignXML(const XML, SignedId: string): string;
{$IFDEF TEST}
function GetDigests(const XML, SignedId: string): string; // значения: Fdiges1, Fdiges2, Fdiges3
{$ENDIF}
end;

implementation[/code:fs2tuymr]

Отправлено спустя 2 минуты 14 секунды:
Один из классов для ГИСа
[code:fs2tuymr]{*------------------------------------------------------------------------------
Экспорт сведений об организациях
-------------------------------------------------------------------------------}

unit ExportOrgRegistry;

interface

uses
GIS_Interface;

type
TExportOrgRegistry = class(TInterfacedObject, IGIS)
private
FOGRN: string; /// ОГРН
FAsync: Boolean;
FDate: string;
FGUID: string;
FXML: string;
function Header(): string;
public
constructor Create(const orgPPAGUID, OGRN: string; Async: Boolean = False);
function Async(): Boolean;
function Command(): string;
function Date(): string;
function HeaderAction(): string;
function GetObject: TObject;
function GUID(): string;
function WebService(): string;
function XML(): string;
end;

implementation

uses
GIS_Query, GIS_Const;

{ TExportOrgRegistry }

function TExportOrgRegistry.Async: Boolean;
begin
Result := FAsync;
end;

function TExportOrgRegistry.Command: string;
begin
Result := 'exportOrgRegistry';
if FAsync then
Result := Result + '(Async)';
end;

constructor TExportOrgRegistry.Create(const orgPPAGUID, OGRN: string; Async: Boolean = False);
begin
FAsync := Async;
FOGRN := OGRN;
FDate := SetDate;
FGUID := SetGUID_Message(orgPPAGUID, metExportOrgRegistry);
FXML := Concat(Header(),
MakeXMLnode('soapenv:Body', '', BeginNode),
MakeXMLnode('org:exportOrgRegistryRequest', cVer_ExportOrgRegistry, '', BeginNode),
MakeXMLnode('org:SearchCriteria', '', BeginNode),
MakeXMLnode('org1:OGRN', FOGRN, FullNode),
MakeXMLnode('org:SearchCriteria', '', EndNode),
MakeXMLnode('org:exportOrgRegistryRequest', '', EndNode),
MakeXMLnode('soapenv:Body', '', EndNode),
MakeXMLnode('soapenv:Envelope', '', EndNode));
end;

function TExportOrgRegistry.Date: string;
begin
Result := FDate;
end;

function TExportOrgRegistry.GetObject: TObject;
begin
Result := Self;
end;

function TExportOrgRegistry.GUID: string;
begin
Result := FGUID;
end;

function TExportOrgRegistry.Header: string;
begin
Result := Concat(cHeader, cNS_ExportOrgRegistry, #10,
MakeXMLnode('soapenv:Header', '', BeginNode),
MakeXMLnode('base:ISRequestHeader', '', BeginNode),
FDate, #10, FGUID, #10,
MakeXMLnode('base:ISRequestHeader', '', EndNode),
MakeXMLnode('soapenv:Header', '', EndNode));
end;

function TExportOrgRegistry.HeaderAction: string;
begin
Result := '"urn:exportOrgRegistry"';
end;

function TExportOrgRegistry.WebService: string;
begin
Result := 'ext-bus-org-registry-common-service/services/OrgRegistryCommon';
if FAsync then
Result := Result + 'Async';
end;

function TExportOrgRegistry.XML: string;
begin
Result := FXML;
end;

end.
[/code:fs2tuymr]

Отправлено спустя 8 минуты 58 секунды:
Важно! Загрузка ГОСТа из dll (последняя строка)
[code:fs2tuymr](*
инициализация библиотеки
*)
procedure LoadSSL;
begin
OpenSSL_add_all_algorithms;
OpenSSL_add_all_ciphers;
OpenSSL_add_all_digests;
ERR_load_crypto_strings;
ERR_load_RSA_strings;
// используется имя файла, указанное в OPENSSL_CONF
OPENSSL_config(PChar(GetDOSEnvVar('OPENSSL_CONF')));
end;
[/code:fs2tuymr]

Отправлено спустя 14 минуты 20 секунды:
Из ИндиЛога заголовок запроса на https (по http похожий):
POST /ext-bus-org-registry-common-service/services/OrgRegistryCommon HTTP/1.0
Content-Type: text/xml; charset=UTF-8
Content-Length: 6333
SOAPAction: "urn:exportOrgRegistry"
Authorization: Basic c2l0OnJaX0dHNzJYU15WZjU1Wlc=
X-Client-Cert-Fingerprint: cb.... (тут мой отпечаток серт.)
Host: 217.107.108.156:10081
Accept: text/html, */*
Accept-Encoding: gzip,deflate, identity
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)


Отправлено спустя 5 минуты 19 секунды:
Для изучения шифрования по ГОСТу помогло изучение "Библиотека libcrypto.Руководство программиста" от КриптоКома.
Всех с наступающим 23 февраля, вспомним как служили!
#65
0 0
Ура, еще немного и пряморукие люди смогут настроить обмен данными.
#66
0 0
Цитата
RatWar пишет:
Компоненты Indy поддерживают OpenSSL, т.о. защищенный канал "из коробки".
Огромное спасибо! Все замечательно, разве что КриптоПро остался не при делах, а OpenSSL везде или относительно устаревший в котором есть ошибки или не сертифицированный. Ну отдельный класс для каждого отчета править после смен версий ГИС это немного чересчур.

Вставлю 5 копеек о соединении криптопро и OpenSSL, тогда отпадет необходимость в P12FromGostCSP (у меня она вообще вытаскивает непонятно что, пришлось конвертировать через privkey).
1) Как я понял OpenSSL умеет ключ и из памяти брать, так что можно считать закрытый ключ из хранилища сертификатов стандартным криптопровайдером, потом передать OpenSSL.
2) стандартную gost.dll из OpenSSL можно без особых потерь заменить в конфиге на криптопрошную gost_capi.dll (нужно только закомментировать выбор параметров A (кстати у нас все ключи на параметрах exA, так что наверно так правильнее )) и тогда можно из OpenSSL работать с ключами в контейнерах криптопро.
#67
0 0
ГОСПОДИ! Откуда Вы все это знаете?
#68
0 0
OpenSSL не сертифицирован это да, насчет устаревания, всегда можно скачать свежую версию и собрать.
КриптоПро использует ту же OpenSSL, сертифицирует и продает, у них то как раз версия будет устаревшая, т.к. на сертификацию требуется время.
Для подписи ключ не нужен, нужны лишь его параметры, которые можно один раз получить и хранить например, в ini-файле. Для IdSSLIOHandlerSocketOpenSSL нужны ключи, в формате *.key и *.pem

Отправлено спустя 3 минуты 2 секунды:
В заголовке класса подписи видно, что у меня реализовано 2 конструктора, с параметрами и с чтением ключа

Отправлено спустя 1 минуту 51 секунды:
Цитата
Programmer пишет:
ГОСПОДИ! Откуда Вы все это знаете?
Опыт сын ошибок трудных...
#69
0 0
Цитата
two_oceans пишет:
Ну отдельный класс для каждого отчета править после смен версий ГИС это немного чересчур.
В примере класса можно увидеть, что сама версия ГИС обозначается константой cVer_xxx..., константы эти собраны в отдельном файле. Ну если метод измениться, то придется корректировать класс. На каждый метод свой класс, в главном классе вызов методов класса идет по интерфейсной переменой, что упрощает управление памятью и не трогает основную логику.
#70
0 0
Цитата
Programmer пишет:
... так как с XLSX запарился работать.
Цитата
Programmer пишет:
ГОСПОДИ! Откуда Вы все это знаете?
Вам всё еще кажется трудной работа с ёксель-файлом ?
#71
0 0
Цитата
Дамир пишет:
Вам всё еще кажется трудной работа с ёксель-файлом ?

Трудности с Ёксель преодолел - "рисую" их программным методом. Не нравится загружать их.
#72
0 0
Цитата
КриптоПро использует ту же OpenSSL
вот как раз про само ядро криптопро что-то не замечал следов использования openssl, слишком уж разное хранение контейнера закрытого ключа (не думаю, что кто-то стырит чужой код и решит абсолютно новый контейнер изобрести) - это то, что собственно продается. Хотя stunnel однозначно из OpenSSL подправили и переходник к OpenSSL естественно не построить без исходников OpenSSL - но эти добавки или бесплатны или используют основную лицензию.
С остальными криптопровайдерами вроде магпро, сигнал ком и компании полностью согласен. В демо магпро версия 1.0.1с, в то время как в мае прошлого года уже была в сети скомпиленная 1.0.2h. Собрать поновее все никак не соберусь - лениво с компиляторов Си возиться ради одной проги.
Цитата
Для подписи ключ не нужен, нужны лишь его параметры, которые можно один раз получить и хранить например, в ini-файле.
Так, стоп. Что-то я не понял, наверно терминология отличается. По идее для вычисления хеша не нужен закрытый ключ, но для вычисления SignatureValue закрытый ключ потребуется. Не говорите мне что закодировали в строку pem и сохранили в ini файл. Если же там только параметры, то в них наверняка указан путь к ключу и он достается неявно. С другой стороны, сертификат (содержащий открытый ключ) можно хранить хоть как и он потребуется при сборке тега Signature.
Цитата
На каждый метод свой класс, в главном классе вызов методов класса идет по интерфейсной переменой, что упрощает управление памятью и не трогает основную логику.
Интересный подход, я больше склоняюсь к другому - хранить список нужных для версии данных и форматов, потом передавать в некий универсальный класс-построитель эти списки и сами значения данных. Выгода в том, что изменить список гораздо проще чем каждый раз переписывать логику, а недостаток в том, что работать будет медленнее, так как на анализ списка потребуется дополнительное время. Но в общем это тесно завязано с выборкой данных из самой ИС, так что дело автора ИС, что выбрать.
Цитата
Вам всё еще кажется трудной работа с ёксель-файлом ?
Прошу заметить, что тут еще ненавязчиво выкинули приведение к каноническому виду (дескать наша вручную высеченная ИС сразу дает канонический вид). А если писать с нуля процентов 60 всей работы это как раз написать полностью соответствующий стандарту каноникализатор. Серьезно, почитал стандарт приведения к каноничному виду, в XML открылись такие возможности о которых я даже не подозревал и вряд ли кто в своем уме их вообще использует, но тем не менее их надо поддерживать при приведении. :)
#73
0 0
Цитата
two_oceans пишет:
По идее для вычисления хеша не нужен закрытый ключ, но для вычисления SignatureValue закрытый ключ потребуется.
Да, один раз вычисляю дайджест и сохраняю его. Если сертификат не меняется, то дайджест тоже не меняется. Потому то в дальнейшем не нужен *.key.
Fdigest2: string; // Берётся сертификат в x509, декодируется из BASE64, считается от него хеш-сумма и вывод кодируется в BASE64
#74
0 0
Ясно, все же про разное говорим. Дайджест(он же хэш, хеш) от сертификата сохраняется, но говорю не про него, так как он в идеале вообще никак с закрытым ключом не пересекается.
Видимо у Вас ключевая пара после переведения в .p12 затем в .key осталась в одном файле и поэтому возникла путаница, где открытый ключ, а где закрытый ключ - так как в данном случае они в одном и том же файле.
Но при вычислении содержимого тега SignatureValue откуда-то же берется нужный закрытый ключ?

Отправлено спустя 2 минуты 21 секунды:
я вообще расширение .key стараюсь не использовать - редактор реестра на него срабатывает, что несколько раздражает. А на .pem настроил блокнот - удобно смотреть что в файле содержится.

Отправлено спустя 36 минуты 45 секунды:
Цитата
ГОСПОДИ! Откуда Вы все это знаете?
Полагаю, немного приберусь в файлах и выложу подборку статей по которым все изучал на общедоступный сайт. Сейчас они у меня сохранены на локальном сайте - на случай если исходная удалится. Подчищаю рекламу, посторонние функции и читать становится легче (особенно статьи с хабра - на самом хабре и реклама и куча других отвлекающих статей). Однако локальный сайт на обычной (не серверной) Windows поэтому нормально просмотреть извне не получится.
Для начала cтатья про SSL/TLS, сертификаты, УЦ, ключи, форматы PEM и DER, различия открытых-закрытых ключей. Программистам прочитать однозначно советую, чтобы не выглядеть дубом при обсуждении сертификатов. Сайт вообще про службы каталогов, но статья достаточно полно освещает тему сертификатов. Проблема в том, что информации там слишком много и в том числе напрямую не относящейся к "нашим баранам". Поэтому "не-программистам" будет крайне скучно. Если начнете на уровне новичка, то вряд ли дочитаете все за первый раз. По мере надобности не раз еще вернетесь. Ну хотя бы как словарик используйте.
#75
0 0
Цитата
Programmer пишет:
Цитата
Дамир пишет:
Вам всё еще кажется трудной работа с ёксель-файлом ?
Трудности с Ёксель преодолел - "рисую" их программным методом. Не нравится загружать их.
От ГИС-овцев всего-то требуется дать возможность автоматизировать загрузку/выгрузку ёкселевских файлов.
Т.е. некий сервис (почта, ftp, да тот же соап - загружают же они сканы документов).
нет жеж... соап для каждой операции с уникальным форматом xml-данных на вход/выход.
С этого вся ветка началась - 'нафига этот соап, автоматизируйте обмен ёксель-файлами'
#76
0 0
Цитата
Дамир пишет:
От ГИС-овцев всего-то требуется дать возможность автоматизировать загрузку/выгрузку ёкселевских файлов.

Было бы здорово. Надо, например,отправить почтой файл abc.xlsx, копируешь электронную подпись в файл abc.key, и отправляешь оба файла автоматом: abc.xlsx и abc.key.
#77
0 0
Цитата
Programmer пишет:
Надо, например,отправить почтой файл abc.xlsx
Насчет конкретно почты идея не очень удачная. Я как-то разбирался можно ли отправлять данные между подразделениями с ЭП и оказалось не так все просто.
1) По идее как канал шифруется так надо будет и отправляемые почтой файлы зашифровать. Просто шифрование канала от клиента до сервера не решит проблему, так как обычная почта соединяется со своим сервером, а не с Гисовским и тогда данные будут не зашищены между серверами. Либо надо создавать каждому пользователю учетку на гисовском почтовом сервере - тогда шифрования канала достаточно.
Шифрование файлов (как и подписание) можно сделать какой-то программой (консольной командой openssl или КриптоАрм) до отправки либо самим почтовым клиентом.
Если шифровать почтовыми клиентами, то там в сертификате ЭП должны быть строго определенные поля - назначение сертификата keyUsage (цифровая подпись, шифрование данных) и расширенное использование ключа extended key Usage(Защита электронной почты) плюс к тому адрес почты в сертификате должен совпадать с адресом с которым отправляется почта. А если шифровать по ГОСТ, то нужно еще поле "возможности SMIME" с указанием алгоритма ГОСТ. Про наличие криптопровайдера не говорю - почтовые программы в основном поддерживают openssl, но там придется морочиться с преобразование ключа.Это реальная головная боль - на текущий момент у нас всего 2 сертификата в которых есть шифрование данных. Почтовые адреса тоже указаны наобум. И уж точно ни в одном действующем сертификате нет ничего про возможности SMIME. (Нашлись сертификаты 2012 года с этими возможностями и после перевода времени в 2012 год почтовик TheBat! согласился их использовать, но по факту они истекли, так что реально использовать не выйдет).2) Все передаваемые по почте данные кодируются в base64, что повышает размер на 30-40%. А шифрование не даст эффективно сжать. Представляете какой ГИС надо иметь почтовый ящик чтобы письма со всей страны его не переполняли.
3) такой единый ящик наверняка засветится (на форумах вроде этого) и будет получать тонны спама. Значит будет спам-фильтр - значит будут срезаться и почта с данными.
С FTP идея получше, но это тоже сводится к созданию учетки для каждого пользователя и chroot. Иначе будут затираться файлы у всех кто "креативно" назвал файл abc.xml или 111.xml. Но можно называть файл через guid. Из плюсов - можно результат выкладывать тоже на FTP. Минусы - FTP относительно медленный протокол (из-за кучи служебных команд) и съедает кириллицу в названиях файлов (это можно обойти если подобрать совместимые клиент и сервер, но лучше кириллицу вообще избегать при работе с FTP), файл с данными испортится если передать в текстовом режиме (обычно можно настроить автопереключение на двоичный режим при передаче файлов), дата изменения по FTP передается крайне безобразно (часто округленно до суток или часов).
Еще есть примерно той же с FTP направленности WebDAV (дополнительное расширение протокола HTTP для изменения файлов на сервере) - тоже создание учетки для каждого пользователя и chroot. Но поудобнее чем FTP в плане кириллицы, передачи времени, выбора режима и есть встроенная поддержка от Windows - можно подключить как сетевой диск. Просто скопировал файл и подпись в папку приема на сетевом диске и ждешь результата в папке результатов. Большинство программ прекрасно работают с сетевыми дисками (пока только cmd и dism на удивление отказались). FTP тоже можно подключить как сетевой диск, но придется залезть вглубь настроек системы - "из коробки" принимаются имена локальной сети. Для сервера поудобнее тем, что папка с результатами может находиться на совершенно другом сервере чем папка для приема данных, но клиент не этого даже заметит. Так что я бы скорее предпочел этот вариант.
С SOAP идея тоже хороша - если и данные и подпись как отдельные вложения в унифицированном SOAP конверте с указанием id шаблона, но без использования xmldsign на SOAP. Все эти способы могут работать через настроенный по сегодняшним требованиям защищенный канал.
Цитата
Programmer пишет:
копируешь электронную подпись в файл abc.key
Все же .key расширение для ключей (в *nix) и называть так файл подписи не очень хорошо. Важно их не путать - ключ один и тот же на все время действия сертификата (и закрытый и открытый), а подпись создается для каждого файла данных отдельно. Общепринято отсоединенный файл подписи называть как .sig или .p7s, то есть если файл c данными назывался abc.xlsx , то автоматическое средство проверки в первую очередь будет искать его подпись в abc.xlsx.sig или abc.xlsx.p7s
#78
0 0
Цитата
two_oceans пишет:

С SOAP идея еще лучше - если и данные и подпись как отдельные вложения в унифицированном SOAP конверте с указанием id шаблона, но без использования xmldsign на SOAP.
id шаблона содержится внутри самого ёксель-файла на скрытой вкладке CONF.
Итого в остатке: от ГИСовцев нужна программа-транспорт (по соап, с шифрацией и прочей только им нужной фигней), которая будет забирать из указанного каталога ёксель-файлы и выгружать в указанный каталог ёксель-файлы.
фсё! Пользователю телевизора не нужно знание принципа работы полевого транзистора.
#79
0 0
Цитата
Дамир пишет:
Пользователю телевизора не нужно знание принципа работы полевого транзистора.
Дописал про WebDAV - там даже отдельную программу не надо. Настроил stunnel (можно собрать архивчик, достающий ключ из системы, останется только сертификат воткнуть и его прописать), подключил сетевой диск и вперед.
#80
0 0
Цитата
two_oceans пишет:
... подключил сетевой диск и вперед.
А как бы мысль до ГИСовцев донести ?
чтоб работать могли все, а не только с 10 годами опыта веб-программирования.
#81
0 0
Цитата
Дамир пишет:
А как бы мысль до ГИСовцев донести ?

А гис - ОВЦАМ по фигу. Они сами себе на уме.
#82
0 0
Цитата
Дамир пишет:
чтоб работать могли все, а не только с 10 годами опыта веб-программирования

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

Я занимаюсь программированием неполных 25 лет.
За это время изучил и использовал на практике несколько языков программирования. Свой выбор 10 лет назад остановил на Pascal, разработкой занимаюсь в Delphi, в основном - коммунальные платежи, несколько программ для АСУ (Pascal и Assebler).
За все это время в области интернет - технологий достиг немногого, только то, что требовалось по работе:
отправка и получение SMS;
отправка и получение почты с вложениями;
отслеживание изменений на сайте;
обмен по FTP.
Вдруг откуда ни возьмись появились ГИС и ИС.
Разработал заполнение шаблонов, но в процессе их выгрузки понял, что нужно осваивать SOAP, но мои знания в этой области на нуле, если не ниже. И вот, благодаря таким асам как two_oceans, AlcorVol и RatWar (может быть еще какой-нибудь ас объявится), появилась надежда в освоении этого зверя. Надеюсь, коллеги меня поймут.
#83
0 0
Спасибо большое за лестный отзыв. Сам себя к асам наверно относить не стану, хватаю всего помаленьку, но постепенно кое-что накапливается. За неполных 20 лет программирования еще ни одной крупной программы, зато куча мелких или одноразовых. На наш отдел сваливают все что что хоть как-то с компьютерами связано, за месяц более 100-200 разных обращений от мелких "мышка не бегает", "картридж нужно заправить", перезагрузить 1С, опубликовать новость на сайте, переустановить Windows до таких необъятных как взаимодействие по соап с разными ФГИС. С ЭП впервые столкнулся лет 6 назад, наблюдал за действиями коллеги. 3 года как занимаюсь ЭП вплотную. Openssl, разбор сертификатов на байты, собственный УЦ на openssl уже около года в работе, а соап и ГИС месяца 4. Короче интересов много, на все времени не хватает, тем более что очень часто отвлекают не по делу, весь январь доставали с отчетами.
Из февральского - в 2005 и 2015 году были приняты законы по концессионных соглашениям в сфере ЖКХ, в начале февраля внезапно в ГАС "Управление" сделали возможность заполнения информации по ним и дали сроку до... 22 февраля. Прям зло берет - сами делали пару лет, а нам дали 20 дней. Причем возможность загружать xls файлы включили за 5 дней до срока. Пришлось все бросать и набивать вручную данные, о которых мы вообще как-то без понятия - реальные или красивая сказка на бумаге. На получение реальных нужно немало времени, так что скорее второе.В свою очередь мне было бы интересно узнать про SMS (для внутреннего сайта приема обращений от коллег) и почту (теоретические наметки есть, даже свой мини клиент-сервер POP3 когда-то писал, больше интересно как не спамить сообщениями и про вложения).

Отправлено спустя 19 минуты 3 секунды:
Очень надеюсь, что все же доведем совместными усилиями СОАП до ума. Пока для себя все представляю в том же ключе - модуль генерации соап, модуль подписания XML-DSIGN, модуль отправки, модуль обмена настроек генерации через сайт, модуль анализа шаблонов, типовой сайт обмена настроек. Естественно, еще куча "подмодулей" и возможность выбора криптоядра. Про обмен настройками я тут подробно еще не расписывал, но есть "альфа версия" описания в Word.
Возможно, имеет смысл вообще начать осваивать git и создать проект на github для совместной работы. Если конечно коллеги согласятся объединить усилия хотя средства разработки у всех отличаются. На форуме выкладывать несколько неудобно, но очевидно, что чем больше глаз будет наблюдать, тем проще выловить потенциальные ошибки и улучшить код.
#84
0 0
Цитата
Programmer пишет:
И вот, благодаря таким асам как two_oceans, AlcorVol и RatWar
Хотя мой программистский стаж и приближается потихоньку к 40 годам, сам себя в "асы" записывать не стал бы. :) Осваиваю только то, что жизненно необходимо. А вот two_oceans - это просто джип-универсал! :) Нет такой программистской области, где он не разбирался бы на уровне хорошего спеца. Балдею просто!
#85
0 0
Может быть не по теме,
но для тех, кто интересуется отправкой писем
с вложениями, выкладываю рабочую демо (Delphi).
Внутри архива файл READ.ME, прочтите.
#86
0 0
Цитата
Programmer пишет:
Может быть не по теме,
но для тех, кто интересуется отправкой писем
с вложениями, выкладываю рабочую демо (Delphi).
Внутри архива файл READ.ME, прочтите.
Что это? Выглядит, как вирусы для ГИСа :)
#87
0 0
Это не вирусы, а часть моей программы для рассылки отчетов для председателей ТСЖ, адаптированная под демо.
#88
0 0
Цитата
Programmer пишет:
Может быть не по теме,
но для тех, кто интересуется отправкой писем
с вложениями, выкладываю рабочую демо (Delphi)
Спасибо, но у меня эта задача давно уже решена - по-своему. ;) FoxPro позволяет вызывать командой RUN любые консольные приложения. Откопал в Интернете простенькую консольную утилиту blat, позволяющую отправлять email'ы по протоколу SMTP через почтовые сервера (вроде mail.ru или gmail.com). Но сия программа использует фиксированные адреса портов, давно устаревшие. Пришлось освоить и программу stunnel, позволяющую делать переадресацию портов. В итоге - могу посылать клиентам ПД, а также любые другие документы, так как всякие attachments этот blat прекрасно отрабатывает. Если кому-то интересно, могу и более подробной информацией поделиться.
#89
0 0
Цитата
Не успеешь глазом моргнуть как наступит ответственность...
Спасибо. Классный текст сообщения, однако. Судя по тому, что я вижу в папке synapse... там уже половина исходников для соап есть. DLL ки правда 10+ летней давности. А еще по названию синапс припомнился фильм "Опасная правда".
Цитата
AlcorVol пишет:
FoxPro позволяет вызывать командой RUN любые консольные приложения.
На PHP принцип такой же и куча консольных программ отправки, правда большинство для Linux. Еще я как-то пробовал отправлять через Яндекс себе от своего домена, на котором не установлено ограничений с каких адресов почта допустима через программу Kerio Mail Server. Обычно Яндекс без своей авторизации от клиента письма не принимает. Как ни удивительно, оказалось что если другой почтовый сервер в заголовках письма пишет "авторизация пройдена, зуб даю", Яндекс дает отправить через себя 1 письмо в 15 минут с левым адресом. Естественно если авторизоваться нормально, то можно побольше и почаще, но только от своих адресов.
А поводу ограничения спама есть какие-то задумки? Допустим, прикручу отправку письма (или смс) к добавлению заявки на сайте, но это же будет ужас если на каждую заявку письмо. Думал сделать планировщиком (раз в 3 часа, например) проверять есть ли заявки и высылать письмо, но так потеряется оперативность первой заявки (допустим в 9-05 отработает и ничего не обнаружит, а кто-то заявку сделает в 9-06 и три часа провисит).
К слову, отправка смс, Android и мобильные приложения - пример области, в которой я только смутно разбираюсь - что наверно надо что-то как-то отправить на смс-шлюз, но без понятия что, как и где шлюз брать, с Ростелекомом договариваться наверно? и что можно мобильное приложение самому написать и скидывать на телефон вручную, не через магазин. Все. Наверно еще можно установить дешевый тарифный план на телефон, подключить к компьютеру и отправлять смс через телефон, но как это сделать программно - не в курсе.
#90
0 0
Цитата
two_oceans пишет:
Обычно Яндекс без своей авторизации от клиента письма не принимает.
Ну, и на mail.ru мне тоже пришлось завести специальный "служебный" аккаунт. От его имени и посылаю всё. Можно было и gmail.com использовать, но там все мессаджи в папку "Отправленные" складируются. :) А мне совсем не хотелось ни следов оставлять, ни дисковое пространство переполнять. :) В этом смысле - mail.ru меня устроил полностью. Никаких ограничений на частоту отправок не обнаружил. Всё сразу обрабатывает, ни на что не жалуется.
Цитата
two_oceans пишет:
А поводу ограничения спама есть какие-то задумки?
Не совсем понял вопрос. Моя программа посылает что-то только явно, по запросу "оператора". Никаких автоматических рассылок нет. Если клиент позвонит и попросит отправить ему ПД - то оператор (бухгалтер) пошлёт. Никто ещё не позволил оставлять жильца без бумажного документа. А если вдруг потеряется - то пожалуйста, можно и через SMTP продублировать.
Цитата
two_oceans пишет:
К слову, отправка смс, Android и мобильные приложения - пример области, в которой я только смутно разбираюсь
С ума сойти! Нашлась-таки такая область, где ты не очень хорошо разбираешься. :D Но я-то - ещё меньше! :D
Сейчас на форуме: 7 пользователей
7 пользователей сейчас на форуме

Подпишись на рассылку новостей ЖКХ, а также наших статей!

Спасибо, вы успешно подписались на рассылку!