search

tomek-o / tSIP

SIP softphone
148 stars 32 forks source link

Support for encryption? #10

Closed wolrah closed 2 years ago

wolrah commented 4 years ago

It does not look like there is currently support for SIP over TLS or SRTP.

Am I correct about that or did I miss something?

Assuming I'm correct, is that a feature you'd be willing to put on the roadmap? It's not a critical feature to me at the moment but it would certainly be nice to have.

Great work otherwise though, this is so far the only open source softphone I've used where the BLF actually works the way it should.

tomek-o commented 4 years ago

You are right, there is no TLS and SRTP (nor ZRTP for that matter) at the moment. I have some problems with TLS:

I don't have any fixed roadmap at the moment (but I have quite long list of TODOs and TLS is also there). Let's leave it open, but no promises.

wolrah commented 4 years ago

Thanks for the response. A couple of thoughts on your points:

  • my "main" PABX does not support this (although I see that sip2sip.info can be used for testing)

If testing is ever the primary issue, FreePBX has a wizard for getting a certificate from Let's Encrypt, then it's a few clicks in settings from there to enable TLS. IIRC FusionPBX was also working on some kind of automation for this, but I haven't been following it too closely recently.

I could also provide access to a server in my network. I have production systems on Asterisk and Freeswitch plus test systems on basically any platform I can run.

  • I think demand is pretty low - I've received maybe 3 or 4 e-mails on this subject, last one at the beginning of January

Can't argue this. I have ~2000 phones and literally two are using SIP/TLS, and those two are both mine. None of my customers have ever asked me about it, not even the industries where they probably should be using it.

  • I probably wouldn't use it frequently myself, user base is rather low and TLS adds another layer of complexity and potential interoperability issues

Can't argue this either.

  • it might be silly, but I don't like that it adds ~1.5MB when linked statically (not sure if static linking would be right here, but this is the number from some other application)

Some other VoIP projects like OpenSIPS support being built both with and without TLS support, presumably with something along these lines being at least one of the reasons. Something to consider, I totally get not wanting to bloat your binary.

I don't have any fixed roadmap at the moment (but I have quite long list of TODOs and TLS is also there). Let's leave it open, but no promises.

Sounds good. If you ever decide you feel like going for it, ping me and I'll help testing in any way I can. Thanks again.

tomek-o commented 4 years ago

Thanks for the feedback.

If testing is ever the primary issue, FreePBX has a wizard for getting a certificate from Let's Encrypt, then it's a few clicks in settings from there to enable TLS. IIRC FusionPBX was also working on some kind of automation for this, but I haven't been following it too closely recently.

Although AFAIK this would be only for servers with public domain name. Otherwise only option would be using own CA or ignore certificate error and proceed anyway.

wolrah commented 4 years ago

Although AFAIK this would be only for servers with public domain name. Otherwise only option would be using own CA or ignore certificate error and proceed anyway.

Yes, you are correct. The Let's Encrypt wizard built in to FreePBX uses the HTTP-01 challenge method which requires that the system requesting the certificate can make a file available to the internet via port 80 at the DNS name(s) the cert is for. There's an option to expose only a special endpoint where nothing but the validation file is available so you don't have to expose your actual web interfaces to the world, but if you can't accept any incoming connections at all it of course becomes more complicated.

Not much more complicated mind you, thanks to scripts like acme.sh automating the hard parts as long as you're using a major DNS provider, but certainly no longer point and click.

InterLinked1 commented 3 years ago

I second everything wolrah said. I have previously been using MicroSIP for soft phones until now and I just found out about tSIP. Wow - this is superior in pretty much every way! Except... no TLS/SRTP. This is kind of a big deal as the switch is not located in the same building so calls go over the public Internet. So, it would be really great to have it. Likewise, I have a few Asterisk machines if you ever need help testing. The only thing I disagree with is that TLS/SRTP is no longer a niche thing. It is essential. We use MicroSIP in the financial industry and it would be a huge no-no if calls were not encrypted. So this would be the only thing stopping us from upgrading to tSIP. The big reasons I like tSIP more are support for A-D, even if they are removed, since I use those occasionally, and an actual FLASH button. Everything else is icing on top. If TLS/SRTP could be added, this would be perfect. Thank you for the consideration!

tomek-o commented 3 years ago

support for A-D, even if they are removed

Just to clarify, A-D were removed from "fixed"/static part of the GUI/keyboard 6 years ago, but they still can be added by the user as programmable "DTMF" keys and/or used from scripts.

InterLinked1 commented 3 years ago

support for A-D, even if they are removed

