Русский
Русский
English
Статистика
Реклама

Rfc

Памятка для удостоверяющих центров и других участников PKI

26.04.2021 14:21:23 | Автор: admin

Памятка для удостоверяющих центров и других участников PKI

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

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

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

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

В этом посте я хочу рассказать, с какими критическими проблемами и нарушениями в работе УЦ часто приходится сталкиваться, а также о том, как их избежать.

У полноправного участника Public Key Infrastructure, должна быть информационная система со встроенными СКЗИ, которая позволяет вести электронный документооборот с клиентами и партнерами, обмениваясь с ними документами с электронной подписью (ЭП) или зашифрованными данными.

Когда партнер присылает документы с ЭП, система выполняет ряд действий. Она проверяет электронную подпись на документе и партнерский сертификат открытого ключа проверки этой подписи.

В частности, для сертификата партнера строится путь сертификации - цепочка сертификатов, от его конечного пользовательского, на котором проверилась ЭП, до корневого центра сертификации.

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

Для квалифицированных сертификатов также выполняются проверки согласно 63-ФЗ Об электронной подписи и Приказа ФСБ РФ 795. Контролируется наличие и правильность заполнения всех необходимых атрибутов в сертификате пользователя.

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

Сбои и некорректная работа УЦ в части публикации CRL

В сертификатах есть атрибут CDP - CRL Distribution Points, в нем УЦ публикует ссылки на свой список отозванных сертификатов - Certificate Revocation List

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

CRL тоже подписан ЭП удостоверяющего центра, что дает дополнительную защиту от подмены и атак посредника Man in the middle при его загрузке по открытому каналу. Он содержит атрибуты с периодом своего действия и серийные номера отозванных сертификатов.

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

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

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

То же самое касается контроля клиентских и серверных сертификатов, которые используются для построения защищенного канала связи TLS ГОСТ или TLS RSA по протоколу HTTPS. Если системам партнеров не удается проверить их на отзыв, то защищенное и 100% доверенное соединение партнеры установить между собой не смогут.

Какие сбои и нарушения здесь может допустить УЦ?

1. Перенаправление ссылок (Redirect)

УЦ опубликовал в сертификате конкретный URL, но на сервере, где этот ресурс опубликован, происходит перенаправление клиента на другой URL.

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

private static final String ATTENTION_CRL_REDIRECT_DETECTED = "Attention CRL redirect detected: ";    private static final String LOCATION = "Location";   URL url = new URL(crlURL);        InputStream crlStream = null;        URLConnection connection = url.openConnection();        String redirect = connection.getHeaderField(LOCATION);        if (redirect != null) {            throw new DownloadCRLException(                    ATTENTION_CRL_REDIRECT_DETECTED + crlURL + STRING_DIRECTION + redirect);        }

2. HTTPS в CDP атрибуте сертификата и ни одной общедоступной ссылки

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

Попадались сертификаты с https://, ldap:// или защищенный SFTP, также были просто URL с IP адресами из внутренней подсети. Все эти ссылки допустимы при наличии хотя бы одной ссылки HTTP или FTP (без логина и пароля) доступной из сети Internet всем.

Почему HTTPS к свободным не относится?

За списками отзыва могут обращаться далеко не только интернет-браузеры, имеющие обширное хранилище корневых доверенных сертификатов международных УЦ, которое позволяет им поднимать защищенное соединение по HTTPS-ссылке и принимать ресурс как доверенный.

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

Просто невозможно во все системы установить все корни для всего многообразия УЦ, выпускающих SSL/TLS-сертификаты.

По понятным причинам информационные системы также не могут знать логин и пароль от FTP и не будут иметь доступ к внутренней службе Active Directory по LDAP-протоколу.

Поэтому принято, что CRL публикуется в свободном доступе.

3. HTTP перенаправление (redirect) на HTTPS

Это гибридная ситуация, с которой приходилось сталкиваться, состоящая из приведенных выше пунктов 1 и 2.

Как такое возможно?

Сайт компании, где УЦ публикует свои списки отзыва, или просто веб-сервер, который используется удостоверяющим центром для этих целей, запущен, например, на Nginx.

Администратор сайта, желающий исключительно добра и защитить сайт и пользователей, совершенно забыв, а может, и не зная про публикацию CRL, включает безусловный redirect всего сайта на HTTPS.

server {    listen 80 default_server;    listen [::]:80 default_server;    server_name _;    return 301 https://$host$request_uri;}

Получается, что в сертификате приведен URL с http://, а системы, которые чувствительны к такому факту подмены подписанной информации из сертификата и справедливо защищаются от атак посредников, перестают загружать списки отзыва данного УЦ, пока администратор не настроит на сайте исключения для CRL.

4. Фильтрация по User Agent

Данная проблема и нарушение доступа к спискам отзыва сильно перекликается с приведенной в пункте 3.

Тот же администратор сайта, на том же Nginx включает фильтрацию по User Agent. Например, все системы на Java будут получать ошибку HTTP 403 при обращении к ресурсу.

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

if ($http_user_agent = "Mozilla/5.0 (Linux; Android 4.2.2; SGH-M919 Build/JDQ39) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.169 Mobile Safari/537.22"){    return 403;}if  ($http_user_agent ~* "^Java"){ return 403; }

Еще администратор сайта, где публикуются списки отзыва, может включить redirect на основе User Agent.

5. Просроченный CRL

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

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

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

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

Были случаи, когда по каким-то причинам УЦ своевременно не обновлял CRL.

Список отзыва с истекшим сроком действия, естественно, не принимается. И если для сертификата нет или не удается загрузить по другим ссылкам действующий список, то общий результат будет отрицательным, а документ с ЭП отвергнут.

6. Сбои на сетевом и транспортном уровне

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

В сертификате, выпущенном УЦ, может быть прописано два URL с http:// и разными host именами. Такой подход правильный, он позволяет иметь резерв и всегда держать одну ссылку в доступе, если требуется провести какие-то работы на другом сервере.

Но вот незадача. Вызывающая система вдруг начинает получать IOException: ConnectionTimeOut при попытке подключения к одной из ссылок. Вторая ссылка при этом работает и отдает CRL. А вызывающая система все равно начинает замедляться на настроенное в ней время, например, ConnectionTimeOut=15000 mSec, потому что проверяет обе ссылки, и ей приходится ждать ответа от недоступной в настоящий момент.

А если в CDP сертификата четыре, пять разных ссылок на CRL и при этом две или три из них оказываются недоступны с ConnectionTimeOut?

В этом случае время проверки сертификата возрастает до неприличной величины, равной времени таймаута, умноженному на количество таких ссылок.

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

Получается коллизия.

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

Почему может происходить ConnectionTimeOut?

Как вариант, это регламентные работы, сетевая атака или повышенная нагрузка на сайт УЦ, что привело к неконсистентному состоянию:

  • какой-то брандмауэр, файрвол на пути, который просто начал съедать сетевые пакеты, не сообщая отправителю такие вещи, как "No Route to host"

  • началась потеря пакетов из-за неправильной конфигурации сети или перегрузки линии

  • слишком много запросов, перегружающих сервер

  • небольшое количество одновременно доступных потоков / процессов на сервере, что приводит к их блокировке. Это происходит особенно с запросами, выполнение которых занимает много времени и может сочетаться с предыдущим пунктом

Как с этим справляться?

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

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

Если точка публикации будет корректно отключена, то вызывающая система, мгновенно получив от этой ссылки, например, IOException Connection Refused: connect, сразу перейдет к загрузке по следующему URL.

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

Чем должны руководствоваться УЦ при публикации CRL

RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

Спецификацией RFC 5280 IETF и стандартом X.509 ITU-T, разработанными Инженерным советом Интернета и Международным консультационным комитетом по телефонии и телеграфии.

В частности, пунктом 8. Security Considerations из RFC 5280

When certificates include a cRLDistributionPoints extension with an https URI or similar scheme, circular dependencies can be introduced. The relying party is forced to perform an additional path validation in order to obtain the CRL required to complete the initial path validation! Circular conditions can also be created with an https URI (or similar scheme) in the authorityInfoAccess or subjectInfoAccess extensions. At worst, this situation can create unresolvable dependencies.

CAs SHOULD NOT include URIs that specify https, ldaps, or similar schemes in extensions. CAs that include an https URI in one of these extensions MUST ensure that the server's certificate can be validated without using the information that is pointed to by the URI. Relying parties that choose to validate the server's certificate when obtaining information pointed to by an https URI in the cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess extensions MUST be prepared for the possibility that this will result in unbounded recursion.

УЦ не должны включать HTTPS или LDAP-ссылки для публикации своих списков отзыва.

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

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

Другими словами, клиент и сервер будут пытаться поднять защищенное HTTPS-соединение друг с другом. Для этого им потребуется проверить сертификаты на отзыв. А чтобы это сделать, тоже нужно поднять защищенное соединение по HTTPS-ссылке к CRL, которую УЦ неосмотрительно опубликовал в атрибуте сертификата.

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

Протокол онлайн-проверки статуса сертификата OCSP - Online Certificate Status Protocol.

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

А для работы с сервером OCSP они должны включать еще и расширение OCSP Server Client.

Но это материал для отдельнойстатьи.

Обязательные атрибуты квалифицированных сертификатов

Состав квалифицированного сертификата регулируется Федеральным законом "Об электронной подписи" от 06.04.2011 N 63-ФЗ и Приказом ФСБ РФ от 27 декабря 2011 г. N 795 "Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи".

Несколько раз встречались квалифицированные сертификаты проверки подписи юридических лиц, выпущенные аккредитованным УЦ, в которых в поле Subject - субъект сертификации отсутствовал атрибут L Местоположение.

Контроль квалифицированных сертификатов нашей системы отвергал данный сертификат и документы с ЭП партнера.

Удостоверяющий центр данную ситуацию комментировал так:

атрибут L для юридических лиц, зарегистрированных в г. Москве, не проставляется согласно 63-ФЗ и Приказа 795

На конкретный пункты Закона и Приказа в УЦ не ссылались.

Собственный повторный анализ юридических аспектов показал:

63-ФЗ от 06.04.2011 "Об электронной подписи"

Статья 14. Сертификат ключа проверки электронной подписи

2. Сертификат ключа проверки электронной подписи должен содержать следующую информацию:

2) фамилия, имя и отчество (если имеется) - для физических лиц, наименование и место нахождения - для юридических лиц или иная информация, позволяющая идентифицировать владельца сертификата ключа проверки электронной подписи;

