nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-10 18:07:59 +00:00
Code Issues Projects Releases Wiki Activity
4721571b8b
putty-source/proxy/telnet.c

386 lines
12 KiB
C
Raw 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
/*
* "Telnet" proxy negotiation.
*
* (This is for ad-hoc proxies where you connect to the proxy's
* telnet port and send a command such as `connect host port'. The
* command is configurable, since this proxy type is typically not
* standardised or at all well-defined.)
*/
#include "putty.h"
#include "network.h"
#include "proxy.h"
Support interactive password prompts in Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
#include "sshcr.h"
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 Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
char *format_telnet_command(SockAddr *addr, int port, Conf *conf,
unsigned *flags_out)
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
{
char *fmt = conf_get_str(conf, CONF_proxy_telnet_command);
int so = 0, eo = 0;
strbuf *buf = strbuf_new();
Support interactive password prompts in Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
unsigned flags = 0;
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
/* we need to escape \\, \%, \r, \n, \t, \x??, \0???,
* %%, %host, %port, %user, and %pass
*/
while (fmt[eo] != 0) {
/* scan forward until we hit end-of-line,
* or an escape character (\ or %) */
while (fmt[eo] != 0 && fmt[eo] != '%' && fmt[eo] != '\\')
eo++;
/* if we hit eol, break out of our escaping loop */
if (fmt[eo] == 0) break;
/* if there was any unescaped text before the escape
* character, send that now */
if (eo != so)
put_data(buf, fmt + so, eo - so);
so = eo++;
/* if the escape character was the last character of
* the line, we'll just stop and send it. */
if (fmt[eo] == 0) break;
if (fmt[so] == '\\') {
/* we recognize \\, \%, \r, \n, \t, \x??.
* anything else, we just send unescaped (including the \).
*/
switch (fmt[eo]) {
case '\\':
put_byte(buf, '\\');
eo++;
break;
case '%':
put_byte(buf, '%');
eo++;
break;
case 'r':
put_byte(buf, '\r');
eo++;
break;
case 'n':
put_byte(buf, '\n');
eo++;
break;
case 't':
put_byte(buf, '\t');
eo++;
break;
case 'x':
case 'X': {
/* escaped hexadecimal value (ie. \xff) */
unsigned char v = 0;
int i = 0;
for (;;) {
eo++;
if (fmt[eo] >= '0' && fmt[eo] <= '9')
v += fmt[eo] - '0';
else if (fmt[eo] >= 'a' && fmt[eo] <= 'f')
v += fmt[eo] - 'a' + 10;
else if (fmt[eo] >= 'A' && fmt[eo] <= 'F')
v += fmt[eo] - 'A' + 10;
else {
/* non hex character, so we abort and just
* send the whole thing unescaped (including \x)
*/
put_byte(buf, '\\');
eo = so + 1;
break;
}
/* we only extract two hex characters */
if (i == 1) {
put_byte(buf, v);
eo++;
break;
}
i++;
v <<= 4;
}
break;
}
default:
put_data(buf, fmt + so, 2);
eo++;
break;
}
} else {
/* % escape. we recognize %%, %host, %port, %user, %pass.
* %proxyhost, %proxyport. Anything else we just send
* unescaped (including the %).
*/
if (fmt[eo] == '%') {
put_byte(buf, '%');
eo++;
}
else if (strnicmp(fmt + eo, "host", 4) == 0) {
char dest[512];
sk_getaddr(addr, dest, lenof(dest));
put_data(buf, dest, strlen(dest));
eo += 4;
}
else if (strnicmp(fmt + eo, "port", 4) == 0) {
put_fmt(buf, "%d", port);
eo += 4;
}
else if (strnicmp(fmt + eo, "user", 4) == 0) {
const char *username = conf_get_str(conf, CONF_proxy_username);
put_data(buf, username, strlen(username));
eo += 4;
Support interactive password prompts in Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
if (!*username)
flags |= TELNET_CMD_MISSING_USERNAME;
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
}
else if (strnicmp(fmt + eo, "pass", 4) == 0) {
const char *password = conf_get_str(conf, CONF_proxy_password);
put_data(buf, password, strlen(password));
eo += 4;
Support interactive password prompts in Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
if (!*password)
flags |= TELNET_CMD_MISSING_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
}
else if (strnicmp(fmt + eo, "proxyhost", 9) == 0) {
const char *host = conf_get_str(conf, CONF_proxy_host);
put_data(buf, host, strlen(host));
eo += 9;
}
else if (strnicmp(fmt + eo, "proxyport", 9) == 0) {
int port = conf_get_int(conf, CONF_proxy_port);
put_fmt(buf, "%d", port);
eo += 9;
}
else {
/* we don't escape this, so send the % now, and
* don't advance eo, so that we'll consider the
* text immediately following the % as unescaped.
*/
put_byte(buf, '%');
}
}
/* resume scanning for additional escapes after this one. */
so = eo;
}
/* if there is any unescaped text at the end of the line, send it */
if (eo != so) {
put_data(buf, fmt + so, eo - so);
}
Support interactive password prompts in Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
if (flags_out)
*flags_out = flags;
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 strbuf_to_str(buf);
}
typedef struct TelnetProxyNegotiator {
Support interactive password prompts in Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
int crLine;
Conf *conf;
char *formatted_cmd;
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
ProxyNegotiator pn;
} TelnetProxyNegotiator;
static ProxyNegotiator *proxy_telnet_new(const ProxyNegotiatorVT *vt)
{
TelnetProxyNegotiator *s = snew(TelnetProxyNegotiator);
Support interactive password prompts in Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
memset(s, 0, 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
s->pn.vt = vt;
return &s->pn;
}
static void proxy_telnet_free(ProxyNegotiator *pn)
{
TelnetProxyNegotiator *s = container_of(pn, TelnetProxyNegotiator, pn);
Support interactive password prompts in Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
if (s->conf)
conf_free(s->conf);
if (s->prompts)
free_prompts(s->prompts);
burnstr(s->formatted_cmd);
delete_callbacks_for_context(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);
}
Support interactive password prompts in Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
static void proxy_telnet_process_queue_callback(void *vctx)
{
TelnetProxyNegotiator *s = (TelnetProxyNegotiator *)vctx;
proxy_negotiator_process_queue(&s->pn);
}
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
static void proxy_telnet_process_queue(ProxyNegotiator *pn)
{
Support interactive password prompts in Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
TelnetProxyNegotiator *s = container_of(pn, TelnetProxyNegotiator, pn);
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 Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
crBegin(s->crLine);
s->conf = conf_copy(pn->ps->conf);
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 Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
* Make an initial attempt to figure out the command we want, and
* see if it tried to include a username or password that we don't
* have.
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 Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
{
unsigned flags;
s->formatted_cmd = format_telnet_command(
pn->ps->remote_addr, pn->ps->remote_port, s->conf, &flags);
if (pn->itr && (flags & (TELNET_CMD_MISSING_USERNAME |
TELNET_CMD_MISSING_PASSWORD))) {
burnstr(s->formatted_cmd);
s->formatted_cmd = NULL;
/*
* We're missing at least one of the two parts, and we
* have an Interactor we can use to prompt for them, so
* try it.
*/
s->prompts = proxy_new_prompts(pn->ps);
s->prompts->to_server = true;
s->prompts->from_server = false;
s->prompts->name = dupstr("Telnet proxy authentication");
if (flags & TELNET_CMD_MISSING_USERNAME) {
s->username_prompt_index = s->prompts->n_prompts;
add_prompt(s->prompts, dupstr("Proxy username: "), true);
} else {
s->username_prompt_index = -1;
}
if (flags & TELNET_CMD_MISSING_PASSWORD) {
s->password_prompt_index = s->prompts->n_prompts;
add_prompt(s->prompts, dupstr("Proxy password: "), false);
} else {
s->password_prompt_index = -1;
}
/*
* This prompt is presented extremely early in PuTTY's
* setup. (Very promptly, you might say.)
*
* In particular, we can get here through a chain of
* synchronous calls from backend_init, which means (in
* GUI PuTTY) that the terminal we'll be sending this
* prompt to may not have its Ldisc set up yet (due to
* cyclic dependencies among all the things that have to
* be initialised).
*
* So we'll start by having ourself called back via a
* toplevel callback, to make sure we don't call
* seat_get_userpass_input until we've returned from
* backend_init and the frontend has finished getting
* everything ready.
*/
queue_toplevel_callback(proxy_telnet_process_queue_callback, s);
crReturnV;
while (true) {
int prompt_result = seat_get_userpass_input(
interactor_announce(pn->itr), s->prompts);
if (prompt_result > 0) {
break;
} else if (prompt_result == 0) {
pn->aborted = true;
crStopV;
}
crReturnV;
}
if (s->username_prompt_index != -1) {
conf_set_str(
s->conf, CONF_proxy_username,
prompt_get_result_ref(
s->prompts->prompts[s->username_prompt_index]));
}
if (s->password_prompt_index != -1) {
conf_set_str(
s->conf, CONF_proxy_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 Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
/*
* Now format the command a second time, with the results of
* those prompts written into s->conf.
*/
s->formatted_cmd = format_telnet_command(
pn->ps->remote_addr, pn->ps->remote_port, s->conf, 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 Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
/*
Telnet proxy: censor the password in the log file. Probably should have done this a long time ago: when we write the formatted command into the log file, we now base it on a version in which CONF_proxy_password has been reset to "*password*", to avoid writing the actual password (if any) into log files.
2021-11-19 15:59:27 +00:00
* Log the command, with some changes. Firstly, we regenerate it
* with the password masked; secondly, we escape control
* characters so that the log message is printable.
Support interactive password prompts in Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
*/
Telnet proxy: censor the password in the log file. Probably should have done this a long time ago: when we write the formatted command into the log file, we now base it on a version in which CONF_proxy_password has been reset to "*password*", to avoid writing the actual password (if any) into log files.
2021-11-19 15:59:27 +00:00
conf_set_str(s->conf, CONF_proxy_password, "*password*");
Support interactive password prompts in Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
{
Telnet proxy: censor the password in the log file. Probably should have done this a long time ago: when we write the formatted command into the log file, we now base it on a version in which CONF_proxy_password has been reset to "*password*", to avoid writing the actual password (if any) into log files.
2021-11-19 15:59:27 +00:00
char *censored_cmd = format_telnet_command(
pn->ps->remote_addr, pn->ps->remote_port, s->conf, NULL);
Support interactive password prompts in Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
strbuf *logmsg = strbuf_new();
const char *in;
put_datapl(logmsg, PTRLEN_LITERAL("Sending Telnet proxy command: "));
Telnet proxy: censor the password in the log file. Probably should have done this a long time ago: when we write the formatted command into the log file, we now base it on a version in which CONF_proxy_password has been reset to "*password*", to avoid writing the actual password (if any) into log files.
2021-11-19 15:59:27 +00:00
for (in = censored_cmd; *in; in++) {
Support interactive password prompts in Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
if (*in == '\n') {
put_datapl(logmsg, PTRLEN_LITERAL("\\n"));
} else if (*in == '\r') {
put_datapl(logmsg, PTRLEN_LITERAL("\\r"));
} else if (*in == '\t') {
put_datapl(logmsg, PTRLEN_LITERAL("\\t"));
} else if (*in == '\\') {
put_datapl(logmsg, PTRLEN_LITERAL("\\\\"));
} else if (0x20 <= *in && *in < 0x7F) {
put_byte(logmsg, *in);
} else {
put_fmt(logmsg, "\\x%02X", (unsigned)*in & 0xFF);
}
}
plug_log(pn->ps->plug, PLUGLOG_PROXY_MSG, NULL, 0, logmsg->s, 0);
strbuf_free(logmsg);
Telnet proxy: censor the password in the log file. Probably should have done this a long time ago: when we write the formatted command into the log file, we now base it on a version in which CONF_proxy_password has been reset to "*password*", to avoid writing the actual password (if any) into log files.
2021-11-19 15:59:27 +00:00
sfree(censored_cmd);
Support interactive password prompts in Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
}
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 Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
/*
* Actually send the command.
*/
put_dataz(pn->output, s->formatted_cmd);
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 Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
* Unconditionally report success. We don't hang around waiting
* for error messages from the proxy, because this proxy type is
* so ad-hoc that we wouldn't know how to even recognise an error
* message if we saw one, let alone what to do about it.
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->done = true;
Support interactive password prompts in Telnet proxy. The Telnet proxy system is not a proper network protocol - we have no reliable way to receive communication from the proxy telling us whether a password is even required. However, we _do_ know (a) whether the keywords '%user' or '%pass' appeared in the format string stored in the Conf, and (b) whether we actually had a username or a password to substitute into them. So that's how we know whether to ask for a username or a password: if the format string asks for them and the Conf doesn't provide them, we prompt for them at startup. This involved turning TelnetProxyNegotiator into a coroutine (matching all the other proxy types, but previously, it was the only one simple enough not to need to be one), so that it can wait until a response arrives to that prompt. (And also, as it turned out, so that it can wait until setup is finished before even presenting the prompt!) It also involves having format_telnet_command grow an extra output parameter, in the form of 'unsigned *flags', with which it can communicate back to the caller that a username or password was wanted but not found. The other clients of that function (the local proxy implementations) don't use those flags, but if necessary, they could.
2021-11-19 16:03:22 +00:00
crFinishV;
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
}
const struct ProxyNegotiatorVT telnet_proxy_negotiator_vt = {
.new = proxy_telnet_new,
.free = proxy_telnet_free,
.process_queue = proxy_telnet_process_queue,
.type = "Telnet",
};
Reference in New Issue Copy Permalink