One other note on this, as I do not see it specified in your question, is that everyone appears to have made the jump to suggest that when you asked about TLS/SSL you were meaning just HTTPS. Since you mention TCP communications you may also be considering the use of TLS/SSL for other applications that run over it besides HTTPS.
What comes to mind is TLS/SSL as used by SMTP. When it comes to using TLS/SSL for SMTP communications I personally would not ever rely on it as a maintainable method for security (note, I do mean SMTP communications, not the use of TLS/SSL to provide security between a mail client and mail server). The reason I say this is the inherent nature of TLS/SSL. You are looking at a point to point secure socket connection being adapted for a multiple hop communication mechanism.
So even if you force the use of TLS/SSL for your SMTP connections, you can only verify the connection was secure one hop out from your server. As most mail streams have multiple hops such as this:
mail server -> AV solution -> Internet -> AV Solution -> Mail Server
And the use of 3rd party AV solutions in the cloud are becoming more prominent, it is difficult to ensure TLS is used for every hop between two organizations.
For the sake of argument (as I have done this) let's say you take the time to secure that SMTP traffic between two sites by verifying each and every hop between the sites forces TLS. That is all well and good for today, but what happens when infrastructure changes 5 years from now? If not careful for example, when the AV solution is changed/replaced, you could easily leave one hop not forcing TLS.
Just wanted to throw this out there as another TLS implementation for brainstorming (and BTW if requiring secure email, I would go the S/Mime route to actually encrypt the message on the sender side and decrypt on the recipient side). As with any tool, you have to use the right tool for the right job
"If the only tool you have is a hammer, every problem becomes a nail"