Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #2231

Closed (moved)
Open
Opened Nov 30, 2010 by Nick Mathewson@nickm🐙

Our server-side renegotiation-detection logic has grown baroque and ugly

Currently, bufferevent- and non-bufferevent code takes alternate approaches to detecting when a client has done a TLS renegotiation.

The non-bufferevent code detects renegotiation when it gets a positive result from SSL_read() tor_tls_read() , and invokes a renegotiation callback there. The bufferevent code checks for callback in connection_or_process_inbuf when it's waiting for a renegotiation, and calls the callback when it gets one.

Really, it would be nice to unify these approaches better.

See #2205 (moved) for some approaches here. A cleaned-up version of my bug2205_idea branch plus cypherpunks' idea_raw patch would let us have both versions of the code use the current bufferevent approach safely.

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#2231