What exactly does the “Proxy TLS” option do on Blackberry handhelds and how does it affect data traffic from the mobile device to BES

It depends on the phone (which is especially obvious with BB Connect devices) and the radio internally (and also how well it's been programmed). Some phones support having both a voice and a data channel open, some don't. Most commonly, you can't have both GPRS and voice channels open and more commonly phones support having 3g and voice channels open but this isn't a hard and fast rule. It's also possible from the use-cases you've given that some applications are actually disconnecting their data channel if they detect a voice call in progress.

Basically, it is as you thought, dependent on if the data channel is using the same radio as the voice channel, but with some added complications.

As for the backend, my experience is with BB connect and that uses the phone data connection (so GPRS, 3g, HDPSA) and connects to a RIM server gateway. It's this that then uses your phones registration data to work out which BB server to send to (or the BIS servers if you aren't on an enterprise server) using routing information the phone keeps stored. On BB Connect at least, it doesn't use the voice channel directly apart from as stated above when they can interfere.

TLS and SSL are closely related technologies.

First, email and Opportunistic TLS. ESMTP has the option of performing the actual data transfer portion of the conversation over an encrypted link. This is part of the protocol and has been called TLS for most of its existence. It works roughly like this:

-> EHLO foreignmailer.example.com
<- 250 Howdy, stranger
<- [list of capabilities, of which TLS is listed]
-> [Indicates it wants to start a TLS session]
<- [accepts negotioation]
-> [Mail actions, of which LOGIN might be one]

Once the TLS session has been started, new login methods might be available. This is an example of a protocol that includes Transaction Layer Security in it directly. The certificates used are the same kind of certificates used for SSL over HTTP.

For an example of a service that doesn't include TLS directly, take POP3-over-SSL. In that case, the secure session is negotiated before the actual protocol is negotiated. In essence, POP3 is being encapsulated inside a secure session.

In general, if a service supports SSL it can be extended to support TLS. Whether or not that has been done is up to the maintainers of the service. This does mean that TLS can replace SSL in "SSL VPNs".

SSL VPNs are distinct from their IPSec based cousins in that the secure session is done at a different level. SSL VPNs do their work much the same way that POP3-over-SSL does, in that traffic is encapsulated over an existing TCP connection. IPSec VPNs create an IP-level secure tunnel, where SSL VPNs create a TCP-level secure tunnel. The reason SSL VPNs seem to be taking over is that they're easier to set up and are more tolerant of bad network conditions. SSL VPNs can and do use the TLS protocol for securing the session, though it does depend on the maker of the VPN itself.

As for the exact protocol level differences between SSL and TLS, that I can't get into. TLS as a standard was arrived at later than SSL and therefore includes some of the lessons learned in the early SSL versions. SSLv3 was ratified back in 1996 and TLS1.0 in 1999, and further protocol development appears to be limited to the TLS suite. It has taken a LONG time for SSLv1 and v2 to go away. TLS is the clear successor of the SSL suite.