[asterisk-dev] [svn-commits] mmichelson: branch 12 r399083 - in /branches/12: include/asterisk/ res/

Mon Sep 16 13:16:54 CDT 2013

16 sep 2013 kl. 19:30 skrev Matthew Jordan <mjordan at digium.com>:

> 
> On Mon, Sep 16, 2013 at 6:31 AM, Olle E. Johansson <oej at edvina.net> wrote:
> 
> 16 sep 2013 kl. 11:40 skrev Saúl Ibarra Corretgé <saghul at gmail.com>:
> 
> >
> > [snip]
> >
> >> After reading your e-mail and the RFCs, I don't have a clear
> >> understanding either of all of the issues surrounding usage of a SIPS
> >> URI instead of a SIP URI with TLS as transport. The fact that SIPS does
> >> not equate to "best-effort" TLS obviously has implications if hops in
> >> the middle don't support TLS (you either think you're secure but aren't,
> >> or your calls fail, or... something else perhaps?). What I don't have a
> >> clear understanding of is why we should prefer SIP with TLS as the
> >> transport over SIPS. Couldn't a user make the argument that they really
> >> don't want "best-effort" - that is, if they asked for secure
> >> communication, they want secure communication along the entire path?
> >> What explicit pitfalls are we running into by using SIPS in the URI in
> >> the contact header?
> >
> > FWIW, I'll just throw here what we do in Blink. I know it's not kosher as per the standard, but oh well, world is not perfect: we ignore SIPS. We basically treat it as it were "sip:". And we use transport=tls.
> >
> > I know Olle will want to slap me in the wrist, but that's what has worked so far out there in the wild. Sue me! ;-)
> 
> I'll take care of the slapping when we're on tour. :-)
> 
> We are several who have voted for deprecating SIPS: totally. The meaning is very unclear and the
> benefits of using it even more so.
> 
> The important fact is that in this case we don't know if the other UA used udp, tcp or TLS - just the
> fact that we get a request over a TLS connection doesn't mean that we can upgrade to SIPS:.
> Could be a proxy or a b2bua that upgraded to TLS based on NAPTR or policy. Adding sips: in a
> contact without getting an inbound complete SIPS: request (with all the right headers in place) will break
> communication.
> 
> Based on your above comment - and since this particular commit is concerned with generating Contact headers when creating a server side SIP dialog when using TLS - I think we can break down our questions into three categories:
> 
> 1. The Contact header URI scheme. Should we mirror Blink's behavior and just use SIP URIs for all Contact headers? Should we, under certain circumstances, generate a SIPS URI in our Contact header? Under what circumstances should we feel it safe to do so?
If the incoming request target is sips: and the other headers (according to the RFC) are compliant with the requirements for SIPs you have to add a SIPS uri to the contact. The follow-up question is of course if you can honour this request and never ever forward it to a sip: uri over udp. 

> 
> 2. The Contact header transport parameter. Should we ever put ";transport=tls" in our Contact header? When we wish to be contacted over TLS, should we put any sort of transport parameter in our Contact header? If not, how do we indicate that we wish to be contacted over TLS?
Doing that may break communication. Normally a proxy in the path will record route and reuse the connection so we're talking edge cases here. The contact will not be used as the next hop target from the other end, only for the last hop. If there's no route set defined for the dialog, you may have an issue if the other end does not support TLS by doing this. That UA may not be able to continue the dialog and communication will break down. 
I think you just have to rely on the route set keeping TLS.

You have to be prepared for upgrades from udp to tcp during a call, so adding a transport parameter will lock down the possibilities. Adding transport=udp is not needed and will break communication if there's a need to switch to TCP.

Your question is still interesting.  If you really really want to force TLS for some reason, you could add transport=TLS. Make sure you have TLS in the via headers for outbound messages as well. Before doing that, I would really inspect all via's and record-routes to make sure that every server and UA involved in the call supports TLS.

> 
> 3. The potential effects that 1. and 2. have on the rest of the SIP traffic Asterisk generates for this dialog. What other areas do you have in mind that might be affected? Some headers are likely taken care of for us by the SIP stack, (Route, Via, etc.)  but there may be others that we are not thinking of.
> 
See above. If the proxy talking to you in the first transaction gets out of the loop, transport may change. Only for SIPS uri's you are locked to one single transport. The effect of SIPS handling on the PBX needs to be taken care of if you really want to support SIPS. Can we automatically deny the call if it's forwarded over an insecure skinny connection? Is ISDN secure enough to be accepted? When you start thinking about that you will soon realize that SIPS: doesn't really deliver what it was meant to do. S/MIME could possibly do that, but then we have an issue with b2bua's like Asterisk...

Try to not mix the SIPS: uri, which is a request for privacy protection, with TLS. TLS can be used for any request uri, but HAS TO BE used for SIPS:

Yes, it's unfortunate that the tls tag for DNS SRV is also "sips". Leads to a lot of misunderstandings. I don't think not supporting SIPS: would mean any harm. I do not recommend following Saghul and downgrading to SIP:  ;-)

Instead of SIPS: support I would suggest proper SIP domain support with  proper TLS certificate handling compared with the current chan_sip. But that's another story altogether.

> Thanks!
You're welcome.

/O
> 
> Matt
> 
> -- 
> Matthew Jordan
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev

---
* Olle E Johansson - oej at edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130916/8fd30ce4/attachment-0001.htm>