Статья 17. Квалифицированный сертификат

2. Квалифицированный сертификат должен содержать следующую информацию:

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

Приказ ФСБ РФ от 27 декабря 2011 г. 795

III. Требования к порядку расположения полей квалифицированного сертификата

5) stateOrProvinceName (наименование штата или области).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование соответствующего субъекта Российской Федерации. Объектный идентификатор типа атрибута stateOrProvinceName имеет вид 2.5.4.8;

6) localityName (наименование населенного пункта).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование соответствующего населенного пункта. Объектный идентификатор типа атрибута localityName имеет вид 2.5.4.7;

7) streetAddress (название улицы, номер дома).

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

В сертификате партнера в имени субъекта сертификации были указаны: stateOrProvinceName (наименование штата или области), streetAddress (название улицы, номер дома).

И не указано localityName (наименование населенного пункта).

locality - Местонахождение

В Законе 63-ФЗ и Приказе 795 нет информации, что для города Москва не нужно заполнять атрибут locality - Местонахождение.

Наоборот в обоих документах на русском языке применяется термин место нахождения, чему соответствует атрибут localityName ( 2.5.4.7)

После данного разбора удалось найти документ ФСБ РФ ИЗВЕЩЕНИЕ ОБ ИСПОЛЬЗОВАНИИ АТРИБУТА ИМЕНИ LOCALITYNAME ПОЛЯ SUBJECT В СТРУКТУРЕ КВАЛИФИЦИРОВАННОГО СЕРТИФИКАТА КЛЮЧА ПРОВЕРКИ ЭЛЕКТРОННОЙ ПОДПИСИ

