[Freeswitch-users] ZRTP SAS to non ZRTP call leg UA?

[Bill Ross]

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 at 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.