asterisk users - Jul 2019 - unsolved: Re: solved: how to create a working certificate for using TLS?

On 7/6/19 10:40 AM, Michael Maier wrote:
> On 05.07.19 at 22:02 hw wrote:
>>
>> openssl verify -CAfile ca.pem asterisk.pem
>> asterisk.pem: OK
>>
>>
>> When I set tlsdontverifyserver=yes, it works (i. e. asterisk registers
>> to the SIP provider and there is no error message).  Otherwise I'm
>> getting the error message and asterisk does not register.
>>
>> Reading the comments in sip.conf.sample, I would assume that asterisk
>> can not verify the certificate of the SIP provider.  Yet
>>
>>
>> openssl s_client -connect secure.sip.easybell.de:5061
> 
> You know that you don't need an own certificate to connect via tls to
the ISP?
No, I didn't know that.  However, there are local clients connecting to
asterisk
using encryption, so I suppose my own certificate is required.
> To be able to verify the certificate of the ISP, asterisk has to know the
local CA database. For CentOS 7, this is /etc/pki/tls/certs/ca-bundle.crt.
How did you know I'm doing this on Centos? :)

Setting 'tlscapath' to /etc/pki or to /etc/pki/ca-trust/source/
didn't seem to
make a difference, so I figured that this might be figured out automatically
since 'openssl s_client ...' apparently does figure it out
automatically.
There is much figuring involved for the wanting of clear documentation ...

Now I've set 'tlscafile=/etc/pki/tls/certs/ca-bundle.crt' on the
asterisk at
work, but that one didn't have issues with certificates after I made a new
one.  I'll try the same at home when I get back to see if it makes a
difference.

Is 'tlscafile' the correct option for this?

On 06.07.19 at 12:16 hwilmer wrote:
> On 7/6/19 10:40 AM, Michael Maier wrote:
>> On 05.07.19 at 22:02 hw wrote:
>>>
>>> openssl verify -CAfile ca.pem asterisk.pem
>>> asterisk.pem: OK
>>>
>>>
>>> When I set tlsdontverifyserver=yes, it works (i. e. asterisk
registers
>>> to the SIP provider and there is no error message).  Otherwise
I'm
>>> getting the error message and asterisk does not register.
>>>
>>> Reading the comments in sip.conf.sample, I would assume that
asterisk
>>> can not verify the certificate of the SIP provider.  Yet
>>>
>>>
>>> openssl s_client -connect secure.sip.easybell.de:5061
I'm using easybell via tls, too - but with pjsip - I had never any problem.
>>
>> You know that you don't need an own certificate to connect via tls
to the ISP?
> 
> No, I didn't know that.  However, there are local clients connecting to
asterisk
> using encryption, so I suppose my own certificate is required.
That's true - but why do you need encryption on your own LAN? Just for fun
or are there any particular requirements?
>> To be able to verify the certificate of the ISP, asterisk has to know
the local CA database. For CentOS 7, this is /etc/pki/tls/certs/ca-bundle.crt.
> 
> How did you know I'm doing this on Centos? :)
This was just meant as an example - chance :-)
> Setting 'tlscapath' to /etc/pki or to /etc/pki/ca-trust/source/
didn't seem to
I'm sorry - I don't know how to handle ca bundles with chan_sip. With
pjsip it's

ca_list_file=/etc/pki/tls/certs/ca-bundle.crt

in pjsip.transports.conf.


Michael

On 06.07.19 at 22:16 hwilmer wrote:
> Is there an advantage to using pjsip?  What's needed for easybell with
pjsip?
For easybell, I don't know of any advantage. But that's not very
reliable, because I'm using easybell for dedicated requirements only.
I'm
considering chan_sip legacy. I wouldn't build any new installation on
chan_sip (if there are no technical contradictions).

Easybell does have a pretty fine documentation for FreePBX and pjsip:
https://www.easybell.de/nc/hilfe/ergebnis/freepbx-130124-mit-asterisk-13.html


[why encryption?]
> I consider it a requirement for when employees end up using their mobile
phones over foreign wireless networks, which is something that would be
> virtually impossible to prevent should the asterisk server be made
reachable from the outside.
That's true. But don't forget to encrypt RTP at this point! This must be
done additionally.
BTW: easybell doesn't support full RTP encryption. It's supported for
outgoing calls only
(https://en.easybell.de/nc/help/questions/questions-concerning-the-telephone-connection/answer/does-easybell-support-the-data-encryption-srtp-for-voip.html).

That's an example for an inbound call - there isn't any support for RTP
encryption:

<--- Received SIP request (869 bytes) from TLS:195.185.37.60:5061 --->
INVITE sip:+4912345678989 at 93.165.22.128:5061;transport=TLS;line=xxxxxxx
SIP/2.0
Via: SIP/2.0/TLS 195.185.37.60:5061;branch=z9hG4bKcu8ZTaf6c4iPU;rport
From: <sip:45678901234 at
sip.easybell.de>;tag=2DC25244-5D21B65400044D02-6A194700
To: <sip:+4912345678989 at sip.easybell.de>
CSeq: 1891 INVITE
Call-ID: SBC4115e0000af5-5d21b654-67c091e3-a60cca0-924117e-01_b2b-1
Max-Forwards: 68
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK
Supported: histinfo
Content-Type: application/sdp
Content-Length: 286
Contact: <sip:5819011B-5D21B65400045FF0-F2350700 at
195.185.37.60:5061;transport=tls>

v=0
o=- 1667528048 2824605765 IN IP4 195.185.37.60
s=-
c=IN IP4 195.185.37.60
t=0 0
m=audio 30934 RTP/AVP 9 8 0 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=direction:both
a=sendrecv
a=maxptime:150

> 
> And before that, why shouldn't phone calls always be encrypted for just
in case?  They are always genuinely private, and it doesn't hurt anything.
True - no contradiction of mine.
> 
>>> Setting 'tlscapath' to /etc/pki or to
/etc/pki/ca-trust/source/ didn't seem to
>>
>> I'm sorry - I don't know how to handle ca bundles with
chan_sip. With pjsip it's
>>
>> ca_list_file=/etc/pki/tls/certs/ca-bundle.crt >
>> in pjsip.transports.conf.
> 
> Thanks, setting 'tlscafile=/etc/pki/tls/certs/ca-bundle.crt' seems
to do the trick.  However:
Happy to here that it's working now.
> 
> First I set 'tlsdontverifyserver=no' and issued a 'sip
reload'.  There was no error message.  I found that suspicious and restarted
asterisk,
> and the error message came back.
There are some config changes which need a complete restart AFAIK (FreePBX
explicitly warns about some changes requiring a restart).
> Only then I added 'tlscafile=/etc/pki/tls/certs/ca-bundle.crt'
(which was unset before), and after a 'sip reload', the error message
was gone.
> So far, it hasn't come back even when restarting asterisk.
That's how I'm handling it: After each change concerning the transport
I'm restarting asterisk. Just to be sure. But that's a question which
could be answered by Joshua much better.
> This shows that 'sip reload' doesn't really do a reload in that
a certificate which hasn't been verified continues to be accepted after the
> configuration changed to now require verifying the certificate.
The certificate check is done on starting the connection (SYN) by openssl. sip
reload most probably doesn't restart the connection (because all
running calls would be disconnected - that's most of the time not a good
idea - sip reload usually doesn't destroy running sessions / calls).
> This might be a security problem, and if not, it is certainly good for
surprises
> and can create much confusion.
Just handle it like this: each transport relevant change requires a complete
restart!
> 
> Is it supposed to be like this, or should I make a bug report?
I think it's supposed to behave like this, because it would mean to
disconnect all running calls on sip reload. That's probably not what most of
the people expect / want to have.


Regards
Michael

On 7/6/19 7:23 PM, Michael Maier wrote:
> On 06.07.19 at 12:16 hwilmer wrote:
>> On 7/6/19 10:40 AM, Michael Maier wrote:
>>> On 05.07.19 at 22:02 hw wrote:
>>>>
>>>> openssl verify -CAfile ca.pem asterisk.pem
>>>> asterisk.pem: OK
>>>>
>>>>
>>>> When I set tlsdontverifyserver=yes, it works (i. e. asterisk
registers
>>>> to the SIP provider and there is no error message).  Otherwise
I'm
>>>> getting the error message and asterisk does not register.
>>>>
>>>> Reading the comments in sip.conf.sample, I would assume that
asterisk
>>>> can not verify the certificate of the SIP provider.  Yet
>>>>
>>>>
>>>> openssl s_client -connect secure.sip.easybell.de:5061
> 
> I'm using easybell via tls, too - but with pjsip - I had never any
problem.
Yes, easybell works fine, and their support is great.  But don't tell 
anyone or they might be overwhelmed with customers fleeing the bad
support of other providers ...

Is there an advantage to using pjsip?  What's needed for easybell with 
pjsip?
>>> You know that you don't need an own certificate to connect via
tls to the ISP?
>>
>> No, I didn't know that.  However, there are local clients
connecting to asterisk
>> using encryption, so I suppose my own certificate is required.
> 
> That's true - but why do you need encryption on your own LAN? Just for
fun or are there any particular requirements?
I consider it a requirement for when employees end up using their mobile 
phones over foreign wireless networks, which is something that would be 
virtually impossible to prevent should the asterisk server be made 
reachable from the outside.

And before that, why shouldn't phone calls always be encrypted for just 
in case?  They are always genuinely private, and it doesn't hurt anything.
>> Setting 'tlscapath' to /etc/pki or to /etc/pki/ca-trust/source/
didn't seem to
> 
> I'm sorry - I don't know how to handle ca bundles with chan_sip.
With pjsip it's
> 
> ca_list_file=/etc/pki/tls/certs/ca-bundle.crt >
> in pjsip.transports.conf.
Thanks, setting 'tlscafile=/etc/pki/tls/certs/ca-bundle.crt' seems to do
the trick.  However:

First I set 'tlsdontverifyserver=no' and issued a 'sip reload'. 
There
was no error message.  I found that suspicious and restarted asterisk, 
and the error message came back.

Only then I added 'tlscafile=/etc/pki/tls/certs/ca-bundle.crt' (which 
was unset before), and after a 'sip reload', the error message was gone.
So far, it hasn't come back even when restarting asterisk.

This shows that 'sip reload' doesn't really do a reload in that a 
certificate which hasn't been verified continues to be accepted after 
the configuration changed to now require verifying the certificate. This 
might be a security problem, and if not, it is certainly good for 
surprises and can create much confusion.

Is it supposed to be like this, or should I make a bug report?

On 7/7/19 11:55 AM, Michael Maier wrote:
> On 06.07.19 at 22:16 hwilmer wrote:
>> Is there an advantage to using pjsip?  What's needed for easybell
with pjsip?
> 
> For easybell, I don't know of any advantage. But that's not very
reliable, because I'm using easybell for dedicated requirements only.
I'm considering chan_sip legacy. I wouldn't build any new installation
on chan_sip (if there are no technical
> contradictions).
> 
> Easybell does have a pretty fine documentation for FreePBX and pjsip:
>
https://www.easybell.de/nc/hilfe/ergebnis/freepbx-130124-mit-asterisk-13.html
That's not for asterisk, and most documentations for asterisk are not for
pjsip.
> [why encryption?]
> 
>> I consider it a requirement for when employees end up using their
mobile phones over foreign wireless networks, which is something that would be
virtually impossible to prevent should the asterisk server be made reachable
from the outside.
> 
> That's true. But don't forget to encrypt RTP at this point! This
must be done additionally.
> BTW: easybell doesn't support full RTP encryption. It's supported
for outgoing calls only
(https://en.easybell.de/nc/help/questions/questions-concerning-the-telephone-connection/answer/does-easybell-support-the-data-encryption-srtp-for-voip.html).
They also say that encryption is possible:
https://en.easybell.de/nc/help/questions/questions-concerning-the-telephone-connection/answer/can-i-encrypt-the-telephony.html

I'll have to see what their support says about this.
> 
> That's an example for an inbound call - there isn't any support for
RTP encryption:
[...]

That would really suck.  It is not acceptable that phone calls over the internet
shouldn't be encrypted.
> [...]