Ну вы чего? Исследователи, нашедшие уязвимость, написали такое красивое её описание, причины, действительно постарались, а вы все это выкинули и оформили как новость.
Ну он еще сносно работает в 7, но в 8, 8.1 и 10 уже не очень, то зависает сервис при разрыве соединения, то просто падает. Ребята сейчас выкидывают его, 2.3.9, вышедший 2 дня назад, поддерживает NSSM полностью. Скоро будет новый сервис, насколько я знаю, с которым будет нормально работать GUI и не требовать прав администратора.
Для генерирования ключей лучше использовать Easy-RSA v3, а не v2. v2 вам подпишет ключи SHA-1, а v2 уже SHA-256. Да и DH-группу лучше использовать длиной 2048-бит и выше, а не 1024.
Все еще не слишком быстро и не слишком хорошо работает под Windows, к сожалению. Windows-разработчиков в проекте всего два-три. Вот прямо сейчас сижу, отлаживаю проблемы со скоростью под Windows: всегда думал, что все более-менее нормально под Windows, а сейчас запустил и удивился — получаю в лучшем случае в 2 раза ниже скорость, чем под Linux с той же конфигурацией, а по умолчанию вообще в 4-5 раз ниже была.
pcnews и pvsm статьи просто тащат к себе автоматически, а сохабр очень классный (кто не знал, достаточно вместо habrahabr.ru написать sohabrahabr.ru прямо с ссылкой на пост, и получите пост)
Я знаю о signal, и знал о нем до его переименования, но вот номер телефона портит для меня ВСЕ. Я банально не могу в нем зарегистрироваться, скачал его, установил, смотрю на этот печальный диалог и унываю. А в техническом плане, если забыть о номере телефона, да, он офигенный!
Если к нашему серверу придёт запрос на первый интерфейс (188), то ответ на него всё равно пойдёт по нижнему. Если у маршрутизатора/провайдера есть хотя бы минимальная защита от подделки адресов, то ответ просто дропнут, как невалидный (с точки зрения 241.241.241.1 ему прислали из сети 241.241.241.0/24 пакет с src 188.188.188.188, чего, очевидно, быть не должно).
Не совсем.
По умолчанию, наверное, в большинстве дистрибутивов (Ubuntu, Fedora, ArchLinux) уже стоит net.ipv4.conf.*.rp_filter=1. Знаю только Debian, где по умолчанию 0.
Если этот параметр установлен в значение 1, приложение, получающее входящий пакет, пришедший, скажем, на интерфейс с IP 188, вообще не получит его, его отбросит ядро как Martian packet.
Такие пакеты можно логировать, что очень удобно:
# sysctl net.ipv4.conf.*.log_martians=1
Если же rp_filter отключен, то в Linux ответ действительно пойдет с неправильным IP через неправильный интерфейс, независимо от протокола, и, с большой вероятностью, отбросится провайдерскими маршрутизаторами. А вот в Windows и OS X все интересней: в Windows, при использовании TCP, никакой дополнительной настройки source routing не требуется — ответ на пакет, пришедший на определенный интерфейс, пойдет через этот же интерфейс и с правильным IP, аналогичная ситуация для TCP наблюдается и в OS X.
А вот с UDP все интересней: как в Windows, так и в OS X, ответ на пакет, пришедший с одного интерфейса, уйдет через другой интерфейс с правильным IP другого интерфейса!
Надеюсь, в середине недели расскажу об этом более подробно отдельной статьей — такая, казалось бы, очевидная вещь, с которой сталкивался любой, кто настраивал Multi WAN и Multihoming, может использоваться для деанонимизации пользователей VPN.
К сожалению, там нет поддержки source routing, а очень бы хотелось, очень.
Кто-нибудь подскажет вообще хоть что-нибудь, чем можно управлять source routing? Для OpenWRT есть mwan3, а под обычный линукс вообще нет ни софта, ни скриптов. Есть только bird, но он не совсем для этого. Очень давно ищу, ничего найти не могу.
Если б счётчик посещений убрали со страницы блокировки, то статистика пользователей, обошедших блокировку, была бы видна в явном виде. Почему оставили счётчик — непонятно.
Объясните мне, что за шум вокруг всех этих мессангеров последние полгода где-то?
Шум, как я полагаю, пошел от СМИ, которые добавляли желтизну в заголовки, умышленно или по незнанию технической части. Добавляли шума в СМИ еще и теоретические террористы, пользующуюся Telegram. Мне не нравится Telegram, но, в целом, он определенно лучше прочих популярных мессенджеров хотя бы тем, что там есть возможность сделать шифрованный чат с более-менее нормальной сверкой отпечатка ключа, но у обычных чатов-то защищен только транспорт, как и у, собственно, большинства прочих популярных мессенджеров, а СМИ, по большей части, описывают Telegram как супер защищенное решение, которым пользуются даже террористы, так что вам, типа, точно подойдет. Я считаю такое преувеличение со стороны СМИ достаточно большой проблемой, без шуток, т.к. такие новости привлекают в Telegram много технически неграмотных новых пользователей. Если в тот же Tor безопасность заложена архитектурно, то безопасность переписки неграмотных пользователей Telegram держится только на принципиальности разработчиков о нераскрытии данных и физической сохранности серверов, а в случае компрометации страдают не только сами пользователи, но и вы тоже, если вы переписывались с пользователем, данные которого, например, выдали правительственным организациям.
Насколько я понимаю, ТЗ у Kpyto было вполне вменяемое, из него можно было написать технически точную статью, достойную хабра, а претензии были больше к тому, что он сделал массовую рассылку.
Но сама проблема в мессенджерах в том, что их много, а все популярные продукты — проприетарные, требуют ввода телефонного номера, с закрытым сервером, или имеют еще какие-то недостатки.
Эта тема сильно больше нас всех, потому как такая важная для человечества технология как IM и аудио-видео звонки не может быть управляема одной компанией. Есть всякие рабочие группы поддержания критических для индустрии библиотек и программ, типа openssl, apache. Мне кажется этим должен заниматься какой-то IETF.
Просто в какой-то момент они проебали это и открытые стандарты не успели за коммерческими поделками. То что сейчас IM монополизирован компаниями это ужасно. В идеале все мессенджеры должны поддерживать унифицированный минимальный стандарт, достаточный для того чтобы связаться с кем угодно, как email, а все свои фирменные штуки реализовывать внутри сети для своих пользователей.
Представьте что имейлы можно было бы слать только между outlook, но на gmail уже нельзя. Или звонить можно было только с Nokia на Nokia, а на самсунг нельзя. Именно так и выглядят так сейчас мессенджеры.
если попросить его сконвертировать тот же файл сначала с 0 по 10 секунду, а потом (отдельным запуском FFmpeg) с 10 по 20 секунду, и сделать правильный плейлист, то при переходе с одного файла на другой (примерно на 10-й секунде) мы услышим заметный звуковой щелчок. Мы потратили не один день на перебор различных параметров запуска FFmpeg, но ни к какому результату не пришли. Пришлось влезть внутрь и написать небольшой патч, который при передаче определенного параметра командной строки исправляет этот недочет, возникающий из-за особенностей кодирования аудио- и видеодорожек.
Как в итоге поправили, просто начинаете кодировать аудио чуть раньше и обрезаете его до нужного фрейма, или как-то умнее? Я тоже натыкался на эту проблему, но из-за того, что мне аудиодорожку нужно кодировать целиком, а не по кускам, и кодируется она на порядки быстрее видео, решил, что мне достаточно кодировать аудио отдельно.
Ну, если у вас нормальный торрент-клиент, то достаточно просто переименовать файлы внутри торрента, и старые файлы подхватятся. Да и вообще, bakabt, пожалуй, самый легкий торрент-трекер для поддержания рейтинга: у меня скачано всего 727 гигабайт, а отдано аж 64 терабайта!
А откуда вы качаете? Я частенько старое с XDCC качаю (один из самых больших листпарсеров — news.kae.re), иногда (очень редко) через eDonkey, и очень редко с Usenet. Через публичные bittorrent-трекеры, как правило, старье действительно не скачаешь, но на animebytes и bakabt частенько качается все, что нужно.
По умолчанию, наверное, в большинстве дистрибутивов (Ubuntu, Fedora, ArchLinux) уже стоит net.ipv4.conf.*.rp_filter=1. Знаю только Debian, где по умолчанию 0.
Если этот параметр установлен в значение 1, приложение, получающее входящий пакет, пришедший, скажем, на интерфейс с IP 188, вообще не получит его, его отбросит ядро как Martian packet.
Такие пакеты можно логировать, что очень удобно:
Если же rp_filter отключен, то в Linux ответ действительно пойдет с неправильным IP через неправильный интерфейс, независимо от протокола, и, с большой вероятностью, отбросится провайдерскими маршрутизаторами. А вот в Windows и OS X все интересней: в Windows, при использовании TCP, никакой дополнительной настройки source routing не требуется — ответ на пакет, пришедший на определенный интерфейс, пойдет через этот же интерфейс и с правильным IP, аналогичная ситуация для TCP наблюдается и в OS X.
А вот с UDP все интересней: как в Windows, так и в OS X, ответ на пакет, пришедший с одного интерфейса, уйдет через другой интерфейс с правильным IP другого интерфейса!
Надеюсь, в середине недели расскажу об этом более подробно отдельной статьей — такая, казалось бы, очевидная вещь, с которой сталкивался любой, кто настраивал Multi WAN и Multihoming, может использоваться для деанонимизации пользователей VPN.
Кто-нибудь подскажет вообще хоть что-нибудь, чем можно управлять source routing? Для OpenWRT есть mwan3, а под обычный линукс вообще нет ни софта, ни скриптов. Есть только bird, но он не совсем для этого. Очень давно ищу, ничего найти не могу.
Насколько я понимаю, ТЗ у Kpyto было вполне вменяемое, из него можно было написать технически точную статью, достойную хабра, а претензии были больше к тому, что он сделал массовую рассылку.
Но сама проблема в мессенджерах в том, что их много, а все популярные продукты — проприетарные, требуют ввода телефонного номера, с закрытым сервером, или имеют еще какие-то недостатки.
Как сказал zhovner: