Рубрика «ietf»

Основная идея проекта — формализация взаимодействия между внутренней ИБ и внешними исследователями, давая четкое указание как и куда направлять информацию об уязвимостях или проблемах безопасности. Формализация взаимодействия — серьезная проблема, не все сайты имеют программы bug bounty, или даже просто указывают контакты специалистов по безопасности. А попытки достучаться через службу поддержки и твиттер зачастую заканчиваются уверениями что «Все так и должно быть», и последующим игнорированием.
Конечно, это будет работать только если компания размещающая информацию в security.txt готова проверять и своевременно реагировать на информацию полученную через этот канал.

Интернет проект security.txt — знакомство с еще одним .well-known файлом - 1
Читать полностью »

Мы включили TLS 1.3. Почему вам стоит сделать то же самое - 1

В начале года, в отчете о проблемах и доступности интернета за 2018-2019 мы уже писали, что распространение TLS 1.3 неизбежно. Некоторое время назад мы сами развернули версию 1.3 протокола Transport Layer Security и, после сбора и анализа данных, наконец, готовы рассказать об особенностях этого перехода.

Председатели рабочей группы IETF TLS пишут:
«Вкратце, TLS 1.3 должен предоставить фундамент более безопасного и эффективного Интернета на следующие 20 лет».

Разработка TLS 1.3 заняла долгих 10 лет. Мы в Qrator Labs, вместе со всей остальной отраслью, внимательно следили за процессом создания протокола от первоначального проекта. За это время потребовалось написать 28 последовательных версий черновика для того, чтобы в конечном счёте в 2019 году свет увидел сбалансированный и удобный в развертывании протокол. Активная поддержка TLS 1.3 рынком уже очевидна: внедрение проверенного и надежного протокола безопасности отвечает требованиям времени.

По словам Эрика Рескорлы (технического директора Firefox и единственного автора TLS 1.3) в интервью The Register:

«Это полная замена TLS 1.2, использующая те же ключи и сертификаты, поэтому клиент и сервер могут автоматически общаться по TLS 1.3, если оба его поддерживают», — сказал он. «Уже есть хорошая поддержка на уровне библиотек, а Chrome и Firefox по умолчанию включают TLS 1.3».

Читать полностью »

Eliminating opportunities for traffic hijacking - 1
Beautiful scheme for BGP connection to Qrator filtering network

A little historical overview

  • BGP hijacks — when an ISP originates an advertisement of address space that does not belong to it;
  • BGP route leaks — when an ISP advertises prefixes received from one provider or peer to another provider or peer.

This week it has been 11 years since the memorable YouTube BGP incident, provoked by the global propagation of a more specific prefix announce, originated by the Pakistan Telecom, leading to an almost 2 hour in duration traffic disruption in the form of redirecting traffic from legitimate path to the bogus one. We could guess if that event was intentional, and even a correct answer wouldn’t help us completely prevent such incidents from happening today. While you read this, a route leak or a hijack is spreading over the networks. Why? Because BGP is not easy, and configuring a correct and secure setup is even harder (yet).

In these eleven years, BGP hijacking became quite damaging attack vector due to the BGP emplacement in the architecture of modern internet. Thanks to BGP, routers not only acquire peer information, and therefore all the Internet routes — they are able of calculating the best path for traffic to its destination through many intermediate (transit) networks, each representing an individual AS. A single AS is just a group of IPv4 and/or IPv6 networks operating under a single external routing policy.
Читать полностью »

Протокол прикладного уровня HTTP лежит в основе интернета. Он начал свою жизнь в 1991 году как HTTP/0.9, а к 1999 году превратился в HTTP/1.1, который был стандартизирован Инженерным советом Интернета (IETF).

HTTP/1.1 долго всех удовлетворял, но растущие потребности Сети потребовали апгрейда — и в 2015 году приняли HTTP/2. На этом история не закончилась: совсем недавно IETF анонсировал новую версию HTTP/3. Для некоторых это стало неожиданностью и вызвало некоторое замешательство. Если вы не отслеживаете работу IETF, может показаться, что HTTP/3 появился из ниоткуда. Тем не менее, мы можем отследить его происхождение по истории экспериментов и эволюции веб-протоколов, в частности, транспортного протокола QUIC.

Если вы не знакомы с QUIC, мои коллеги по Cloudflare довольно подробно осветили разные аспекты: например, см. статьи о реальных недостатках современного HTTP и подробности о протоколе транспортного уровня. Мы собрали эти и другие материалы на сайте cloudflare-quic.com. А если интересно, обязательно ознакомьтесь с quiche: это наша собственная реализация QUIC, написанная на Rust с открытым исходным кодом.
Читать полностью »

