Re: [asterisk-users] unsolved: Re: solved: how to create a working certificate for using TLS?
On Sun, Jul 7, 2019, at 11:17 AM, hw wrote: > > 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? Support for this probably wasn't fully done to support such behavior. You could file a bug report but support for chan_sip is provided by the community and there is no time frame on when (or if) such a thing would be looked into so keep that in mind. -- Joshua C. Colp Digium - A Sangoma Company | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] unsolved: Re: solved: how to create a working certificate for using TLS?
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? -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] unsolved: Re: solved: how to create a working certificate for using TLS?
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@93.165.22.128:5061;transport=TLS;line=xxx SIP/2.0 Via: SIP/2.0/TLS 195.185.37.60:5061;branch=z9hG4bKcu8ZTaf6c4iPU;rport From: ;tag=2DC25244-5D21B65400044D02-6A194700 To: CSeq: 1891 INVITE Call-ID: SBC4115eaf5-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: 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 -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
