Re: [tor-dev] bridge:// URI and QR codes
On Monday, 18 July 2022 13:47:21 -03 meskio wrote: > What do you think of the proposal? How can we improve it? A slightly unrelated question: Was there any consideration about deanonymization attacks by giving the user a bridge controlled by the attacker? I worry that those get more likely when getting bridges via links and QR codes becomes normalized. Apart from the source IP address of the user and their Tor traffic pattern, is there anything else an attacker can learn from operating the bridge? Kind Regards, Torsten ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] bridge:// URI and QR codes
Quoting Torsten Grote (2022-07-19 14:54:01) > On Monday, 18 July 2022 13:47:21 -03 meskio wrote: > > What do you think of the proposal? How can we improve it? > > A slightly unrelated question: > > Was there any consideration about deanonymization attacks by giving the user > a > bridge controlled by the attacker? I worry that those get more likely when > getting bridges via links and QR codes becomes normalized. > > Apart from the source IP address of the user and their Tor traffic pattern, > is > there anything else an attacker can learn from operating the bridge? At least from my side there was not consideration on this topic yet. Thank you for bringing it, I think is a pretty valid concern and we should do some planning on it. I wonder if we should only accept bridge URIs/QR codes when the user clicks on 'add bridges' inside the tor related app. Or will be enough to accept bridge URIs on any moment but communicate to the user clearly what is happening and ask them for confirmation. We should never change the bridge configuration silently from a bridge URI without any user intervention. I think we should add something about it to the "Recommendations to implementers" on the proposal. -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] bridge:// URI and QR codes
On Wed, Jul 20, 2022, at 8:01 AM, meskio wrote: > Quoting Torsten Grote (2022-07-19 14:54:01) >> On Monday, 18 July 2022 13:47:21 -03 meskio wrote: >> > What do you think of the proposal? How can we improve it? >> >> A slightly unrelated question: >> >> Was there any consideration about deanonymization attacks by giving the user >> a >> bridge controlled by the attacker? I worry that those get more likely when >> getting bridges via links and QR codes becomes normalized. >> >> Apart from the source IP address of the user and their Tor traffic pattern, >> is >> there anything else an attacker can learn from operating the bridge? > > At least from my side there was not consideration on this topic yet. Thank > you > for bringing it, I think is a pretty valid concern and we should do some > planning on it. > > I wonder if we should only accept bridge URIs/QR codes when the user > clicks on > 'add bridges' inside the tor related app. Or will be enough to accept > bridge > URIs on any moment but communicate to the user clearly what is > happening and ask > them for confirmation. We should never change the bridge configuration > silently > from a bridge URI without any user intervention. > > I think we should add something about it to the "Recommendations to > implementers" on the proposal. I believe in Orbot today we do promote the user after they scan a code or click on a bridge link. Definitely agree there should be that step. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] bridge:// URI and QR codes
On Wed, Jul 20, 2022, at 1:15 PM, Nathan Freitas wrote: > I believe in Orbot today we do promote the user after they scan a code > or click on a bridge link. Definitely agree there should be that step. I meant *prompt* the user. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] bridge:// URI and QR codes
On 20/07/2022 18:15, Nathan Freitas wrote: On Wed, Jul 20, 2022, at 8:01 AM, meskio wrote: Quoting Torsten Grote (2022-07-19 14:54:01) On Monday, 18 July 2022 13:47:21 -03 meskio wrote: What do you think of the proposal? How can we improve it? A slightly unrelated question: Was there any consideration about deanonymization attacks by giving the user a bridge controlled by the attacker? I worry that those get more likely when getting bridges via links and QR codes becomes normalized. Apart from the source IP address of the user and their Tor traffic pattern, is there anything else an attacker can learn from operating the bridge? At least from my side there was not consideration on this topic yet. Thank you for bringing it, I think is a pretty valid concern and we should do some planning on it. I wonder if we should only accept bridge URIs/QR codes when the user clicks on 'add bridges' inside the tor related app. Or will be enough to accept bridge URIs on any moment but communicate to the user clearly what is happening and ask them for confirmation. We should never change the bridge configuration silently from a bridge URI without any user intervention. I think we should add something about it to the "Recommendations to implementers" on the proposal. I believe in Orbot today we do promote the user after they scan a code or click on a bridge link. Definitely agree there should be that step. Another thing that would be useful for this scenario would be for BridgeDB to publish some kind of signed record saying "the bridge with such-and-such a fingerprint was known to BridgeDB at such-and-such a time" - similar to what can already be queried via the API, but in a form that could be distributed offline. If users were able to distribute these records alongside the corresponding bridge lines then apps might decide to treat BridgeDB bridges differently - for example, showing a warning if the bridge entered by the user was *not* signed by BridgeDB. This would provide a useful second layer of trust when finding bridges from sources like Telegram bots, where the provenance isn't always clear. However, including these signatures in a bridge URI might make the URI quite long, which in turn might cause issues with scanning QR codes. So there might be tradeoffs here. Cheers, Michael OpenPGP_0x11044FD19FC527CC.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] bridge:// URI and QR codes
> Bridge URIs do not address the problem of multiple bridges in the same QR. An > idea could be to separate them by newlines. QR-codes from BridgeDB are already big enough I can't scan them reliably on my phone. I think even if multiple bridges per QR-code is supported, BridgeDB (and anything allowing to export bridge lines) should provide a way to export bridges as QR codes one at a time. This would become even more important if some additional metadata like a signature is added. Regards, Trinity Le mar. 2 août 2022 à 13:23, Michael Rogers a écrit : > > > On 20/07/2022 18:15, Nathan Freitas wrote: > > > > > > On Wed, Jul 20, 2022, at 8:01 AM, meskio wrote: > >> Quoting Torsten Grote (2022-07-19 14:54:01) > >>> On Monday, 18 July 2022 13:47:21 -03 meskio wrote: > What do you think of the proposal? How can we improve it? > >>> > >>> A slightly unrelated question: > >>> > >>> Was there any consideration about deanonymization attacks by giving > the user a > >>> bridge controlled by the attacker? I worry that those get more likely > when > >>> getting bridges via links and QR codes becomes normalized. > >>> > >>> Apart from the source IP address of the user and their Tor traffic > pattern, is > >>> there anything else an attacker can learn from operating the bridge? > >> > >> At least from my side there was not consideration on this topic yet. > Thank you > >> for bringing it, I think is a pretty valid concern and we should do some > >> planning on it. > >> > >> I wonder if we should only accept bridge URIs/QR codes when the user > >> clicks on > >> 'add bridges' inside the tor related app. Or will be enough to accept > >> bridge > >> URIs on any moment but communicate to the user clearly what is > >> happening and ask > >> them for confirmation. We should never change the bridge configuration > >> silently > >> from a bridge URI without any user intervention. > >> > >> I think we should add something about it to the "Recommendations to > >> implementers" on the proposal. > > > > I believe in Orbot today we do promote the user after they scan a code > or click on a bridge link. Definitely agree there should be that step. > > Another thing that would be useful for this scenario would be for > BridgeDB to publish some kind of signed record saying "the bridge with > such-and-such a fingerprint was known to BridgeDB at such-and-such a > time" - similar to what can already be queried via the API, but in a > form that could be distributed offline. > > If users were able to distribute these records alongside the > corresponding bridge lines then apps might decide to treat BridgeDB > bridges differently - for example, showing a warning if the bridge > entered by the user was *not* signed by BridgeDB. This would provide a > useful second layer of trust when finding bridges from sources like > Telegram bots, where the provenance isn't always clear. > > However, including these signatures in a bridge URI might make the URI > quite long, which in turn might cause issues with scanning QR codes. So > there might be tradeoffs here. > > Cheers, > Michael > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] bridge:// URI and QR codes
Quoting trinity pointard (2022-08-02 15:29:37) > > Bridge URIs do not address the problem of multiple bridges in the same > QR. An > > idea could be to separate them by newlines. > > > > QR-codes from BridgeDB are already big enough I can't scan them reliably on > my > phone. I think even if multiple bridges per QR-code is supported, BridgeDB > (and > anything allowing to export bridge lines) should provide a way to export > bridges > as QR codes one at a time. This would become even more important if some > additional metadata like a signature is added. Yes, I agree it will be a nice idea to move to a single bridge per QR code (like tor browser does). That will make easier to scan, but might require multiple scans. And will keep bridge URIs representing a single bridge. We might need to think on the UX of the clients, as scanning a QR code or visiting a bridge URI should not delete the other bridges known by the users by default. Maybe it should ask if the bridge should be added to (the default option) or should replace the existing ones. -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] bridge:// URI and QR codes
Quoting Michael Rogers (2022-08-02 13:23:30) > Another thing that would be useful for this scenario would be for > BridgeDB to publish some kind of signed record saying "the bridge with > such-and-such a fingerprint was known to BridgeDB at such-and-such a > time" - similar to what can already be queried via the API, but in a > form that could be distributed offline. > > If users were able to distribute these records alongside the > corresponding bridge lines then apps might decide to treat BridgeDB > bridges differently - for example, showing a warning if the bridge > entered by the user was *not* signed by BridgeDB. This would provide a > useful second layer of trust when finding bridges from sources like > Telegram bots, where the provenance isn't always clear. > > However, including these signatures in a bridge URI might make the URI > quite long, which in turn might cause issues with scanning QR codes. So > there might be tradeoffs here. This log already exists in collector, the server descriptors[0] contains the hashed fingerprint and the software could check if the bridge has existed there. But I understand is not a simple API. Will be trivial for an attacker to add a bridge there, just making it public configured with a distributor like email that might not have tons of users. And share it to the person they want to attack. I'm not sure how much this mechanism will prevent this kind of attack. Also we have to take into account that many users use private bridges, that will never be known by BridgeDB and we don't want to scare the private bridges users. Is the only reliable way to connect to Tor for some people. [0]https://metrics.torproject.org/collector/recent/bridge-descriptors/server-descriptors/ -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan. signature.asc Description: signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
