Adding TLS Support

Asterisk Asterisk APIs
1

I have been doing further work on Seaskirt, which I would like to be a comprehensive wrapper for every way of communicating with an Asterisk server process (other than making phone calls, of course). Now I am thinking where to add the option for TLS-encrypted connections.

Presumably ARI can benefit from this. What about AMI? I see that this version of the AMI-over-HTTP page says “AJAM” is deprecated (does that include the whole of AMI-over-HTTP?). Interestingly, another version (not Asterisk-version-specific) mentions no such thing. Can AMI-over-TCP use TLS?

2

AJAM is AMI-over-HTTP. It is still in the code, but deprecated and not maintained really.

Non-HTTP supports TLS[1].

[1] asterisk/manager.conf.sample at master · asterisk/asterisk · GitHub

3

Thanks for that. Note to self: the Asterisk source code offers better-documented example configs than the default ones installed by Debian.

By the way, it’s worth mentioning that, if you create your own CA for generating certs (which seems the most likely way to use this feature), then the command for testing a TLS connection would involve passing the CA cert for client-side verification of the server, something like

openssl s_client -CAfile /path/to/aster-ca.crt -connect asterisk-host:5039

Also, are there any plans to offer an option for server-side verification of the client as well? That is, the client also passes a cert signed by some recognized CA (the cert for which is specified in the Asterisk config), as an alternative to username/password authentication.

4

If you’re referring to AMI, I know of noone working on such a thing and that is not something Sangoma has plans to do.

5

OK, the bulk of the rework is done, with TLS now available as an option for both AMI and ARI connections. Of course more testing is needed. Next I should add the option to connect via TLS to some of the example scripts.

Something occurs to me: ARI requires a new HTTP connection for every request/response transaction. Adding TLS would obviously increase the overhead of doing this reconnect every time. The natural fix would be to move to WebSockets for request/response connections, as is already done for event-listener connections.

6

The built in basic HTTP server supports persistent connections if the client uses it for this specific reason. Noone is working on extending the Websocket support to do requests/responses as of this time.

7

Ah. Must give that a try.

8

OK, got persistent connections working. Of course you can’t tell if/when the other end has disconnected, so you have to build in a retry loop.

Seems like mine is the only framework to support TLS, or let you do an AMI connection with asyncio. Or access the console socket.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.