ENOG 15: «Почему Интернет до сих пор онлайн?» - 1

Здравствуй! Это — одновременно транскрипция и частичный перевод часовой сессии под названием «Почему Интернет до сих пор онлайн?» с пятнадцатой встречи «Евразийской группы сетевых операторов».

Qrator Labs благодарит всех участников обсуждения: Алексея Семеняку, RIPE NCC; Игнаса Багдонаса, Equinix; Мартина Дж. Леви, Cloudflare; Александра Азимова, Qrator Labs и модератора Алексея Учакина из команды подкаста LinkmeUp за разрешение опубликовать данный текст.

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

Читать полностью »

Инженерный совет интернета (IETF) опубликовал черновик нового протокола — Message Layer Security (MLS). Его задача — обеспечить защищённую передачу сообщений между двумя устройствами. Он описывает абстрактные структуры данных, которые можно использовать не только в чат-приложениях, но и для работы с TLS 1.3 и JSON. Расскажем о принципах работы MLS.

IETF предложили новый стандарт для обмена сообщениями — что нужно знать - 1Читать полностью »

В IETF (Internet Engineering Task Force) предлагают реализовать Proof of Transit (PoT) — «путевой журнал» для сетевых пакетов. Подробнее об инициативе и принципах работы PoT — под катом.

«Proof of Transit»: в IETF предложили новый подход для подтверждения пути сетевых пакетов - 1Читать полностью »

Спустя 4 года и 28 драфтов, Инженерный совет Интернета (IETF) одобрил обновленный протокол TLS 1.3. Далее расскажем, в чем причина длительного утверждения протокола, и поговорим о его особенностях.

«Интернет стал чуть безопаснее»: комитет IETF утвердил TLS 1.3 - 1Читать полностью »

В этом году в апреле на IETF Meeting 95 был представлен драфт, в создании которого я принимал участие. Этот драфт – предложение Qrator Labs по улучшению стандарта протокола BGP для обнаружения и устранения route leaks («утечки» маршрутов, далее – лики). Эта сетевая аномалия возникает, когда маршрут анонсируется с нарушением политик маршрутизации. В результате могут значительно увеличиться сетевые задержки, а помимо этого данный механизм может быть использован для организации атак MitM (Man in the Middle) или DoS (Denial of Service). Про IETF (Internet Engineering Task Force) не так давно писал на хабре мой коллега и соавтор данного драфта.

Главной идеей предлагаемого решения стало добавление информации о типе взаимосвязи между BGP-соседями непосредственно в их конфигурации с верификацией этих настроек через handshake в сообщении OPEN. Мы хотим, чтобы только на основании этой настройки (которая показывает, является ли оператор клиентом, пиром или поставщиком для своего соседа) можно было как избежать ликов внутри отдельной автономной системы, так и обнаруживать лики, сделанные другими операторами связи в Интернете. Описание нашей идеи с картинками можно посмотреть здесь.

Я оказался соавтором этого драфта практически случайно, в основном благодаря тому, что примерно за год до этого познакомился с компанией Qrator Labs на Дне карьеры в МГУ. Далее я расскажу, как это случилось.
Читать полностью »

В августе текущего года в архивах IETF появилось обсуждение способов решения проблемы обмена мета-информацией между автономными системами (AS) по методу RFC1997 BGP communities.

Дело в том, что интернет опять угрожает «кончиться», причём самым неожиданным образом — из-за «скелета в шкафу» или частного, но широкого, случая иллюстрирующего, насколько серьёзной может быть проблема технического долга, известная любому разработчику. Сначала мы наблюдали проблему исчерпания пула IPv4 адресов, в качестве решения которой был введён в эксплуатацию не на 100% функционирующий стандарт IPv6. Теперь на наших глазах назревает другая опухоль, связанная, однако, всё с той же сетевой маршрутизацией.

Написанное Йобом Шнайдерсом из компании NTT открытое письмо к IETF служит стартом общественного обсуждения проблемы, угрожающей вскоре стать критической. Дело в том, что основное удобство RFC1997 — 32-битность записи. Первые 16 бит принадлежат ASN, последние 16 несут в себе какое-то значение. Однако уже сейчас один из пяти операторов автономных систем в сети имеет 4-байтный ASN (RFC4893) (4 байта = 32 бита), что делает невозможным использование 16-битной записи (32-битное значение просто не влазит).

Примером Large BGP Community является: 2914:1299:40.

Мы обратились напрямую к Йобу Шнайдерсу за комментарием по данной проблеме.

Йоб Шнайдерс, NTT: «Large BGP Communities — решение проблемы роутинга между операторами AS» - 1
Йоб Шнайдерс, IP Development Engineer в NTT Communications, основатель NLNOG RING, вице-президент PeeringDB.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js