Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #4367

Closed (moved)
(moved)
Open
Created Nov 01, 2011 by Roger Dingledine@arma

command_process_auth_challenge_cell() mishandles lack of expected auth type

In command_process_auth_challenge_cell() we start with

use_type = -1;

Then we do

  for (i=0; i < n_types; ++i, cp += 2) {
    uint16_t authtype = ntohs(get_uint16(cp));
    if (authtype == AUTHTYPE_RSA_SHA256_TLSSECRET)
      use_type = authtype;
  }

Then we check

  if (use_type && public_server_mode(get_options())) {

So if we didn't find any authtypes of 1 offered, use_type will remain -1, which is true, so we'll call connection_or_send_authenticate_cell(), which will fail, and we'll mark the conn.

It's not so bad since connection_or_send_authenticate_cell() just does a log_warn at LD_BUG and returns.

But it's not entirely harmless, since in the far future if we stop listing authtype 1, these tors will close the conn when they ought to (at least based on what the code is trying to do; it's up for grabs if this is actually the right behavior) be just not authenticating.

I think we can fix just by initting use_type to 0.

Reported and diagnosed by frosty_un.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking