Opened 9 years ago

Closed 5 years ago

#2231 closed defect (wontfix)

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

Reported by: nickm Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Keywords: tor-relay
Cc: iang@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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 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.

Child Tickets

Change History (5)

comment:1 Changed 9 years ago by iang

Cc: iang@… added

comment:2 Changed 8 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: unspecified

I believe part of this is getting done in order to do renegotiation-counting limits, and in part this is made less vital by the v3 link handshake. Calling this "Tor: unspecified"

comment:3 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:4 Changed 7 years ago by nickm

Component: Tor RelayTor

comment:5 Changed 5 years ago by nickm

Resolution: wontfix
Status: newclosed

The real fix here is to kill the v2 link protocol

Note: See TracTickets for help on using tickets.