>From the servers perspective: Receives StartupPacket | | (Is SSL_NEGOTIATE_CODE?) ----------- Normal startup | No | | Yes | | (Server compiled with USE_SSL?) ------- Send 'N' | No | | | | Yes Normal startup | | Send 'S' | | Establish SSL | | Normal startup >From the clients perspective (v6.6 client _with_ SSL): Connect | | Send packet with SSL_NEGOTIATE_CODE | | Receive single char ------- 'S' -------- Establish SSL | | | '' | | Normal startup | | Is it 'E' for error ------------------- Retry connection | Yes without SSL | No | Is it 'N' for normal ------------------- Normal startup | Yes | Fail with unknown Comments from Bear Giles: On a related note, I had mentioned this before but it's a subtle point and I'm sure that it's slipped everyone's mind... - if you need to have confidence in the identity of the database server, e.g., you're storing sensitive information and you absolutely must prevent any "man in the middle" attacks, use the SSL code I provided with server-side certs. To many users, the key issue is not whether the data is encrypted, it's whether the other party can be trusted to be who they claim to be. - if you just need confidentiality, but you don't need to verify the identity of the database server (e.g., because you trust the IP address, but worry about packet sniffers), SSH tunnels are much easier to set up and maintain than the embedded SSL code. You can set up the database server so it doesn't require a certificate (hell, you can hard code a fallback certificate into the server!), *but that violates the common practice of SSL-enabled servers.* I cannot overemphasize this - every other SSL-enabled server requires a certificate, and most provide installation scripts to create a "snake oil" temporary certificate. I can't think of any server (apache+mod_ssl, courier-imap, postfix(+tls), etc.) that uses anonymous servers. - if you don't need confidentiality, e.g., you're on a trusted network segment, then use direct access to the server port.