aboutsummaryrefslogtreecommitdiff
path: root/src/core/proto
diff options
context:
space:
mode:
authorrl1987 <rl1987@sdf.lonestar.org>2019-01-26 10:55:53 +0200
committerrl1987 <rl1987@sdf.lonestar.org>2019-01-26 11:06:33 +0200
commit790150e57a98221fbb4cfdc5c34b3395808416b4 (patch)
treeb7fc50e05c424374ba1252c271584cb0dadad136 /src/core/proto
parent712a622fcecd43a7a50c7b35a9811f1210aeadb8 (diff)
downloadtor-790150e57a98221fbb4cfdc5c34b3395808416b4.tar.gz
tor-790150e57a98221fbb4cfdc5c34b3395808416b4.zip
Allow empty username/password in SOCKS5 username/password auth message
Diffstat (limited to 'src/core/proto')
-rw-r--r--src/core/proto/proto_socks.c12
1 files changed, 8 insertions, 4 deletions
diff --git a/src/core/proto/proto_socks.c b/src/core/proto/proto_socks.c
index a8f4a06c26..8b78ed44c2 100644
--- a/src/core/proto/proto_socks.c
+++ b/src/core/proto/proto_socks.c
@@ -450,18 +450,22 @@ parse_socks5_userpass_auth(const uint8_t *raw_data, socks_request_t *req,
tor_free(req->username);
req->username = tor_memdup_nulterm(username, usernamelen);
req->usernamelen = usernamelen;
-
- req->got_auth = 1;
}
if (passwordlen && password) {
tor_free(req->password);
req->password = tor_memdup_nulterm(password, passwordlen);
req->passwordlen = passwordlen;
-
- req->got_auth = 1;
}
+ /**
+ * Yes, we allow username and/or password to be empty. Yes, that does
+ * violate RFC 1929. However, some client software can send a username/
+ * password message with these fields being empty and we want to allow them
+ * to be used with Tor.
+ */
+ req->got_auth = 1;
+
end:
socks5_client_userpass_auth_free(trunnel_req);
return res;