Hi Travis; Agree with your analysis / interpretation. This is indeed about assuring the user on the encrypted leg that there is no MITM attack between encrypted UA and Freeswitch. Also agree that the unencrypted link is vulnerable to MITM / spoofing. Intend to handle this with physically secured LAN and, if any non-ZRTP UA's in the cloud, well, cannot assure security must be clearly understood. Under these conditions, given that no other (user friendly) way is provided to verify one legged ZRTP UA / Freeswitch SAS, believe this is worth doing, so, I am. My original question regarding where / how to call this script has been answered (duh, by me - on learning curve): just before bridge, and, it is getting called. I am now stuck at: Variable "zrtp_secure_media_confirmed_audio" (nor is zrtp_secure_media_confirmed) is never observed set on either one or two legged ZRTP calls. Have variable names changed? I am aware that I must modify zrtp_sas_proxy.lua to send the SAS to the unencrypted leg. Right now, stuck at lack of trigger condition above. Regards; Bill -----Original Message----- From: Travis Cross [mailto:tc@travislists.com] Sent: March-18-14 12:54 PM To: FreeSWITCH Users Help Cc: Bill Ross Subject: Re: [Freeswitch-users] ZRTP SAS to non ZRTP call leg UA? On 2014-03-16 21:52, Bill Ross wrote:
Trouble is trust. Us techhies have it, but end users have no basis. Would still like to do this and, also add a UA to display /speak other call leg SAS on demand.
The trouble with this in practice is that it requires users to have an excellent understanding of the security parameters. The non-ZRTP leg user must understand that the SAS does nothing to enhance the security of his call leg. The entire exercise is to enhance the security of the other call leg. It's something of a perversion of the SAS as it's not being generated by the client device. Or rather, you have to treat the PBX as the client device, and the non-ZRTP UA as simply a terminal to that actual client. You also have to be careful about training users to accept an SAS presented in an insecure place like the Caller ID field or via an automated read-back. Attackers can trivially exploit user comfort with that behavior. The script is there because Phil wanted to use it. But Phil may be the only person I would trust to use this sort of thing regularly without getting confused about the awkward security situation.