Just to clarify, A-D were removed from "fixed"/static part of the GUI/keyboard 6 years ago, but they still can be added by the user as programmable "DTMF" keys and/or used from scripts.

Yeah, sorry, I should've worded that better - I meant part of the custom buttons instead of the main keypad. My only peeve here is that the buttons aren't the same size and don't align properly, since A should be exactly to the right of 3, B to 6, C to 9, and D to *, and since the heights are different, the alignment is off, but I haven't played too much with the customizations for those so there might be a way to do that. Still need to play around more!

tomek-o commented 3 years ago

A should be exactly to the right of 3, B to 6, C to 9, and D to *, and since the heights are different, the alignment is off, but I haven't played too much with the customizations for those so there might be a way to do that.

Yeah, with versions 0.1.x button height and button margins can be used for alignment. Version 0.2 adds about a dozen new settings for programmable buttons, they can be freely positioned/resized. tSIP_0_2_basic_btn_container

InterLinked1 commented 3 years ago

Yeah, with versions 0.1.x button height and button margins can be used for alignment. Version 0.2 adds about a dozen new settings for programmable buttons, they can be freely positioned/resized. tSIP_0_2_basic_btn_container

Yup, I was able to figure it out. I'll play around some more and add a template. I guess I have the two volume bars in the middle but close enough.

It seems the number buttons cannot be modified. Any way to make them show the letters, e.g. 2 = ABC, 7 = PRS... 0 = OPER? MicroSIP has letters on the buttons. I can't seem to be able to add these using Caption 2 either, there are no modification options. This makes dialing using letters difficult.

tomek-o commented 3 years ago

It seems the number buttons cannot be modified.

I've moved this to https://github.com/tomek-o/tSIP/issues/22.

tomek-o commented 2 years ago

TLS and SRTP were added in https://github.com/tomek-o/tSIP/commit/cd59079679504fcb029ae255543b11483a08cef4, http://tomeko.net/tmp/tSIP_0_2_04_2_bin.7z .

It is only shortly tested at the moment and I'm not sure if this should be always compiled or only optional - this adds requirement libcrypto-1_1.dll and libssl-1_1.dll and indirectly Visual Studio 2015 runtime (required by OpenSSL dlls).

New configuration elements:

To get certificate chain details for test servers I've used command line openssl: openssl s_client -showcerts -verify 5 -connect proxy.sipthor.net:5061 openssl s_client -showcerts -verify 5 -connect iptel.org:5061 Apparently sip2sip.info requires CA from https://www.identrust.com/dst-root-ca-x3 and iptel.org https://letsencrypt.org/certs/isrgrootx1.pem.txt (though iptel.org certificate is expired at the moment).

wolrah commented 2 years ago

Consider me quite happily surprised to see this post!

I can confirm that it does seem to work at a basic level, I have successfully connected to my TLS server and made a test call.

I did have to combine both the ISRG Root X1 and Let's Encrypt R3 PEMs in to a single file and manually select that to get it to connect. Is this an intentional design decision, having to configure trusted CAs manually, or is it just an artifact of a "quick and dirty" implementation where automatically trusting the system trusted CAs takes extra work that wasn't needed to get the feature usable?

tomek-o commented 2 years ago

Is this an intentional design decision, having to configure trusted CAs manually, or is it just an artifact of a "quick and dirty" implementation where automatically trusting the system trusted CAs takes extra work that wasn't needed to get the feature usable?

More of the latter I guess, this was most straightforward copy of baresip code so far and I wasn't thinking of anything non-essential. I would also wonder if these certificates are included in system store - my guess is that browsers (most common usage) are relying on built-in certificates by default. Wine compatibility would also matter for me.

wolrah commented 2 years ago

More of the latter I guess, this was most straightforward copy of baresip code so far and I wasn't thinking of anything non-essential.

Completely understandable, I have never directly had to implement anything dealing with TLS, my stuff just passes a URL to a library and lets it do it's thing, so I wasn't sure whether the use of system certificate stores was something that "just worked" or had to be explicitly coded for. Sounds like it's the latter so as you said it's not essential to most use cases.

I would also wonder if these certificates are included in system store

https://letsencrypt.org/docs/certificate-compatibility/ indicates that the ISRG root should be trusted by default on any all OSes that are worth supporting and that the DST root should be trusted by default on almost anything still in use at all.

my guess is that browsers (most common usage) are relying on built-in certificates by default. Wine compatibility would also matter for me.

Obviously the various OS-provided browsers use the OS-provided certificate store.

Firefox uses Mozilla's certificate store that is part of their NSS library but can be configured to also use the system store.

