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
  • #2231

Closed (moved)
(moved)
Open
Created 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 an admin enable hashed storage. More information
Assignee
Assign to
Time tracking