sipsorcery's blog
Occassional posts about VoIP, SIP, WebRTC and Bitcoin.
Occassional posts about VoIP, SIP, WebRTC and Bitcoin.
When mysipswitch was first conceived it was one of those things that could easily have ended up lasting a few months as such the software was written very much as a prototype and wherever a shortcut could be taken it was. One of those shortcuts was to allow access to the mysipswitch real-time log messages via telnet. The problem with telnet is that it transmits data in cleartext meaning anyone able to capture the authentication packets can obtain usernames and passwords. The choice for mysipswitch at the time was to provide the log messages over telnet or not provide them at all since incorporating a more secure mechanism would have taken more time and effort than was available.
In practice it’s actually quite difficult for an arbitrary attacker to capture packets on the internet. Sure it’s easy on a compromised PC, on a LAN or for a network admin at an ISP but apart from that it’s a lot of effort. An attacker who has gone to that level of effort and has compromised a core router or similar is likely to be looking for a return on investment and is going to be after credit card details, online banking passwords etc. and very unlikely to be interested in usernames and passwords for a esoteric SIP aggregator service.
Now that I have a little bit more time on my hands over the last two or so months I have been incorporating an SSH daemon into sipsorcery to replace the telnet one. In addition the console monitoring available in the Silverlight client has been modified to allow it to work over a secure channel. Previously it used a plain text TCP socket connection and while no usernames and passwords were transmitted over it a time limited authorisration token was and the log messages from the sipsorcery server were sent on it. To fix that a new HTTP duplex mechanism has been added so that the login and log messages to and from the silverlight client will now be transmitted over SSL. It’s proven somewhat tricky to implement the HTTP duplex mechanism as HTTP is a request/response protocol and doesn’t lend itself to pushing information to the client. At the moment it works in spurts but then IIS will give up the ghost and decide it can’t talk to the sipsorcery monitoring service and refuse to process any requests. I’ve disabled the server side of the logging while I continue to work on it but am hopeful it will be sorted out soon.
For the SSH monitoring that is working but it to has been restricted as there is an issue with it that when probed by the script kiddies doing their never ending trawls across the internet on port 22 it freezes up the sipsorcery SSH daemon. It’s new software so that’s not entirely suprising but to avoid the whole sipsorcery service being affected I’ve limited access to the SSH port. Again I’m hopeful to have the problem sorted out in the near future.
While this work is ongoing the telnet monitoring option has been turned off and barring any unforseen complications will be gone for good.