Согласно части 2.2 статьи 18 Закона об ЭП для заполнения квалифицированного сертификата в соответствии с частью 2 статьи 17 Закона об ЭП аккредитованный удостоверяющий центр запрашивает и получает из государственных информационных ресурсов, в том числе, выписку из единого государственного реестра юридических лиц в отношении заявителя юридического лица.

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

На основании изложенного в качестве значения атрибута имени localityName поля subject в структуре квалифицированного сертификата следует указывать текстовую строку, содержащую наименование соответствующего населенного пункта или соответствующего муниципального образования.

Данное извещение с разъяснениями регулятора, как правильно заполнять атрибут L в квалифицированном сертификате юридического лица, также было направлено в аккредитованный УЦ.

Прошу использовать данную информацию в работе.

Желаю всем участникам PKI удачи и успехов!

Подробнее..

Шутка и доля правды парочка интересных RFC практически без практического применения

15.08.2020 20:04:47 | Автор: admin
Формат RFC существует с 1969 года его представили во время обсуждения ARPANET. Тогда инженер Стив Крокер написал RFC 1 о работе программного обеспечения хоста.

С тех пор прошло более 50 лет, но Request for Comments все еще в ходу опубликовано ~9 тыс. документов по сетевым протоколам, моделям хранения данных и алгоритмам шифрования.

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


Фото Braydon Anderson Unsplash

RFC 8771


Здесь описана интернационализированная сознательно нечитаемая сетевая нотация (I-DUNNO). По словам авторов, документ призван внести баланс в следующую ситуацию:

В начале 80-х была представлена DNS. Она сделала доступ к сетевым ресурсам удобнее, но инженеры по-прежнему вторгаются в сферу коммуникаций machine-to-machine: читают и вручную прописывают IP-адреса. Задача I-DUNNO воспрепятствовать этой деятельности и, наконец, закрепить работу с адресами за вычислительными системами.

I-DUNNO использует кодировку UTF-8, чтобы обфусцировать IP-адреса и усложнить их чтение для человека. Кодовые точки представлены октетами в количестве от одного до четырех, а сама последовательность включает как минимум один символ, запрещенный IDNA2008.

В качестве примера авторы RFC 8771 приводят трансформацию IPv4-адреса 198.51.100.164. Сперва его записывают в виде 32-битной строки:

11000110001100110110010010100100

Затем переводят в символьную форму:

