How SSL (similar version) works?

Question

My book suggested the following protocol to replace SSL:

A lot of the terms are familiar to me from the Original SSL, like ChangeCipherSpec message which means from now on the messages I send will be encrypted. and FinishedClient: which is the first message to be encrypted.

But few things aren't clear for me:

1. Diffie-Hellman is the short-term key here, what about the long-term key?

2. I know pre-shared secret but what is pre-master secret, who generates it and what is it used for (I don't see the server using it anywhere)?

3. After stage 5, How are the messages between the client and server passed? what's the encoding function, what's the key?

Answer 1

1. Diffie-Hellman is the short-term key here, what about the long-term key?

The various meanings of various elements used within the protocol aren't explained; my best guess is that 'pass' is a password that is shared between the two sides, and is used to authenticate the exchange - that would be the closest thing here to a 'long-term key'.

If my guess is correct, there is an obvious problem with this protocol and passwords with weak entropy; if a bogus site manages to get traffic that is supposed to go to a legitimate server, when it can do is generate the ServerHello honestly; it client will then send message 4-6. The bogus site can then iterate through various possibilities of the password, and with each one, decrypt $g^y \bmod p$, generate the corresponding shared secret, generate the session keys and then attempt to decrypt the Finished message. If it hits on the correct password, the Finished message would then decrypt - it can then mimic the server or the client in future sessions.

If you need to rely on a password for authentication, you need a better protocol.

2. I know pre-shared secret but what is pre-master secret, who generates it and what is it used for (I don't see the server using it anywhere)?

Actually, pre-master secret is standard SSL/TLS terminology, and is the initially exchanged secret that kicks off everything secret; all the session keys are derived (through a rather involved process) from this secret and public data.

In the original SSL design, it was a random value selected by the client and sent encrypted (by the server's public key); the server would decrypt it and then both would know it. In more recent versions, the client and the server would perform a DH (or ECDH) exchange, and both sides would use the shared secret as the pre-master secret. This proposal appears to be similar to the original approach; the server picks it (presumably as a random value), encrypts it with a key based on an ephemeral DH exchange.

3. after stage 5, How are the messages between the client and server passed? what's the encoding function, what's the key?

Presumably, it follows what TLS does; it probably uses a similar record format, and encrypts things based on keys derived from the premaster secret.