SILC: Problems and Concerns

SILC stands for Secure Internet Live Conferencing, it was released in 2000, and it is commonly believed that it is “more secure” than other chat networks, but is it really? What is the situation with SILC, and can it be trusted for secure communications?

There are a number of concerns with SILC, an outline of these concerns follows.

Community¶

Although the SILC web pages talk about a community and volunteers, SILC is primarily developed by one person (Pekka Riikonen), although some other people occasionally have committed, the only developer doing any commits in 2008 is Pekka. It almost appears as if the project is in maintenance mode, there are releases relatively frequently, but they only fix one or two small bugs.

There has never been a large-scale adoption, either of SILC servers that are public, or SILC client support. Part of this probably has to do with the dominance of other chat protocols that have existed for significantly longer that have more client support in more operating systems, and to be fair a lot of those have had very limited communities themselves, but I believe that a significant reason is SILC is still very difficult to use and has poor client support. These wouldn’t be a problem if the SILC project didn’t suffer from Not Invented Here syndrome.

NIH (Not Invented Here)¶

SILC suffers greatly from NIH, rather than working with existing, well known and audited components, the SILC project developed their own. For example, their entire crypto layer was written from scratch, rather than using the well-audited and supported libraries such as libssl, gnutls, libgcrypt, etc. The chances of this crypto layer being intact and audited are significantly lower than these other libraries that SILC decided not to use. Additionally, its a well understood maxim that just as ten eyes looking at code are more likely to find problems, one set of eyes is just as likely to cause problems. Projects such as libssl are much more likely to be better code because of the number of people looking at it, using it and auditing it.

The SILC project aims to create “the most rich featured conferencing services and high security”, it has been developing its own protocol and have actually sent their specifications through the IETF and it is their intention to fully standardize the SILC protocol in the IETF. There doesn’t seem to have been any movement on this for a couple years now. The fact that there are seemingly dead RFCs, and a lack of other active documentation or development seems like a problem. Bootstrapping something from the protocol level all the way up is going to be a lot of work, and something really hard for someone to do alone, so hard that I believe that the project suffers from this attempt to monolithic approach overwhelming itself.

The one case where the SILC project has not suffered from NIH syndrome is the monolithic SILC client, which is based off of the irssi code. This would seem like a good thing, as irssi is the top preferred client for geeks nowdays, but the approach was wrong. Specifically, rather than work on irssi itself, the SILC project forked irssi into their own client, which is SILC-only. This is unfortunate. If you actually want to use irssi, you can use the normal irssi program, but with a SILC plugin, but this plugin suffers from weak client implementation support.

Weak client implementation support¶

Additionally, due to the NIH problem, the client support has to be boot-strapped from scratch. It is for this reason that the client support for various operating systems is very weak, at best, even now over eight years into the project. The clients that are available are not reliable, have very limited protocol implementation (such as missing key authentication functionality) or simply do not work for common operating systems. This means that not everyone can use the protocol. The implementations as plugins in various clients (Pidgin, irssi, Colloquoy, and Kopete) all are incomplete implementations which suffer from lack of SILC functionality that are critical to the security and authentication components that SILC tries to achieve. This decreases the number of people who are able to use it, and is a function of deciding to build everything from scratch.

The various plugins, and even the monolithic client regularly segfault, sometimes without any particular pattern. To be fair, these problems could be unrelated to SILC itself, but the plugin implementation in the client, but this highlights the sorry state that the SILC project has to work with when they’ve decided to implement everything on their own. The segfaults that do have a pattern are related to particularly annoying things, such as the amazingly horrible case of ‘silky’ which is one of the few pure SILC clients. If a silky user on windows hits the tab key while in a channel (which is a common thing to do to tab-complete nicknames in other chat clients), all irssi silc plugin users would segfault! This was fixed fortunately, but still… what? It also took a very long time. Another unfortunate segfault happens if you delay acceptance of a server’s key, because you are doing your due diligence to verify that it is correct, the sever will drop the connection and your client segfaults. In irssi, the plugin will trap you, so you cannot do anything except verify the signature (such as switch to another window to ask the server administrator out of band where you can find their cryptographically signed server fingerprint for verification). If you resize the terminal during the passphrase prompt, boom! You get doubles of emotes and signed messages, with improper spacing… it crashes when your machine wakes from sleep. If you type your passphrase wrong when you load the silc plugin for irssi, you are not told that you typed it incorrectly, you just mysteriously cannot connect to a silc network (it just tries to connect to the standard IRC port, but it sure would be nice if you were told that your passphrase was wrong so you had a clue. Also you have to unload the silc plugin and then reload it to try again. Not clear at all).

The list goes on, and it reads like beta software that has not been properly tested, has poor implementation and one would not expect that SILC is over eight years old and in this state.

Responses to Security¶

For a project that prides itself on security, its lackluster responses to security issues have been somewhat appalling. Software that claims to be written for the sole purposes of enhancing security, should not be maintained in a way which defeats this goal.

There are many examples of this. In June of 2005, Eric Romang reported a security issue in SILC to the Gentoo bug tracker, the SILC developers were informed two days later. They seem to have never replied to this issue, but silently fixed it on September 2nd, almost three months later. Their reason for not fixing it sooner was that it was published on the bugtraq security mailing list. Huh?!

They failed to make an announcement of this security fix being available, nor did they provide a new release which would have fixed this issue until two months after it was fixed in CVS, on November 21st when they released 1.0.1 as a “bug fix release”. Without making it clear that a release fixes security bugs, people will believe that it is not as critical and think that it only improves functionality and will delay upgrading. Worse, the security advisories section on the SILC website remained empty until 2007 when one DoS was put there, but nothing else has ever appeared there.

Weak authentication¶

The SILC implementation of its own spec is poor in that it is vulnerable to weak authentication which undermines any strong encryption it might have. For example, it is impossible to differentiate between two users whose keys you have verified before. If you verify these two user’s keys, and one of those users decides to impersonate the other one, SILC will happily continue without even mentioning this appalling situation. This permits anyone whose key you have cached to impersonate anyone else whose key you have also cached. It also means that a single compromised key compromises the security of everyone who has ever cached that key. With no mechanism for revocation of your keys (you can delete them and generate new ones, but there is no way to actually alert anyone through a published revocation method) you are essentially a sitting duck.

This issue was reported a year and a half ago, and although it did receive responses from the core developer, nothing has been done to rectify the situation. See Community and Responses to Security above.

Required false security¶

The SILC draft specification contains instances of required steps that do not add anything to system security (though they might look like they do at first glance) which make the protocol significantly more unstable under real-world scenarios, and subject to new classes of DoS attacks. Since one of the goals of a secure chat network is reliability in times of crisis, this seems like a bad thing.

For example, the client-to-server connection step seems to indicate that:

When client connects to server the server MUST perform IP address lookup and reverse IP address lookup to assure that the origin host really is who it claims to be.

However, DNS is not a secure protocol (it can be spoofed or poisoned), and shifting DNS records in the real world (e.g. a server being moved to a new host without reverse DNS capabilities) can make a compliant client unable to connect.

Server-to-server connections appear to have the same DNS requirements as the client-to-server bindings, which makes maintaining a silcnet across machines on, say, low-budget DSL lines (no reverse DNS) or dynamic IP addresses effectively impossible.

Since the connections are expected to be validated cryptographically anyway, what security gain do we get from the rigorous enforcement of reverse DNS lookups? Is that gain (if any) worth the tradeoff in flexibility and reliability?

Complicated and non-standard upstream packaging and linking choices¶

Upstream has added a layer of tools to the standard free software distribution mechanism. in addition to automake and autoconf, SILC uses (and maintains, afaict) autodist: “Autodist was originally written for the SILC Project which needed controlled mechanism to create several distinct distributions from one source tree.”

The result of this is that the distributed tarballs all contain a remarkable amount of overlap. Due to the staggered release times of the various pieces (silc toolkit, irssi plugin, monolithic silc client, pidgin plugin, etc), bugs get fixed piecemeal, and there are many copies of critical code floating around. It also makes it challenging for downstream distributors (such as debian, which has struggled to keep silc functional and clean. The code overlap also occasionally introduces serious problems with linking and reuse.

This is in distinct contrast to the standard distribution and use of the shared object mechanism, which would look more like:

• silc-toolkit would contain critical code, and be distributed individually
• silc-server would dynamically link to silc-toolkit, and would also be distributed separately from silc-toolkit.
• irssi plugin would link against silc-toolkit and the irssi developer tools
• pidgin plugin wold link against silc-toolkit and the pidgin developer tools
• any attempt at generating a monolithic client (ideally not an embedded copy of an out-of-date irssi) would still link against silc-toolkit

Then if anything silc-related needed fixing, a new version of silc-toolkit could be released independently and the other tools wouldn’t need to be touched. As it stands, there are regularly-recurring problems with integrating core silc functionality with other packages related to these choices by upstream.

No functional mechanism for key revocation or re-keying¶

While the protocol does have a hook for the use of a PKI, there have not seen any client or server implementations that produce or consume X.509v3 certificates, OpenPGP certificates, or SPKI certificates. There is also no clear description of how the parties involved are expected to identify one another using any of these PKI approaches. This seems to be a common problem with current cryptographic tools, so its not quite fair to single out SILC, when the protocol is at least flexible enough to accommodate these alternate architectures. But until at least one real PKI is implemented, users of the protocol (both client and server) remain vulnerable to impersonation by compromised keys, even if the legitimate holder of the key knows it to have been compromised. Lack of a functional PKI also makes proactive re-keying more difficult than it should be.

Complicated and obscure security¶

SILC’s underlying protocol seems to be flawed in ways that keep me from trusting it implicitly, it is disturbing how easily people are lulled into a false sense of security just by using SILC. Worse yet is that some of the actual important security implementation points are a bit obscure and require some complicated understandings to use correctly.

For example, by default, you have to trust the servers that are running the SILC network, which you cannot really do, leaving the default as susceptible to man-in-the-middle attacks. SILC is an asymmetric private/secret key encryption like GPG, and queries or messages between users are end-to-end encrypted with both user’s keys, sounds good right? But wait! By default, when in a channel, its only encrypted from user to server and from server to the users in a channel, requiring you to trust the server. No thanks. You can get around this, if you had any clue that this was happening and knew how to get around it (hint: its complicated. You have to first agree amongst all the people who will be in a channel a server-independent channel-key that each client/user will have to set. With this set, then all traffic will be encrypted in that channel on an end-to-end basis, thus mitigating the MITM-attack on the server).

If you do manage to sort out the complications and arcana involved with setting up a channel founder, restricting a channel to be key restricted and finally setup a shared channel key secret that everyone actually uses, then you are set! Well, sort of. Getting this far is not for the faint of heart, not only is it really awkward, but there are also complications. If anyone joins the channel without setting their channel key properly they will have no idea that other people are talking on the channel, their cries of ‘can you hear me!?’ will go unheard because everyone is talking on a different channel. Thats frustrating, but once you understand it you can deal with it, but you must remember to set this channel key properly every time you join the channel. I haven’t mentioned how unstable the server has been (odd combinations of settings seem to cause it to segfault as well, try turning off all logging, that seems to mysteriously make things more stable). When the server restarts all the restrictions and security measures you painstakingly figured out and setup are completely lost. Try figuring out how to set a permanent founder, a +s secret channel so it doesn’t show up in the list of channels on the server, public-key channel authentication, and a shared channel key, and after you’ve got that all sorted out to loose it because whenever the server stops it looses all of that. Not only does it loose it but when it comes back up, the first person to rejoin the channel will become the channel founder with all the privileges, and unless they know how to setup all those restrictions, or how to pass the channel founder flag to someone who does, then the channel is wide-open until this is resolved. This is complicated and frustrating, its really hard to get someone who is using pidgin’s silc client to pass founder status to someone who knows how to re-setup everything, it may not even be possible because of the weak client support, and so you need to coordinate everyone leaving the channel, so you can join first….