Comments 36
И вы нигде не используете /dev/random в качестве источника случайных чисел? Пфф
В openssl используется свой генератор случайных чисел, который получает их в том числе и из /dev/random. Проблема /dev/random'а в том, что данные оттуда следует использовать экономно, потому что они быстро заканчиваются и медленно обновляются. Вы можете убедиться в этом, выполнив команду cat /dev/random.
Так же, openssl умеет использовать аппаратные генераторы случайных чисел. В интеловских процессорах архитектуры Ivy Bridge и выше есть инструкция RDRAND, которая кладёт в регистр очень случайное число, используя источник энтропии, встроенный в процессор.
Для ещё большей случайности, состояние генератора случайных чисел записывается в файл ~/.rnd и читается оттуда при следующем запуске.
Хотя не обходилось и без курьёзов: в 2008 году один из майнтейнеров debian применил на openssl патч, чтобы не ругался valgrind, не осознавая того, что сильно уменьшил этим случайность генератора случайных чисел.
Так же, openssl умеет использовать аппаратные генераторы случайных чисел. В интеловских процессорах архитектуры Ivy Bridge и выше есть инструкция RDRAND, которая кладёт в регистр очень случайное число, используя источник энтропии, встроенный в процессор.
Для ещё большей случайности, состояние генератора случайных чисел записывается в файл ~/.rnd и читается оттуда при следующем запуске.
Хотя не обходилось и без курьёзов: в 2008 году один из майнтейнеров debian применил на openssl патч, чтобы не ругался valgrind, не осознавая того, что сильно уменьшил этим случайность генератора случайных чисел.
А можно объяснить магию с протыканимем ната, двумя независимыми сессииями ssh и туннелированием более подробно и понятно? Мне кажется тут бы диаграмма или рисунок сильно помог.
Немного углубимся: протокол ssh позволяет иметь внутри одного TCP-соединения несколько логических. Тогда схема будет выглядеть так:
А) На Сервере SSH-клиент говорит SSH-серверу: «если к тебе придёт подключение, то отправь его в этот логический канал, а я его расшифрую и передам данные на свой порт 4445».
… дальше по аналогии…
Кстати, у стандартного линуксового ssh клиента есть замечательные горячие клавиши. Если вы нажмёте после подключения <enter>~#, то вам покажут список логических каналов, а если вы нажмёте <enter>~C, то вам покажут командную строку, в которой вы сможете создавать каналы динамически(введите help для информации о синтаксисе). А если вы нажмёте <enter>~?, то вам покажут что ещё можно нажать; самое полезное, это, конечно, <enter>~., завершающее текущее ssh-соединение.
А) На Сервере SSH-клиент говорит SSH-серверу: «если к тебе придёт подключение, то отправь его в этот логический канал, а я его расшифрую и передам данные на свой порт 4445».
… дальше по аналогии…
Кстати, у стандартного линуксового ssh клиента есть замечательные горячие клавиши. Если вы нажмёте после подключения <enter>~#, то вам покажут список логических каналов, а если вы нажмёте <enter>~C, то вам покажут командную строку, в которой вы сможете создавать каналы динамически(введите help для информации о синтаксисе). А если вы нажмёте <enter>~?, то вам покажут что ещё можно нажать; самое полезное, это, конечно, <enter>~., завершающее текущее ssh-соединение.
UFO just landed and posted this here
Люблю такие темы. Спасибо!
И много людей готовы так с вами общаться?
зы. Хотел было спросить про jabber на своём сервере с pgp, но вы ж наверняка скажете, что он дырявый как решето.
зы. Хотел было спросить про jabber на своём сервере с pgp, но вы ж наверняка скажете, что он дырявый как решето.
Понятно, что использовать это в повседневном общении — перебор и паранойя. Но информация бывает разной.
Спасибо за ссылку. Нашёл описание метода, но не нашёл конкретных инструкций, как им воспользоваться.
По поводу велосипедостроения не согласен. Скорее наоборот — мы пользуется стандартными протоколами и открытыми, хорошо себя зарекомендовавшими программами и библиотеками.
По поводу велосипедостроения не согласен. Скорее наоборот — мы пользуется стандартными протоколами и открытыми, хорошо себя зарекомендовавшими программами и библиотеками.
>не нашёл конкретных инструкций, как им воспользоваться
Просто пройдите на сайт где лежит та пдфка, там есть и доки и сорцы. Ну и конечно реализации под многие клиенты уже давно есть. (Имеются конечно некоторые ньюансы при выходе собеседника в оффлайн, но они вполне терпимы)
>Скорее наоборот — мы пользуется стандартными протоколами и открытыми, хорошо себя зарекомендовавшими программами и библиотеками.
Тут конечно мнения могут быть разными, но я всё-же склоняюсь к тому что если соединить хорошо зарекомендовавшие себя колёса и палки, то всё-равно получится велосипед сделанный на коленке.
P.S.: От себя ещё порекомендую данную статью, ибо вы совсем забыли об анонимности.
Просто пройдите на сайт где лежит та пдфка, там есть и доки и сорцы. Ну и конечно реализации под многие клиенты уже давно есть. (Имеются конечно некоторые ньюансы при выходе собеседника в оффлайн, но они вполне терпимы)
>Скорее наоборот — мы пользуется стандартными протоколами и открытыми, хорошо себя зарекомендовавшими программами и библиотеками.
Тут конечно мнения могут быть разными, но я всё-же склоняюсь к тому что если соединить хорошо зарекомендовавшие себя колёса и палки, то всё-равно получится велосипед сделанный на коленке.
P.S.: От себя ещё порекомендую данную статью, ибо вы совсем забыли об анонимности.
При попытке зайти на httpS://www.cypherpunks.ca/otr/ видим проблему с сертификатом.
А доверять цепочке провайдеров между сайтом www.cypherpunks.ca и мной при общении по http опасно, ведь они могли подменить бинарники и исходники (а также их подписи) малозаметным образом (например, нарушив генерацию случайных чисел).
А доверять цепочке провайдеров между сайтом www.cypherpunks.ca и мной при общении по http опасно, ведь они могли подменить бинарники и исходники (а также их подписи) малозаметным образом (например, нарушив генерацию случайных чисел).
О том, что выводить себе в терминал нефильтрованные символы с удаленного конца это нехорошо для параноика, т.к. они могут содержать управляющие последовательности — не задумывались?
Подразумевается, что я доверяю своему собеседнику. Есть небольшое опасение, что управляющие последовательности смогут сломать эмулятор терминала, но я пока не встречал таких уязвимостей.
Ну как же это не бывало, бывало. Сломать (сделать неюзабельным) можно почти всегда, а можно и что-то хуже. Например замечательный баг в Xfree86 с переполнением буфера через заголовок окна в сочетании с возможностью установить заголовок через ESC-последовательность в терминале становится чудесной дыркой с выполнением кода.
Да, вы правы.
Имеет смысл регулярно обновлять ПО и запускать эмулятор терминала из под отдельного пользователя, а лучше даже из-под отдельной виртуальной машины.
Тут ещё есть другая, социальная опасность. Если один собеседник пытается хакнуть другого, то с таким же успехом он может посадить около себя, например, полицейского, нарушив тем самым конфиденциальность данных.
Имеет смысл регулярно обновлять ПО и запускать эмулятор терминала из под отдельного пользователя, а лучше даже из-под отдельной виртуальной машины.
Тут ещё есть другая, социальная опасность. Если один собеседник пытается хакнуть другого, то с таким же успехом он может посадить около себя, например, полицейского, нарушив тем самым конфиденциальность данных.
Представьте, что в какой-то момент вы видите запущенный xterm в котором bash с вашим стандартным юзернеймом в промте. Т.е. он выглядит как свежезапущенный xterm, имеет заголовок, как свежезапущенный xterm, пахнет свежезапущенным xterm. На ввод команды отвечает что надо сказать sudo. С какой долей вероятности вы скажете sudo и пароль в это окно? А на самом деле это окно чата.
То что окно чата не выглядит как окно чата — это секьюритная проблема, которая может привести к утечке данных. И я не уверен, что это единственная непродуманная вещь. Т.е. в любых вопросах связанных с безопасностью присоединюсь к противникам непродуманных наколенных решений, любое подобное решение может устранять параноидальную несущественную проблему, а приводить к вполне существенным.
То что окно чата не выглядит как окно чата — это секьюритная проблема, которая может привести к утечке данных. И я не уверен, что это единственная непродуманная вещь. Т.е. в любых вопросах связанных с безопасностью присоединюсь к противникам непродуманных наколенных решений, любое подобное решение может устранять параноидальную несущественную проблему, а приводить к вполне существенным.
В моём случае вероятность этого не очень высока, т.к. я использую zsh, не использую утилиту sudo и не использую пароль для аутентификации. А вообще да, такой сценарий возможен. Но повторюсь: я доверяю своему собеседнику.
Да, можно было бы сделать фильтрацию спецсимволов, красивые окошки, удобный, интуитивно-понятный пользовательский интерфейс, придумать ники и ставить timestamp'ы перед каждой фразой. Но это бы потребовало написания кода, что привело бы к проблемам «а вдруг у вас там баги и уязвимости?» или даже «а вдруг вас заставили внести туда баги и уязвимости?». Тем более, таких продуктов и сервисов уже существует довольно много. В них периодически находят уязвимости, и с ними происходит, например, внезапное закрытие. Я писал об этом в статье. Основная идея статьи — не писать код. Я специально не использовал даже перенаправление ввода вывода и пайпы.
Решение не позиционируется как универсальное решение, которое подойдёт всем. Если данные таковы, что их секретная передача таким способом — параноидальная несущественная проблема, то лучше использовать способы попроще(например GnuPG). Решение для тех, для кого передача данных является параноидальной существенной проблемой.
Да, можно было бы сделать фильтрацию спецсимволов, красивые окошки, удобный, интуитивно-понятный пользовательский интерфейс, придумать ники и ставить timestamp'ы перед каждой фразой. Но это бы потребовало написания кода, что привело бы к проблемам «а вдруг у вас там баги и уязвимости?» или даже «а вдруг вас заставили внести туда баги и уязвимости?». Тем более, таких продуктов и сервисов уже существует довольно много. В них периодически находят уязвимости, и с ними происходит, например, внезапное закрытие. Я писал об этом в статье. Основная идея статьи — не писать код. Я специально не использовал даже перенаправление ввода вывода и пайпы.
Решение не позиционируется как универсальное решение, которое подойдёт всем. Если данные таковы, что их секретная передача таким способом — параноидальная несущественная проблема, то лучше использовать способы попроще(например GnuPG). Решение для тех, для кого передача данных является параноидальной существенной проблемой.
А кстати вот, Вы пишете «Что мы только что сделали? Первой командой мы запустили tls 1.0-сервер, а второй — подключились к нему. Теперь можно общаться,»
А как общаться-то? Клиенту и серверу как буковки передавать-то?
Или эти «стандартные» openssl-ные запущенные клиент и сервер автоматически передают и отображают в консоли то, что в консоли набирает собеседник? А как файл собеседнику через это передать?
А как общаться-то? Клиенту и серверу как буковки передавать-то?
Или эти «стандартные» openssl-ные запущенные клиент и сервер автоматически передают и отображают в консоли то, что в консоли набирает собеседник? А как файл собеседнику через это передать?
А почему бы не воспользоваться любым IM поддерживающим OTR шифрование?
UFO just landed and posted this here
Я имел ввиду, что при использовании GPG всегда быть готовым быстро удалить свой приватный ключ без возможности восстановления. Если не успеть это сделать, то сообщения можно расшифровать. При использовании обмена ключами с помощью алгоритма D-H, ключ каждый раз новый и старые сообщения уже не расшифровать. Хотя есть шанс, что они останутся в swap'е. Решение — выключить swap.
Если на машине, стоит кейлоггер, то вся защита насмарку.
Если на машине, стоит кейлоггер, то вся защита насмарку.
У Вас недостаточный уровень паранойи. :)
Вы доверяете операционным системам и известным алгоритмам шифрования, считаете, что разработчик ОС не внедрил в нее кейлоггер, который будет отправлять нажатия кнопок по незащищенным никакими SSL каналам связи. Что не стоят бэкдоры, что нет троянов и прочих программ. Что алгоритм не взломан и т. п.
Вы доверяете операционным системам и известным алгоритмам шифрования, считаете, что разработчик ОС не внедрил в нее кейлоггер, который будет отправлять нажатия кнопок по незащищенным никакими SSL каналам связи. Что не стоят бэкдоры, что нет троянов и прочих программ. Что алгоритм не взломан и т. п.
К тому же объем исходников например openssl и openssh уже такой, что разобраться и понять, нет ли там дверки какой уже довольно сложно. На примере OpenBSD marc.info/?l=openbsd-tech&m=129236621626462&w=2
Я к тому, что хочешь что-то сделать хорошо — сделай это сам.
Я к тому, что хочешь что-то сделать хорошо — сделай это сам.
Во-во.
Более того, дверки могут быть и в toolchain'e, используемом при сборке, и в разделяемых библиотеках, и даже в железе. Если выкрутить уровень паранойи почти на максимум, то возможно видеонаблюдение в помещении, использование высокочувствительных микрофонов для изучение звука нажатых клавиш, сбор электромагнитных волн, испускаемых оборудованием, использование паяльника не по назначению и.т.д.
В самостоятельной реализации tls есть проблема: протокол настолько обширен, что реализовать его самому и не допустить ошибок — практически невыполнимая задача. Особенно, если вспомнить про существование атак, основанных на задержках по времени. Если спуститься на уровень ниже и реализовывать toolchain, библиотеки, ОС и железо, то может не хватить и всей жизни.
В самостоятельной реализации tls есть проблема: протокол настолько обширен, что реализовать его самому и не допустить ошибок — практически невыполнимая задача. Особенно, если вспомнить про существование атак, основанных на задержках по времени. Если спуститься на уровень ниже и реализовывать toolchain, библиотеки, ОС и железо, то может не хватить и всей жизни.
В таком подходе минус следующий — если логгировать на стороне одного из собеседников весь сеанс, то потом возможно доказать, что все сообщения, отправленные вами, были отправлены именно вами, особенно если найдут у вас приватный ключ к сертификату. Существуют протоколы, по логам которых после завершения диалога невозможно доказать авторство. Естественно, что это не всем нужно. Но данные-то, как вы говорите, разные бывают.
Нет возможности групповой чата.
Проанализировав траффик SSH сервера, можно понять, кто кому посылает. Проблема бы смягчилась, если можно было бы вести несколько диалогов с различными собеседниками через один SSH тоннель. И/или добавлять туда бесполезный шум.
Но вообще ваш способ замечательно покрывает 99% применений современных «криптомессенджеров» и не имеет тех потенциальных дыр. Блестяще. Было приятно читать.
Нет возможности групповой чата.
Проанализировав траффик SSH сервера, можно понять, кто кому посылает. Проблема бы смягчилась, если можно было бы вести несколько диалогов с различными собеседниками через один SSH тоннель. И/или добавлять туда бесполезный шум.
Но вообще ваш способ замечательно покрывает 99% применений современных «криптомессенджеров» и не имеет тех потенциальных дыр. Блестяще. Было приятно читать.
Мы будем использовать версию 1.0 (TLS — добавлено комментатором) т.к. она вышла в 1999 году и в ней не было найдено серьёзных уязвимостей.
Ай-ай-ай. Дальше цитаты не читал. Или как раз следом раскрыта контрмера против BEAST?
Да, про BEAST мне известно, в комментариях к соседней теме я давал ссылку на лучшее описание методов атаки на tls, из тех которые мне встречались.
Касаемо BEAST, для успешной эксплуатации этой атаки требуется возможность заставить жертву шифровать произвольные (более-менее) запросы. В случае с чатом это не актуально.
Касаемо BEAST, для успешной эксплуатации этой атаки требуется возможность заставить жертву шифровать произвольные (более-менее) запросы. В случае с чатом это не актуально.
Sign up to leave a comment.
Криптопереписка для недоверчивых