mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-01-09 17:38:00 +00:00
42740a5455
In the case where a server presents a host key signed by a different certificate from the one you've configured, it need not _always_ be evidence of wrongdoing. I can imagine situations in which two CAs cover overlapping sets of things, and you don't want to blanket-trust one of them, but you do want to connect to a specific host signed by that one. Accordingly, PuTTY's previous policy of unconditionally aborting the connection if certificate validation fails (which was always intended as a stopgap until I thought through what I wanted to replace it with) is now replaced by fallback handling: we present the host key fingerprint to the user and give them the option to accept and/or cache it based on the public key itself. This means that the certified key types have to have a representation in the host key cache. So I've assigned each one a type id, and generate the cache string itself by simply falling back to the base key. (Rationale for the latter: re-signing a public key with a different certificate doesn't change the _private_ key, or the set of valid signatures generated with it. So if you've been convinced for reasons other than the certificate that a particular private key is in the possession of $host, then proof of ownership of that private key should be enough to convince you you're talking to $host no matter what CA has signed the public half this week.) We now offer to receive a given certified host key type if _either_ we have at least one CA configured to trust that host, _or_ we have a certified key of that type cached. (So once you've decided manually that you trust a particular key, we can still receive that key and authenticate the host with it, even if you later delete the CA record that it didn't match anyway.) One change from normal (uncertified) host key handling is that for certified key types _all_ the host key prompts use the stronger language, with "WARNING - POTENTIAL SECURITY BREACH!" rather than the mild 'hmm, we haven't seen this host before'. Rationale: if you expected this CA key and got that one, it _could_ be a bold-as-brass MITM attempt in which someone hoped you'd accept their entire CA key. The mild wording is only for the case where we had no previous expectations _at all_ for the host to violate: not a CA _or_ a cached key. |
||
|---|---|---|
| .. | ||
| aes-common.c | ||
| aes-neon.c | ||
| aes-ni.c | ||
| aes-select.c | ||
| aes-sw.c | ||
| aes.h | ||
| arcfour.c | ||
| argon2.c | ||
| bcrypt.c | ||
| blake2.c | ||
| blowfish.c | ||
| blowfish.h | ||
| chacha20-poly1305.c | ||
| CMakeLists.txt | ||
| crc32.c | ||
| des.c | ||
| diffie-hellman.c | ||
| dsa.c | ||
| ecc-arithmetic.c | ||
| ecc-ssh.c | ||
| ecc.h | ||
| hash_simple.c | ||
| hmac.c | ||
| mac_simple.c | ||
| mac.c | ||
| md5.c | ||
| mpint_i.h | ||
| mpint.c | ||
| ntru.c | ||
| ntru.h | ||
| openssh-certs.c | ||
| prng.c | ||
| pubkey-pem.c | ||
| pubkey-ppk.c | ||
| pubkey-ssh1.c | ||
| rsa.c | ||
| sha1-common.c | ||
| sha1-neon.c | ||
| sha1-ni.c | ||
| sha1-select.c | ||
| sha1-sw.c | ||
| sha1.h | ||
| sha3.c | ||
| sha256-common.c | ||
| sha256-neon.c | ||
| sha256-ni.c | ||
| sha256-select.c | ||
| sha256-sw.c | ||
| sha256.h | ||
| sha512-common.c | ||
| sha512-neon.c | ||
| sha512-select.c | ||
| sha512-sw.c | ||
| sha512.h | ||
| xdmauth.c | ||