tor-dev September 2016

tor-dev@lists.torproject.org

42 participants
34 discussions

Tor path selection upon failure
by Liu, Zhuotao 14 Sep '16

14 Sep '16

Hi Folks, There have been some technical reports about how to deal with the problem when a botnet uses Tor as its primary C&C channel. In this case, the CPU of some relays is exhausted, causing circuit creation failure. I am wondering currently how a client reacts when its circuit creation fails? Does the client simply resends create cells to the relays on the original path or it will re-select a new path instead? Thanks

2 2

[Patch] common/util_bug.h
by Gisle Vanem 13 Sep '16

13 Sep '16

The 'IF_BUG_ONCE__' for non-gcc is wrong. A simple patch: --- a/util_bug.h 2016-09-13 10:44:59 +++ b/util_bug.h 2016-09-08 20:24:45 @@ -117,7 +117,7 @@ #else #define IF_BUG_ONCE__(cond,var) \ static int var = 0; \ - if (PREDICT_UNLIKELY(cond)) ? \ + if (PREDICT_UNLIKELY(cond) ? \ (var ? 1 : \ (var=1, \ tor_bug_occurred_(SHORT_FILE__, __LINE__, __func__, \ -- --gv

2 1

Tor path selection upon failure
by Liu, Zhuotao 13 Sep '16

13 Sep '16

Hi Folks, There have been some technical reports about how to deal with the problem when a botnet uses Tor as its primary C&C channel. In this case, the CPU of some relays is exhausted, causing circuit creation failure. I am wondering currently how a client reacts when its circuit creation fails? Does the client simply resend another create cell or it will re-select new path instead? Thanks

2 1

How to query HS hostname from control port
by Jesse V 10 Sep '16

10 Sep '16

Hi everyone, TL;DR: Please let me know how to fetch the hostname of my hidden service from Tor's control port. Say I have configured torrc to set up a hidden/onion service. By default, it's set up in /var/lib/tor/hidden_service, a directory which isn't world-readable. My software can authenticate into Tor's control port, but it needs to know the hostname/address of the service. It can't read the hidden_service/hostname file directly, and so far I haven't figured out how to query Tor for that information. As a last resort, I suppose I could copy /var/lib/tor/hidden_service/hostname to a directory that the software can read, but I'd like to avoid that if possible. I have hunted through https://gitweb.torproject.org/torspec.git/tree/control-spec.txt without too much success. The closest I have come is "GETCONF HiddenServiceOptions" but I suspect that the option is under GETINFO instead. However, the documentation mostly describes how to query information about other onion services. I need to know about my service though, if that's possible. Please advise. -- Jesse V I look forward to seeing everyone again in July at Minneapolis. :)

5 14

Hmac
by Flipchan 10 Sep '16

10 Sep '16

Hi all, so i spook with a friend of mine yesterday and we where chating about encryption and i told him that i use scrypt for password hashing. He told that hmac was alot better. Does anyone know any Good whitepapers on hmac? Any Good python lib? Does anyone use it ? Take care -- Sincerly Flipchan

3 2

Dirauth setting for PathsNeededToBuildCircuits
by Jesse V 09 Sep '16

09 Sep '16

Tor clients can only build circuits once they know enough about the network. This "know enough" threshold is determined by the PathsNeededToBuildCircuits setting. From reading Tor's manual, it seems that a setting of X tells Tor clients to wait until they have enough descriptors/microdescriptors such that they have X percentage of consensus weight. By default PathsNeededToBuildCircuits is determined by the directory authorities. I'm curious, how is PathsNeededToBuildCircuits set? I don't see that value in the microdescriptor documents, it doesn't seem to be documented in tor-spec, and I don't see much about it online, but maybe I missed something. What is the typical value? I see that 0.95 is the cutoff, but how high will prevent a client from bootstrapping? -- Jesse V

2 1

Bored C programmers? I've got some warnings for you....
by Nick Mathewson 08 Sep '16

