[tor-dev] GSoC: Support all kinds of DNS queries

[Daniel Achleitner]

Hi everyone,

I'm a Software Engineering master's student at TU Wien, Austria, with a
recent focus on computer security and privacy issues. I am interested in
participating in GSoC 2017, particularily in the task to support all
kinds of DNS queries via Tor [1].

I've seen the mailing list discussions of 2012 and read the resulting
proposition 219 [2]. What do you think, which parts of it (if any) would
need to be adapted for DNS in 2017? My current impression is that not
much has changed, particularily regarding DNSSEC support and deployment.

As of now, the proposal looks fairly complete with few questions
remaining, the biggest research task being how to utilize libunbound for
query/response parsing and construction. Implementing the RELAY DNS
cells then seems fairly straightforward. Unit/integration tests and some
fuzzing would be a good idea. The problem of reducing DNSSEC roundtrips
(serialization) to be investigated in a later phase, I would say.

Is a separate AXFR tool still something that is desired? I have no
experience with zone transfers -- can't the existing tooling just be
used over a normal TCP conn through Tor?

This project idea would make a good match to my thesis in progress, for
which I am researching and evaluating privacy-improving DNS tools in the
context of Tor (DNSCrypt, DNS-over-TLS) [3], inspired by the awesome
paper on DNS correlation [4]. For example, I recently built a
SOCKS-to-SOCKS translator which allows to resolve hostnames using a
resolver of choice, e.g. using DNSCrypt with TBB.

Looking forward to hearing your thoughts, concerns and opinions!

Best regards,
Daniel

IRC handle on OFTC: idealchain

[1]: https://www.torproject.org/getinvolved/volunteer.html.en#supportAllDNS
[2]:
https://gitweb.torproject.org/torspec.git/tree/proposals/219-expanded-dns.txt
[3]: My work-in-progress mindmap about DNS Privacy (not related to prop219):
 https://drive.google.com/open?id=0B3d38csDsjwudDJOUjRleE93bjQ
[4]: https://nymity.ch/dns-traffic-correlation/tor-dns.pdf




signature.asc
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] GSoC 2017 - unMessage: a privacy enhanced instant messenger

[Felipe Dau]

On Wed, Mar 29, 2017 at 03:57:29AM -0400, grarpamp wrote:
> You may want to link unmessage into the I2P network as well.

Hi grarpamp,

Thanks for the suggestion. It should be possible to support multiple
kinds of transport, but we still need to do some research on that
because it might make some attacks
possible/easier (e.g., partitioning attacks)? It would be great to
have a discussion about that.

Thanks,
-Felipe


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] "firefox --app" for meek-http-helper

[anonym]

Georg Koppen:
> David Fifield:
>> On Sun, Mar 26, 2017 at 02:28:00PM +, anonym wrote:
>>> Tails uses the Tor Launcher shipped in Tor Browser, but it's run as a
>>> stand-alone XUL application (`firefox --app ...`), so the *web*
>>> browser isn't started as part of it.
>>
>> Sorry to change the subject, but should we be running meek-http-helper
>> using "firefox --app"? I didn't know about that before. It sounds like
>> it could solve some of the problems associated with having multiple
>> Firefox profiles.
>
> I have no strong opinions here. It seems worth playing with it to figure
> out if it could be helpful in a meek context.

Correct me if I am wrong, but won't `firefox --app` stop working early next 
year? Or is it only XUL extensions that won't work initially? Any way, XUL is 
going away, so I don't think too much effort should be put into anything 
XUL-related.

Cheers!

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] "firefox --app" for meek-http-helper

[Georg Koppen]

David Fifield:
> On Sun, Mar 26, 2017 at 02:28:00PM +, anonym wrote:
>> Tails uses the Tor Launcher shipped in Tor Browser, but it's run as a
>> stand-alone XUL application (`firefox --app ...`), so the *web*
>> browser isn't started as part of it.
> 
> Sorry to change the subject, but should we be running meek-http-helper
> using "firefox --app"? I didn't know about that before. It sounds like
> it could solve some of the problems associated with having multiple
> Firefox profiles.

I have no strong opinions here. It seems worth playing with it to figure
out if it could be helpful in a meek context.

Georg




signature.asc
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] GSoC 17 | Name System API for Tor Onion Services

[George Kadianakis]

George Kadianakis  writes:

> Pickfire  writes:
>
>> Hi,
>>
>> I am Ivan Tham. Currently studying in Computer Science in APIIT Malaysia. I 
>> am
>> interested particapate in Google Summer of Code 2017 under tor organization. 
>> I
>> am interested to see Proposal 224 coming along but I would really like to see
>> [Proposal 272][0] and hope that tor hidden services can be more 
>> user-friendly.
>>
>
> Hello,
>
> there is still interest in this proposal but unfortunately it hasn't
> been revised since it was first posted on the mailing list. The mailing
> list feedback unfortunately has not been incorporated to the proposal
> yet; particularly the comments by David Fifield are very relevant and
> should be considered carefully before taking the proposal too seriously.
>
> In general, I suggest to anyone who wants to work on this proposal, to
> do it using a Tor controller instead of hacking the main C tor
> code. meejah suggested this here:
>   https://lists.torproject.org/pipermail/tor-dev/2016-October/011517.html
> and it seems like a proper solution here would involve controller events
> like NEWRESOLVE, MAPADDRESS, and plus some extra magic.
>
> I must say that this project is definitely relevant for GSoC, but it
> needs a _strong_ and _independent_ student that can handle it.
>
> Also, Tor is currently having a real life meeting so most of us are very
> busy. We plan to discuss the proposal during the meeting, so I hope to
> send a short update next week at some point if I find the time (and also
> merge it to torspec.git since it's currently missing).
>

FWIW, I merged the draft proposal from [tor-dev] to torspec, so that we
have a common point of reference. The proposal still needs improvements
before we can call it complete.

You can find it as proposal279:

https://gitweb.torproject.org/torspec.git/tree/proposals/279-naming-layer-api.txt

Cheers!
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] GSoC 2017 - unMessage: a privacy enhanced instant messenger

[grarpamp]

You may want to link unmessage into the I2P network as well.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev