1999-09-27 05:16:09 +02:00
|
|
|
>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
|
|
|
|
|
| |
|
|
|
|
|
| '<else>' |
|
|
|
|
|
| Normal startup
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Is it 'E' for error ------------------- Retry connection
|
|
|
|
|
| Yes without SSL
|
|
|
|
|
| No
|
|
|
|
|
|
|
|
|
|
|
Is it 'N' for normal ------------------- Normal startup
|
|
|
|
|
| Yes
|
|
|
|
|
|
|
|
|
|
|
Fail with unknown
|
2002-09-29 06:06:54 +02:00
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
