Re: Bug in SRTP when pjsua_acc_config.use_srtp == PJMEDIA_SRTP_OPTIONAL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I see my mistake.   I misunderstood the settings and I tried to apply
them globally, not realizing that I can apply them per account when
I'm about to make the call.  I do that now in my application and I get
the control I desire.

My thanks to Colin and Johan for their input.

On Mon, Apr 10, 2017 at 10:26 AM, Colin Morelli <colin.morelli@xxxxxxxxx> wrote:
> To be clear, PJMEDIA_SRTP_OPTIONAL does not require you to call a SIPS URIs.
> It simply allows SDPs to include both SRTP and RTP. The signaling
> constraints are driven entirely by the srtp_secure_signaling setting.
>
> The issue you're running into here is this: you've told PJSIP that SRTP is
> optional. As a result, it should offer both SRTP and non-SRTP when it
> generates an invite. Now, when you place a call, it adds both SRTP and RTP,
> but the default setting for srtp_secure_signaling does not allow PJSIP to
> send an invite containing SRTP invite over a non-TLS connection
> (understandably, because in most cases this would be pointless because
> establishing an SRTP call when the keys are exchanged in plaintext is a
> pointless exercise in security).
>
> Now, as far as I'm aware, there's no way to selectively generate an SRTP or
> RTP invite based on the scheme of the destination you're calling (which I
> believe would be ideally what you'd want). However, if you set
> srtp_secure_signaling to 0, PJSIP will not require that SRTP keys are
> exchanged via a TLS connection. This should allow you to use
> PJMEDIA_SRTP_OPTIONAL with non-TLS signaling. Note that it has the
> side-effect of allowing SRTP keys to be exchanged over any type of
> connection; however, based on the fact that you already want your client to
> be able to selectively connect to either secure or insecure transports, I
> don't think this does much more to compromise security. As long as you
> ensure that when you truly want a secure call, you will signal over TLS
> also, it shouldn't be a huge issue.
>
> Probably, the right long-term answer here would be to get your client to
> always call via SRTP, possibly adding a proxy in the middle where required
> if you need SRTP termination. However, I assume that's not an option and/or
> not feasible at this time.
>
> Hopefully, that helps.
>
> Best,
> Colin
>
> On Mon, Apr 10, 2017 at 10:15 AM, David Talmage <sip.phone.fan@xxxxxxxxx>
> wrote:
>>
>> Thanks, Johan.  Perhaps I misunderstood the SRTP settings.
>>
>> I need a way that I can make calls to both SIP: and SIPS: URIs.  When
>> I make a call to a SIPS: URI, I want to use SRTP.
>>
>> The code in its current state does not allow me to do that.  If
>> use_srtp is set to PJMEDIA_SRTP_OPTIONAL, the code requires me to call
>> SIPS: URIs.
>>
>> The documentation isn't as clear as I need it to be.  The
>> documentation for use_srtp says that I can make SRTP not used at all,
>> optional, or mandatory. For optional SRTP, the documentation addresses
>> only incoming calls.
>>
>> On Mon, Apr 10, 2017 at 4:41 AM, JOHAN LANTZ <johan.lantz@xxxxxxxxxxxxxx>
>> wrote:
>> > Maybe I misunderstand your question but are you sure you problem is not
>> > the acc->cfg.srtp_secure_signaling setting?
>> >
>> > If that is set to require a secure signalling transport when SRTP is
>> > used, changing the value of pjsua_acc_config.use_srtp is probably not going
>> > to help if you use a non secure address.
>> >
>> > IIRC pjsua_acc_config.use_srtp basically checks if the sdp info contains
>> > RTP/AVP or RTP/SAVP and PJMEDIA_SRTP_OPTIONAL would allow both to pass but
>> > that is not related to the sip vs sips in the signalling part.
>> >
>> > Johan
>> >
>> >
>> >
>> > On 07/04/2017, 18:46, "pjsip on behalf of David Talmage"
>> > <pjsip-bounces@xxxxxxxxxxxxxxx on behalf of sip.phone.fan@xxxxxxxxx> wrote:
>> >
>> >>I think I found a bug in the way that PJSIP handles the SRTP settings.
>> >>Would someone please confirm this?
>> >>
>> >>When pjsua_acc_config.use_srtp is not PJMEDIA_SRTP_DISABLED, PJSIP
>> >>requires SRTP and all calls must be addressed to a sips: URI. PJSIP
>> >>rejects calls to sip: URIs with the status code
>> >>PJSIP_ESESSIONINSECURE.
>> >>
>> >>The behavior I expect is for PJSIP to fall back to an insecure call
>> >>when the destination URI is sip: and the value of
>> >>pjsua_acc_config.use_srtp is PJMEDIA_SRTP_OPTIONAL.
>> >>
>> >>The mistake is in pjsua_media.c:call_media_init_cb().  Here is the code:
>> >>
>> >>    /* Check if SRTP requires secure signaling */
>> >>    if (acc->cfg.use_srtp != PJMEDIA_SRTP_DISABLED) {
>> >>        if (security_level < acc->cfg.srtp_secure_signaling) {
>> >>        err_code = PJSIP_SC_NOT_ACCEPTABLE;
>> >>        status = PJSIP_ESESSIONINSECURE;
>> >>        goto on_return;
>> >>        }
>> >>    }
>> >>
>> >>I don't have a working solution yet.  It looks easy but perhaps there
>> >>will be unintended consequences.
>> >>
>> >>_______________________________________________
>> >>Visit our blog: http://blog.pjsip.org
>> >>
>> >>pjsip mailing list
>> >>pjsip@xxxxxxxxxxxxxxx
>> >>http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>> > _______________________________________________
>> > Visit our blog: http://blog.pjsip.org
>> >
>> > pjsip mailing list
>> > pjsip@xxxxxxxxxxxxxxx
>> > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip@xxxxxxxxxxxxxxx
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip@xxxxxxxxxxxxxxx
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>

_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
pjsip@xxxxxxxxxxxxxxx
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org



[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux