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

При использовании SSH3 сервер неотличим от HTTP-сервера и принимает запросы на 443 сетевом порту (HTTPS), а трафик SSH3 сливается с типовым HTTP-трафиком, что затрудняет проведение атак, связанных со сканированием портов и выявлением SSH-серверов для подбора паролей. Для усложнения совершения атак на серверы SSH3, кроме знания сведений о наличии сервера на заданном IP-адресе, может задаваться секретный путь-идентификатор SSH3-сервера. Без обращения с корректным идентификатором сервер обработает ответы как обычный HTTPS-сервер и не выдаст факт наличия возможности подключения по SSH3. Например, при задании идентификатора "e6ae772cbdaafd6918865cc2ce449dae" подключиться к серверу можно только по URL "https://192.0.2.0:443/e6ae772cbdaafd6918865cc2ce449dae", а если идентификатор указан некорректно, сервер выдаст штатную ошибку "404".

Из расширенной функциональности SSH3 упоминается возможность использования для аутентификации сертификатов X.509 и методов OAuth 2.0/OpenID Connect, помимо классических методов SSH; поддержка перенаправления UDP-портов через SSH-туннель в дополнение к возможности перенаправления TCP-портов (например, для проброса QUIC, DNS и RTP); использование расширенных функций протокола QUIC, таких как миграция соединений без разрыва подключения и установка multipath-соединений для распараллеливания трафика по нескольким маршрутам.
. . .
Время реакции на клавиатурный ввод для уже установленных сеансов в SSH3 и SSHv2 находится на одном уровне.

Trying to adapt observability tools into security tools generally increases overhead (e.g., adding extra probes) which negates the main reason I developed these using eBPF in the first place. That would be like taking the wheels off a car to help make it float. There are other issues as well, like decreasing maintainability when moving probes from stable tracepoints to unstable inner workings for TOU tracing. Had I written these as security tools to start with, I would have done them differently: I'd start with LSM hooks, use a plugin model instead of standalone CLI tools, support configurable policies for event drop behavior, optimize event logging (which we still haven't done), and lots more.

Why we built Corrosion

We built Corrosion specifically for service discovery across a large global network, replacing Consul’s central state database with eventually consistent state distributed across our hosts.
. . .
How Corrosion works

In a nutshell, Corrosion:

- Maintains a SQLite database on each node
- Gossips local changes throughout the cluster
- Uses CR-SQLite for conflict resolution with CRDTs
- Uses Foca to manage cluster membership using a SWIM protocol
- Periodically synchronizes with a subset of other cluster nodes, to ensure consistency

Features

- A flexible API to read from and write to Corrosion's store using SQL statements
- File-based schemas with on-the-fly updates
- HTTP streaming subscriptions based on SQL queries
- Live population of configuration files from Corrosion state with user-defined Rhai templates
- Storage and propagation of state from locally registered Consul services, replacing the central database with Corrosion's distributed state
- Secure peer-to-peer communication with the QUIC transport protocol (using Quinn)

"cart": [
    {
        "id": 0,
        "qty": 5
    },
    {
        "id": 1,
        "qty": -1,
        "qty": 1
    }
]

В развиваемом компанией Intel открытом телефонном стеке oFono, используемом для организации осуществления звонков, передачи данных через сотового оператора и отправки SMS в таких платформах, как Tizen, Ubuntu Touch, Mobian, Maemo, postmarketOS и Sailfish/Aurora, выявлены две уязвимости, позволяющие организовать выполнение кода при обработке специально оформленных SMS-сообщений. Уязвимости устранены в выпуске oFono 2.1.

Обе уязвимости вызваны отсутствием должной проверки размера внешних данных в коде декодирования SMS-сообщений в формате PDU, что можно использовать для записи данных за пределы выделенного буфера. Первая уязвимость (CVE-2023-4233) проявляется в функции sms_decode_address_field(), а вторая (CVE-2023-4234) в decode_submit_report().

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

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

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