I just noticed SecureSocket.ChangeSecurityProtocol isn't blocking. Using the FtpClient, you can end up sending "USER xyz" while the server certificate isn't received yet.

I need to block operations until authentication completes. What is the best approach to make sure authentication has completed before proceeding with further sends and receives on the socket? A ManualResetEvent which is set in the Verifier callback? Then how can I be garanteed the callback will get called?

The non-blocking behavior of ChangeSecurityProtocol is by design. Also, don't worry about sending the USER command too soon; if you call ChangeSecurityProtocol before sending "USER ...", the SecureSocket will always make sure there's a secure connection before sending the actual USER command.

We have an FTP example in the Samples\SSL\FtpClient directory.

Ok, but in my particular case, I need to wait for the handshake to have completed before returning. To make it short, it's an FTP library, with an "Authenticate" method. I don't want this method to return before the handshake completes (i.e. the exchange of certificates is done).

What technique do you suggest? Is there a flag somewhere I could associate a WaitHandle with?

The current version of the library doesn't support handshake notification.

Certificates can be intercepted by specifying CredentialVerification.Manual in the SecurityOptions instance.