Opened 11 years ago
Last modified 10 years ago
#1735 closed enhancement
Terminate the call if 200/OK response to INVITE to SIPS target is not secure — at Version 1
Reported by: | bennylp | Owned by: | bennylp |
---|---|---|---|
Priority: | normal | Milestone: | release-2.3 |
Component: | pjsua-lib | Version: | trunk |
Keywords: | Cc: | peter | |
Backport to 1.x milestone: | Backported: | no |
Description (last modified by nanang)
The standard says that a SIPS dialog should be secure end to end. However some proxies or UASes disobey this requirement and give back plain SIP URI in the Record-Route or Contact header. We should terminate such call.
This ticket will implement Contact/Record-Route header checks in incoming initial/subsequent INVITE/UPDATE request or 2xx response to INVITE/UPDATE. Contact URI should use "sips" scheme and Record-Route URI should use either "sips" scheme or "transport=tls" param. As UAC, if it receives 200/OK response to initial/subsequent INVITE/UPDATE with insecure Contact/Record-Route, it will terminate the session. As UAS, if it receives initial/subsequent INVITE/UPDATE request with insecure Contact/Route headers, it will send response with SIP status code 480 and Warning header: 381 "SIPS required".
This feature can be disabled by setting pjsip_cfg()->endpt.disable_secure_dlg_check to PJ_TRUE (default is PJ_FALSE).
Here are some texts from the standard:
- All hops must use TLS (should we check if all Record-Route URIs use "sips" scheme or "transport=tls" param? Currently we'll just check the top Record-Route header)
- http://tools.ietf.org/html/rfc5630#section-4:
This document specifies that SIPS means that the SIP resource designated by the target SIPS URI is to be contacted securely, using TLS on each hop between the UAC and the remote UAS (as opposed to only to the proxy responsible for the target domain of the Request- URI).
- http://tools.ietf.org/html/rfc5630#section-4:
- Contact header must use "sips" scheme:
- in request
http://tools.ietf.org/html/rfc5630#section-5.1.1:
As mandated by [RFC3261], Section 8.1.1.8, in a request, "if the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well".
- in target refresh
http://tools.ietf.org/html/rfc5630#section-5.1.1.2:
When a target refresh occurs within a dialog (e.g., re-INVITE request, UPDATE request), the UAC MUST include a Contact header field with a SIPS URI if the original request used a SIPS Request-URI.
- in response
http://tools.ietf.org/html/rfc3261#section-12.1.1:
If the request that initiated the dialog contained a SIPS URI in the Request-URI or in the top Record-Route header field value, if there was any, or the Contact header field if there was no Record- Route header field, the Contact header field in the response MUST be a SIPS URI.
- in request
http://tools.ietf.org/html/rfc5630#section-5.1.1: