Сейчас, например, могут возникнуть заморочки при использовании trio вместе с aiohttp (не знаю есть ли под trio свой http клиент и сервер), т.к. в aiohttp не используется nursery, которые могут понадобится в приложени в качестве родительских. Например nursery с лайфтаймом всего приложения и nursery с лайфтаймом реквеста.
Вероятно их можно как-то намонкипатчить, но это не выглядит надёжно.

я не пользовал. На конфах говорят продакшен реди. И и кого была боль с асинкио, трио помог побороть..

я в этой области плаваю. 😞(
Это получается надо захардкодить сертификат в клиент?  тут надо будет с цепочками что то городить, ибо клиент может на разные домены ходить.
Заказчик в данный момент хочет внутри TLS вручную шифровать jsonчики..

Но мне эта идея совсем не нравится

но от мамкиных хакеров это спасет

Ну да, зашивать сертификат в клиента. Довольно не удобно, но проблему решает

О, тогда надо погуглить выступления, почему-то не попадались, и на ютьюбе сплошной Хеттингер в рекомендациях 😊. Спасибо

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

на рупайтане девочка рассказывала из nvideo кажется. Но у неё особая боль была. Доклад достаточно абстрактный.

ключ можно из кода достатать 😞

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

HPKP - это мамкина защита, которая совершенно бесполезна в реальном мире. Есть certificate transparency, но я не очень в курсе, насколько оно уже распространено.

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

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

Да и кто ж знает этот реальный мир. Security through obscurity, это тоже безопасность, она также повышает стоимость взлома. Поставить фидлер по инструкции — много ума не надо. А вот пытаться расшифровать чужой протокол, это надо уже иметь знания.
Плюс у заказчика моего заказчика (это подразделение очень известной корпорации, которой в своё время очень досталось от хакеров всех уровней) есть определенные формальные требования в защите. Правда их требования мне не говорят, мне только сообщают что нужно сделать чтобы якобы соответствовать этим требованиям.

Я тему секурный каналов уже дааавно забыл. Есть что почитать? Без всех этих алис и бобов, а просто и формально сделай вот так и будет тебя счастье.

Мне по долгу службы приходится крутиться около MITM-решений, что-то я даже опенсорсил (https://github.com/9seconds/httransform/) задача «сделать MITM в TLS» - намного сложнее подмены http-хедера. Сложнее как с точки зрения необходимых знаний, так и с точки зрения реализации. Подмена хедера - это так, good first issue а подобных штуках

ээ, я бы больше предложил что тебе требуется как раз MITM делать, а не защищаться от него..

И эта, уже этот твой пост тянет на докладик 😊)

И кстати.. где видосики лебовски? 😃

Я с этой точки зрения и говорил. Берём, перепаковываем поток и норм. Http1 вообще просто, со второй версией чуток больше присяданий

Блин

Сделаю видео) Закрутился в конце года