1

I'm a newbie to Bitlbee, using it with libpurple to aggregate all my messaging. It's very cool, but I have some security concerns, which I'd like to clarify.

When connecting from an IRC Client (I'm using weechat.el on emacs) to a local Bitlbee gateway it seems I cannot keep the infomation encrypted end-to-end due to Bitlbee's lack of support for client SSL?

This means information is transmitted in cleartext:

weechat.el --SSL--> WeeChat(Relay) --PLAIN--> Bitlbee --SSL--> |Firewall| --> Skype/Facebook

The only advice I can find relates to securing the connection from an external network, using stunnel. Whilst good advice, this is no use locally as stunnel will ultimately still talk to bitlbee over an unsecured connection, so having a local stunnel is surely a waste of time?

I understand that having an unsecure localhost connection is a relative low risk, but it does mean that identification of the user on the client and any messages sent can technically be sniffed over the lo interface, by someone with root access to the server?

In an ideal world this information would never appear across any connection in cleartext.

A few questions I have

Is it possible provide end-to-end SSL encryption from client to Bitlbee?

If not, what steps beside co-locating the client and server on the same server (or using stunnel) are recommended? Obviously I can block all incoming traffic on port 6667, but is there anything else?

Can anyone clarify the actual risk of packet sniffing on localhost connections?

Improve this question

1 Answer 1

Reset to default
3

Is it possible provide end-to-end SSL encryption from client to Bitlbee?

No, Bitlbee does not have server SSL/TLS support.

Whilst good advice, this is no use locally as stunnel will ultimately still talk to bitlbee over an unsecured connection, so having a local stunnel is surely a waste of time?

The idea is that stunnel would run on the same host as Bitlbee, not on the same host as your client.

Can anyone clarify the actual risk of packet sniffing on localhost connections?

On Linux and most other Unix-like operating systems, this is only availble to root, i.e. the server's administrator. If you don't trust root, you cannot trust the server.

Improve this answer
3
  • Thanks for clearing this up - I can stop googling now :-) I understand the stunnel use-case and agree - you co-locate your tunnel and the Bitlbee server. Then your client can use the tunnel and the connection is secure - at least up to the stunnel. I take your point about root, but there is a case to be made for - I trust root to admin my servers, but that shouldn't extend to reading my messages and passwords in plaintext, ever. I'd prefer that privilege to only be available to the user. I'm probably being overly paranoid. Commented May 20, 2018 at 16:21
  • That's unavoidable: root can replace your SSL/TLS library with one that logs plaintext data; root can inspect your processes to see what data they encrypt and decrypt. Commented May 20, 2018 at 17:18
  • Fair point - I guess wherever you draw the line, there is always an opportunity for root. Once a bad guy is root on your box, encryption won't protect you if they can get at the library doing the encrypting :-) Commented May 20, 2018 at 17:33

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.