On 7 Sep 2015, at 17:13, Yulia Bensman <ybensman@interwise.com> wrote:

But when I am opening the second socket and sending ClientHello, the sessionID contains the 32-bytes token, sent by server in ServerHello to the first socket. So it behaves like it wants to re-negotiate.

Not "re-negotiate" but rather "resume the previous session". And yes, this is expected behaviour. The server should either support resume or not support resume. In the latter case it should send back a new session ID, not just fail the handshake. Ideally you should fix this on the server. Session resume is a standard part of TLS and kinda important when it comes to performance. However, if you can't fix the server, you can work around this on the client by setting the "peer ID". To do this: 1. get the Secure Transport context from the stream before you open it [1] 2. call SSLSetPeerID on that to set a unique peer ID The peer ID is used as the TLS session cache key, so if it's unique then no session reuse is possible. Share and Enjoy -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware [1] Use kCFStreamPropertySSLContext, as shown by the TLSTool sample code. <https://developer.apple.com/library/mac/samplecode/SC1236/> _______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/macnetworkprog/site_archiver%40lists... This email sent to site_archiver@lists.apple.com