Re: [reSIProcate] Mutual TLS / From and Referred-By header authentication issues
On 21/11/18 23:20, Daniel Pocock wrote:
>
> On 16/11/18 18:42, Scott Godin wrote:
>> Hi Daniel,
>>
>>> What would you expect a phone to put in the From header of an in-dialog
>> REFER?
>>
>> I don't believe the phone has a choice. Since REFER is an in-dialog
>> request, the From header cannot be different from the To/From header
>> that was used to establish the call.
>>
>> I like the idea of tracking that the dialog was already authenticated
>> (ie: from the INVITE) and as long as future requests arrive on the same
>> TLS connection, then mid-dialog requests don't need to be checked.
>>
>
> Currently, the CertificateAuthenticator is not authenticating[1] the
> headers for any ACK or BYE request, so this issue doesn't arise for
> those methods. That is much the same[2] in DIGEST authentication.
>
> A similarly loose approach could permit other methods through a proxy
> under the right conditions, for example, if both the To and From tags
> are present. If the tags were forged then the UAS would hopefully
> reject the request and if TLS is used end-to-end then no eavesdropper
> could sniff and replay the correct tags.
I implemented that for CertificateAuthenticator (in the repro proxy):
https://github.com/resiprocate/resiprocate/commit/d3dcaba3dde3c522087a59c22553934ad1edab7d
and if this seems sensible, I can add it to TlsPeerAuthManager (for DUM)
We could also have a config option for this behaviour if it is not
suitable for every user.
When I look at the logs, I notice it actually helps reduce load on the
database too, as a lot of in-dialog NOTIFY requests don't need to be
authorized after the To-tag is added.
> The CSeq value doesn't appear to be helpful in this case because it
> doesn't have to start at 1 for the first request in a dialog. Apart
> from checking the presence of a To tag, is there any other hard rule for
> determining if a request is for an existing dialog?
>
> A stronger validation mechanism might be harder to achieve though if
> outbound is to be supported. If all requests go through the same proxy,
> then the proxy can build a map of dialogs to certificates. In the case
> of outbound, the UA can maintain connections to multiple proxies in
> parallel and all those proxies would need to share the state
> information. That is achievable but would introduce extra complexity,
> so I wonder if the former approach would be sufficient and secure for
> most cases.
>
> Regards,
>
> Daniel
>
>
> 1.
> https://github.com/resiprocate/resiprocate/blob/master/repro/monkeys/CertificateAuthenticator.cxx#L80
> 2.
> https://github.com/resiprocate/resiprocate/blob/master/repro/monkeys/DigestAuthenticator.cxx