<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><br><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">-- <br>Tim / teor<br><br>PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B<br>ricochet:ekmygaiu4rzgsk6n<br>------------------------------------------------------------------------</span><br style="font-family: UICTFontTextStyleTallBody; font-size: 17px; -webkit-text-size-adjust: auto;"></div><div><br>On 30 Oct 2017, at 22:30, George Kadianakis <<a href="mailto:desnacked@riseup.net">desnacked@riseup.net</a>> wrote:<br><br></div><blockquote type="cite"><div><span>teor <<a href="mailto:teor2345@gmail.com">teor2345@gmail.com</a>> writes:</span><br><span></span><br><blockquote type="cite"><blockquote type="cite"><span>On 29 Oct 2017, at 01:19, George Kadianakis <<a href="mailto:desnacked@riseup.net">desnacked@riseup.net</a>> wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Hey Tim,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>just wanted to ask a clarifying question wrt #21969.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>First of all there are various forms of #21969 (aka the "missing</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>descriptors for some of our primary entry guards" issue). Sometimes it</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>occurs for 10 mins and then goes away, whereas for other people it</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>disables their service permanently (until restart). I call this the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>hardcore case of #21969. It has happened to me and disabled my service</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>for days, and I've also seen it happen to other people (e.g. dgoulet).</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>So. We have found various md-related bugs and put them as children of</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>#21969. Do you think we have found the bugs that can cause the hardcore</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>case of #21969? That is, is any of these bugs (or a bug combo) capable</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>of permanently disabling an onion service?</span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Yes, this bug is disabling:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span></span><br><span>Thanks for the reply, Tim.</span><br><span></span><br><blockquote type="cite"><span>#23862, where we don't update guard state unless we have enough</span><br></blockquote><blockquote type="cite"><span>directory info.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>When tor gets in a state where it doesn't have enough directory info</span><br></blockquote><blockquote type="cite"><span>due to another bug, this makes sure it will never get out of that state.</span><br></blockquote><blockquote type="cite"><span>Because it will never mark its directory guards as up when it gets a</span><br></blockquote><blockquote type="cite"><span>new consensus, and therefore it will never fetch microdescs, find out</span><br></blockquote><blockquote type="cite"><span>it has enough directory info, and build circuits.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span></span><br><span>Hmm, just want to make sure I get this.</span><br><span></span><br><span>My understanding with #23862 is that Tor would never mark its directory</span><br><span>guards as up like you say, but it _would still_ fetch microdescs using</span><br><span>fallback directories because of the way</span><br><span>directory_pick_generic_dirserver() works. Isn't that the case?</span><br></div></blockquote><br><div>No, because we're not actually marking those guards as down (#23863),</div><div>I think we might be putting them in a partly usable guard state instead.</div><div>(Fallbacks are only used when all directory guards or mirrors are down.)</div><div><br></div><div>And so we keep trying guards until we backoff for a long time (#23817).</div><div><br></div><div>Which means that some of our microdescs start expiring or change in the</div><div>consensus. Which triggers #23862, which we fixed in 0.3.2.3-alpha.</div><div><br></div><div>And we don't reset the right download state when we get an application</div><div>request (#23620). Which makes it hard for tor to recover from this bug.</div><div><br></div><div>I might be wrong or missing a few of the details, but those bugs are</div><div>enough to cause the issues we're seeing. Hopefully we can find any</div><div>remaining bugs when we fix these ones.</div><div><br></div><div>This set of bugs is actually better than the alternative, which is clients</div><div>trying too fast, and DDoSing relays. If we hadn't implemented exponential</div><div>backoff, these retries could have caused either a slow or fast DDoS.</div><div><br></div><div>T</div></body></html>