TCPClient SSL on Android

[BartKindt]

The Client receives a "StartTLS" from the IdTCPServer (Part of my code).

Why would the *server* send a STARTTLS to the *client*?  That is an unusual design choice.

The Client responces with a "STARTTLS" back, then does a Sleep(1000) (this solves some timing issues) and then switches the Passthrough to FALSE

Sleeping should not be necessary.  If you are having timing-related issues, you need to fix those separately.

The SSL Negotiating starts, and gets to this:
<snip>
And then it stops. And there is no Exception raised.

How are you configuring the SSLIOHandler on each end?  Are you specifying which party is client and which is server, in terms of the SSL session (connect vs accept), not in term of the TCP connection?  Have you tried sniffing the network traffic, such as with Wireshark, to make sure the handshake packets are correct?

- At which point does the SSL negotiation start: Immediatly after PassThrough := false, OR after the first attempt to send data over the link?

It is handled *inside* the PassThrough property setter.  The setter does not return to your code until the handshake is complete.

- When the Internet connection fails at this point, (and possibly the *Server* got a TCP Reset) is should there be a time-out exception being raised?

Probably not, since Indy uses blocking sockets and there are no timeouts used at the socket layer by default.  However, you can enable socket-layer timeouts manually if needed, via the TIdTCPConnection.Socket.SetSockOpt() method (in fact, TIdSSLIOHandlerSocketOpenSSL does enable socket-level timeouts, but only on Windows Vista+ as part of a bug fix for OpenSSL handling on Windows).