nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
b26077b1ae
putty-source/proxy/cproxy.h

100 lines
4.4 KiB
C
Raw Normal View History

HTTP proxy: implement Digest authentication. In http.c, this drops in reasonably neatly alongside the existing support for Basic, now that we're waiting for an initial 407 response from the proxy to tell us which auth mechanism it would prefer to use. The rest of this patch is mostly contriving to add testcrypt support for the function in cproxy.c that generates the complicated output header to go in the HTTP request: you need about a dozen assorted parameters, the actual response hash has two more hashes in its preimage, and there's even an option to hash the username as well if necessary. Much more complicated than CHAP (which is just plain HMAC-MD5), so it needs testing! Happily, RFC 7616 comes with some reasonably useful test cases, and I've managed to transcribe them directly into cryptsuite.py and demonstrate that my response-generator agrees with them. End-to-end testing of the whole system was done against Squid 4.13 (specifically, the squid package in Debian bullseye, version 4.13-10).
2021-11-20 14:56:32 +00:00
/*
* Header for the interaction between proxy.c and cproxy.c. Separated
* from proxy.h proper so that testcrypt can include it conveniently.
*/
extern const bool socks5_chap_available;
strbuf *chap_response(ptrlen challenge, ptrlen password);
extern const bool http_digest_available;
Withdraw support for SHA-512-256 in HTTP Digest. I was dubious about it to begin with, when I found that RFC 7616's example seemed to be treating it as a 256-bit truncation of SHA-512, and not the thing FIPS 180-4 section 6.7 specifies as "SHA-512/256" (which also changes the initial hash state). Having failed to get a clarifying response from the RFC authors, I had the idea this morning of testing other HTTP clients to see what _they_ thought that hash function meant, and then at least I could go with an existing in-practice consensus. There is no in-practice consensus. Firefox doesn't support that algorithm at all (but they do support SHA-256); wget doesn't support anything that RFC 7616 added to the original RFC 2617. But the prize for weirdness goes to curl, which does accept the name "SHA-512-256" and ... treats it as an alias for SHA-256! So I think the situation among real clients is too confusing to even try to work with, and I'm going to stop adding to it. PuTTY will follow Firefox's policy: if a proxy server asks for SHA-256 digests we'll happily provide them, but if they ask for SHA-512-256 we'll refuse on the grounds that it's not clear enough what it means.
2021-11-27 11:41:00 +00:00
/*
* List macro for the various hash functions defined for HTTP Digest.
*
* Of these, MD5 is the original one; SHA-256 is unambiguous; but
* SHA-512-256 seems to be controversial.
*
* RFC 7616 doesn't provide a normative reference, or any text
* explaining what they mean by it. They apparently expect you to
* already know. The problem with that is that there are two plausible
* things they _might_ have meant:
*
* 1. Ordinary SHA-512, truncated to 256 bits by discarding the
* second half of the hash output, per FIPS 180-4 section 7 (which
* says that in general it's OK to truncate hash functions like
* that if you need to). FIPS 180-4 assigns no particular specific
* spelling to this kind of truncated hash.
*
* 2. The same except that the initial state of the SHA-512 algorithm
* is reset to a different 512-bit vector to ensure that it's a
* distinguishable hash function in its own right, per FIPS 180-4
* section 6.7 (which in turn refers to section 5.3.6.2 for the
* actual initial values). FIPS 180-4 spells this "SHA-512/256".
*
* The text of RFC 7616 is totally silent as to which of these they
* meant. Their spelling is inconsistent: the protocol identifier is
* "SHA-512-256", but in some places in the RFC they say
* "SHA-512/256", matching FIPS's spelling for the hash in option 2
* above. On the other hand, the example authentication exchange in
* section 3.9.2 of the RFC contains hashes that are consistent with
* option 1 above (a truncation of plain SHA-512).
*
* Erratum 4897, https://www.rfc-editor.org/errata/eid4897, points out
* this ambiguity, and suggests correcting the example exchange to be
* consistent with option 2. However, as of 2021-11-27, that erratum
* is shown on the RFC Editor website in state "Reported", with no
* response (positive _or_ negative) from the RFC authors or anyone
* else. (And it was reported in 2016, so it's not as if they haven't
* had time.)
*
* So, which hash should we implement? Perhaps there's a consensus
* among existing implementations in the wild?
*
* I rigged up an HTTP server to present a SHA-512-256 Digest auth
* request, and tried various HTTP clients against it. The only HTTP
* client I found that accepts 'algorithm="SHA-512-256"' and sends
* back an auth attempt quoting the same hash is curl - and curl,
* bizarrely, seems to treat "SHA-512-256" as _neither_ of the above
* options, but as simply an alias for SHA-256!
*
* Therefore, I think the only safe answer is to refuse to support
* that hash at all: it's too confusing.
*
* However, I keep it in the list of hashes here, so that we can check
* the test case from RFC 7616, because that test case is also the
* only test of username hashing. So we reject it in proxy/http.c, but
* accept it in the internal function http_digest_response(), and
* treat it as option 1 (truncated SHA-512).
*
* Therefore, the parameters to each invocation of X in the following
* list macro are:
*
* - internal enum id for the hash
* - protocol identifier string
* - algorithm to use for computing it (as a const ssh_hashalg *)
* - length to truncate the output to
* - whether we accept it in http.c or not.
HTTP proxy: correctly handle multiple auth headers. This is a piece I forgot in the initial implementation of HTTP Digest: an HTTP server can send _more than one_ authentication request header (WWW-Authenticate for normal servers, Proxy-Authenticate for proxies), and if it does, they're supposed to be treated as alternatives to each other, so that the client chooses one to reply to. I suppose that technically we were 'complying' with that spec already, in that HttpProxyNegotiator would have read each new header and overwritten all the fields set by the previous one, so we'd always have gone with the last header presented by the server. But that seems inelegant: better to choose the one we actually like best. So now we do that. All the details of an auth header are moved out of the main HttpProxyNegotiator struct into a sub-struct we can have multiple copies of. Each new header is parsed into a fresh struct of that kind, and then we can compare it with the previous one and decide which we prefer. The preference order, naturally, is 'more secure is better': Digest beats Basic, and between two Digest headers, SHA-256 beats MD5. (And anything beats a header we can't make sense of at all.) Another side effect of this change is that a 407 response which contains _no_ Proxy-Authenticate headers will trigger an error message saying so, instead of just going with whatever happened to be left in the relevant variables from the previous attempt.
2021-12-21 09:35:13 +00:00
*
* Finally, the ordering of the accepted hashes is our preference
* order among them if the server offers a choice.
Withdraw support for SHA-512-256 in HTTP Digest. I was dubious about it to begin with, when I found that RFC 7616's example seemed to be treating it as a 256-bit truncation of SHA-512, and not the thing FIPS 180-4 section 6.7 specifies as "SHA-512/256" (which also changes the initial hash state). Having failed to get a clarifying response from the RFC authors, I had the idea this morning of testing other HTTP clients to see what _they_ thought that hash function meant, and then at least I could go with an existing in-practice consensus. There is no in-practice consensus. Firefox doesn't support that algorithm at all (but they do support SHA-256); wget doesn't support anything that RFC 7616 added to the original RFC 2617. But the prize for weirdness goes to curl, which does accept the name "SHA-512-256" and ... treats it as an alias for SHA-256! So I think the situation among real clients is too confusing to even try to work with, and I'm going to stop adding to it. PuTTY will follow Firefox's policy: if a proxy server asks for SHA-256 digests we'll happily provide them, but if they ask for SHA-512-256 we'll refuse on the grounds that it's not clear enough what it means.
2021-11-27 11:41:00 +00:00
*/
HTTP proxy: implement Digest authentication. In http.c, this drops in reasonably neatly alongside the existing support for Basic, now that we're waiting for an initial 407 response from the proxy to tell us which auth mechanism it would prefer to use. The rest of this patch is mostly contriving to add testcrypt support for the function in cproxy.c that generates the complicated output header to go in the HTTP request: you need about a dozen assorted parameters, the actual response hash has two more hashes in its preimage, and there's even an option to hash the username as well if necessary. Much more complicated than CHAP (which is just plain HMAC-MD5), so it needs testing! Happily, RFC 7616 comes with some reasonably useful test cases, and I've managed to transcribe them directly into cryptsuite.py and demonstrate that my response-generator agrees with them. End-to-end testing of the whole system was done against Squid 4.13 (specifically, the squid package in Debian bullseye, version 4.13-10).
2021-11-20 14:56:32 +00:00
#define HTTP_DIGEST_HASHES(X) \
Withdraw support for SHA-512-256 in HTTP Digest. I was dubious about it to begin with, when I found that RFC 7616's example seemed to be treating it as a 256-bit truncation of SHA-512, and not the thing FIPS 180-4 section 6.7 specifies as "SHA-512/256" (which also changes the initial hash state). Having failed to get a clarifying response from the RFC authors, I had the idea this morning of testing other HTTP clients to see what _they_ thought that hash function meant, and then at least I could go with an existing in-practice consensus. There is no in-practice consensus. Firefox doesn't support that algorithm at all (but they do support SHA-256); wget doesn't support anything that RFC 7616 added to the original RFC 2617. But the prize for weirdness goes to curl, which does accept the name "SHA-512-256" and ... treats it as an alias for SHA-256! So I think the situation among real clients is too confusing to even try to work with, and I'm going to stop adding to it. PuTTY will follow Firefox's policy: if a proxy server asks for SHA-256 digests we'll happily provide them, but if they ask for SHA-512-256 we'll refuse on the grounds that it's not clear enough what it means.
2021-11-27 11:41:00 +00:00
X(HTTP_DIGEST_MD5, "MD5", &ssh_md5, 128, true) \
X(HTTP_DIGEST_SHA256, "SHA-256", &ssh_sha256, 256, true) \
X(HTTP_DIGEST_SHA512_256, "SHA-512-256", &ssh_sha512, 256, false) \
HTTP proxy: implement Digest authentication. In http.c, this drops in reasonably neatly alongside the existing support for Basic, now that we're waiting for an initial 407 response from the proxy to tell us which auth mechanism it would prefer to use. The rest of this patch is mostly contriving to add testcrypt support for the function in cproxy.c that generates the complicated output header to go in the HTTP request: you need about a dozen assorted parameters, the actual response hash has two more hashes in its preimage, and there's even an option to hash the username as well if necessary. Much more complicated than CHAP (which is just plain HMAC-MD5), so it needs testing! Happily, RFC 7616 comes with some reasonably useful test cases, and I've managed to transcribe them directly into cryptsuite.py and demonstrate that my response-generator agrees with them. End-to-end testing of the whole system was done against Squid 4.13 (specifically, the squid package in Debian bullseye, version 4.13-10).
2021-11-20 14:56:32 +00:00
/* end of list */
Withdraw support for SHA-512-256 in HTTP Digest. I was dubious about it to begin with, when I found that RFC 7616's example seemed to be treating it as a 256-bit truncation of SHA-512, and not the thing FIPS 180-4 section 6.7 specifies as "SHA-512/256" (which also changes the initial hash state). Having failed to get a clarifying response from the RFC authors, I had the idea this morning of testing other HTTP clients to see what _they_ thought that hash function meant, and then at least I could go with an existing in-practice consensus. There is no in-practice consensus. Firefox doesn't support that algorithm at all (but they do support SHA-256); wget doesn't support anything that RFC 7616 added to the original RFC 2617. But the prize for weirdness goes to curl, which does accept the name "SHA-512-256" and ... treats it as an alias for SHA-256! So I think the situation among real clients is too confusing to even try to work with, and I'm going to stop adding to it. PuTTY will follow Firefox's policy: if a proxy server asks for SHA-256 digests we'll happily provide them, but if they ask for SHA-512-256 we'll refuse on the grounds that it's not clear enough what it means.
2021-11-27 11:41:00 +00:00
HTTP proxy: implement Digest authentication. In http.c, this drops in reasonably neatly alongside the existing support for Basic, now that we're waiting for an initial 407 response from the proxy to tell us which auth mechanism it would prefer to use. The rest of this patch is mostly contriving to add testcrypt support for the function in cproxy.c that generates the complicated output header to go in the HTTP request: you need about a dozen assorted parameters, the actual response hash has two more hashes in its preimage, and there's even an option to hash the username as well if necessary. Much more complicated than CHAP (which is just plain HMAC-MD5), so it needs testing! Happily, RFC 7616 comes with some reasonably useful test cases, and I've managed to transcribe them directly into cryptsuite.py and demonstrate that my response-generator agrees with them. End-to-end testing of the whole system was done against Squid 4.13 (specifically, the squid package in Debian bullseye, version 4.13-10).
2021-11-20 14:56:32 +00:00
typedef enum HttpDigestHash {
Withdraw support for SHA-512-256 in HTTP Digest. I was dubious about it to begin with, when I found that RFC 7616's example seemed to be treating it as a 256-bit truncation of SHA-512, and not the thing FIPS 180-4 section 6.7 specifies as "SHA-512/256" (which also changes the initial hash state). Having failed to get a clarifying response from the RFC authors, I had the idea this morning of testing other HTTP clients to see what _they_ thought that hash function meant, and then at least I could go with an existing in-practice consensus. There is no in-practice consensus. Firefox doesn't support that algorithm at all (but they do support SHA-256); wget doesn't support anything that RFC 7616 added to the original RFC 2617. But the prize for weirdness goes to curl, which does accept the name "SHA-512-256" and ... treats it as an alias for SHA-256! So I think the situation among real clients is too confusing to even try to work with, and I'm going to stop adding to it. PuTTY will follow Firefox's policy: if a proxy server asks for SHA-256 digests we'll happily provide them, but if they ask for SHA-512-256 we'll refuse on the grounds that it's not clear enough what it means.
2021-11-27 11:41:00 +00:00
#define DECL_ENUM(id, str, alg, bits, accepted) id,
HTTP proxy: implement Digest authentication. In http.c, this drops in reasonably neatly alongside the existing support for Basic, now that we're waiting for an initial 407 response from the proxy to tell us which auth mechanism it would prefer to use. The rest of this patch is mostly contriving to add testcrypt support for the function in cproxy.c that generates the complicated output header to go in the HTTP request: you need about a dozen assorted parameters, the actual response hash has two more hashes in its preimage, and there's even an option to hash the username as well if necessary. Much more complicated than CHAP (which is just plain HMAC-MD5), so it needs testing! Happily, RFC 7616 comes with some reasonably useful test cases, and I've managed to transcribe them directly into cryptsuite.py and demonstrate that my response-generator agrees with them. End-to-end testing of the whole system was done against Squid 4.13 (specifically, the squid package in Debian bullseye, version 4.13-10).
2021-11-20 14:56:32 +00:00
HTTP_DIGEST_HASHES(DECL_ENUM)
#undef DECL_ENUM
N_HTTP_DIGEST_HASHES
} HttpDigestHash;
Withdraw support for SHA-512-256 in HTTP Digest. I was dubious about it to begin with, when I found that RFC 7616's example seemed to be treating it as a 256-bit truncation of SHA-512, and not the thing FIPS 180-4 section 6.7 specifies as "SHA-512/256" (which also changes the initial hash state). Having failed to get a clarifying response from the RFC authors, I had the idea this morning of testing other HTTP clients to see what _they_ thought that hash function meant, and then at least I could go with an existing in-practice consensus. There is no in-practice consensus. Firefox doesn't support that algorithm at all (but they do support SHA-256); wget doesn't support anything that RFC 7616 added to the original RFC 2617. But the prize for weirdness goes to curl, which does accept the name "SHA-512-256" and ... treats it as an alias for SHA-256! So I think the situation among real clients is too confusing to even try to work with, and I'm going to stop adding to it. PuTTY will follow Firefox's policy: if a proxy server asks for SHA-256 digests we'll happily provide them, but if they ask for SHA-512-256 we'll refuse on the grounds that it's not clear enough what it means.
2021-11-27 11:41:00 +00:00
HTTP proxy: implement Digest authentication. In http.c, this drops in reasonably neatly alongside the existing support for Basic, now that we're waiting for an initial 407 response from the proxy to tell us which auth mechanism it would prefer to use. The rest of this patch is mostly contriving to add testcrypt support for the function in cproxy.c that generates the complicated output header to go in the HTTP request: you need about a dozen assorted parameters, the actual response hash has two more hashes in its preimage, and there's even an option to hash the username as well if necessary. Much more complicated than CHAP (which is just plain HMAC-MD5), so it needs testing! Happily, RFC 7616 comes with some reasonably useful test cases, and I've managed to transcribe them directly into cryptsuite.py and demonstrate that my response-generator agrees with them. End-to-end testing of the whole system was done against Squid 4.13 (specifically, the squid package in Debian bullseye, version 4.13-10).
2021-11-20 14:56:32 +00:00
extern const char *const httphashnames[];
Withdraw support for SHA-512-256 in HTTP Digest. I was dubious about it to begin with, when I found that RFC 7616's example seemed to be treating it as a 256-bit truncation of SHA-512, and not the thing FIPS 180-4 section 6.7 specifies as "SHA-512/256" (which also changes the initial hash state). Having failed to get a clarifying response from the RFC authors, I had the idea this morning of testing other HTTP clients to see what _they_ thought that hash function meant, and then at least I could go with an existing in-practice consensus. There is no in-practice consensus. Firefox doesn't support that algorithm at all (but they do support SHA-256); wget doesn't support anything that RFC 7616 added to the original RFC 2617. But the prize for weirdness goes to curl, which does accept the name "SHA-512-256" and ... treats it as an alias for SHA-256! So I think the situation among real clients is too confusing to even try to work with, and I'm going to stop adding to it. PuTTY will follow Firefox's policy: if a proxy server asks for SHA-256 digests we'll happily provide them, but if they ask for SHA-512-256 we'll refuse on the grounds that it's not clear enough what it means.
2021-11-27 11:41:00 +00:00
extern const bool httphashaccepted[];
HTTP proxy: implement Digest authentication. In http.c, this drops in reasonably neatly alongside the existing support for Basic, now that we're waiting for an initial 407 response from the proxy to tell us which auth mechanism it would prefer to use. The rest of this patch is mostly contriving to add testcrypt support for the function in cproxy.c that generates the complicated output header to go in the HTTP request: you need about a dozen assorted parameters, the actual response hash has two more hashes in its preimage, and there's even an option to hash the username as well if necessary. Much more complicated than CHAP (which is just plain HMAC-MD5), so it needs testing! Happily, RFC 7616 comes with some reasonably useful test cases, and I've managed to transcribe them directly into cryptsuite.py and demonstrate that my response-generator agrees with them. End-to-end testing of the whole system was done against Squid 4.13 (specifically, the squid package in Debian bullseye, version 4.13-10).
2021-11-20 14:56:32 +00:00
void http_digest_response(BinarySink *bs, ptrlen username, ptrlen password,
ptrlen realm, ptrlen method, ptrlen uri, ptrlen qop,
ptrlen nonce, ptrlen opaque, uint32_t nonce_count,
HttpDigestHash hash, bool hash_username);
Reference in New Issue Copy Permalink