aboutsummaryrefslogtreecommitdiff
path: root/src/core/proto
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2019-02-08 08:19:34 -0500
committerNick Mathewson <nickm@torproject.org>2019-02-08 08:19:34 -0500
commitb1ae2fd65ba165722dc121df7bb0be4ec5d6597c (patch)
treeb94afb6ed96076c780d66c7cebfb3c9d11ca243b /src/core/proto
parentbfd1d702433fde0c551a1c79d410d87fe22feb30 (diff)
parent4b36f9676db4ca98101c26ba5fc539ed458ae571 (diff)
downloadtor-b1ae2fd65ba165722dc121df7bb0be4ec5d6597c.tar.gz
tor-b1ae2fd65ba165722dc121df7bb0be4ec5d6597c.zip
Merge branch 'maint-0.3.5'
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 86c656e39d..ac0c9e911b 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;