Re: [tor-dev] Pluggable transport idea: TLS session resumption

On Wed, 7 Sep 2016 14:24:12 -0700 David Fifield wrote: > The protocol as just described would be vulnerable to active probing; > the censor could test for servers by sending them garbage session > tickets and seeing how they respond. But that's easy to fix. We can, > for

Re: [tor-dev] Reducing initial onion descriptor upload delay (down to 0s?)

> On 8 Sep 2016, at 01:40, Ivan Markin wrote: > > Hi tor-dev@! > > Moving the discussion on the future of rendinitialpostdelay from ticket > #20082 [1] here. > > Transcribing the issue: >> At the moment descriptor is getting posted at >> MIN_REND_INITIAL_POST_DELAY (30)

[tor-dev] Pluggable transport idea: TLS session resumption

Here's an idea for a new pluggable transport. It's just a TLS tunnel, but with a twist that allows the server's certificate to be omitted, depriving the censor of many classification features, such as whether the certificate is signed by a CA, the certificate's lifetime, and whether the commonName

[tor-dev] Reducing initial onion descriptor upload delay (down to 0s?)

Hi tor-dev@! Moving the discussion on the future of rendinitialpostdelay from ticket #20082 [1] here. Transcribing the issue: > At the moment descriptor is getting posted at > MIN_REND_INITIAL_POST_DELAY (30) seconds after onion service > initialization. For the use case of real-time one-time