Primerjava izbranih različic
Prikazane so razlike med izbrano in trenutno različico strani.
Both sides previous revision Prejšnja revizija Naslednja revizija | Prejšnja revizija | ||
manuals:start [16. 09. 2016 00:07] – [The crypto] Jure | manuals:start [17. 08. 2023 14:12] (Trenutna) – ustvarjena Jurij | ||
---|---|---|---|
Vrstica 1: | Vrstica 1: | ||
+ | # Navodila | ||
- | Rahlo paranoične navodile | + | Tukaj se nahajajo razna uporabniška navodila |
- | + | ||
- | Vir: [[https:// | + | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | Key exchange | + | |
- | ------------ | + | |
- | + | ||
- | There are basically two ways to do key exchange: [[https:// | + | |
- | + | ||
- | DH works with a multiplicative group of integers modulo a prime. Its security is based on the hardness of the discrete logarithm problem. | + | |
- | + | ||
- | Alice Bob | + | |
- | --------------------------- | + | |
- | Sa = random | + | |
- | Pa = g^Sa | + | |
- | Sb = random | + | |
- | Pb <-- Pb = g^Sb | + | |
- | s = Pb^Sa s = Pa^Sb | + | |
- | k = KDF(s) | + | |
- | + | ||
- | ECDH works with elliptic curves over finite fields. Its security is based on the hardness of the elliptic curve discrete logarithm problem. | + | |
- | + | ||
- | Alice Bob | + | |
- | --------------------------- | + | |
- | Sa = random | + | |
- | Pa = Sa * G --> Pa | + | |
- | Sb = random | + | |
- | Pb <-- Pb = Sb * G | + | |
- | s = Sa * Pb s = Sb * Pa | + | |
- | k = KDF(s) | + | |
- | + | ||
- | OpenSSH supports 8 key exchange protocols: | + | |
- | + | ||
- | curve25519-sha256: | + | |
- | diffie-hellman-group1-sha1: | + | |
- | diffie-hellman-group14-sha1: | + | |
- | diffie-hellman-group-exchange-sha1: | + | |
- | diffie-hellman-group-exchange-sha256: | + | |
- | ecdh-sha2-nistp256: | + | |
- | ecdh-sha2-nistp384: | + | |
- | ecdh-sha2-nistp521: | + | |
- | + | ||
- | We have to look at 3 things here: | + | |
- | + | ||
- | ECDH curve choice: This eliminates 6-8 because NIST curves suck. They leak secrets through timing side channels and off-curve inputs. Also, NIST is considered harmful and cannot be trusted. | + | |
- | Bit size of the DH modulus: This eliminates 2 because the NSA has supercomputers and possibly unknown attacks. 1024 bits simply don’t offer sufficient security margin. | + | |
- | Security of the hash function: This eliminates 2-4 because SHA1 is broken. We don’t have to wait for a second preimage attack that takes 10 minutes on a cellphone to disable it right now. | + | |
- | + | ||
- | We are left with 1 and 5. 1 is better and it’s perfectly OK to only support that but for interoperability (with Eclipse, WinSCP), 5 can be included. | + | |
- | + | ||
- | Recommended / | + | |
- | + | ||
- | KexAlgorithms curve25519-sha256@libssh.org, | + | |
- | + | ||
- | Recommended / | + | |
- | + | ||
- | # Github needs diffie-hellman-group-exchange-sha1 some of the time but not always. | + | |
- | #Host github.com | + | |
- | # KexAlgorithms curve25519-sha256@libssh.org, | + | |
- | + | ||
- | Host * | + | |
- | KexAlgorithms curve25519-sha256@libssh.org, | + | |
- | + | ||
- | If you chose to enable 5, open / | + | |
- | + | ||
- | awk '$5 > 2000' / | + | |
- | wc -l " | + | |
- | mv " | + | |
- | + | ||
- | If it does not exist, create it: | + | |
- | + | ||
- | ssh-keygen -G / | + | |
- | ssh-keygen -T / | + | |
- | mv / | + | |
- | rm / | + | |
- | + | ||
- | This will take a while so continue while it’s running. | + | |
- | Authentication | + | |
- | + | ||
- | The key exchange ensures that the server and the client shares a secret no one else knows. We also have to make sure that they share this secret with each other and not an NSA analyst. | + | |
- | Server authentication | + | |
- | + | ||
- | The server proves its identity to the client by signing the key resulting from the key exchange. There are 4 public key algorithms for authentication: | + | |
- | + | ||
- | DSA with SHA1 | + | |
- | ECDSA with SHA256, SHA384 or SHA512 depending on key size | + | |
- | Ed25519 with SHA512 | + | |
- | RSA with SHA1 | + | |
- | + | ||
- | DSA keys must be exactly 1024 bits so let’s disable that. Number 2 here involves NIST suckage and should be disabled as well. Another important disadvantage of DSA and ECDSA is that it uses randomness for each signature. If the random numbers are not the best quality, then it is possible to recover the secret key. Fortunately, | + | |
- | + | ||
- | Protocol 2 | + | |
- | HostKey / | + | |
- | HostKey / | + | |
- | + | ||
- | The first time you connect to your server, you will be asked to accept the new fingerprint. | + | |
- | + | ||
- | This will also disable the horribly broken v1 protocol that you should not have enabled | + | |
- | + | ||
- | cd /etc/ssh | + | |
- | rm ssh_host_*key* | + | |
- | ssh-keygen -t ed25519 -f ssh_host_ed25519_key < /dev/null | + | |
- | ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null | + | |
- | + | ||
- | Client authentication | + | |
- | + | ||
- | The client must prove its identity to the server as well. There are various methods to do that. | + | |
- | + | ||
- | The simplest is password authentication. This should be disabled immediately after setting up a more secure method because it allows compromised servers to steal passwords. Password authentication is also more vulnerable to online bruteforce attacks. | + | |
- | + | ||
- | Recommended / | + | |
- | + | ||
- | PasswordAuthentication no | + | |
- | ChallengeResponseAuthentication no | + | |
- | + | ||
- | Recommended / | + | |
- | + | ||
- | Host * | + | |
- | PasswordAuthentication no | + | |
- | ChallengeResponseAuthentication no | + | |
- | + | ||
- | The most common and secure method is public key authentication, | + | |
- | + | ||
- | Recommended / | + | |
- | + | ||
- | PubkeyAuthentication yes | + | |
- | + | ||
- | Recommended / | + | |
- | + | ||
- | Host * | + | |
- | PubkeyAuthentication yes | + | |
- | HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com, | + | |
- | + | ||
- | Generate client keys using the following commands: | + | |
- | + | ||
- | ssh-keygen -t ed25519 -o -a 100 | + | |
- | ssh-keygen -t rsa -b 4096 -o -a 100 | + | |
- | + | ||
- | You can deploy your new client public keys using ssh-copy-id. | + | |
- | + | ||
- | It is also possible to use OTP authentication to reduce the consequences of lost passwords. Google Authenticator is a nice implementation of TOTP, or Timebased One Time Password. You can also use a printed list of one time passwords or any other PAM module, really, if you enable ChallengeResponseAuthentication. | + | |
- | User Authentication | + | |
- | + | ||
- | Even with Public Key authentication, | + | |
- | + | ||
- | Recommended / | + | |
- | + | ||
- | AllowGroups ssh-user | + | |
- | + | ||
- | Create the ssh-user group with sudo groupadd ssh-user, then add each ssh user to the group with sudo usermod -a -G ssh-user < | + | |
- | Symmetric ciphers | + | |
- | + | ||
- | Symmetric ciphers are used to encrypt the data after the initial key exchange and authentication is complete. | + | |
- | + | ||
- | Here we have quite a few algorithms: | + | |
- | + | ||
- | 3des-cbc | + | |
- | aes128-cbc | + | |
- | aes192-cbc | + | |
- | aes256-cbc | + | |
- | aes128-ctr | + | |
- | aes192-ctr | + | |
- | aes256-ctr | + | |
- | aes128-gcm@openssh.com | + | |
- | aes256-gcm@openssh.com | + | |
- | arcfour | + | |
- | arcfour128 | + | |
- | arcfour256 | + | |
- | blowfish-cbc | + | |
- | cast128-cbc | + | |
- | chacha20-poly1305@openssh.com | + | |
- | + | ||
- | We have to consider the following: | + | |
- | + | ||
- | Security of the cipher algorithm: This eliminates 1 and 10-12 - both DES and RC4 are broken. Again, no need to wait for them to become even weaker, disable them now. | + | |
- | Key size: At least 128 bits, the more the better. | + | |
- | Block size: Does not apply to stream ciphers. At least 128 bits. This eliminates 13 and 14 because those have a 64 bit block size. | + | |
- | Cipher mode: The recommended approach here is to prefer AE modes and optionally allow CTR for compatibility. CTR with Encrypt-then-MAC is provably secure. | + | |
- | + | ||
- | Chacha20-poly1305 is preferred over AES-GCM because the SSH protocol does not encrypt message sizes when GCM (or EtM) is in use. This allows some traffic analysis even without decrypting the data. We will deal with that soon. | + | |
- | + | ||
- | Recommended / | + | |
- | + | ||
- | Ciphers chacha20-poly1305@openssh.com, | + | |
- | + | ||
- | Recommended / | + | |
- | + | ||
- | Host * | + | |
- | Ciphers chacha20-poly1305@openssh.com, | + | |
- | + | ||
- | Message authentication codes | + | |
- | + | ||
- | Encryption provides confidentiality, | + | |
- | + | ||
- | There are multiple ways to combine ciphers and MACs - not all of these are useful. The 3 most common: | + | |
- | + | ||
- | Encrypt-then-MAC: | + | |
- | MAC-then-encrypt: | + | |
- | Encrypt-and-MAC: | + | |
- | + | ||
- | Only Encrypt-then-MAC should be used, period. Using MAC-then-encrypt have lead to many attacks on TLS while Encrypt-and-MAC have lead to not quite that many attacks on SSH. The reason for this is that the more you fiddle with an attacker provided message, the more chance the attacker has to gain information through side channels. In case of Encrypt-then-MAC, | + | |
- | + | ||
- | Here are the available MAC choices: | + | |
- | + | ||
- | hmac-md5 | + | |
- | hmac-md5-96 | + | |
- | hmac-ripemd160 | + | |
- | hmac-sha1 | + | |
- | hmac-sha1-96 | + | |
- | hmac-sha2-256 | + | |
- | hmac-sha2-512 | + | |
- | umac-64 | + | |
- | umac-128 | + | |
- | hmac-md5-etm@openssh.com | + | |
- | hmac-md5-96-etm@openssh.com | + | |
- | hmac-ripemd160-etm@openssh.com | + | |
- | hmac-sha1-etm@openssh.com | + | |
- | hmac-sha1-96-etm@openssh.com | + | |
- | hmac-sha2-256-etm@openssh.com | + | |
- | hmac-sha2-512-etm@openssh.com | + | |
- | umac-64-etm@openssh.com | + | |
- | umac-128-etm@openssh.com | + | |
- | + | ||
- | The selection considerations: | + | |
- | + | ||
- | Security of the hash algorithm: No MD5 and SHA1. Yes, I know that HMAC-SHA1 does not need collision resistance but why wait? Disable weak crypto today. | + | |
- | Encrypt-then-MAC: | + | |
- | Tag size: At least 128 bits. This eliminates umac-64-etm. | + | |
- | Key size: At least 128 bits. This doesn’t eliminate anything at this point. | + | |
- | + | ||
- | Recommended / | + | |
- | + | ||
- | MACs hmac-sha2-512-etm@openssh.com, | + | |
- | + | ||
- | Recommended / | + | |
- | + | ||
- | Host * | + | |
- | MACs hmac-sha2-512-etm@openssh.com, | + | |
- | + | ||
- | Preventing key theft | + | |
- | + | ||
- | Even with forward secrecy the secret keys must be kept secret. The NSA has a database of stolen keys - you do not want your key there. | + | |
- | System hardening | + | |
- | + | ||
- | OpenSSH has some undocumented, | + | |
- | + | ||
- | Recommended / | + | |
- | + | ||
- | Host * | + | |
- | | + | |
- | + | ||
- | This post is not intended to be a comprehensive system security guide. Very briefly: | + | |
- | + | ||
- | Don’t install what you don’t need: Every single line of code has a chance of containing a bug. Some of these bugs are security holes. Fewer lines, fewer holes. | + | |
- | Use free software: As in speech. You want to use code that’s actually reviewed or that you can review yourself. There is no way to achieve that without source code. Someone may have reviewed proprietary crap but who knows. | + | |
- | Keep your software up to date: New versions often fix critical security holes. | + | |
- | Exploit mitigation: Sad but true - there will always be security holes in your software. There are things you can do to prevent their exploitation, | + | |
- | + | ||
- | + | ||
+ | {{indexmenu>: |