View source for User:Davidgothberg/Encrypted connections negotiation

This page is for David's testing of Wikipedia editing. David's personal sandbox so to speak.


== Encrypted connections negotiation ==

This is a list of different cases of what a client and a server node knows and what then is the best possible encrypted negotiation and connection they can do.

"Stealth" means that someone scanning your ports and not even an eavesdropper should be able to detect what protocol you are using.

"Forward secure" means that even if the client's and/or server's keys later on get compromised old messages still can not be read by an attacker. This is usually done by also using some kind of temporary asymmetric keys that both nodes delete after the session ends. Thus those temporary keys can never be compromised.

For most methods below:
* If possible the client should talk first and the server should only respond after the client told what protocol it wants to talk and only if the server supports the protocol the client wants to use. This is part of stealth and makes it harder for automatic port scanning tools to determine what kind of server you are running.
* IVs should be sent in both directions to prevent replay attacks and man-in-the-middle attacks. Note that for stealth reasons the server in most cases should not send its server IV until after it has understood what protocol the client wants to talk. Both IVs should be included in the final shared session secret.

=== Nothing ===

Client does not have any keys or user names what so ever.
Server knows no keys or user names what so ever.
No protocol is pre-agreed.

Best method seems to be:

Protocol negotiation in clear text. For stealth reasons the client should talk first and the server should only respond after the client told what protocol it wants to talk and only if the server supports that protocol.

Then the two nodes can do a Diffie-Hellman crypto negotiation. (Note that this can also be done by using temporary RSA keys.)

This is not that stealthy and not man-in-the-middle secure but at least passive eavesdropper secure. It also kind of gives forward secrecy. 

=== Almost nothing === 

Client does not have any keys or user names what so ever.
Server knows no keys or user names what so ever.
Client expects the server to understand the stealthy Diffie-Hellman crypto negotiation protocol.

Best method seems to be:

Do a stealthy Diffie-Hellman crypto negotiation to agree about a shared secret, then turn on encryption. Then send a first encrypted standard string to show it is the Diffie-Hellman method and that it succeeded.

This is fairly stealthy and it is eavesdropper secure but not man-in-the-middle secure. It also kind of gives forward secrecy.

Note that this can also be done by using temporary RSA keys but then it is less stealthy.

=== Symmetric key ===

Client has a user name and a symmetric key (for instance a password or passphrase).
Server knows the user name and the user's symmetric key.
Client expects the server to understand the stealthy negotiation protocol.

Best method seems to be:

Protocol negotiation using some stealthy method that encrypts from the first byte using the user name + user password as key to encrypt/hide data from the first byte. (Negotiation about what protocol to be used actually can be done encrypted from the first byte.)

Method 1:

For instance use Rik's hashed method or a symmetrically encrypted method. In these methods the server has to test hash or test decrypt for each key it knows and then for each protocol it knows. Then turn on the first encryption. 

This is stealthy, eavesdropper secure and man-in-the-middle secure. But it is not forward secure.

For added security and to get forward secrecy then also do a Diffie-Hellman key negotiation. (Note that this can also be done by using temporary RSA keys.) Then combine the Diffie-Hellman negotiated shared secret with the user name and key to get a new stronger shared secret. Then turn on the second stronger encryption.

Now we are stealthy, eavesdropper secure, man-in-the-middle secure and forward secure.

Method 2:

Slightly less stealthy than method 1.

First do a Diffie-Hellman crypto negotiation to agree about a first shared secret. Then turn on first encryption. Then send a first encrypted standard string to show it is the Diffie-Hellman method and that it succeeded.

Then do more protocol negotiation and tell which user it is. Then combine the Diffie-Hellman negotiated shared secret with the user name and user key to get a new stronger shared secret. Then turn on the second stronger encryption.

This is fairly stealthy, eavesdropper secure, man-in-the-middle secure and forward secure.

=== Server certificate === 

This is the normal case on the web today.
Client does not have any keys or user names what so ever. Client is aware of CAs and can thus check server certificates.
Server knows no user keys or user names what so ever. Server has an asymmetric key pair and has a certificate for the key pair.
No protocol is pre-agreed.

Best method seems to be:

Protocol negotiation in clear text. For stealth reasons the client should talk first and the server should only respond after the client told what protocol it wants to talk and only if the server supports that protocol. 

