[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] trackers in OONI Probe Mobile App / was: NEW RiseupVPN test in OONI Probe Mobile App



I have posted this (which as you see is not new at all) so it can be
challenged, if the concepts are or have become useless then that's it, I
don't think this is the case, I have presented this since years but
apparently nobody understands it (now things have evolved since years
and I am not concentrating on this daily)

The client is feigning to reach a domain, for example
https://abc.google.com, if some evil in the path is interested to see
what this client is doing to google.com it might substitute a valid
google.com certificate, the connection will "succeed" (in reality it
will fail since the tool just handles the first handshake messages but
with no security exception from the browser) then you know that you are
intercepted (that's why for example the logjam attack would have been
detected because the browser would not have raised a security exception)

In its original form only one server was used to relay the messages
between the client and the server page, so it's trivial for the evil to
discover the "trick", that's where decentralized/changing nodes (like
OONI's ?) can come into the party

Ideally the tool should be installed at the target domain server side,
ie https://abc.mybank.com, the server part of the tool is installed at
mybank.com, of course this is unlikely in practice


Le 16/02/2021 à 22:34, Dave Warren a écrit :
> I’m not sure I see the point.
>
> If we assume we are building a probe with a client and server
> component, can the client not just connect to the server using a
> pinned certificate (or otherwise validate this connection via any of
> the well established public key mechanisms) and then each side connect
> to the target, retrieve the certificate, calculate the fingerprint and
> compare?
>
> Of course this also assumes that you get the same fingerprint from
> everywhere, something that is absolutely not guaranteed in the general
> case, although many specific targets will use one certificate
> universally. 
>
> Admittedly the quoted protocol proposal might have some advantages if
> you (operating the client) don’t trust the server, or want a
> cryptographic guarantee, but at least for the use-cases of OONI Probe
> Mobile that I see (detecting whether my current connection is being
> censored, relying on a centralized platform to provide censorship test
> data) it seems to be overkill. 
>
>
>
>> On Feb 16, 2021, at 04:33, Aymeric Vitte <aymeric@xxxxxxxxxx> wrote:
>>
>> Resending ccing directly the participants since apparently it's not
>> going to make it to the list
>>
>>
>>
>> -------- Message transféré --------
>> Sujet :
>> 	Re: [tor-talk] trackers in OONI Probe Mobile App / was: NEW
>> RiseupVPN test in OONI Probe Mobile App
>> Date :
>> 	Wed, 10 Feb 2021 17:21:20 +0100
>> De :
>> 	Aymeric Vitte <aymeric@xxxxxxxxxx>
>> Pour :
>> 	tor-talk@xxxxxxxxxxxxxxxxxxxx
>>
>>
>>
>> You might consider adding to OONI features the "Interception Detector",
>> see http://ianonym.peersm.com/intercept.html
>>
>> This is from 2012 but still actual, the basic principles are that you
>> are intercepting yourself with the help of a remote server (ie an OONI
>> node here), by "browser" below we could mean the OONI app
>>
>> Indeed, one browser page is acting as a server page connected to a
>> remote server via websockets, once the user enters the domain to check
>> (for example abcd.google.com) it generates a self-signed TLS certificate
>> and a link (https://abcd.google.com), clicking on the link opens a
>> client page in the browser which produces a https request with the
>> target server name (google.com) that is proxied to the server, then a
>> TLS handshake is initiated between the browser client page and the
>> browser server page since the messages are intercepted by the server
>> that relays messages between both
>>
>> Then the user can check that the signature/fingerprint of the
>> certificate in the handshake match the ones indicated on the server
>> page, if not it means that someone in the path between the browser and
>> the server did intercept the TLS connection
>>
>> In fact, we can summarize this today (because browsers do not really
>> give the possibility any longer to accept self signed certificates) as:
>> if the browser does not raise a security exception then you are for sure
>> intercepted
>>
>> Of course a positive result does not say that you are not intercepted
>> (because the interceptor might have missed the server name honeypot or
>> just not be interested by it), that's where OONI network becomes
>> interesting since you can multiply the tests via various destinations/nodes
>>
>> This is not a "week-end" project as some "experts" think since it
>> requires to implement TLS in js inside the browser, some other experts
>> here might question/destroy the concepts, please do
>>
>> It would have defeated the logjam attack if deployed at that time
>>
>> It's not open source for now but can be with some little funding
>>
>> For the other concerns in this thread you should develop things by
>> yourself instead of adding dubious third party sw, 1.3 MUSD (at least)
>> of funding since years should allow this, no?
>>
>>
>> Le 10/02/2021 à 10:28, Maria Xynou a écrit :
>> > On 09/02/21 19:39, Dave Warren wrote:
>> >>> It should give results for middle boxes , DNS/TLS hijacking ...etc
>> >>> something useful/worth to run OONI for. 
>> >> These would be great things to consider adding too. 
>> > Thanks for the feedback (and support!).
>> >
>> > Current OONI Probe tests are available here:
>> > https://github.com/ooni/probe-engine/tree/master/experiment
>> >
>> > We are working towards shipping new tests (such as that for measuring
>> > SNI based filtering) as part of the OONI Probe apps.
>> >
>> > Code review and feedback is greatly appreciated, and we also encourage
>> > community members to contribute their own tests.
>> >
>> > For example, the recent RiseupVPN test (shipped in the latest OONI Probe
>> > mobile release) was contributed by community members.
>> >
>> > Cheers,
>> >
>> > Maria.
>> >
>>
>> -- 
>> Sophia-Antipolis, France
>> LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
>> Move your coins by yourself (browser version): https://peersm.com/wallet
>> Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
>> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
>> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
>> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
>> Check the 10 M passwords list: http://peersm.com/findmyass
>> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
>> Peersm : http://www.peersm.com
>> torrent-live: https://github.com/Ayms/torrent-live
>> node-Tor : https://www.github.com/Ayms/node-Tor
>> GitHub : https://www.github.com/Ayms
>>
>>
>>
>

-- 
Sophia-Antipolis, France
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk