Делю людей на умных и нормальных!
Концепция хранения и проверки ключей у меня была пересмотрена. В частности, открытые ключи вместе с идентификатором пользователя, которому ключ принадлежит, будут шифроваться закрытым ключом отдельного сервера. Но, обо всем по порядку.
Перенес информацию на отдельную страницу: Jamm
Я писал уже о своём проекте, который позволил бы общаться всем людям без опаски, что за ними может кто-нибудь шпионить. Но те идеи претерпели очень много изменений. Я старался упростить систему как только можно. В итоге, получилась очень интересная штука. Единственное, что я еще не решил в достаточной мере, это как обойти блокировку сервиса на территории некой страны третьего мира. Ведь, когда появится и станет достаточно известным мой революционный продукт любые тоталитарные власти им заинтересуются…
P.S.: Всю схему я опубликую чуть позже. Stay tuned.
RSA не рекомендуется использовать для шифрования сообщений, для этого есть много причин. Одного того, что это детерменированный алгоримтм (одинаковый текст всегда дает одинаковый шифр) хватает. А вообще Attacks_against_plain_RSA
Рекомендованный способ — сгенерить ключ K, зашифровать его открытым ключом PK (RSA), параллельно посчитать его (K, не PK) хэш H(K) (SHA-256), полученный H(K) использовать как ключ для симметричного шифрования (AES) сообщения. Передать результат работы RSA и AES одним сообщением. Получатель расшифровывает своим закрытым ключом SK первую часть, получает ключ K, считает его хэш H(K) и расшифровывает им сообщение.
А вот тут: gembox.us
Вот так вот. Google как всегда в своём репертуаре. Забота о безопасности их продукта всегда лежит на плечах пользователей.
Если можете, не пользуйтесь продуктами Google. Ни почтой, ни поиском, ни какими-то ни было другими сервисами Google.
Очень интересный обзор по ссылке: http://habrahabr.ru/post/209258/
Не секрет, что в мире очень много злоумышленников. Некоторые могут быть настроены на веселье, а некоторые на конкретную цель — завладеть вашим блогом с целью сделать его частью бот-нета, либо распространителем ссылок на другие ресурсы. А могут и вовсе совершать с помощью вашего сервера разные опасные действия.
Методов взлома бывает два: первый — через уязвимость кода в самом вордпресс, либо в каком-нибудь плагине, а второй — подбор паролей от пользователя с правами администратора.
В первом случае можно посоветовать только обновлять все плагины, темы и сам движок сразу же, как только появилось обновление. Не пренебрегайте этим! Это проект с открытым исходным кодом (opensource), код пишут студенты-недоучки и библиотекари-самоучки. В нём множество недочётов и ошибок.
Во втором — предложу несколько советов. Есть некоторые плагины, довольно сильно повышающие безопасность вашего блога. Я могу порекомендовать два из них: Limit Login Attempts и Wordfence.
По умолчанию WordPress разрешает сколько угодно попыток входа в систему. Этим пользуются злоумышленники и подбирают пароли по словарю, либо вообще полным перебором по буквам/цифрам. Оба названных плагина реализуют блокировку по IP тех, кто занимается таким перебором.
Отдельно скажу, что Wordfence умеет еще следить за целостностью файлов в вашей установке WordPress, плагинов и тем, и присылает администратору письма тогда, когда надо что-то обновить, или когда возникли проблемы.
Сегодня я таки сделал то, о чем думал давно — сгенерировал себе SSL сертификат и настроил сервер, чтобы он использовал его для этого блога. Дело не совсем в безопасности, а скорее в том, чтобы информация, которую я тут пишу, не летала через сети моего провайдера, да и других российских провайдеров, которые, я знаю, не чисты на руку. Мне, конечно, нечего скрывать, иначе я бы это не писал тут, но мне не нравится мысль о том, что вся информация хранится где-то у людей в погонах и без.
Кстати, хочу тут записать команды, с помощью которых я создал wild-card сертификат для сайта.
1. Сначала редактируем значения по умолчанию:
nano /etc/ssl/openssl.cnf
Самое главное, это закомментировать строки со значениями, которые нам не нужны в сертификате.
2. Генерируем ключ
openssl genrsa 2048 > wildcard.hostname.key
3. Создаем сам сертификат
openssl req -new -x509 -nodes -sha1 -days 3652 -key wildcard.hostname.key > wildcard.hostname.crt
Создаем мы его не на вечность, а на 3652 дня, это 10 лет.
4. Ну а потом подставляем его в конфиг nginx, перезапускаем его и — вуаля! Сайт доступен (только) по HTTPS.
В процессе создания защищенного от перехвата мессенджера, нашел в сети описание довольно интересного расширения над UDP протоколом. Называется UDP Lite.
Отличие этого протокола от обычного UDP состоит в том, что чек-сумма берется не от всего пакета, а от заведомо установленного куска. Таким образом, появляется возможность не отбрасывать пакеты, которые дошли с какими-то изменениями. Например, один измененный бит для программ VoIP не важен, такие программы умеют компенсировать неточности. И в таком случае звук может «икнуть», но не пропасть совсем на секунду и более.
Жаль, что это расширение только для Linux’а. Ну и целесообразность использования в моем мессенджере под большим вопросом…
В заметке о схеме приватного интернета, а точнее возможности обмениваться по-настоящему приватными сообщениями, я довольно хорошо всё расписал, но сегодня возникла очень интересная идея!
В основе предлагаемой мной схемы лежит некий сайт — хранилище открытых ключей пользователей. Таким образом, чтобы связаться с любым новым пользователем, достаточно поискать его на этом сайте по е-мейлу, или даже какой-либо другой информации (надо подумать), взять оттуда его ключ и послать ему сообщение, зашифрованное этим ключом.
А новая идея состоит в том, что ключи же можно распространять и через социальные сети! Главное, сделать вспомогательную систему, которая будет следить за целостностью раздаваемых ключей. Она описана в первоначальной заметке.