Then the server sends its certificate to the client. The client then creates a random session key, encrypts it and sends it to the server by using the server's public key. Then turn on encryption. 

This is not stealthy and not forward secure, but it is passive eavesdropper secure and man-in-the-middle secure. 

For added security and to get forward secrecy then also do a Diffie-Hellman key negotiation. (Note that this can also be done by using temporary RSA keys.) Combine the Diffie-Hellman negotiated shared secret with the client created random session key to get a new stronger shared secret. Turn on the second stronger encryption.

This is not stealthy, but now it is eavesdropper secure, man-in-the-middle secure and forward secure.

Note that the client here knows for sure what server it talks to but the server does not know who the client is.

=== Server asymmetric key === 

Client does not have any keys or user names what so ever. Client knows the server's public key or at least the ID (the hash) of the server's public key.
Server knows no user keys or user names what so ever. Server has an asymmetric key pair. Client expects the server to understand the stealthy negotiation protocol.

This is slightly similar to the normal case on the web today but no certificates are used instead the client has knowledge of the server's public key. This allows us to add full stealth to the connection.

Best method seems to be:

The ID (the hash) of the server's public key is used as the "semi-secret key".

Use the semi-secret key together with Rik's hashed method or a symmetrically encrypted method. In these methods the server has to test hash or test decrypt for each semi-secret key it knows (usually just one) and then for each protocol it knows. Then turn on the first encryption. 

We are now stealthy but not especially secure.

If the client only knows the ID of the server's public key the client now asks the server for the full public key and gets it. The client then hashes the public key and checks that the hash becomes the ID it already know.

The client now creates a random session key, encrypts it and sends it to the server by using the server's public key. 

For added security and to get forward secrecy then also do a Diffie-Hellman key negotiation. (Note that this can also be done by using temporary RSA keys.) Then combine the Diffie-Hellman negotiated shared secret with the random session key to get a new stronger shared secret. 

Then turn on the second stronger encryption.

Now we are stealthy, eavesdropper secure, man-in-the-middle secure and forward secure.

Note that the client here knows for sure what server it talks to but the server does not know who the client is.

=== Client and server asymmetric key === 

Client has an asymmetric key pair and for some methods also has a client certificate. Client knows the server's public key or the ID (hash) of the server's public key.
Server knows the users public key or the ID (hash) of the users public key or is CA aware and thus can verify the users certificate. 

Client expects the server to understand the stealthy negotiation protocol.

Best method seems to be:

The ID (the hash) of the server's public key is used as the "semi-secret key".

Use the semi-secret key together with Rik's hashed method or a symmetrically encrypted method. In these methods the server has to test hash or test decrypt for each semi-secret key it knows (usually just one) and then for each protocol it knows. Then turn on the first encryption. 

We are now stealthy but not especially secure.

If the client only knows the ID of the server's public key the client now asks the server for the full public key and gets it. The client then hashes the public key and checks that the hash becomes the ID it already know.

The client now creates a random session key, encrypts it and sends it to the server by using the server's public key. 

For added security and to get forward secrecy then also do a Diffie-Hellman key negotiation. (Note that this can also be done by using temporary RSA keys.) Then combine the Diffie-Hellman negotiated shared secret with the random session key to get a new stronger shared secret. 

Then turn on the second stronger encryption.

Now we are stealthy, eavesdropper secure, man-in-the-middle secure and forward secure.

Note that now the client knows for sure what server it talks to but the server does not know who the client is.

Now the client tells the server who it is by sending over the client's public key ID. 

If the server knows the client it recognises the client's public key ID. However the server might only know the ID and not the actual public key of the client. Then the server simply asks the client for the full public key and gets it. The server then hashes the public key and checks that the hash becomes the ID it already know.

If the server does not know the client it does not recognise the client's public key ID. But if the server supports that clients use certificates it can now request a certificate from the client. If the server is not open for anyone the certificate should contain info that tells if the client is allowed to use this server.

The server now creates a second random session key, encrypts it and sends it to the client by using the client's public key. 

Then combine the Diffie-Hellman negotiated shared secret with the random session key sent from the client to the server and the second session key sent from the server to the client, to get a new even stronger shared secret.

Then turn on the third even stronger encryption.

Now we are stealthy, eavesdropper secure, man-in-the-middle secure and forward secure.

Now both the client and the server know for sure who the other party is.