Chrome uses the system certificate store as well on Windows and Mac. On Linux they use the NSS store.

I would imagine Wine implements a Windows-style certificate store, but I can't say I've ever had to install a custom root for a Wine application so I have no idea how that works.

wolrah commented 2 years ago

After a bit of looking around it seems like baresip's use of libSSL makes use of the Windows native store less than straightforward but it can be done.

cURL recently added that capability, perhaps their implementation might be of interest https://github.com/curl/curl/blob/abbc5d6044f95ba84acaae6912b2d097c6b435d1/lib/vtls/openssl.c#L2819

InterLinked1 commented 2 years ago

Consider me pleasantly surprised as well! I am excited about this.

Seems to work with TLS 1.2 and SRTP, once I disable certificate validation.

I do see the following error with PJSIP on my Asterisk server:

15:55:52 WARNING[13707] pjproject: SSL SSL_ERROR_SSL (Handshake): Level: 0 err: <336151576> <SSL routines-ssl3_read_bytes-tlsv1 alert unknown ca> len: 0 peer: REDACTED:61111

Probably because I passed by the certificate validation, so expected. Tested some basic calls, all good. Really great to see!

This is at the point now where I can now switch to tSIP as my primary softphone program, and this will probably be our program of choice at work now as well.

The certificate settings for TLS right now are flexible, and I wonder if maybe we could even take that further. It seems like it would be easy to add provisioning to this, since a client certificate could be added, which could then be used to present itself to a provisioning server. Since you accept JSON for config, maybe the provisioning server could then spit out JSON templates to provision the program (server/username/password, etc.). Haven't really thought this through yet. But this is really great, thank you and ten thumbs up!

InterLinked1 commented 2 years ago

To add on to my previous thoughts, I personally think it should always be compiled, rather than optional/add-on. It is an important security feature that is no longer really optional for many people/companies/deployments. No TLS support is a dealbreaker if I look at softphones for approving for corporate use, as just one example.

At the very least, this should be the "standard" version and there could also be a "lite" version that didn't have TLS/SRTP. It's worth the small overhead to most people, I think. I use MicroSIP Lite because I don't need video support, but TLS/SRTP is a basic thing nowadays, not really an add on.

tomek-o commented 2 years ago

After a bit of looking around it seems like baresip's use of libSSL makes use of the Windows native store less than straightforward but it can be done.

cURL recently added that capability

http://tomeko.net/tmp/tSIP_0_2_04_3_bin.7z (only exe changed inside) adds checkbox in "TLS" to use Windows ROOT store, enabled by default. Seems to work with sip2sip.info.

tomek-o commented 2 years ago

The certificate settings for TLS right now are flexible, and I wonder if maybe we could even take that further. It seems like it would be easy to add provisioning to this, since a client certificate could be added, which could then be used to present itself to a provisioning server. Since you accept JSON for config, maybe the provisioning server could then spit out JSON templates to provision the program (server/username/password, etc.).

I've made some simple provisioning example a while ago (https://tomeko.net/software/SIPclient/howto/provisioning.php) and I would still recommend using curl for these purposes. Of course it could use client certificate shared with SIP, though I'm not sure if any popular SIP system actually uses client certificates. The main difficulty would still be organization, like generating and storing user certificates or user names and passwords and identifying users. Convenience is in opposition to security. Yealink desk phones are using MAC for identification, it might be less reliable with PCs though and this works only in LAN and is insecure (same as all vendor-based provisioning services in my opinion), though it might be acceptable due to LAN limitation. I guess it really depends on organization size and trust - LAN provisioning at my workplace would allow me to get credentials for any users that have it enabled, but I would just see no point in it.

InterLinked1 commented 2 years ago

The certificate settings for TLS right now are flexible, and I wonder if maybe we could even take that further. It seems like it would be easy to add provisioning to this, since a client certificate could be added, which could then be used to present itself to a provisioning server. Since you accept JSON for config, maybe the provisioning server could then spit out JSON templates to provision the program (server/username/password, etc.).

I've made some simple provisioning example a while ago (https://tomeko.net/software/SIPclient/howto/provisioning.php) and I would still recommend using curl for these purposes. Of course it could use client certificate shared with SIP, though I'm not sure if any popular SIP system actually uses client certificates. The main difficulty would still be organization, like generating and storing user certificates or user names and passwords and identifying users. Convenience is in opposition to security. Yealink desk phones are using MAC for identification, it might be less reliable with PCs though and this works only in LAN and is insecure (same as all vendor-based provisioning services in my opinion), though it might be acceptable due to LAN limitation. I guess it really depends on organization size and trust - LAN provisioning at my workplace would allow me to get credentials for any users that have it enabled, but I would just see no point in it.

