Hi list, I'm running a FS server @home to create a small network of people that need confidentiality upon their calls/conferences. I'm reading the SIPS/SRTP FS wiki page at this moment and I've got some questions: * I've a dyndns WAN name for my adsl box (that I loop on my DNS to the server LAN's name: nslookup extname.org => 192.168.1.50); so I suppose I must have the WAN name as the 'cn' in my cert/key for external clients being able to connect? (but what about internal ones?) * If I'm not using auto-nat, is forwarding port 5081 from the WAN to the server sufficient for making and receiving external calls? * BTW, SIP 5060 is supposed to be internal, so why is it also part of the uPNP forwards? * How can I force FS to only work in SSLv23 + SRTP modes? (how?) * Is there a possibility for each user to have its own certificate, so I would be able to revoke permissions atomically if needed? Jean-Yves -- We are Pentium of Borg. Division is futile. You will be approximated. (seen in someone's .signature)
Hello Jean-Yves, well common-name matching is not required by all sip clients but may be by some of yours. Yes you would want to set this set as the cn name. Assuming your FS box is run on your adsl box (or the important ports are forwarded to your FS box) you shouldn't run into an issue as you already handle the natted client problem by faking the dns entry for your cn name. FS should be able to handle both external and internal clients without an issue. While you can certainly issue certificates for each client (Infact its encouraged!) see http://wiki.freeswitch.org/wiki/SIP_TLS#Step_4_Client_Configuration for generating individual client certs easily (although make sure you are running HEAD), there may be an issue with revocation. I am not sure if revocation is currently enabled(or supported) in the libsofia stack. Test it and see, I would bet it isn't. As for getting it enabled first would be to verify its supported by libsofia first, checking the documentation at http://sofia-sip.sourceforge.net/ specifically http://sofia-sip.sourceforge.net/refdocs/tport/tport__tag_8h.html may be a good place to start. If it supports revocation but we don't expose it then it may be an easy change, if it doesn't its going to be a bit more of an uphill battle as you will have to patch it and our sofia to add the option for revocation checks. If you post back with your results I may be willing to help with the work to add this additional security feature (assuming it doesn't already work). Normally I would guess that you would actually have everyone connecting on 5061 (or whatever your tls port is) that are authed users. 5060 is meant for users who auth against the server vs 5080 being more of the public /outbound side of the server is somewhat of how I have always looked at it. As for forcing SSLv23 and SRTP thats pretty straightforward: http://wiki.freeswitch.org/wiki/Sofia_Configuration_Files#TLS documents the sofia options including: tls-only which will prevent sofia from even listening for un-encrypted connections. Settings tls-version to the sslv23 takes care of what version to use, the final is just how to ensure all calls are encrypted. As your clients can only connect encrypted with tls-only it takes care of ensuring the signalling channel is encrypted, to ensure SRTP just add sip_secure_media=true to the channel vars. ~Mitch
On Wed, 14 Mar 2012 08:24:39 -0700 Mitch Capper <mitch.capper@gmail.com> wrote: Hi Mitch,
and internal clients without an issue. While you can certainly issue certificates for each client (Infact its encouraged!) see http://wiki.freeswitch.org/wiki/SIP_TLS#Step_4_Client_Configuration
Oops, I sent my email before reaching this text.
for generating individual client certs easily (although make sure you are running HEAD), there may be an issue with revocation. I am not sure if revocation is currently enabled(or supported) in the libsofia stack. Test it and see, I would bet it isn't. As for getting it enabled first would be to verify its supported by libsofia first, checking the documentation at http://sofia-sip.sourceforge.net/ specifically http://sofia-sip.sourceforge.net/refdocs/tport/tport__tag_8h.html
Thanks for this links; unfortunately I didn't find any primitive nor comment that address this issue, and a: grep -Ri revo * in the source tree didn't returned any results. This is weird as it force to re-generate another couple crt/key and distribute it to non-revoked users :(
As for forcing SSLv23 and SRTP thats pretty straightforward: http://wiki.freeswitch.org/wiki/Sofia_Configuration_Files#TLS
Thank for the link.
documents the sofia options including: tls-only which will prevent sofia from even listening for un-encrypted connections. Settings tls-version to the sslv23 takes care of what version to use, the final is just how to ensure all calls are encrypted. As your clients can only connect encrypted with tls-only it takes care of ensuring the signalling channel is encrypted,
to ensure SRTP just add sip_secure_media=true to the channel vars.
That's exactly what I need:) JY --
JY, Keep in mind it may not quite be that simple as libsofia doesn't actually implement the ssl features it uses openssl, so the question is how does one enable revocation in openssl and is libsofia doing it:) It could be something like setting a CRL or the index or what have you so just grepping for revocation might not do it:) One other option is you could instead of using the CA cert have all the client certs catted together then if you want to revoke one of them you pull it out. Its clumsy but works right now:) ~Mitch
On Wed, 14 Mar 2012 09:34:15 -0700 Mitch Capper <mitch.capper@gmail.com> wrote:
One other option is you could instead of using the CA cert have all the client certs catted together then if you want to revoke one of them you pull it out. Its clumsy but works right now:)
This is a bit obscur to me Mitch, so I try to reformulate: Do you mean getting rid of the CA (the *whole* conf/ssl/CA?) and keeping only the clients certs in conf/ssl ? Without changing anything to the regular SIPS/SRTP conf? JY --
I believe if you replace cafile.pem with the contents of all the clients certs it will ensure that a connecting client cert matches a cert in that file. ~Mitch
On Wed, 14 Mar 2012 11:36:14 -0700 Mitch Capper <mitch.capper@gmail.com> wrote:
I believe if you replace cafile.pem with the contents of all the clients certs it will ensure that a connecting client cert matches a cert in that file.
Ha, ok, thanks Mitch I'll try that ASA my conf will be ok with regular way. -- Like winter snow on summer lawn, time past is time gone.
participants (2)
-
Bzzz
-
Mitch Capper