This originally started as FS-3071 last Feb, an issue is best described as:
 When a client connects to a server it creates an encryption TCP channel used to communicate with the server. Any time it places a call, registers, etc it does so using this TCP session. Unfortunately when FreeSWITCH goes to communicate with the client to tell it about an incoming call, notify's, etc it establishes a second TCP channel from the server to the client. While this is encrypted it can cause some problems for some firewall configurations and for many of the TLS/SSL security options in FreeSWITCH. If FreeSWITCH cannot establish this channel the client will be able to make calls but it will not be able to receive calls (or anything else that is server -> client originated). In addition many TLS features may act unexpectedly so direction is important to consider for example tls-verify-policy set to "out" would cause FreeSWITCH to try to verify the client certificate when it connects back to the client, so even though the client is connecting to the server initially and that would skip validation for calls from the server->client it would verify it. In addition it can open security holes, for example setting the policy to "in" for verification of incoming clients would NOT verify the client certificate when the server connects back to the client which would allow a MITM attack to occur there. Things like subject validation can also be tricky, especially if freeswitch is acting as a client. For example subject validation checks the hostname freeswitch connects to against the certificate common name, while a nice security check cannot possibly done when the server connects back to freeswitch (as at that point freeswitch actually tries to check the IP address against the common name). In addition purpose validation (making sure when freeswitch is connecting to a server its a certificate that has been issued for a server and not a client, or vice versa) currently is not supported. This allows MITM against a FS server using a client certificate (or vice versa) but due to the connection going both ways purpose validation is currently not supported (as an incoming connection may be from a server cert connecting back). So while FS gentls_cert does properly assign purpose it is not currently used by FS itself. One solution to avoid this MITM hole is to issue client certs from a different CA for now.



MikeJ said in march of last year they had some patches that should allow for reuse and fix this issue, this ticket is mainly to track when those actually get applied.

There is one additional feature that should be implemented once those are in place and thats purpose validation of ssl certificates. This ensures a client certificate can't be used in a MITM attack as FS as a client can validate servers connected to are using server certs.


Purpose validation would be an optional TLS param in the config but would be fairly easy to implement:
in short we would just need two
new tags, TPTAG_TLS_VERIFY_PURPOSE_INCOMING /
TPTAG_TLS_VERIFY_PURPOSE_OUTGOING for example. These would only need
to support 3 values NONE/CLIENT/SERVER (well probably only need two as
omitting the tag can be assumed as none). There are more than 2
possible purposes
(http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/MAN/MAN3/1624____.HTM)
however this is all that would probably be required.

Then in tport_tls.c around line 385 you have:
SSL_CTX_set_verify_depth(tls->ctx, ti->verify_depth);
 SSL_CTX_set_verify(tls->ctx, verify, tls_verify_cb);

Adding after these:
SSL_CTX_set_purpose(tls->ctx, X509_PURPOSE_SSL_CLIENT );

With it being X509_PURPOSE_SSL_CLIENT or X509_PURPOSE_SSL_SERVER for
the two different verification options.

Thats it, then on validation X509_V_ERR_INVALID_PURPOSE will be
returned, the code already there to handle errors will properly say
invalid purpose if the purpose doesn't match.

I have verified the SSL_CTX_set_purpose works properly and will reject
certificates and connections with the incorrect purpose.