1100011 -> U+0063 (буква c)0001100 -> U+000C (символ смены страницы form feed1101100 -> U+006C (буква l)10010100100 -> U+04A4 (кириллическая заглавная лигатура нг)

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

RFC 8774


В этом документе описаны особые ошибки, которые возникнут в квантовых сетях будущего. Информация в них передается по оптоволоконным кабелям с помощью кубитов поляризованных фотонов. Автор RFC 8774 пишет, что после массового внедрения таких сетей, значение времени передачи пакета сможет равняться нулю. Этот факт приведет к сбоям в интернете, так как классическая сетевая инфраструктура и протоколы не рассчитаны на работу с таким таймингом.

К ситуации 0-RTT подготовлены лишь несколько протоколов: TFO, TLS 1.3 и QUIC. Многие другие будут работать с ошибками квантовыми багами.


Фото Umberto Unsplash

В протоколе Multipath TCP для оценки пропускной способности вычисляется значение alpha. На одном из этапов необходимо поделить на RTT, что невозможно при круговой задержке равной нулю. В свою очередь, протокол LEDBAT, используемый Apple и BitTorrent, начнет передавать пакеты максимально быстро и засорять канал, хотя должен ограничивать нагрузку на сеть.

Чтобы решить проблему, автор RFC 8774 предлагает начать с составления полного списка протоколов, подверженных квантовым багам. В качестве референса можно использовать RFC 2626 о проблеме 2000 года. Затем останется обновить весь ненадежный код. Этот процесс может затянуться, учитывая, что проблему 2038 года для Linux решали несколько лет и закончили переписывать код ядра лишь в этом году.



Больше интересных материалов в нашем корпоративном блоге:

Нашел, увидел, получил: необычные приглашения на собеседование
Группа разработчиков предлагает перейти на UTF-8
Как развивалась система доменных имен: эра ARPANET
Подборка книг по кибербезопасности



Подробнее..

Шутки ради пара занимательных RFC

16.08.2020 00:12:08 | Автор: admin
Формат RFC существует с 1969 года его представили во время обсуждения ARPANET. Тогда инженер Стив Крокер написал RFC 1 о работе программного обеспечения хоста.

С тех пор прошло более 50 лет, но Request for Comments все еще в ходу опубликовано ~9 тыс. документов по сетевым протоколам, моделям хранения данных и алгоритмам шифрования.

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


Фото Braydon Anderson Unsplash

RFC 8771


Здесь описана интернационализированная сознательно нечитаемая сетевая нотация (I-DUNNO). По словам авторов, документ призван внести баланс в следующую ситуацию:

В начале 80-х была представлена DNS. Она сделала доступ к сетевым ресурсам удобнее, но инженеры по-прежнему вторгаются в сферу коммуникаций machine-to-machine: читают и вручную прописывают IP-адреса. Задача I-DUNNO воспрепятствовать этой деятельности и, наконец, закрепить работу с адресами за вычислительными системами.

I-DUNNO использует кодировку UTF-8, чтобы обфусцировать IP-адреса и усложнить их чтение для человека. Кодовые точки представлены октетами в количестве от одного до четырех, а сама последовательность включает как минимум один символ, запрещенный IDNA2008.

В качестве примера авторы RFC 8771 приводят трансформацию IPv4-адреса 198.51.100.164. Сперва его записывают в виде 32-битной строки:

11000110001100110110010010100100

Затем переводят в символьную форму:

1100011 -> U+0063 (буква c)0001100 -> U+000C (символ смены страницы form feed)1101100 -> U+006C (буква l)10010100100 -> U+04A4 (кириллическая заглавная лигатура нг)

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

RFC 8774


В этом документе описаны особые ошибки, которые возникнут в квантовых сетях будущего. Информация в них передается по оптоволоконным кабелям с помощью кубитов поляризованных фотонов. Автор RFC 8774 пишет, что после массового внедрения таких сетей, значение времени передачи пакета сможет равняться нулю. Этот факт приведет к сбоям в интернете, так как классическая сетевая инфраструктура и протоколы не рассчитаны на работу с таким таймингом.

К ситуации 0-RTT подготовлены лишь несколько протоколов: TFO, TLS 1.3 и QUIC. Многие другие будут работать с ошибками квантовыми багами.


Фото Umberto Unsplash

В протоколе Multipath TCP для оценки пропускной способности вычисляется значение alpha. На одном из этапов необходимо поделить на RTT, что невозможно при круговой задержке равной нулю. В свою очередь, протокол LEDBAT, используемый Apple и BitTorrent, начнет передавать пакеты максимально быстро и засорять канал, хотя должен ограничивать нагрузку на сеть.

Чтобы решить проблему, автор RFC 8774 предлагает начать с составления полного списка протоколов, подверженных квантовым багам. В качестве референса можно использовать RFC 2626 о проблеме 2000 года. Затем останется обновить весь ненадежный код. Этот процесс может затянуться, учитывая, что проблему 2038 года для Linux решали несколько лет и закончили переписывать код ядра лишь в этом году.



Больше интересных материалов в нашем корпоративном блоге:

Нашел, увидел, получил: необычные приглашения на собеседование
Группа разработчиков предлагает перейти на UTF-8
Как развивалась система доменных имен: эра ARPANET
Подборка книг по кибербезопасности



Подробнее..

На замену TCP обсуждение протокола QUIC

05.07.2020 14:08:58 | Автор: admin
QUIC новый транспортный протокол, работающий поверх UDP. Некоторые в шутку называют его TCP/2. Расскажем, что сейчас обсуждают, как принять участие и кто внедряет поддержку QUIC.


/ Unsplash / Sticker Mule

Что такое QUIC


Это механизм передачи данных по сети, построенный на протоколе UDP. Позволяет сократить задержку соединения. В отличие от TCP, который использует принцип тройного рукопожатия, в QUIC рукопожатие происходит в один этап со знакомым сервером и в два этапа с незнакомым.

По сравнению с TCP QUIC также обладает большей пропускной способностью. Тесты показали 30-процентное снижение числа ребуферизаций при воспроизведении YouTube-видео.

Какие документы обсуждают


В 2018 году представители Инженерного совета интернета (IETF) отмечали, что QUIC готов для широкомасштабных тестов, но пока не может стать стандартом из-за ряда недостатков. За два года протокол доработали, и группа экспертов готовится оформить его в формате RFC.

Дополнительное чтение из нашего блога на Хабре:


В середине июня сопредседатель рабочей группы в IETF Лукас Пардью (Lucas Pardue) сообщил о начале последнего этапа обсуждения черновиков QUIC. Всего документов шесть, и они посвящены различным аспектам работы протокола:

  • QUIC Transport. Это описание механизмов транспортного протокола QUIC: управление потоками передачи данных и обработки пакетов, согласование версий, открытие защищенного канала связи и обмен криптографическими ключами.
  • QUIC Loss Detection and Congestion Control. Содержит описание методов контроля целостности данных и перегрузки каналов связи.
  • Using TLS to Secure QUIC. Документ, посвященный использованию TLS для защиты QUIC. Есть информация об интерфейсах, работе с ключами и регистрах IANA.
  • Version-Independent Properties of QUIC. Здесь описаны свойства нового протокола, которые должны оставаться неизменными от версии к версии например, заголовки.
  • HTTP/3. Документ, описывающий сопоставление семантики HTTP на QUIC.
  • QPACK Header Compression for HTTP/3. Документ посвящен формату сжатия заголовков QPACK в частности, работе кодировщика и декодировщика.

Обсуждение закончат на следующей неделе 8 июля. Через какое-то время после этого спецификация QUIC получит одобрение IETF и будет опубликована. Принять участие в обсуждении могут все желающие свои замечания и предложения можно оставить на GitHub.

Сейчас ведется дискуссия, посвященная выбору между AAD или nonce. Но возвращаться к вопросам, по которым уже был достигнут консенсус, будут только по веским причинам.

Кто уже внедряет протокол


Несмотря на то что QUIC пока не является стандартом, его используют некоторые ИТ-компании. С ним начали работать CDN-сервисы, включая Cloudflare и Verizon Digital Media Services (VDMS).


/ Unsplash / Nathan Dumlao

Экспериментальную поддержку HTTP/3 уже добавили в Chrome и Firefox. В последнем случае работа протокола строится на проекте Neqo (есть на GitHub). Это реализация клиента и сервера для QUIC.

Черновики IETF использовали и в NGINX в середине июня компания представила превью-версию прокси-сервера с поддержкой QUIC и HTTP/3. В конце мая Microsoft также объявили, что открывают код библиотеки MsQuic с реализацией протокола. Библиотека кроссплатформенная можно запустить на Windows и Linux, используя Schannel и OpenSSL соответственно (для TLS 1.3). Эксперты прогнозируют, что с принятием стандарта QUIC свои реализации выпустит еще больше компаний.

О чем мы пишем в корпоративном блоге:

Подробнее..

TLDR занимательные RFC, YT-каналы на выходные, живойкомпьютер из 50-х и история Fidoneta

25.10.2020 16:08:20 | Автор: admin

В прошлый раз мы поговорили о перестройке IT-монополий, сломе cookie-стен и открытом ПО, а до этого обсудили непривычную дистанционку, личную ИБ и то, почему разработчики дороже денег. Сегодня вновь делимся главными моментами из наших избранных материалов.

Alex Motoc / Unsplash.comAlex Motoc / Unsplash.com

Шутки ради: пара занимательных RFC

Формат Request for Comments существует более пятидесяти лет. За это время вышло около девяти тысяч различных спецификаций, но не ко всем из них стоит относиться слишком уж серьезно.

Так, RFC 8771 описывает сетевую нотацию I-DUNNO. Ее задача необратимо обфусцировать IP-адреса, чтобы усложнить их чтение и закрепить эту область за вычислительными системами.

В 8774-м документе предусмотрели возможные проблемы с квантовыми сетями будущего, а именно 0-RTT, с которым готовы столкнуться лишь TLS 1.3 и QUIC. Чтобы справиться с потенциальными сложностями, автор предлагает составить список всех протоколов, подверженных квантовым багам.


Компьютер, который отказывается умирать

Еще одна наша находка японский FACOM 128B. В этом году ему исполняется 62 года, а 100-й линейке этих устройств 66 лет. Стоит признать, что компьютер уступает своим современникам (вроде IBM 701) по производительности, но его хватило, чтобы спроектировать целый авиалайнер.

Недостатки FACOM компенсирует надежностью и простотой обслуживания. 128B прекрасно себя чувствует и в роли музейного экспоната для поддержки его работоспособности нужен всего один инженер. Кстати, в статье мы говорим и о других долгожителях IBM 402 и DEC MicroVAX 3100.

Наш короткий ролик о FACOM 128B:


Почти анархия: краткая история Fidonet

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

Том Дженнингс, начавший работу над проектом в 83-м, уже через год провел первый сеанс связи с коллегой, находившимся на другом побережье США. Но от формата точка-точка к простой древовидной структуре сеть перевели лишь через несколько лет. Тогда и появились пойнты, ноды, сисопы и регионы, задавшие международный масштаб для независимого проекта.

В Россию Fidonet пришел в 90-е, тогда он был на пике популярности. Однако уже к концу десятилетия по уровню и скорости развития интернет не оставил Fidonet'у ни единого шанса. С другой стороны, сама технология все еще в ходу сегодня Fido Technology Network все еще пользуются не только отдельные энтузиасты, но и некоторые банки или даже правоохранительные структуры.


Изучить на выходных: книги для сетевых администраторов

Мы посмотрели, что сегодня обсуждают на Hacker News и других англоязычных технологических площадках, а по итогам такого анализа подготовили компактную подборку литературы.

Первая книга о принципах построения компьютерных сетей при участии ведущего специалиста VMware. Она распространяется бесплатно репозиторий проекта на GitHub, а читать тут.

Вторая книга бестселлер и всесторонний справочник для сетевого администратора. Один из разработчиков DNS назвал ее незаменимой для тех, кто работает с облаком и открытым ПО.

Третья от одного из топовых экспертов по кибербезопасности. Здесь сделали ставку на простоту примеров и разбор ситуаций, с которыми может столкнуться системный администратор.

Кстати, вот короткий видеообзор еще одной подборки книг на этот раз с фокусом на ИБ:


Парочка тематических подкастов по теме сетевых технологий

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

Ведущие второго подкаста уделяют больше внимания вопросам информационной безопасности. Здесь выпуски чуть объемнее, но и формат отличается свежий эпизод повествует о борьбе TrickBot'ом, есть двухсерийный разбор крупномасштабной учётки данных в Yahoo и рассказ о Золотом щите.


Англ. YT-каналы об алгоритмах, разработке и архитектуре ПО

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

Среди ключевых находок стоит отметить:

Пара специализированных рекомендаций (Python, Linux и др.) в комментариях к хабратопику.


Подробнее..

Выгрузка данных из SAP через RFC на Python

16.02.2021 10:21:44 | Автор: admin

Поговорим о выгрузке данных из SAP ERP или S/4 HANA с использованием механизма SAP RFC.

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

Интерфейс SAP RFC (remote function call) позволяет вызывать различные функции SAP из стороннего приложения.

Преимущества этого интерфейса:

  • прямое и быстрое подключение с SAP.

  • возможность менять параметры запроса, запрашивая данные частями.

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

Установка

Для работы через RFC вам потребуется установить следующее:

  • Библиотека PyRFC https://github.com/SAP/PyRFC pip install pynwrfc

  • Библиотека SAP NW RFC для вашей платформы, скачанный с https://support.sap.com (нужен акаунт SAP).

  • Установить переменную окружения, указав каталог с библиотекой SAP NW RFC: SAPNWRFC_HOME=C:\NWRFC\nwrfcsdk\

Поиск уже имеющихся в системе функций

В системе SAP можно поискать уже готовые функциональные модули.

Сделать это можно следующим образом:

  1. Запустить транзакцию SE16 (просмотр таблиц).

  2. Указать имя таблицы TFDIR.

  3. Задать фильтры для поиска:

  • FUNCNAME=*MATERIAL* (задать маску поиска)

  • FMODE=R (возможность вызова функции через механизм RFC)

Чтение таблиц через RFC_READ_TABLE

RFC_READ_TABLE позволяет выгружать данные из таблицы SAP, ограничивая выборку фильтрами.

Несмотря на то, что SAP позиционирует эту функцию как тестовую и не предназначенную для использования в продуктивной среде, она вполне работоспособна.

Следует сказать, что RFC_READ_TABLE часто неудобна, т.к. она позволяет читать только одну таблицу (не поддерживает JOIN).

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

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

Просмотр функции через SE37

Входные и выходные параметры функции можно просмотреть с использованием транзакции SE37.

Параметры вызова функции присутствуют на следующих вкладках:

  • Importing - входные параметры простого типа (не табличные)

  • Exporting - выходные параметры простого типа

  • Tables - как входные, так и выходные параметры в виде таблиц

Рассмотрим использование SE37 на примере BAPI_MATERIAL_GETLIST.

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

SE37 - вкладка TablesSE37 - вкладка TablesПросмотр полей таблицыПросмотр полей таблицы

Эта функция выдает не слишком много полезных данных: Номер материала и описание.

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

Например поиск по коду материала (MATNRSELECTION):

Таблица входных значенийТаблица входных значений

Подключаемся к SAP

Подключение к SAP с использованием библиотеки pyrfc делается не сложно, но нужно знать корректные параметры подключения, которые может сообщить специалист SAP basis.

Код на Python:

import pandas as pd

import os

import pyrfc

conn = pyrfc.Connection(user='', passwd='',

mshost='111.111.11.11',

msserv='3600',

sysid='010',

group='NN',

saprouter='',

lang='EN',

client='')

Вызываем необходимую функцию

Рассмотрим вызов функции на примере BAPI_MATERIAL_GETLIST.

Сначала зададим входные параметры.

В данном случае для каждого параметра в таблице будет по одной строке.

Строка таблицы задается как python dictionary, а вся таблица задается как list, состоящий из строк.

В нашем примере укажем фильтр на код материала: '' (т.е. все значения), а также укажем значение для Plant.

Для выборки используем SIGN="I" (Includes),

Варианты для OPTION:

  • EQ Equal

  • BT Between (требует задать значение для для LOW и HIGH)

  • LE Less Equal

  • GE Greater Equal

  • CP Contains Pattern

matnrselection = [{'SIGN':'I', 'OPTION':'CP', 'MATNR_LOW':''}]

plantselection = [{'SIGN':'I', 'OPTION':'EQ', 'PLANT_LOW':'NNNN'}]

Далее вызываем функцию с этими параметрами.

result = conn.call('BAPI_MATERIAL_GETLIST',

MATNRSELECTION = matnrselection,

PLANTSELECTION = plantselection)

Преобразуем результат в DataFrame

DataFrame можно получить в одну строку:

df = pd.DataFrame(result['MATNRLIST'])

Где MATNRLIST, это имя результирующей таблицы, указанное в разделе Tables.

Итак, с помощью буквально нескольких строк кода, мы получили данные из SAP в DataFrame и можем дальше работать с этими данным используя все возможности языка Python.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru