Шифрование трафика и идентификация сервера

Не стоит изобретать велосипеды. Ключевая фраза «TLS mutual authentication». Проверяйте сертификаты в обе стороны.

если в этом ничего не смыслите, то openssl и его конкуренты - ваши друзья

если в этом ничего не смыслите,

у меня слабые знания. Все на уровне понимания как работают хэшфункции, симметричное шифрование, блочные шифры и прочее... т.е. чисто теория. Кроме того, я не работала с криптографическими протоколами, но могу сформулировать требования к ним))

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

да тут tls один времени может отъесть... протокол нужно описать как конечный автомат. нужно смотреть как сделано в nginx или передирать оттуда. Со снифером и RFC сидеть самой это слишком уж накладно по времени

Как будто кто-то предложил тебе реализовать TLS самостоятельно.

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

Реализацию протокола умные дяди уже написали давно, достаточно взять библиотеку и вызывать из неё функции

Например, OpenSSL и читать маны по SSL_connect(), SSL_accept и остальным

Данные [...] представляют собой некоторую коммерческую ценность

это дает простор для разнообразных атак (типа синкхола и снифа)
синкхола

Разработчик ботнета детектед.

И вообще, как можно иметь «понимание как работают хэшфункции, симметричное шифрование, блочные шифры и прочее» и не знать первого правила криптографии: «don't roll your own cryptography»?

для tcp трафика несколько лет назад использовал stunnel и самоподписанные сертификаты на обеих сторонах. это и есть готовая реализация openssl/tls

Если тебе нужно разнообразный трафик передавать, то бишь vpn нужен, то ipsec или openvpn тебе в руки

Реализацию протокола умные дяди уже написали давно, достаточно взять библиотеку и вызывать из неё функции

Например, OpenSSL и читать маны по SSL_connect(), SSL_accept и остальным

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

не проблема

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

В первом коменте правильно написали про tls mutual. Смотри либу с реализацией тлс для языка на котором пишешь.

Это самая обычная серая будничная тема. Изобретать ничего не нужно.

а кто говорил, что будет легко :)

в общем, OpenSSL в неблокирующие сокеты умеет

с документацией у него не всё хорошо, но вот как бе минимальный пример сервера

https://wiki.openssl.org/index.php/Simple_TLS_Server

в общем, OpenSSL в неблокирующие сокеты умеет

Выдохнула прям. однозначно +

Разработчик ботнета детектед.

Спасибо, но это игровой карточный сервер)))

и не знать первого правила криптографии

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

а в наколенных поделках васянов хертблиды никто и не чешется искать

И вообще, как можно иметь «понимание как работают хэшфункции, симметричное шифрование, блочные шифры и прочее» и не знать первого правила криптографии: «don't roll your own cryptography»?

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

и чего совсем не хочется, так это того чтобы моя работа была васянской поделкой

с документацией у него не всё хорошо

документация к нему просто продаётся отдельно: http://shop.oreilly.com/product/9780596002701.do

сам не читал (обошлось), но коллега как раз героически с её помощью прикрутил openssl к event-driven серверу.

Толсто, попробуй ещё раз.

на гитхабе полно таких поделок

Выдохнула прям. однозначно +

ЕМНИП, практически все нормальные высокоуровневые обертки над сокетами (вроде Asio и ACE для C++, libev/libuv для C) умеют работать с TLS в асинхронном режиме. Даже с деталями работы OpenSSL близко знакомится не придется.

не мешайте, она пишет свой велосипед с нуля

она пишет свой велосипед с нуля

Тогда можно посоветовать ей это: https://www.youtube.com/watch?v=vFjq9pID4-E

у DH насколько я помню mitm присутсвует

Мейби. Я глубоко в шифрования не нырял. Но на видео говорят что митм не будет. По крайней мере в классическом виде.

может быть, я просто помню что какой то DH mitm недавно всплывал в openssl, может это в контексте TLS или может как реализация в самом openssl

DH подвержен mitm

Кэн ю эксплейн?

Т.к. я не спец в этих вопросах, я процетирую RSA Labs. Речь идет о DH в чистом виде.
К сожалению, моя квалификация не позволяет строить мат. модели и дискутировать на эту тему(((

The Diffie-Hellman key exchange is vulnerable to a man-in-the-middle attack. In this attack, an opponent Carol intercepts Alice's public value and sends her own public value to Bob. When Bob transmits his public value, Carol substitutes it with her own and sends it to Alice. Carol and Alice thus agree on one shared key and Carol and Bob agree on another shared key. After this exchange, Carol simply decrypts any messages sent out by Alice or Bob, and then reads and possibly modifies them before re-encrypting with the appropriate key and transmitting them to the other party. This vulnerability is present because Diffie-Hellman key exchange does not authenticate the participants.

чё тоньше то? даже новое слово узнал просто загуглив эту фразу: Astroturfing

Набрось тоньше.

даже новое слово узнал просто загуглив эту фразу: Astroturfing

В смысле ты постишь эту чушь в расчете убедить общественность, что неадекватов с калечной самопальной криптографией много? Ну допустим даже это и так, и что?

какую чушь я пощу?

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

DH в TLS применяется для обеспечения Perfect Forward Secrecy, чтобы не использовать ключи сертификатов для шифрования, а только для аутентификации. Если впоследствии ключи будут похищены, это не позволит расшифровать предыдущую переписку

я писал, что якобы надо что-то делать? в этом треде?

Это так очевидно, что я даже задумался, как это эксплейн-то.

DH позволяет тебе выработать общий секрет, но никак не аутентифицирует вторую сторону. Не удостоверился в подлинности собеседника внешним способом? Наслаждайся зашифрованным соединением с атакующим, которое никто кроме вас не расшифрует.

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

Нет, ты на это лишь толсто и неуместно намекал вот этим тупняком. Мы тут ТСа уговариваем не саботировать тяжким трудом свою контору, а тут ты.

у меня слабые знания

Не только, походу Пука, ты и сама бестолковая.

Самый обычный TLS, даже не mutual (про идентификацию клиента ничего не сказано).

Не только, походу Пука, ты и сама бестолковая.

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

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

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

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

Либо ты просто ретранслируешь глупость, либо там имелась ввиду алгоритмическая часть. Как максимум какие-то левые, системные/комплексные нюансы, которыми все итак подтираются.

Набрось
ты постишь эту чушь
лишь толсто и неуместно намекал
ты стал подстрекать

долго будешь со своим воображением общаться? как-то невежливо с твоей стороны, когда я тут рядом стою.

с прописной истиной

и нет, это не прописная истина, это просто фраза-лозунг которой прикрываются любители выдавать «умные цитаты» за своё мнение.

по степени простоты реализации:

1. поднять vpn между сервером и клиентом(клиентами). Чисто админское решение - поставить доп.софт, опционально заюзать внешний сервис если лень хранить клиентскую базу, наколдовать с фаерволом

2. если клиент с сервером может общается по https - поднять центр сертификации (или опять-же взять внешний) и распространнить ключи нужным образом. Незначительные изменения в софте всё-же потребуются

3. внедрять tls в соединения. Отлаживать будет печально, и от получения сертификатов всё одно не деться (см п2)

4. фигачить свой защищённый протокол с блекджеком. Есть исчезающе малый шанс, что это будет круто и востребовано. Тогда мальдивы-канары :-)