LINUX.ORG.RU

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

 , ,


0

3

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

С чего правильно начать выбор методов?
Какие подводные камни?


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

sanwashere ★★
()

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

nyka
() автор топика
Ответ на: комментарий от t184256

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

nyka
() автор топика
Ответ на: комментарий от nyka

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

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

t184256 ★★★★★
()
Ответ на: комментарий от nyka

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

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

Harald ★★★★★
()

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

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

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

edigaryev ★★★★★
()
Ответ на: комментарий от nyka

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

t184256 ★★★★★
()

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

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

anto215 ★★
()
Ответ на: комментарий от Harald

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

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

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

nyka
() автор топика

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

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

redixin ★★★★
()
Ответ на: комментарий от t184256

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

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

system-root ★★★★★
()
Ответ на: комментарий от system-root

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

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

nyka
() автор топика
Ответ на: комментарий от Harald

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

nyka
() автор топика
Ответ на: комментарий от Harald

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

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

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

anonymous
()
Ответ на: комментарий от nyka

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

anonymous
()
Ответ на: комментарий от nyka

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

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

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

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

deep-purple ★★★★★
()
Ответ на: комментарий от deep-purple

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

anonymous
()
Ответ на: комментарий от deep-purple

Т.к. я не спец в этих вопросах, я процетирую 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.

nyka
() автор топика
Ответ на: комментарий от system-root

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

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

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

t184256 ★★★★★
()
Ответ на: комментарий от nyka

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

Harald ★★★★★
()
Ответ на: комментарий от deep-purple

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

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

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

t184256 ★★★★★
()

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

slovazap ★★★★★
()
Ответ на: комментарий от Bobby_

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

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

nyka
() автор топика
Ответ на: комментарий от t184256

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

system-root ★★★★★
()
Ответ на: комментарий от system-root

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

t184256 ★★★★★
()
Ответ на: комментарий от t184256

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

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

LjubaSherif
()
Ответ на: комментарий от t184256

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

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

system-root ★★★★★
()
Ответ на: комментарий от t184256

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

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

system-root ★★★★★
()

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

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

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

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

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

MKuznetsov ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.