nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 09:27:59 +00:00
Code Issues Projects Releases Wiki Activity
pre-0.83
putty-source/proxy/socks5.c

499 lines
17 KiB
C
Raw Permalink Normal View History

Reorganise proxy system into coroutines. Previously, the proxy negotiation functions were written as explicit state machines, with ps->state being manually set to a sequence of positive integer values which would be tested by if statements in the next call to the same negotiation function. That's not how this code base likes to do things! We have a coroutine system to allow those state machines to be implicit rather than explicit, so that we can use ordinary control flow statements like while loops. Reorganised each proxy negotiation function into a coroutine-based system like that. While I'm at it, I've also moved each proxy negotiator out into its own source file, to make proxy.c less overcrowded and monolithic. And _that_ gave me the opportunity to define each negotiator as an implementation of a trait rather than as a single function - which means now each one can define its own local variables and have its own cleanup function, instead of all of them having to share the variables inside the main ProxySocket struct. In the new coroutine system, negotiators don't have to worry about the mechanics of actually sending data down the underlying Socket any more. The negotiator coroutine just appends to a bufchain (via a provided bufchain_sink), and after every call to the coroutine, central code in proxy.c transfers the data to the Socket itself. This avoids a lot of intermediate allocations within the negotiators, which previously kept having to make temporary strbufs or arrays in order to have something to point an sk_write() at; now they can just put formatted data directly into the output bufchain via the marshal.h interface. In this version of the code, I've also moved most of the SOCKS5 CHAP implementation from cproxy.c into socks5.c, so that it can sit in the same coroutine as the rest of the proxy negotiation control flow. That's because calling a sub-coroutine (co-subroutine?) is awkward to set up (though it is _possible_ - we do SSH-2 kex that way), and there's no real need to bother in this case, since the only thing that really needs to go in cproxy.c is the actual cryptography plus a flag to tell socks5.c whether to offer CHAP authentication in the first place.
2021-11-19 10:26:41 +00:00
/*
* SOCKS 5 proxy negotiation.
*/
#include "putty.h"
#include "network.h"
#include "proxy.h"
#include "socks.h"
#include "sshcr.h"
static inline const char *socks5_auth_name(unsigned char m)
{
switch (m) {
case SOCKS5_AUTH_NONE: return "none";
case SOCKS5_AUTH_GSSAPI: return "GSSAPI";
case SOCKS5_AUTH_PASSWORD: return "password";
case SOCKS5_AUTH_CHAP: return "CHAP";
default: return "unknown";
}
}
static inline const char *socks5_response_text(unsigned char m)
{
switch (m) {
case SOCKS5_RESP_SUCCESS: return "success";
case SOCKS5_RESP_FAILURE: return "unspecified failure";
case SOCKS5_RESP_CONNECTION_NOT_ALLOWED_BY_RULESET:
return "connection not allowed by ruleset";
case SOCKS5_RESP_NETWORK_UNREACHABLE: return "network unreachable";
case SOCKS5_RESP_HOST_UNREACHABLE: return "host unreachable";
case SOCKS5_RESP_CONNECTION_REFUSED: return "connection refused";
case SOCKS5_RESP_TTL_EXPIRED: return "TTL expired";
case SOCKS5_RESP_COMMAND_NOT_SUPPORTED: return "command not supported";
case SOCKS5_RESP_ADDRTYPE_NOT_SUPPORTED:
return "address type not supported";
default: return "unknown";
}
}
typedef struct Socks5ProxyNegotiator {
int crLine;
strbuf *auth_methods_offered;
unsigned char auth_method;
unsigned n_chap_attrs;
unsigned chap_attr, chap_attr_len;
unsigned char chap_buf[256];
Support interactive password prompts in SOCKS 5. This is the first of the ProxyNegotiator implementations to use the new interaction system. The other two both need more work than just inserting a prompt and using the result.
2021-11-19 14:33:47 +00:00
strbuf *username, *password;
prompts_t *prompts;
int username_prompt_index, password_prompt_index;
Reorganise proxy system into coroutines. Previously, the proxy negotiation functions were written as explicit state machines, with ps->state being manually set to a sequence of positive integer values which would be tested by if statements in the next call to the same negotiation function. That's not how this code base likes to do things! We have a coroutine system to allow those state machines to be implicit rather than explicit, so that we can use ordinary control flow statements like while loops. Reorganised each proxy negotiation function into a coroutine-based system like that. While I'm at it, I've also moved each proxy negotiator out into its own source file, to make proxy.c less overcrowded and monolithic. And _that_ gave me the opportunity to define each negotiator as an implementation of a trait rather than as a single function - which means now each one can define its own local variables and have its own cleanup function, instead of all of them having to share the variables inside the main ProxySocket struct. In the new coroutine system, negotiators don't have to worry about the mechanics of actually sending data down the underlying Socket any more. The negotiator coroutine just appends to a bufchain (via a provided bufchain_sink), and after every call to the coroutine, central code in proxy.c transfers the data to the Socket itself. This avoids a lot of intermediate allocations within the negotiators, which previously kept having to make temporary strbufs or arrays in order to have something to point an sk_write() at; now they can just put formatted data directly into the output bufchain via the marshal.h interface. In this version of the code, I've also moved most of the SOCKS5 CHAP implementation from cproxy.c into socks5.c, so that it can sit in the same coroutine as the rest of the proxy negotiation control flow. That's because calling a sub-coroutine (co-subroutine?) is awkward to set up (though it is _possible_ - we do SSH-2 kex that way), and there's no real need to bother in this case, since the only thing that really needs to go in cproxy.c is the actual cryptography plus a flag to tell socks5.c whether to offer CHAP authentication in the first place.
2021-11-19 10:26:41 +00:00
int response_addr_length;
ProxyNegotiator pn;
} Socks5ProxyNegotiator;
static ProxyNegotiator *proxy_socks5_new(const ProxyNegotiatorVT *vt)
{
Socks5ProxyNegotiator *s = snew(Socks5ProxyNegotiator);
memset(s, 0, sizeof(*s));
s->pn.vt = vt;
s->auth_methods_offered = strbuf_new();
Support interactive password prompts in SOCKS 5. This is the first of the ProxyNegotiator implementations to use the new interaction system. The other two both need more work than just inserting a prompt and using the result.
2021-11-19 14:33:47 +00:00
s->username = strbuf_new();
s->password = strbuf_new_nm();
Reorganise proxy system into coroutines. Previously, the proxy negotiation functions were written as explicit state machines, with ps->state being manually set to a sequence of positive integer values which would be tested by if statements in the next call to the same negotiation function. That's not how this code base likes to do things! We have a coroutine system to allow those state machines to be implicit rather than explicit, so that we can use ordinary control flow statements like while loops. Reorganised each proxy negotiation function into a coroutine-based system like that. While I'm at it, I've also moved each proxy negotiator out into its own source file, to make proxy.c less overcrowded and monolithic. And _that_ gave me the opportunity to define each negotiator as an implementation of a trait rather than as a single function - which means now each one can define its own local variables and have its own cleanup function, instead of all of them having to share the variables inside the main ProxySocket struct. In the new coroutine system, negotiators don't have to worry about the mechanics of actually sending data down the underlying Socket any more. The negotiator coroutine just appends to a bufchain (via a provided bufchain_sink), and after every call to the coroutine, central code in proxy.c transfers the data to the Socket itself. This avoids a lot of intermediate allocations within the negotiators, which previously kept having to make temporary strbufs or arrays in order to have something to point an sk_write() at; now they can just put formatted data directly into the output bufchain via the marshal.h interface. In this version of the code, I've also moved most of the SOCKS5 CHAP implementation from cproxy.c into socks5.c, so that it can sit in the same coroutine as the rest of the proxy negotiation control flow. That's because calling a sub-coroutine (co-subroutine?) is awkward to set up (though it is _possible_ - we do SSH-2 kex that way), and there's no real need to bother in this case, since the only thing that really needs to go in cproxy.c is the actual cryptography plus a flag to tell socks5.c whether to offer CHAP authentication in the first place.
2021-11-19 10:26:41 +00:00
return &s->pn;
}
static void proxy_socks5_free(ProxyNegotiator *pn)
{
Socks5ProxyNegotiator *s = container_of(pn, Socks5ProxyNegotiator, pn);
strbuf_free(s->auth_methods_offered);
Support interactive password prompts in SOCKS 5. This is the first of the ProxyNegotiator implementations to use the new interaction system. The other two both need more work than just inserting a prompt and using the result.
2021-11-19 14:33:47 +00:00
strbuf_free(s->username);
strbuf_free(s->password);
if (s->prompts)
free_prompts(s->prompts);
proxy_socks5_free: fix inadequate smemclr. Thanks to Coverity for pointing out that I'd only cleared sizeof(pointer) amount of the struct, not sizeof(the whole thing).
2022-01-29 18:00:13 +00:00
smemclr(s, sizeof(*s));
Reorganise proxy system into coroutines. Previously, the proxy negotiation functions were written as explicit state machines, with ps->state being manually set to a sequence of positive integer values which would be tested by if statements in the next call to the same negotiation function. That's not how this code base likes to do things! We have a coroutine system to allow those state machines to be implicit rather than explicit, so that we can use ordinary control flow statements like while loops. Reorganised each proxy negotiation function into a coroutine-based system like that. While I'm at it, I've also moved each proxy negotiator out into its own source file, to make proxy.c less overcrowded and monolithic. And _that_ gave me the opportunity to define each negotiator as an implementation of a trait rather than as a single function - which means now each one can define its own local variables and have its own cleanup function, instead of all of them having to share the variables inside the main ProxySocket struct. In the new coroutine system, negotiators don't have to worry about the mechanics of actually sending data down the underlying Socket any more. The negotiator coroutine just appends to a bufchain (via a provided bufchain_sink), and after every call to the coroutine, central code in proxy.c transfers the data to the Socket itself. This avoids a lot of intermediate allocations within the negotiators, which previously kept having to make temporary strbufs or arrays in order to have something to point an sk_write() at; now they can just put formatted data directly into the output bufchain via the marshal.h interface. In this version of the code, I've also moved most of the SOCKS5 CHAP implementation from cproxy.c into socks5.c, so that it can sit in the same coroutine as the rest of the proxy negotiation control flow. That's because calling a sub-coroutine (co-subroutine?) is awkward to set up (though it is _possible_ - we do SSH-2 kex that way), and there's no real need to bother in this case, since the only thing that really needs to go in cproxy.c is the actual cryptography plus a flag to tell socks5.c whether to offer CHAP authentication in the first place.
2021-11-19 10:26:41 +00:00
sfree(s);
}
static void proxy_socks5_process_queue(ProxyNegotiator *pn)
{
Socks5ProxyNegotiator *s = container_of(pn, Socks5ProxyNegotiator, pn);
crBegin(s->crLine);
/*
* SOCKS 5 initial client packet:
*
* byte version
* byte number of available auth methods
* byte[] that many bytes indicating auth types
*/
put_byte(pn->output, SOCKS5_REQUEST_VERSION);
strbuf_clear(s->auth_methods_offered);
Support interactive password prompts in SOCKS 5. This is the first of the ProxyNegotiator implementations to use the new interaction system. The other two both need more work than just inserting a prompt and using the result.
2021-11-19 14:33:47 +00:00
/*
* We have two basic kinds of authentication to offer: none at
* all, and password-based systems (whether the password is sent
* in cleartext or proved via CHAP).
*
* We always offer 'none' as an option. We offer 'password' if we
* either have a username and password already from the Conf, or
* we have a Seat available to ask for them interactively. If
* neither, we don't offer those options in the first place.
*/
Reorganise proxy system into coroutines. Previously, the proxy negotiation functions were written as explicit state machines, with ps->state being manually set to a sequence of positive integer values which would be tested by if statements in the next call to the same negotiation function. That's not how this code base likes to do things! We have a coroutine system to allow those state machines to be implicit rather than explicit, so that we can use ordinary control flow statements like while loops. Reorganised each proxy negotiation function into a coroutine-based system like that. While I'm at it, I've also moved each proxy negotiator out into its own source file, to make proxy.c less overcrowded and monolithic. And _that_ gave me the opportunity to define each negotiator as an implementation of a trait rather than as a single function - which means now each one can define its own local variables and have its own cleanup function, instead of all of them having to share the variables inside the main ProxySocket struct. In the new coroutine system, negotiators don't have to worry about the mechanics of actually sending data down the underlying Socket any more. The negotiator coroutine just appends to a bufchain (via a provided bufchain_sink), and after every call to the coroutine, central code in proxy.c transfers the data to the Socket itself. This avoids a lot of intermediate allocations within the negotiators, which previously kept having to make temporary strbufs or arrays in order to have something to point an sk_write() at; now they can just put formatted data directly into the output bufchain via the marshal.h interface. In this version of the code, I've also moved most of the SOCKS5 CHAP implementation from cproxy.c into socks5.c, so that it can sit in the same coroutine as the rest of the proxy negotiation control flow. That's because calling a sub-coroutine (co-subroutine?) is awkward to set up (though it is _possible_ - we do SSH-2 kex that way), and there's no real need to bother in this case, since the only thing that really needs to go in cproxy.c is the actual cryptography plus a flag to tell socks5.c whether to offer CHAP authentication in the first place.
2021-11-19 10:26:41 +00:00
put_byte(s->auth_methods_offered, SOCKS5_AUTH_NONE);
Support interactive password prompts in SOCKS 5. This is the first of the ProxyNegotiator implementations to use the new interaction system. The other two both need more work than just inserting a prompt and using the result.
2021-11-19 14:33:47 +00:00
put_dataz(s->username, conf_get_str(pn->ps->conf, CONF_proxy_username));
put_dataz(s->password, conf_get_str(pn->ps->conf, CONF_proxy_password));
if (pn->itr || (s->username->len && s->password->len)) {
if (socks5_chap_available)
put_byte(s->auth_methods_offered, SOCKS5_AUTH_CHAP);
Reorganise proxy system into coroutines. Previously, the proxy negotiation functions were written as explicit state machines, with ps->state being manually set to a sequence of positive integer values which would be tested by if statements in the next call to the same negotiation function. That's not how this code base likes to do things! We have a coroutine system to allow those state machines to be implicit rather than explicit, so that we can use ordinary control flow statements like while loops. Reorganised each proxy negotiation function into a coroutine-based system like that. While I'm at it, I've also moved each proxy negotiator out into its own source file, to make proxy.c less overcrowded and monolithic. And _that_ gave me the opportunity to define each negotiator as an implementation of a trait rather than as a single function - which means now each one can define its own local variables and have its own cleanup function, instead of all of them having to share the variables inside the main ProxySocket struct. In the new coroutine system, negotiators don't have to worry about the mechanics of actually sending data down the underlying Socket any more. The negotiator coroutine just appends to a bufchain (via a provided bufchain_sink), and after every call to the coroutine, central code in proxy.c transfers the data to the Socket itself. This avoids a lot of intermediate allocations within the negotiators, which previously kept having to make temporary strbufs or arrays in order to have something to point an sk_write() at; now they can just put formatted data directly into the output bufchain via the marshal.h interface. In this version of the code, I've also moved most of the SOCKS5 CHAP implementation from cproxy.c into socks5.c, so that it can sit in the same coroutine as the rest of the proxy negotiation control flow. That's because calling a sub-coroutine (co-subroutine?) is awkward to set up (though it is _possible_ - we do SSH-2 kex that way), and there's no real need to bother in this case, since the only thing that really needs to go in cproxy.c is the actual cryptography plus a flag to tell socks5.c whether to offer CHAP authentication in the first place.
2021-11-19 10:26:41 +00:00
Support interactive password prompts in SOCKS 5. This is the first of the ProxyNegotiator implementations to use the new interaction system. The other two both need more work than just inserting a prompt and using the result.
2021-11-19 14:33:47 +00:00
put_byte(s->auth_methods_offered, SOCKS5_AUTH_PASSWORD);
Reorganise proxy system into coroutines. Previously, the proxy negotiation functions were written as explicit state machines, with ps->state being manually set to a sequence of positive integer values which would be tested by if statements in the next call to the same negotiation function. That's not how this code base likes to do things! We have a coroutine system to allow those state machines to be implicit rather than explicit, so that we can use ordinary control flow statements like while loops. Reorganised each proxy negotiation function into a coroutine-based system like that. While I'm at it, I've also moved each proxy negotiator out into its own source file, to make proxy.c less overcrowded and monolithic. And _that_ gave me the opportunity to define each negotiator as an implementation of a trait rather than as a single function - which means now each one can define its own local variables and have its own cleanup function, instead of all of them having to share the variables inside the main ProxySocket struct. In the new coroutine system, negotiators don't have to worry about the mechanics of actually sending data down the underlying Socket any more. The negotiator coroutine just appends to a bufchain (via a provided bufchain_sink), and after every call to the coroutine, central code in proxy.c transfers the data to the Socket itself. This avoids a lot of intermediate allocations within the negotiators, which previously kept having to make temporary strbufs or arrays in order to have something to point an sk_write() at; now they can just put formatted data directly into the output bufchain via the marshal.h interface. In this version of the code, I've also moved most of the SOCKS5 CHAP implementation from cproxy.c into socks5.c, so that it can sit in the same coroutine as the rest of the proxy negotiation control flow. That's because calling a sub-coroutine (co-subroutine?) is awkward to set up (though it is _possible_ - we do SSH-2 kex that way), and there's no real need to bother in this case, since the only thing that really needs to go in cproxy.c is the actual cryptography plus a flag to tell socks5.c whether to offer CHAP authentication in the first place.
2021-11-19 10:26:41 +00:00
}
put_byte(pn->output, s->auth_methods_offered->len);
put_datapl(pn->output, ptrlen_from_strbuf(s->auth_methods_offered));
crReturnV;
/*
* SOCKS 5 initial server packet:
*
* byte version
* byte selected auth method, or SOCKS5_AUTH_REJECTED
*/
{
unsigned char data[2];
crMaybeWaitUntilV(bufchain_try_fetch_consume(pn->input, data, 2));
if (data[0] != SOCKS5_REPLY_VERSION) {
pn->error = dupprintf("SOCKS proxy returned unexpected "
"reply version %d (expected %d)",
(int)data[0], SOCKS5_REPLY_VERSION);
crStopV;
}
if (data[1] == SOCKS5_AUTH_REJECTED) {
pn->error = dupstr("SOCKS server rejected every authentication "
"method we offered");
crStopV;
}
{
bool found = false;
for (size_t i = 0; i < s->auth_methods_offered->len; i++)
if (s->auth_methods_offered->u[i] == data[1]) {
found = true;
break;
}
if (!found) {
pn->error = dupprintf("SOCKS server asked for auth method %d "
"(%s), which we did not offer",
(int)data[1], socks5_auth_name(data[1]));
crStopV;
}
}
s->auth_method = data[1];
}
/*
Support interactive password prompts in SOCKS 5. This is the first of the ProxyNegotiator implementations to use the new interaction system. The other two both need more work than just inserting a prompt and using the result.
2021-11-19 14:33:47 +00:00
* The 'none' auth option requires no further negotiation. If that
* was the one we selected, go straight to making the connection.
Reorganise proxy system into coroutines. Previously, the proxy negotiation functions were written as explicit state machines, with ps->state being manually set to a sequence of positive integer values which would be tested by if statements in the next call to the same negotiation function. That's not how this code base likes to do things! We have a coroutine system to allow those state machines to be implicit rather than explicit, so that we can use ordinary control flow statements like while loops. Reorganised each proxy negotiation function into a coroutine-based system like that. While I'm at it, I've also moved each proxy negotiator out into its own source file, to make proxy.c less overcrowded and monolithic. And _that_ gave me the opportunity to define each negotiator as an implementation of a trait rather than as a single function - which means now each one can define its own local variables and have its own cleanup function, instead of all of them having to share the variables inside the main ProxySocket struct. In the new coroutine system, negotiators don't have to worry about the mechanics of actually sending data down the underlying Socket any more. The negotiator coroutine just appends to a bufchain (via a provided bufchain_sink), and after every call to the coroutine, central code in proxy.c transfers the data to the Socket itself. This avoids a lot of intermediate allocations within the negotiators, which previously kept having to make temporary strbufs or arrays in order to have something to point an sk_write() at; now they can just put formatted data directly into the output bufchain via the marshal.h interface. In this version of the code, I've also moved most of the SOCKS5 CHAP implementation from cproxy.c into socks5.c, so that it can sit in the same coroutine as the rest of the proxy negotiation control flow. That's because calling a sub-coroutine (co-subroutine?) is awkward to set up (though it is _possible_ - we do SSH-2 kex that way), and there's no real need to bother in this case, since the only thing that really needs to go in cproxy.c is the actual cryptography plus a flag to tell socks5.c whether to offer CHAP authentication in the first place.
2021-11-19 10:26:41 +00:00
*/
Support interactive password prompts in SOCKS 5. This is the first of the ProxyNegotiator implementations to use the new interaction system. The other two both need more work than just inserting a prompt and using the result.
2021-11-19 14:33:47 +00:00
if (s->auth_method == SOCKS5_AUTH_NONE)
Reorganise proxy system into coroutines. Previously, the proxy negotiation functions were written as explicit state machines, with ps->state being manually set to a sequence of positive integer values which would be tested by if statements in the next call to the same negotiation function. That's not how this code base likes to do things! We have a coroutine system to allow those state machines to be implicit rather than explicit, so that we can use ordinary control flow statements like while loops. Reorganised each proxy negotiation function into a coroutine-based system like that. While I'm at it, I've also moved each proxy negotiator out into its own source file, to make proxy.c less overcrowded and monolithic. And _that_ gave me the opportunity to define each negotiator as an implementation of a trait rather than as a single function - which means now each one can define its own local variables and have its own cleanup function, instead of all of them having to share the variables inside the main ProxySocket struct. In the new coroutine system, negotiators don't have to worry about the mechanics of actually sending data down the underlying Socket any more. The negotiator coroutine just appends to a bufchain (via a provided bufchain_sink), and after every call to the coroutine, central code in proxy.c transfers the data to the Socket itself. This avoids a lot of intermediate allocations within the negotiators, which previously kept having to make temporary strbufs or arrays in order to have something to point an sk_write() at; now they can just put formatted data directly into the output bufchain via the marshal.h interface. In this version of the code, I've also moved most of the SOCKS5 CHAP implementation from cproxy.c into socks5.c, so that it can sit in the same coroutine as the rest of the proxy negotiation control flow. That's because calling a sub-coroutine (co-subroutine?) is awkward to set up (though it is _possible_ - we do SSH-2 kex that way), and there's no real need to bother in this case, since the only thing that really needs to go in cproxy.c is the actual cryptography plus a flag to tell socks5.c whether to offer CHAP authentication in the first place.
2021-11-19 10:26:41 +00:00
goto authenticated;
Support interactive password prompts in SOCKS 5. This is the first of the ProxyNegotiator implementations to use the new interaction system. The other two both need more work than just inserting a prompt and using the result.
2021-11-19 14:33:47 +00:00
/*
* Otherwise, we're going to need a username and password, so this
* is the moment to stop and ask for one if we don't already have
* them.
*/
if (pn->itr && (!s->username->len || !s->password->len)) {
s->prompts = proxy_new_prompts(pn->ps);
s->prompts->to_server = true;
s->prompts->from_server = false;
s->prompts->name = dupstr("SOCKS proxy authentication");
if (!s->username->len) {
s->username_prompt_index = s->prompts->n_prompts;
add_prompt(s->prompts, dupstr("Proxy username: "), true);
} else {
s->username_prompt_index = -1;
}
if (!s->password->len) {
s->password_prompt_index = s->prompts->n_prompts;
add_prompt(s->prompts, dupstr("Proxy password: "), false);
} else {
s->password_prompt_index = -1;
}
while (true) {
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
SeatPromptResult spr = seat_get_userpass_input(
Support interactive password prompts in SOCKS 5. This is the first of the ProxyNegotiator implementations to use the new interaction system. The other two both need more work than just inserting a prompt and using the result.
2021-11-19 14:33:47 +00:00
interactor_announce(pn->itr), s->prompts);
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
if (spr.kind == SPRK_OK) {
Support interactive password prompts in SOCKS 5. This is the first of the ProxyNegotiator implementations to use the new interaction system. The other two both need more work than just inserting a prompt and using the result.
2021-11-19 14:33:47 +00:00
break;
Richer data type for interactive prompt results. All the seat functions that request an interactive prompt of some kind to the user - both the main seat_get_userpass_input and the various confirmation dialogs for things like host keys - were using a simple int return value, with the general semantics of 0 = "fail", 1 = "proceed" (and in the case of seat_get_userpass_input, answers to the prompts were provided), and -1 = "request in progress, wait for a callback". In this commit I change all those functions' return types to a new struct called SeatPromptResult, whose primary field is an enum replacing those simple integer values. The main purpose is that the enum has not three but _four_ values: the "fail" result has been split into 'user abort' and 'software abort'. The distinction is that a user abort occurs as a result of an interactive UI action, such as the user clicking 'cancel' in a dialog box or hitting ^D or ^C at a terminal password prompt - and therefore, there's no need to display an error message telling the user that the interactive operation has failed, because the user already knows, because they _did_ it. 'Software abort' is from any other cause, where PuTTY is the first to know there was a problem, and has to tell the user. We already had this 'user abort' vs 'software abort' distinction in other parts of the code - the SSH backend has separate termination functions which protocol layers can call. But we assumed that any failure from an interactive prompt request fell into the 'user abort' category, which is not true. A couple of examples: if you configure a host key fingerprint in your saved session via the SSH > Host keys pane, and the server presents a host key that doesn't match it, then verify_ssh_host_key would report that the user had aborted the connection, and feel no need to tell the user what had gone wrong! Similarly, if a password provided on the command line was not accepted, then (after I fixed the semantics of that in the previous commit) the same wrong handling would occur. So now, those Seat prompt functions too can communicate whether the user or the software originated a connection abort. And in the latter case, we also provide an error message to present to the user. Result: in those two example cases (and others), error messages should no longer go missing. Implementation note: to avoid the hassle of having the error message in a SeatPromptResult being a dynamically allocated string (and hence, every recipient of one must always check whether it's non-NULL and free it on every exit path, plus being careful about copying the struct around), I've instead arranged that the structure contains a function pointer and a couple of parameters, so that the string form of the message can be constructed on demand. That way, the only users who need to free it are the ones who actually _asked_ for it in the first place, which is a much smaller set. (This is one of the rare occasions that I regret not having C++'s extra features available in this code base - a unique_ptr or shared_ptr to a string would have been just the thing here, and the compiler would have done all the hard work for me of remembering where to insert the frees!)
2021-12-28 17:52:00 +00:00
} else if (spr_is_abort(spr)) {
proxy_spr_abort(pn, spr);
Support interactive password prompts in SOCKS 5. This is the first of the ProxyNegotiator implementations to use the new interaction system. The other two both need more work than just inserting a prompt and using the result.
2021-11-19 14:33:47 +00:00
crStopV;
}
crReturnV;
}
if (s->username_prompt_index != -1) {
strbuf_clear(s->username);
put_dataz(s->username,
prompt_get_result_ref(
s->prompts->prompts[s->username_prompt_index]));
}
if (s->password_prompt_index != -1) {
strbuf_clear(s->password);
put_dataz(s->password,
prompt_get_result_ref(
s->prompts->prompts[s->password_prompt_index]));
}
free_prompts(s->prompts);
s->prompts = NULL;
Reorganise proxy system into coroutines. Previously, the proxy negotiation functions were written as explicit state machines, with ps->state being manually set to a sequence of positive integer values which would be tested by if statements in the next call to the same negotiation function. That's not how this code base likes to do things! We have a coroutine system to allow those state machines to be implicit rather than explicit, so that we can use ordinary control flow statements like while loops. Reorganised each proxy negotiation function into a coroutine-based system like that. While I'm at it, I've also moved each proxy negotiator out into its own source file, to make proxy.c less overcrowded and monolithic. And _that_ gave me the opportunity to define each negotiator as an implementation of a trait rather than as a single function - which means now each one can define its own local variables and have its own cleanup function, instead of all of them having to share the variables inside the main ProxySocket struct. In the new coroutine system, negotiators don't have to worry about the mechanics of actually sending data down the underlying Socket any more. The negotiator coroutine just appends to a bufchain (via a provided bufchain_sink), and after every call to the coroutine, central code in proxy.c transfers the data to the Socket itself. This avoids a lot of intermediate allocations within the negotiators, which previously kept having to make temporary strbufs or arrays in order to have something to point an sk_write() at; now they can just put formatted data directly into the output bufchain via the marshal.h interface. In this version of the code, I've also moved most of the SOCKS5 CHAP implementation from cproxy.c into socks5.c, so that it can sit in the same coroutine as the rest of the proxy negotiation control flow. That's because calling a sub-coroutine (co-subroutine?) is awkward to set up (though it is _possible_ - we do SSH-2 kex that way), and there's no real need to bother in this case, since the only thing that really needs to go in cproxy.c is the actual cryptography plus a flag to tell socks5.c whether to offer CHAP authentication in the first place.
2021-11-19 10:26:41 +00:00
}
Support interactive password prompts in SOCKS 5. This is the first of the ProxyNegotiator implementations to use the new interaction system. The other two both need more work than just inserting a prompt and using the result.
2021-11-19 14:33:47 +00:00
/*
* Now process the different auth methods that will use that
* username and password. Note we can't do this using the natural
* idiom of a switch statement, because there are crReturns inside
* some cases.
*/
Reorganise proxy system into coroutines. Previously, the proxy negotiation functions were written as explicit state machines, with ps->state being manually set to a sequence of positive integer values which would be tested by if statements in the next call to the same negotiation function. That's not how this code base likes to do things! We have a coroutine system to allow those state machines to be implicit rather than explicit, so that we can use ordinary control flow statements like while loops. Reorganised each proxy negotiation function into a coroutine-based system like that. While I'm at it, I've also moved each proxy negotiator out into its own source file, to make proxy.c less overcrowded and monolithic. And _that_ gave me the opportunity to define each negotiator as an implementation of a trait rather than as a single function - which means now each one can define its own local variables and have its own cleanup function, instead of all of them having to share the variables inside the main ProxySocket struct. In the new coroutine system, negotiators don't have to worry about the mechanics of actually sending data down the underlying Socket any more. The negotiator coroutine just appends to a bufchain (via a provided bufchain_sink), and after every call to the coroutine, central code in proxy.c transfers the data to the Socket itself. This avoids a lot of intermediate allocations within the negotiators, which previously kept having to make temporary strbufs or arrays in order to have something to point an sk_write() at; now they can just put formatted data directly into the output bufchain via the marshal.h interface. In this version of the code, I've also moved most of the SOCKS5 CHAP implementation from cproxy.c into socks5.c, so that it can sit in the same coroutine as the rest of the proxy negotiation control flow. That's because calling a sub-coroutine (co-subroutine?) is awkward to set up (though it is _possible_ - we do SSH-2 kex that way), and there's no real need to bother in this case, since the only thing that really needs to go in cproxy.c is the actual cryptography plus a flag to tell socks5.c whether to offer CHAP authentication in the first place.
2021-11-19 10:26:41 +00:00
if (s->auth_method == SOCKS5_AUTH_PASSWORD) {
/*
* SOCKS 5 password auth packet:
*
* byte version
* pstring username
* pstring password
*/
put_byte(pn->output, SOCKS5_AUTH_PASSWORD_VERSION);
Support interactive password prompts in SOCKS 5. This is the first of the ProxyNegotiator implementations to use the new interaction system. The other two both need more work than just inserting a prompt and using the result.
2021-11-19 14:33:47 +00:00
if (!put_pstring(pn->output, s->username->s)) {
Reorganise proxy system into coroutines. Previously, the proxy negotiation functions were written as explicit state machines, with ps->state being manually set to a sequence of positive integer values which would be tested by if statements in the next call to the same negotiation function. That's not how this code base likes to do things! We have a coroutine system to allow those state machines to be implicit rather than explicit, so that we can use ordinary control flow statements like while loops. Reorganised each proxy negotiation function into a coroutine-based system like that. While I'm at it, I've also moved each proxy negotiator out into its own source file, to make proxy.c less overcrowded and monolithic. And _that_ gave me the opportunity to define each negotiator as an implementation of a trait rather than as a single function - which means now each one can define its own local variables and have its own cleanup function, instead of all of them having to share the variables inside the main ProxySocket struct. In the new coroutine system, negotiators don't have to worry about the mechanics of actually sending data down the underlying Socket any more. The negotiator coroutine just appends to a bufchain (via a provided bufchain_sink), and after every call to the coroutine, central code in proxy.c transfers the data to the Socket itself. This avoids a lot of intermediate allocations within the negotiators, which previously kept having to make temporary strbufs or arrays in order to have something to point an sk_write() at; now they can just put formatted data directly into the output bufchain via the marshal.h interface. In this version of the code, I've also moved most of the SOCKS5 CHAP implementation from cproxy.c into socks5.c, so that it can sit in the same coroutine as the rest of the proxy negotiation control flow. That's because calling a sub-coroutine (co-subroutine?) is awkward to set up (though it is _possible_ - we do SSH-2 kex that way), and there's no real need to bother in this case, since the only thing that really needs to go in cproxy.c is the actual cryptography plus a flag to tell socks5.c whether to offer CHAP authentication in the first place.
2021-11-19 10:26:41 +00:00
pn->error = dupstr("SOCKS 5 authentication cannot support "
"usernames longer than 255 chars");
crStopV;
}
Support interactive password prompts in SOCKS 5. This is the first of the ProxyNegotiator implementations to use the new interaction system. The other two both need more work than just inserting a prompt and using the result.
2021-11-19 14:33:47 +00:00
if (!put_pstring(pn->output, s->password->s)) {
Reorganise proxy system into coroutines. Previously, the proxy negotiation functions were written as explicit state machines, with ps->state being manually set to a sequence of positive integer values which would be tested by if statements in the next call to the same negotiation function. That's not how this code base likes to do things! We have a coroutine system to allow those state machines to be implicit rather than explicit, so that we can use ordinary control flow statements like while loops. Reorganised each proxy negotiation function into a coroutine-based system like that. While I'm at it, I've also moved each proxy negotiator out into its own source file, to make proxy.c less overcrowded and monolithic. And _that_ gave me the opportunity to define each negotiator as an implementation of a trait rather than as a single function - which means now each one can define its own local variables and have its own cleanup function, instead of all of them having to share the variables inside the main ProxySocket struct. In the new coroutine system, negotiators don't have to worry about the mechanics of actually sending data down the underlying Socket any more. The negotiator coroutine just appends to a bufchain (via a provided bufchain_sink), and after every call to the coroutine, central code in proxy.c transfers the data to the Socket itself. This avoids a lot of intermediate allocations within the negotiators, which previously kept having to make temporary strbufs or arrays in order to have something to point an sk_write() at; now they can just put formatted data directly into the output bufchain via the marshal.h interface. In this version of the code, I've also moved most of the SOCKS5 CHAP implementation from cproxy.c into socks5.c, so that it can sit in the same coroutine as the rest of the proxy negotiation control flow. That's because calling a sub-coroutine (co-subroutine?) is awkward to set up (though it is _possible_ - we do SSH-2 kex that way), and there's no real need to bother in this case, since the only thing that really needs to go in cproxy.c is the actual cryptography plus a flag to tell socks5.c whether to offer CHAP authentication in the first place.
2021-11-19 10:26:41 +00:00
pn->error = dupstr("SOCKS 5 authentication cannot support "
"passwords longer than 255 chars");
crStopV;
}
/*
* SOCKS 5 password reply packet:
*
* byte version
* byte 0 for success, >0 for failure
*/
unsigned char data[2];
crMaybeWaitUntilV(bufchain_try_fetch_consume(pn->input, data, 2));
if (data[0] != SOCKS5_AUTH_PASSWORD_VERSION) {
pn->error = dupprintf(
"SOCKS 5 password reply had version number %d (expected "
"%d)", (int)data[0], SOCKS5_AUTH_PASSWORD_VERSION);
crStopV;
}
if (data[1] != 0) {
pn->error = dupstr("SOCKS 5 server rejected our password");
crStopV;
}
} else if (s->auth_method == SOCKS5_AUTH_CHAP) {
assert(socks5_chap_available);
/*
* All CHAP packets, in both directions, have the same
* overall format:
*
* byte version
* byte number of attributes
*
* and then for each attribute:
*
* byte attribute type
* byte length
* byte[] that many bytes of payload
*
* In the initial outgoing packet we send two attributes:
* the list of supported algorithm names, and the
* username.
*
* (It's possible that we ought to delay sending the
* username until the second packet, in case the proxy
* sent back an attribute indicating which character set
* it would like us to use.)
*/
put_byte(pn->output, SOCKS5_AUTH_CHAP_VERSION);
put_byte(pn->output, 2); /* number of attributes */
put_byte(pn->output, SOCKS5_AUTH_CHAP_ATTR_ALGLIST);
put_byte(pn->output, 1); /* string length */
put_byte(pn->output, SOCKS5_AUTH_CHAP_ALG_HMACMD5);
/* Second attribute: username */
{
put_byte(pn->output, SOCKS5_AUTH_CHAP_ATTR_USERNAME);
Support interactive password prompts in SOCKS 5. This is the first of the ProxyNegotiator implementations to use the new interaction system. The other two both need more work than just inserting a prompt and using the result.
2021-11-19 14:33:47 +00:00
if (!put_pstring(pn->output, s->username->s)) {
Reorganise proxy system into coroutines. Previously, the proxy negotiation functions were written as explicit state machines, with ps->state being manually set to a sequence of positive integer values which would be tested by if statements in the next call to the same negotiation function. That's not how this code base likes to do things! We have a coroutine system to allow those state machines to be implicit rather than explicit, so that we can use ordinary control flow statements like while loops. Reorganised each proxy negotiation function into a coroutine-based system like that. While I'm at it, I've also moved each proxy negotiator out into its own source file, to make proxy.c less overcrowded and monolithic. And _that_ gave me the opportunity to define each negotiator as an implementation of a trait rather than as a single function - which means now each one can define its own local variables and have its own cleanup function, instead of all of them having to share the variables inside the main ProxySocket struct. In the new coroutine system, negotiators don't have to worry about the mechanics of actually sending data down the underlying Socket any more. The negotiator coroutine just appends to a bufchain (via a provided bufchain_sink), and after every call to the coroutine, central code in proxy.c transfers the data to the Socket itself. This avoids a lot of intermediate allocations within the negotiators, which previously kept having to make temporary strbufs or arrays in order to have something to point an sk_write() at; now they can just put formatted data directly into the output bufchain via the marshal.h interface. In this version of the code, I've also moved most of the SOCKS5 CHAP implementation from cproxy.c into socks5.c, so that it can sit in the same coroutine as the rest of the proxy negotiation control flow. That's because calling a sub-coroutine (co-subroutine?) is awkward to set up (though it is _possible_ - we do SSH-2 kex that way), and there's no real need to bother in this case, since the only thing that really needs to go in cproxy.c is the actual cryptography plus a flag to tell socks5.c whether to offer CHAP authentication in the first place.
2021-11-19 10:26:41 +00:00
pn->error = dupstr(
"SOCKS 5 CHAP authentication cannot support "
"usernames longer than 255 chars");
crStopV;
}
}
while (true) {
/*
* Process a CHAP response packet, which has the same
* overall format as the outgoing packet shown above.
*/
unsigned char data[2];
crMaybeWaitUntilV(bufchain_try_fetch_consume(
pn->input, data, 2));
if (data[0] != SOCKS5_AUTH_CHAP_VERSION) {
pn->error = dupprintf(
"SOCKS 5 CHAP reply had version number %d (expected "
"%d)", (int)data[0], SOCKS5_AUTH_CHAP_VERSION);
crStopV;
}
s->n_chap_attrs = data[1];
if (s->n_chap_attrs == 0) {
/*
* If we receive a CHAP packet containing no
* attributes, then we have nothing we didn't have
* before, and can't make further progress.
*/
pn->error = dupprintf(
"SOCKS 5 CHAP reply sent no attributes");
crStopV;
}
while (s->n_chap_attrs-- > 0) {
unsigned char data[2];
crMaybeWaitUntilV(bufchain_try_fetch_consume(
pn->input, data, 2));
s->chap_attr = data[0];
s->chap_attr_len = data[1];
crMaybeWaitUntilV(bufchain_try_fetch_consume(
pn->input, s->chap_buf, s->chap_attr_len));
if (s->chap_attr == SOCKS5_AUTH_CHAP_ATTR_STATUS) {
if (s->chap_attr_len == 1 && s->chap_buf[0] == 0) {
/* Status 0 means success: we are authenticated! */
goto authenticated;
} else {
pn->error = dupstr(
"SOCKS 5 CHAP authentication failed");
crStopV;
}
Tiny fixes in the SOCKS proxy code. Just happened to jump out at me in an eyeball inspection just now. I carefully moved all the protocol byte-value constants into a header file with mnemonic names, but I still hard-coded SOCKS4_REPLY_VERSION in the text of one diagnostic, and I got the wrong one of SOCKS5_REQUEST_VERSION and SOCKS5_REPLY_VERSION at one point in the code. Both benign (the right value was there, juste called by the wrong name). Also fixed some missing whitespace, in passing. (Probably the line it was missing from had once been squashed up closer to the right margin.)
2023-09-23 12:28:29 +00:00
} else if (s->chap_attr == SOCKS5_AUTH_CHAP_ATTR_CHALLENGE) {
Reorganise proxy system into coroutines. Previously, the proxy negotiation functions were written as explicit state machines, with ps->state being manually set to a sequence of positive integer values which would be tested by if statements in the next call to the same negotiation function. That's not how this code base likes to do things! We have a coroutine system to allow those state machines to be implicit rather than explicit, so that we can use ordinary control flow statements like while loops. Reorganised each proxy negotiation function into a coroutine-based system like that. While I'm at it, I've also moved each proxy negotiator out into its own source file, to make proxy.c less overcrowded and monolithic. And _that_ gave me the opportunity to define each negotiator as an implementation of a trait rather than as a single function - which means now each one can define its own local variables and have its own cleanup function, instead of all of them having to share the variables inside the main ProxySocket struct. In the new coroutine system, negotiators don't have to worry about the mechanics of actually sending data down the underlying Socket any more. The negotiator coroutine just appends to a bufchain (via a provided bufchain_sink), and after every call to the coroutine, central code in proxy.c transfers the data to the Socket itself. This avoids a lot of intermediate allocations within the negotiators, which previously kept having to make temporary strbufs or arrays in order to have something to point an sk_write() at; now they can just put formatted data directly into the output bufchain via the marshal.h interface. In this version of the code, I've also moved most of the SOCKS5 CHAP implementation from cproxy.c into socks5.c, so that it can sit in the same coroutine as the rest of the proxy negotiation control flow. That's because calling a sub-coroutine (co-subroutine?) is awkward to set up (though it is _possible_ - we do SSH-2 kex that way), and there's no real need to bother in this case, since the only thing that really needs to go in cproxy.c is the actual cryptography plus a flag to tell socks5.c whether to offer CHAP authentication in the first place.
2021-11-19 10:26:41 +00:00
/* The CHAP challenge string. Send the response */
strbuf *response = chap_response(
make_ptrlen(s->chap_buf, s->chap_attr_len),
Support interactive password prompts in SOCKS 5. This is the first of the ProxyNegotiator implementations to use the new interaction system. The other two both need more work than just inserting a prompt and using the result.
2021-11-19 14:33:47 +00:00
ptrlen_from_strbuf(s->password));
Reorganise proxy system into coroutines. Previously, the proxy negotiation functions were written as explicit state machines, with ps->state being manually set to a sequence of positive integer values which would be tested by if statements in the next call to the same negotiation function. That's not how this code base likes to do things! We have a coroutine system to allow those state machines to be implicit rather than explicit, so that we can use ordinary control flow statements like while loops. Reorganised each proxy negotiation function into a coroutine-based system like that. While I'm at it, I've also moved each proxy negotiator out into its own source file, to make proxy.c less overcrowded and monolithic. And _that_ gave me the opportunity to define each negotiator as an implementation of a trait rather than as a single function - which means now each one can define its own local variables and have its own cleanup function, instead of all of them having to share the variables inside the main ProxySocket struct. In the new coroutine system, negotiators don't have to worry about the mechanics of actually sending data down the underlying Socket any more. The negotiator coroutine just appends to a bufchain (via a provided bufchain_sink), and after every call to the coroutine, central code in proxy.c transfers the data to the Socket itself. This avoids a lot of intermediate allocations within the negotiators, which previously kept having to make temporary strbufs or arrays in order to have something to point an sk_write() at; now they can just put formatted data directly into the output bufchain via the marshal.h interface. In this version of the code, I've also moved most of the SOCKS5 CHAP implementation from cproxy.c into socks5.c, so that it can sit in the same coroutine as the rest of the proxy negotiation control flow. That's because calling a sub-coroutine (co-subroutine?) is awkward to set up (though it is _possible_ - we do SSH-2 kex that way), and there's no real need to bother in this case, since the only thing that really needs to go in cproxy.c is the actual cryptography plus a flag to tell socks5.c whether to offer CHAP authentication in the first place.
2021-11-19 10:26:41 +00:00
put_byte(pn->output, SOCKS5_AUTH_CHAP_VERSION);
put_byte(pn->output, 1); /* number of attributes */
put_byte(pn->output, SOCKS5_AUTH_CHAP_ATTR_RESPONSE);
put_byte(pn->output, response->len);
put_datapl(pn->output, ptrlen_from_strbuf(response));
strbuf_free(response);
} else {
/* ignore all other attributes */
}
}
}
} else {
unreachable("bad auth method in SOCKS 5 negotiation");
}
authenticated:
/*
* SOCKS 5 connection command:
*
* byte version
* byte command
* byte reserved (send as zero)
* byte address type
* byte[] address, with variable size (see below)
* uint16 port
*/
Tiny fixes in the SOCKS proxy code. Just happened to jump out at me in an eyeball inspection just now. I carefully moved all the protocol byte-value constants into a header file with mnemonic names, but I still hard-coded SOCKS4_REPLY_VERSION in the text of one diagnostic, and I got the wrong one of SOCKS5_REQUEST_VERSION and SOCKS5_REPLY_VERSION at one point in the code. Both benign (the right value was there, juste called by the wrong name). Also fixed some missing whitespace, in passing. (Probably the line it was missing from had once been squashed up closer to the right margin.)
2023-09-23 12:28:29 +00:00
put_byte(pn->output, SOCKS5_REQUEST_VERSION);
Reorganise proxy system into coroutines. Previously, the proxy negotiation functions were written as explicit state machines, with ps->state being manually set to a sequence of positive integer values which would be tested by if statements in the next call to the same negotiation function. That's not how this code base likes to do things! We have a coroutine system to allow those state machines to be implicit rather than explicit, so that we can use ordinary control flow statements like while loops. Reorganised each proxy negotiation function into a coroutine-based system like that. While I'm at it, I've also moved each proxy negotiator out into its own source file, to make proxy.c less overcrowded and monolithic. And _that_ gave me the opportunity to define each negotiator as an implementation of a trait rather than as a single function - which means now each one can define its own local variables and have its own cleanup function, instead of all of them having to share the variables inside the main ProxySocket struct. In the new coroutine system, negotiators don't have to worry about the mechanics of actually sending data down the underlying Socket any more. The negotiator coroutine just appends to a bufchain (via a provided bufchain_sink), and after every call to the coroutine, central code in proxy.c transfers the data to the Socket itself. This avoids a lot of intermediate allocations within the negotiators, which previously kept having to make temporary strbufs or arrays in order to have something to point an sk_write() at; now they can just put formatted data directly into the output bufchain via the marshal.h interface. In this version of the code, I've also moved most of the SOCKS5 CHAP implementation from cproxy.c into socks5.c, so that it can sit in the same coroutine as the rest of the proxy negotiation control flow. That's because calling a sub-coroutine (co-subroutine?) is awkward to set up (though it is _possible_ - we do SSH-2 kex that way), and there's no real need to bother in this case, since the only thing that really needs to go in cproxy.c is the actual cryptography plus a flag to tell socks5.c whether to offer CHAP authentication in the first place.
2021-11-19 10:26:41 +00:00
put_byte(pn->output, SOCKS_CMD_CONNECT);
put_byte(pn->output, 0); /* reserved byte */
switch (sk_addrtype(pn->ps->remote_addr)) {
case ADDRTYPE_IPV4: {
/* IPv4: address is 4 raw bytes */
put_byte(pn->output, SOCKS5_ADDR_IPV4);
char buf[4];
sk_addrcopy(pn->ps->remote_addr, buf);
put_data(pn->output, buf, sizeof(buf));
break;
}
case ADDRTYPE_IPV6: {
/* IPv6: address is 16 raw bytes */
put_byte(pn->output, SOCKS5_ADDR_IPV6);
char buf[16];
sk_addrcopy(pn->ps->remote_addr, buf);
put_data(pn->output, buf, sizeof(buf));
break;
}
case ADDRTYPE_NAME: {
/* Hostname: address is a pstring (Pascal-style string,
* unterminated but with a one-byte prefix length) */
put_byte(pn->output, SOCKS5_ADDR_HOSTNAME);
char hostname[512];
sk_getaddr(pn->ps->remote_addr, hostname, lenof(hostname));
if (!put_pstring(pn->output, hostname)) {
pn->error = dupstr(
"SOCKS 5 cannot support host names longer than 255 chars");
crStopV;
}
break;
}
default:
unreachable("Unexpected addrtype in SOCKS 5 proxy");
}
put_uint16(pn->output, pn->ps->remote_port);
crReturnV;
/*
* SOCKS 5 connection response:
*
* byte version
* byte status
* byte reserved
* byte address type
* byte[] address bound to (same formats as in connection request)
* uint16 port
*
* We read the first four bytes and then decide what to do next.
*/
{
unsigned char data[4];
crMaybeWaitUntilV(bufchain_try_fetch_consume(pn->input, data, 4));
if (data[0] != SOCKS5_REPLY_VERSION) {
pn->error = dupprintf("SOCKS proxy returned unexpected "
"reply version %d (expected %d)",
(int)data[0], SOCKS5_REPLY_VERSION);
crStopV;
}
if (data[1] != SOCKS5_RESP_SUCCESS) {
pn->error = dupprintf("SOCKS proxy failed to connect, error %d "
"(%s)", (int)data[1],
socks5_response_text(data[1]));
crStopV;
}
/*
* Process each address type to find out the size of the rest
* of the packet. Note we can't do this using the natural
* idiom of a switch statement, because there are crReturns
* inside some cases.
*/
if (data[3] == SOCKS5_ADDR_IPV4) {
s->response_addr_length = 4;
} else if (data[3] == SOCKS5_ADDR_IPV6) {
s->response_addr_length = 16;
} else if (data[3] == SOCKS5_ADDR_HOSTNAME) {
/* Read the hostname length byte to find out how much to read */
unsigned char len;
crMaybeWaitUntilV(bufchain_try_fetch_consume(pn->input, &len, 1));
s->response_addr_length = len;
break;
} else {
pn->error = dupprintf("SOCKS proxy response included unknown "
"address type %d", (int)data[3]);
crStopV;
}
/* Read and ignore the address and port fields */
crMaybeWaitUntilV(bufchain_try_consume(
pn->input, s->response_addr_length + 2));
}
/* And we're done! */
pn->done = true;
crFinishV;
}
const struct ProxyNegotiatorVT socks5_proxy_negotiator_vt = {
.new = proxy_socks5_new,
.free = proxy_socks5_free,
.process_queue = proxy_socks5_process_queue,
.type = "SOCKS 5",
};
Reference in New Issue Copy Permalink