2. cnp3-ebook
3. protocols/ssh
4. English
5. Zen

8 ../../protocols/ssh.rst:81
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In practice, an ``ssh`` implementation supports four types of cryptographic algorithms : 88/10000 · 88
9 ../../protocols/ssh.rst:84
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — key exchange 12/10000 · 12
10 ../../protocols/ssh.rst:85
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — encryption 10/10000 · 10
11 ../../protocols/ssh.rst:86
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Message Authentication Code (MAC) 33/10000 · 33
12 ../../protocols/ssh.rst:87
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — compression 11/10000 · 11
13 ../../protocols/ssh.rst:89
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The IANA_ maintains a `list of the cryptographic algorithms <http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16>`_ that can be used by ``ssh`` implementations. For each type of algorithm, the client provides an ordered list of the algorithms that it supports and agrees to use. The server compares the received list with its own list. The outcome of the negotiation is a set of four algorithms [#fnull]_ that will be combined for this session. 478/10000 · 478
14 ../../protocols/ssh.rst:121
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — This negotiation of the cryptographic algorithms allows the implementations to evolve when new algorithms are proposed. If a client is upgraded, it can announce a new algorithm as its preferred one even if the server is not yet upgraded. 237/10000 · 237
15 ../../protocols/ssh.rst:131
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Once the cryptographic algorithms have been negotiated, the key exchange algorithm is used to negotiate a secret key that will be shared by the client and the server. These key exchange algorithms include some variations over the basic algorithms. As an example, let us analyze how the Diffie Hellman key exchange algorithm is used within the ``ssh`` protocol. In this case, each host has both a private and a public key. 421/10000 · 421
16 ../../protocols/ssh.rst:138
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the client generates the random number :math:`a` and sends :math:`A=g^{a} \mod p` to the server 95/10000 · 95
17 ../../protocols/ssh.rst:140
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the server generates the random number :math:`b`. It then computes :math:`B=g^{b} \mod p`, :math:`K=B^{a} \mod p` and signs with its private key :math:`hash(V_{Client} || V_{Server} || KEX\_INIT_{Client} || KEX\_INIT_{Server} || Server_{pub} || A || B || K )` where :math:`V_{Server}` (resp. :math:`V_{Client}`) is the initial messages sent by the client (resp. server), :math:`KEX\_INIT_{Client}` (resp. :math:`KEX\_INIT_{Server}`) is the key exchange message sent by the client (resp. server) and :math:`A`, :math:`B` and :math:`K` are the messages of the Diffie Hellman key exchange 586/10000 · 586
18 ../../protocols/ssh.rst:148
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — the client can recompute :math:`K=A^{b} \mod p` and verify the signature provided by the server 95/10000 · 95
19 ../../protocols/ssh.rst:151
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — This is a slightly modified authenticated Diffie Hellman key exchange with two interesting points. The first point is that when the server authenticates the key exchange it does not provide a certificate. This is because ``ssh`` assumes that the client will store inside its cache the public key of the servers that it uses on a regular basis. This assumption is valid for a protocol like ``ssh`` because users typically use it to interact with a small number of servers, typically a few or a few tens. Storing this information does not require a lot of storage. In practice, most ``ssh`` clients will accept to connect to remote servers without knowing their public key before the connection. In this case, the client issues a warning to the user who can decide to accept or reject the key. This warning can be associated with a fingerprint of the key, either as a sequence of letters or as an ASCII art which can be posted on the web or elsewhere [#fdnsssh]_ by the system administrator of the server. If a client connects to a server whose public key does not match the stored one, a stronger warning is issued because this could indicate a man-in-the-middle attack or that the remote server has been compromised. It can also indicate that the server has been upgraded and that a new key has been generated during this upgrade. 1330/10000 · 1330
20 ../../protocols/ssh.rst:173
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The second point is that the server authenticates not only the result of the Diffie Hellman exchange but also a hash of all the information sent and received during the exchange. This is important to prevent `downgrade attacks`. A `downgrade attack` is an attack where an active attacker modifies the messages sent by the communicating hosts (typically the client) to request the utilization of weaker encryption algorithms. Consider a client that supports two encryption schemes. The preferred one uses 128 bits secret keys and the second one is an old encryption scheme that uses 48 bits keys. This second algorithm is kept for backward compatibility with older implementations. If an attacker can remove the preferred algorithm from the list of encryption algorithms supported by the client, he can force the server to use a weaker encryption scheme that will be easier to break. Thanks to the hash that covers all the messages exchanged by the server, the downgrade attack cannot occur against ``ssh``. Algorithm agility is a key requirement for security protocols that need to evolve when encryption algorithms are broken by researchers. This agility cannot be used without care and signing a hash of all the messages exchanged is a technique that is frequently used to prevent downgrade attacks. 1301/10000 · 1301
21 ../../protocols/ssh.rst:193
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Single use keys 15/10000 · 15
22 ../../protocols/ssh.rst:195
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Thanks to the Diffie Hellman key exchange, the client and the servers share key :math:`K`. A naive implementation would probably directly use this key for all the cryptographic algorithms that have been negotiated for this session. Like most security protocols, ``ssh`` does not directly use key :math:`K`. Instead, it uses the negotiated hash function with different parameters [#fsshkeys]_ to allow the client and the servers to compute six keys from :math:`K` : 464/10000 · 464
23 ../../protocols/ssh.rst:204
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — a key used by the client (resp. server) to encrypt the data that it sends 73/10000 · 73
24 ../../protocols/ssh.rst:206
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — a key used by the client (resp. server) to authenticate the data that it sends 78/10000 · 78
25 ../../protocols/ssh.rst:208
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — a key used by the client (resp. server) to initialize the negotiated encryption scheme (if required by this scheme) 115/10000 · 115
26 ../../protocols/ssh.rst:211
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — It is common practice among designers of security protocols to never use the same key for different purposes. For example, allowing the client and the server to use the same key to encrypt data could enable an attacker to launch a replay attack by sending to the client data that it has itself encrypted. 304/10000 · 304
27 ../../protocols/ssh.rst:218
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — At this point, all the messages sent over the TCP connection will be encrypted with the negotiated keys. The ``ssh`` protocol uses messages that are encoded according to the Binary Packet Protocol defined in :rfc:`4253`. Each of these messages contains the following information : 280/10000 · 280