08 Sep '16

Hi, all! I've just turned on some code [1] that makes all of the "bug" warnings that occur during the unit tests get logged to console. Previously, all warnings from the unit tests were off by default. Now there are a lot of warnings from the unit tests! For each one, we should either: 1) Decide that the warning message wouldn't actually reflect a bug in Tor, and change it. 2) Decide that there's a bug in the unit tests (or elsewhere) and fix it. 3) Decide that _in this case_, the unit tests are correctly testing code that *would* indicate a real bug in Tor. In this case, we should use the functions in log_test_helpers.c to temporarily suppress the log messages, and make sure that this message (and only this message!) is logged. This is going to be a fair bit of work, but with any luck, we can actually fix it all before the next 029 alpha comes out, and improve our confidence in our unit tests. [1] https://trac.torproject.org/projects/tor/ticket/20042 cheers, -- Nick

2 2

Post-quantum proposals #269 and #270
by lukep＠tutanota.com 08 Sep '16

08 Sep '16

Great to see the community making progress with post-quantum handshakes. But I'm wondering what's going to happen with Proposals #269 and #270. #269 seems to allow any post-quantum algorithm to be used in the hybrid with NTRUEncrypt and NewHope being specified as two options (presumably other options like SIDH or Mceliece could also be used). #270 is more specific, a hybrid of x25519 and NewHope. NewHope seems to be in the lead but do we want to rule others - so a flexible proposal like #269 might be better. #269 and #270 look as if they would not be compatible with each other so what's the process for deciding between them? Also see https://eprint.iacr.org/2016/717.pdf, a comparison of attacks on NTRU. It doesn't break NTRU but it does break (some versions of) YASHE which is a FHE scheme based on NTRUEncrypt. In the conclusion it recommends transforming NTRU-like algorithms into ring-LWE like algorithms, and dismissing the former since they are known to be weaker. I still think a flexible protocol rather than all eggs in the NewHope basket is a Good Thing. -- lukep

4 6

Pluggable transport idea: TLS session resumption
by David Fifield 08 Sep '16

08 Sep '16

Here's an idea for a new pluggable transport. It's just a TLS tunnel, but with a twist that allows the server's certificate to be omitted, depriving the censor of many classification features, such as whether the certificate is signed by a CA, the certificate's lifetime, and whether the commonName matches the server's IP address. I got the idea from ShadowsocksR: https://github.com/breakwa11/shadowsocks-rss/blob/master/ssr.md#2%E6%B7%B7%… The trick that makes it work is RFC 5077 session tickets. How it's supposed to work is, the client makes a TLS connection as usual, and the server sends back a session ticket before beginning the flow of application data. The session ticket is just a random blob from the client's point of view; from the server's point of view it's an authenticated ciphertext that encodes session parameters such as the ciphersuite and master secret. The next time the client connects to the same server, it sends the session ticket along with its ClientHello and the server can skip sending its certificate. Here's a simple way to adapt session tickets for circumvention. The client *always* sends a session ticket when making a connection, even the very first time. The ticket doesn't come from a previous communication with the server; the client generates the ticket itself. The ticket could for instance be a random string--the censor wouldn't be able to distinguish--but we can also use those bits for other purposes. When the server receives the ClientHello, it *pretends* that the ticket was a valid one, and finishes the handshake using hardcoded session parameters, just statically configuring what it would have encoded into a session ticket. The protocol as just described would be vulnerable to active probing; the censor could test for servers by sending them garbage session tickets and seeing how they respond. But that's easy to fix. We can, for example, let the client and server have a shared secret, and have the server treat the session ticket as the client part of an obfs4 handshake--which conveniently resembles a random blob. If the session ticket doesn't pass obfs4 authentication, then the TLS server can respond as it naturally would if a client sent an invalid session ticket; i.e., issue a new ticket and do a full handshake (then send dummy data, I guess). The server can also honor its own legitimately issued tickets, but still send dummy data in response. Only clients who know the shared secret will be able to access the proxy functionality of the server. In order to block such a transport, the censor will have to look at features other than the server certificate. It could, for example: * block all session tickets (dunno how costly that would be) * statefully track which tickets servers have issued, and block connections that use an unknown ticket. * track the fraction of connections that use session tickets on each TLS server. * active-probe the server in order to get a certificate, and then look at certificate features. We'd have to do some research to find out the distribution of session ticket sizes in the wild. (RFC 5077 recommends a specific format: https://tools.ietf.org/html/rfc5077#section-4.) I didn't think of this idea; it comes from ShadowsocksR and its tls1.2_ticket_auth plugin. https://github.com/breakwa11/shadowsocks-rss/blob/master/ssr.md#2%E6%B7%B7%… The documentation is in Chinese. Here is what Google Translate says in English: Analog TLS1.2 handshake at client has a session ticket situation is connected. Currently complete analog implementation, software testing through capture perfectly disguised as TLS1.2. Because there is no ticket so send certificates and other complicated steps, so the firewall can not make a judgment based on the certificate. At the same time it comes with the ability of certain anti-replay attacks. In case of a replay attack is searched end log in to the service, you can grep "replay attack" search, you can use this plug-in found in your area there is no line of interference for TLS. TLS relatively powerless firewall, anti-blocking ability than other plug-ins should be strong, but may also encounter a lot of interference, but the agreement itself will check out any interference, then disconnect encounter interference, to avoid long waits, so that customers end browser or reconnect themselves. This plug-in is compatible with the original agreement (the server is configured to require tls1.2_ticket_auth_compatible), one more than the original protocol handshake causes the connection will take longer, use C # client open automatically reconnect when performed better than the other plug-ins. Support for custom parameters, parameters SNI, it sends the host name field, this function is very similar to the TOR meet widget, for example, is set to cloudfront.net disguised as a cloud server requests, you can use a comma separate multiple host such as a.com, b.net, c.org (C # supports only), then it will randomly use. Note that error settings for this parameter may cause the connection to be disconnected even IP is blocked, such as how to set clear then please leave it blank. Recommended customized parameter settings to cloudflare.com or cloudfront.net. This is how a normal ticketless handshake looks (https://tools.ietf.org/html/rfc5246#section-7.3): ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data This is how the ticket-using transport would look: (https://tools.ietf.org/html/rfc5077#section-3.1): ClientHello (SessionTicket extension) --------> ServerHello NewSessionTicket [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data

2 1

Error in javascript:ISSUE#6761
by AKASH DAS 05 Sep '16

05 Sep '16

There is an error in the javascript syntax in https-anywhere which the test bypasses. I have issued it in the github link https://github.com/EFForg/https-everywhere/issues/6761. On Mon, Sep 5, 2016 at 10:49 PM, AKASH DAS <akash.d14(a)iiits.in> wrote: > If I have to make any patch in the code, do I have to submit it in this > mailing list or https-everywhere's mailing list? Just a doubt > > On Mon, Sep 5, 2016 at 10:35 PM, David Fifield <david(a)bamsoftware.com> > wrote: > >> On Mon, Sep 05, 2016 at 10:28:26PM +0530, AKASH DAS wrote: >> > Can I know the issues that are currently in https everywhere. >> >> I don't know if this is what you're looking for, but here are some open >> bug tracker tickets. >> >> https://trac.torproject.org/projects/tor/query?status=!close >> d&component=HTTPS+Everywhere%2FEFF-HTTPS+Everywhere >> https://trac.torproject.org/projects/tor/query?status=!close >> d&component=HTTPS+Everywhere%2FHTTPS+Everywhere%3A+Chrome >> > > > > -- > > *Akash Das* > > *Student Systems Admin* > > *Indian Institute Of Information Technology* > > *Sricity* > -- *Akash Das* *Student Systems Admin* *Indian Institute Of Information Technology* *Sricity*

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev September 2016