I played around with a man-in-the-middle proxy tool and connected different smart phones to it. As the proxy uses a self signed certificate the tested smartphone apps did not accept the presented server certificate.
The interesting part (from my perspective) was that different smartphone platforms used totally different messages and strategies for making sure that the TLS connection can not be established.
Some just sent a ALERT message with description bad_certificate(42) or certificate_unknown(46). Other phones just continued the handshake but later the key exchange deterministically failed.
I found especially the last case interesting as it is unclear how the client force the handshake phase to fail and if an adapted server/proxy may still be able to "save" the handshake phase and establish the connection...
Are the actions a client should perform somewhere written down in an RFC for dropping the connection in case an untrusted certificate was detected?
If no, does somebody knows what mechanism is usually used for willfully sabotaging the TLS handshake phase?