That requires an insecure DNS lookup. In any case, there is nothing to stop my creating a DNS A record for 192.76.120.10 and obtaining a certificate for the name I used. Ignoring that the DNS lookups are not protected by public key infrastructure, you would need to do a reverse lookup as well, which might be confused, as the reverse lookup, for that address, gives two domain names.
I don’t understand this, and I don’t think it is relevant. Asterisk only cares about the topmost record route;
Ooh, I missed that. For your trunk, try setting:
Outbound Proxy: sip:sip.telnyx.com:5061\;transport=tls\;lr\;hide
The suggestion here is that this may allow you to re-enable Verify Server. I think it might work.
Sorry, I don’t understand what is happening. Outbound proxy overridden by Record-Route? Outbound proxy not being applied to dialog? Something else?
I found
https://pjsip.pjsip.narkive.com/1OZdFjH2/pjsua-bye-issue-when-using-outbound-proxy
but as of the last post, it’s still not solved. More research needed.
I think this is a compromise you’re going to have to take unless you can convince Telnyx to put hostnames in their Record-Route header.
Twilio too.
Sounds a bit like they are treating the outbound proxy as a default route set, so if another one comes along (Record-Route) it is ignored.
SIP over TLS security works best with both ‘check client’ and ‘check server’ checked, you can fix ‘check client’ but it’s a royal pain every three months to distribute and deploy the new certs on every endpoint. More importantly, In the absence of ‘check server’ I venture that you are getting very little better security than just just using TCP transport unless you have ‘check client’ already working seamlessly.
One check you have control over, the other, not so much
Here is the latest response from Telnyx, which I don’t understand what they are trying to tell me. But perhaps someone here does understand and can help to explain.
I believe in layman’s terms what Telnyx is trying to tell me is that FreePbx is instructing Telnyx to use the IP address for return signaling and in reality FreePbx should be instructing Telnyx to use the FQDN for return signaling. Telnyx is simply responding via an IP address because that is what FreePbx is instructing Telnyx to do. Im not sure how to see this in the PCAP file provided by Telnyx.
It would appear to me when I look at the PCAP file from Telnyx perspective the initial BYE command sent from FreePbx is either being ignored or is never received by Telnyx. Thus the external phone never hangs up.
MESSAGE FROM TELNYX BELOW
After checking it details we could stop what caused the issue and what could be wrong on the Asterisk:
The BYE was sent from Telnyx to the Asterisk, but the latter rejected the BYE and didn’t process it, hence the call didn’t hang up from your side
The Asterisk rejected this BYE with a SIP “481 Call leg does not exist”, and that was because the BYE from Telnyx had a different Request URI (RURI for short) than the INVITE, and those should be equal;
The BYE’s RURI, per RFC, must be equal to the Contact header of the 200 OK sent by the Asterisk, and here is where lies the root cause, the asterisk had set the wrong Contact header, this MUST be equal to the RURI of the INVITE.
Screenshots and PCAPs are attached;
That being said, we suggest you check internally for any issues within your Asterisk configurations, there were no issues from our end.
We do have a possible cause: the SIP 481 ‘Call leg does not exist’, is a UAS response, which in this case is Telnyx Registrar, not the Asterisk, since the Asterisk is the one that needs to authenticate the SIP trunk with Telnyx, the asterisk becomes a UAC, that different within its configurations might be causing the problem. But again that’s just a starting point, we cannot act/analyze the internal functionalities outside Telnyx’ infrastructure.
Here is a dropbox link to the PCAP file from Telnyx’s persepctive ( not obfuscated ) .
Telnyx is asserting that they are inappropriately using the IP address for control communication because they are responding to what Asterisk is instructing them to do.
Telnyx says, Asterisk starts off by using a FQDN in its record route, but then later in the conversation changes to an IP address in its record route.
Telnyx then switches from using Asterisk’s FQDN to using the Asterisk machine’s IP address, which Asterisk then rejects because “server verification for TLS” is set for YES.
How can I test for this?
I’ve not analysed all of this, but the issue is with Telnyx’s FQDN, not Asterisk’s.
Both theories seem to be saying the same thing but putting the blame in a different spot.
Telnyx puts the blame on Asterisk and proponents here put the blame on Telnyx (would anyone expect anything different)?
How can I prove to Telnyx this is their problem?
Twillio also has this same problem. How can I prove to Twilio this is their problem?
All you can really do is to show that what they are doing would expose them to a man in the middle attack if the connection wasn’t aborted, as verifying that the address matches the common name cannot be done securely.
I cant really sell them on a man in the middle concept without poof of what they are doing wrong. How can I prove to them what is wrong?
For those new to this very long thread, here is a visual on what is happening;
I think it is probably so obvious that you cannot ask someone to connect to anything other than the common name on the certificate that it may well not be explicitly specified. I suppose you could read the TLS specification, but I suspect it starts at the point where you have the domain name, and doesn’t consider how you got it. I’m pretty sure that the person who mentioned Asterisk also giving IP addresses got the point without needing to have a document that spelled it out.
I think most people who use PKI certificates don’t actually understand why they need them, and just believe they are a pre-requisite for encryption, when their real purpose is to prevent MitM.
