Клієнт IRC на Bitlbee - шифрування в кінці?


1

Я новачок у Bitlbee, використовуючи його з libpurple, щоб зібрати всі свої повідомлення. Це дуже круто, але у мене є проблеми щодо безпеки, які я хотів би уточнити.

Під час підключення з клієнта IRC (я використовую weechat.el для emacs) до локального шлюзу Bitlbee, здається, я не можу тримати інформацію в зашифрованому від кінця до кінця через відсутність підтримки Bitlbee для клієнтської SSL?

Це означає, що інформація передається у чіткому тексті:

weechat.el - SSL -> WeeChat (реле) - ЗВИЧАЙНИЙ -> Bitlbee - SSL -> | Firewall | -> Skype / Facebook

Єдина порада, яку я можу знайти, стосується забезпечення з'єднання із зовнішньої мережі, використовуючи stunnel. Незважаючи на гарну пораду, це не корисно на місцях, оскільки оглушення в кінцевому підсумку все-таки поговорить з бітлбі через незахищений зв’язок, тож мати місцевий оглушення, безумовно, марна трата часу?

Я розумію, що незахищене підключення до локального хосту - відносно низький ризик, але це означає, що ідентифікація користувача на клієнті та будь-які надіслані повідомлення технічно може обнюхуватися через інтерфейс lo, хтось із кореневим доступом до сервера?

В ідеальному світі ця інформація ніколи не з’явиться в будь-якому зв’язку в чіткому тексті.

Кілька питань у мене є

Чи можна забезпечити шифрування SSL від клієнта до Bitlbee?

Якщо ні, то які кроки поруч із розміщенням клієнта та сервера на одному сервері (або використанням оглушення) рекомендуються? Очевидно, я можу заблокувати весь вхідний трафік на порт 6667, але чи є ще щось?

Чи може хтось уточнити фактичний ризик нюхати пакетів на локальних з'єднаннях?

Відповіді:


3

Чи можна забезпечити шифрування SSL від клієнта до Bitlbee?

Ні, у Bitlbee немає підтримки для сервера SSL / TLS.

Незважаючи на гарну пораду, це не корисно на місцях, оскільки оглушення в кінцевому підсумку все-таки поговорить з бітлбі через незахищений зв’язок, тож мати місцевий оглушення, безумовно, марна трата часу?

Ідея полягає в тому, що оглушення буде працювати на тому ж хості, що і Bitlbee , а не на тому ж хості, що і ваш клієнт.

Чи може хтось уточнити фактичний ризик нюхати пакетів на локальних з'єднаннях?

У Linux та більшості інших Unix-подібних операційних систем це доступно лише для root , тобто адміністратора сервера. Якщо ви не довіряєте root, ви не можете довіряти серверу.


Дякую, що вияснили це - зараз я можу припинити гуглінг :-) Я розумію, що стосується використання оглушення і погоджуюся - ви знайдете свій тунель та сервер Bitlbee. Тоді ваш клієнт може використовувати тунель, і з'єднання надійне - принаймні, до оглушення. Я вважаю, що ви маєте справу щодо root, але для цього потрібно зробити справу - я довіряю root адміністраторам своїх серверів, але це не повинно поширюватися на читання моїх повідомлень та паролів у простому тексті ніколи. Я вважаю за краще, щоб ця привілей була доступна лише користувачеві. Я, мабуть, занадто параноїчний.
Філ

Це неминуче: root може замінити вашу бібліотеку SSL / TLS на ту, яка записує дані в простому тексті; root може перевірити ваші процеси, щоб побачити, які дані вони шифрують та дешифрують.
grawity

Справедливий момент - я думаю, де б ви не провели лінію, завжди є можливість отримати корінь. Після того, як поганий хлопець заграє на вашу скриньку, шифрування не захистить вас, якщо вони можуть потрапити до бібліотеки, яка робить шифрування :-)
Філ
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.