Exact criteria for receiving a BadExit flag
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. I contacted an exit operator who had BadExit flags on the same host that I run an exit on and we discussed possible reasons for this. Eventually, we jointly set up a new relay on that host and I configured it exactly as I had configured my own relay, and it still obtained the BadExit flag. So far, these are the exact steps I took to configure it: - Unbound is configured to use a second, clean IPv4 - sysctls are tweaked to ensure conntrack does not drop connections - torrc is configured with safe, sensible exit defaults And it still obtained a BadExit flag. We had discussed whether there was a possibility that his family was "tainted" and somehow the BadExit flag was being applied to new exits on his relay family, but starting up a new relay unrelated to his did not help. We tried disabling Unbound and instead using a popular upstream DNS resolver, but that did not prevent a BadExit from being issued either. What other troubleshooting steps are suggested? The provider does not censor or block anything, and I have been successfully running an exit on their infrastructure for more than a month, but when he sets one up, even if he configures it identically to the way I configure mine, it receives a BadExit flag within a matter of days. The criteria for issuing the BadExit flag do not seem very clear. Since it is not a flag intended to be issued to malicious exits, I would like to understand the exact criteria for being issued a BadExit, beyond the vague explanations that I can find on the Gitlab. Note that I am only asking about the automated flag, not about the (potentially sensitive) policies behind determining whether or not a relay is malicious and should be manually excluded from the consensus. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmkmGG8ACgkQBh18rEKN 1guZhxAAxUFcZm1SuoCO5OOST915LtPPmZ6mizq+NUfS3tPoJj6zKRd/grZJYIRj TZzw7JqK62ajtMJLQcLLKuMNMHYZmzr0DP8jVo/JAoh/rcGIqXL+jWIupDDxIQG7 Mf25OF6OrhNb23HTwrudJIiM/PFH6Yyoj0hlDBxpSu3IcopP9xxPwPKYXQjgaZEx mJPpbTb86vrs1TmBQ7C7W6pBoq6zOtne2NfqC6SJ1UNpk/dYxQnknuFYLDeaSPdz qNkh/h2Ua0a0ASGswxTRatd2epkDKrJHoVJ5t/WBPnzPOUJdo6D26oLr1bKzSTM1 +nKkd5ws5b2d8Fi+FQk7LbgiLBSdGAIFL3bBL3FD5ERE+1LkOTaOs9wR0dlIFNRV 4draROjsgfYIw0LavO+O8EEbS5R5xyf5RNIueNMpqbV/IGhoYLYUUfdqITB1swHr jFaEUoNIFAvBS1qp+9ApjmQJ/J2CiPZJ7Su73v6vA9Qq6Amv3ruMK+w5sqO1BpFB V9L/pr/ZB3619SyqMVN2e+M58xDumwwMTHK1AVIGHZLlff5VYR4rBtqXR1T0qPKl AdliLh39C+oBFD0q+12tbucjjJjg8LiiZfo7KReZDpN78zJWxtR+Z57/XfXYDqJd 9FDJdYAm4qLa9wEzAUslEdrfGnokYJQQcI07eNqPFgnl4B80V4I= =N2Ia -----END PGP SIGNATURE-----
Hi! forest-relay-contact--- via tor-relays:
Hello.
I contacted an exit operator who had BadExit flags on the same host that I run an exit on and we discussed possible reasons for this. Eventually, we jointly set up a new relay on that host and I configured it exactly as I had configured my own relay, and it still obtained the BadExit flag. So far, these are the exact steps I took to configure it:
- Unbound is configured to use a second, clean IPv4 - sysctls are tweaked to ensure conntrack does not drop connections - torrc is configured with safe, sensible exit defaults
And it still obtained a BadExit flag. We had discussed whether there was a possibility that his family was "tainted" and somehow the BadExit flag was being applied to new exits on his relay family, but starting up a new relay unrelated to his did not help. We tried disabling Unbound and instead using a popular upstream DNS resolver, but that did not prevent a BadExit from being issued either.
What other troubleshooting steps are suggested? The provider does not censor or block anything, and I have been successfully running an exit on their infrastructure for more than a month, but when he sets one up, even if he configures it identically to the way I configure mine, it receives a BadExit flag within a matter of days.
The criteria for issuing the BadExit flag do not seem very clear. Since it is not a flag intended to be issued to malicious exits, I would like to understand the exact criteria for being issued a BadExit, beyond the vague explanations that I can find on the Gitlab. Note that I am only asking about the automated flag, not about the (potentially sensitive) policies behind determining whether or not a relay is malicious and should be manually excluded from the consensus.
You did not provide a fingerprint, so it's a bit hard to talk about the specific case and maybe that's fine for your purposes anyway. There are two ways this flag can show up. The first one is when it is explicitly requested. Nowadays, this often happens when we find exit relays with DNS resolution issues, which seems to be an easily fixable misconfiguration. The second one is when the relay is supposed to be in a middleonly position as providing a BadExit flag was a convenient method to cover the "do-not-use-the-relay-at-an-exit-position"-part in that scenario. You can see the differences between both mentioned above on relay-search as the second case has a middleonly flag symbol in the flags column as well. Not sure if that answers your question, but I hope. Georg
Regards, forest _______________________________________________ tor-relays mailing list -- tor-relays@lists.torproject.org To unsubscribe send an email to tor-relays-leave@lists.torproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello.
You did not provide a fingerprint, so it's a bit hard to talk about the specific case
The fingerprint is 41506BAFD0A7147CC0DEE80B9A9E5012CF7742D4. It does have a MiddleOnly flag. Why would it be considered unsuitable for being an exit? It accepts port 80 and 443, and DNS resolutions are not being blocked or censored (the recursive resolver uses a fresh IP that has not been used as an exit). It has the exact same configuration as another exit I run, which has fingerprint FE60EAB170C7D45B57E5C55D6D3E9B7F4DEE314A and is run on the same hosting provider, but does not have a BadExit flag. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmkoGgAACgkQBh18rEKN 1gvDahAAkZ01UQyVuDsG43QV90k6UFei84755c9DLHaT2qozXlZststrrmAOt66P ifPeGcrxRoeSvsRDiBGGc3PfsJXBck0aXTWUHmdEhE1Ond6HvX83mY+eqsCxR0ox 0CJX180jr6bQMATVhRJs/JDYnQoSA3a+dboKNXbJXiMAiAZSpEIaljtM5UQrkAeE kHDcRDQr9WrAUGZKKRj9iMRHR2GCqEFPDe8TXLIb1H1a4pNXZOqGYo7za89w+d3I PAZFou0js9BDXrh9Ya7+2DK+suo3/SiqVtLNjV1XNyzrhdt8mgPSBcv2i6cV61lY NpZipXYMiSVjcXd12asHCwpmSHAP5dXFk2IQY0wNmjET82pGKpe4QJ4CO5EZxrjA Kv+TxwFgqZJH6yzskvObX21h4cLjZ7CkICEmXRg/avaV6Zvqnyn+Osyf2lefL/P9 3Ywt6lJ24CNgrYbmvU75EhlJtYU4s/Q10Mi8oqlmJjU6ALoc7qjUGtLvcoC5vuWe 7hjAWMAnhxaoZKZw2iDf32VDgYbh2y4sfmx9IGBCqSBYPUVoZVVFlf1gOY+eLu0u L0dNsnq9GS4F3wVyCHef15JlvLid2vNfifftZmWRdnx+Zp4OePDNOW1HSZDSMzGz UHC4003CsjqDXFaoEn5Jiw2lwVOMTfutgOaXBeT9TJLW8qB/hTc= =JBiy -----END PGP SIGNATURE-----
participants (2)
-
forest-relay-contact@cryptolab.net -
Georg Koppen