Client certificates are typically used for SIP provisioning.

For instance, I have Grandstream and Cisco ATAs which I provision over HTTPS. They connect to my provisioning server and request a config. They have client certificates which I can validate against the root client CA to ensure that the MAC isn't spoofed and they are who they say they are.

Not quite sure what you mean by "LAN only", I provision ATAs over the WAN by MAC. Not in an insecure way, either.

Obviously, MACs can't be used as unique identifiers with soft-phones, so I'm not entirely sure how to approach this kind of thing from that aspect. However, I saw that client certs could be added so conceivably something similar could be done, as you described. With http basic auth, there's also more flexibility.

I suspect some things, like custom ring cadences, would just need to be packaged with what's provided to users, which is easy enough, but the remaining settings could all be provisioned.

I really do believe this is the softphone of the future - open source, flexible, feature-rich, customizable, supports provisioning, etc. If only I could get those Mac users out there to switch to PCs!

tomek-o commented 2 years ago

Not quite sure what you mean by "LAN only"

I'm mostly used to so called "PnP provisioning" - PABX joins multicast group with address specified by phone manufacturer, phones with no prior configuration (or after factory reset) send SUBSCRIBEs to this fixed address, PABX sends back NOTIFY with address of the HTTP/HTTPS/FTP/... server that has configuration file. Convenient (phone is configured right after pulling out of the box if its MAC was put in a system earlier or there is some automation) but insecure.

InterLinked1 commented 2 years ago

I'm mostly used to so called "PnP provisioning" - PABX joins multicast group with address specified by phone manufacturer, phones with no prior configuration (or after factory reset) send SUBSCRIBEs to this fixed address, PABX sends back NOTIFY with address of the HTTP/HTTPS/FTP/... server that has configuration file. Convenient (phone is configured right after pulling out of the box if its MAC was put in a system earlier or there is some automation) but insecure.

What part of this is in secure, though? That the PABX is sending the address of the provisioning server in the clear? This sounds like the "option 66" that usually causes issues on smaller networks where it was not intentionally set. I generally just do one-touch provisioning, where I put in the provisioning server address and off it goes, since equipment is not all on the same LAN.

Assuming the address is https and MTLS is being used, it sounds secure to me.

tomek-o commented 2 years ago

Assuming the address is https and MTLS is being used, it sounds secure to me.

Maybe it changed with time, but I don't think older yealinks (T2x/T3x) have any preinstaled client certificates - there was no protection against spoofing.

InterLinked1 commented 2 years ago

Assuming the address is https and MTLS is being used, it sounds secure to me.

Maybe it changed with time, but I don't think older yealinks (T2x/T3x) have any preinstaled client certificates - there was no protection against spoofing.

Got it, I see now. Yes, I mostly deal with Grandstream and Cisco/Linksys/Sipura ATAs, all of which have client certs pre-installed so that mutual TLS/authentication can be done, so MAC spoofing is generally not a concern.

wolrah commented 2 years ago

http://tomeko.net/tmp/tSIP_0_2_04_3_bin.7z (only exe changed inside) adds checkbox in "TLS" to use Windows ROOT store, enabled by default. Seems to work with sip2sip.info.

Worked perfectly for me as soon as I figured out that my server wasn't sending the full certificate chain due to a FreePBX bug. This is probably also why I had to combine two certificates to get it working in the previous version. I can now connect with full validation using a publicly trusted certificate without any manual configuration required beyond the basic credentials and selecting TLS, Wonderful!

AlexAMCS commented 1 week ago

Just adding that there is no way to setup TLS for the Outbound Proxy, and I'd really need it, but everything else kinda works fine.

tomek-o commented 1 week ago

Just adding that there is no way to setup TLS for the Outbound Proxy, and I'd really need it, but everything else kinda works fine.

@AlexAMCS Could you try https://tomeko.net/tmp/tSIP.exe using ;transport=tls parameter for outbound proxy (e.g. 192.168.0.52;transport=tls)?

AlexAMCS commented 1 week ago

@AlexAMCS Could you try https://tomeko.net/tmp/tSIP.exe using ;transport=tls parameter for outbound proxy (e.g. 192.168.0.52;transport=tls)?

It worked! Got calls working too, tyvm.

tomek-o commented 1 week ago

;transport=tls parameter

@AlexAMCS For consistency with the main server configuration I've added now combobox for transport selection, so text-based parameter should not be necessary later (e.g. in https://tomeko.net/tmp2/tSIP.exe).