tor-dev August 2015

tor-dev@lists.torproject.org

59 participants
59 discussions

Re: [tor-dev] Remove NULL checks for *_free() calls
by tordev123＠Safe-mail.net 31 Aug '15

31 Aug '15

-------- Original Message -------- From: Zack Weinberg <zackw(a)panix.com> To: tor-dev(a)lists.torproject.org Subject: Re: [tor-dev] Remove NULL checks for *_free() calls Date: Mon, 31 Aug 2015 10:29:31 -0400 > > But you did find some places they forgot to assign NULL after free. > > Unfortunately, setting pointers to 0 after free doesn't help avoid > double free bugs in practice. Double frees happen when there are two > different pointers to the same memory block and both holders think > it's their responsibility to deallocate the object. Clearing one > pointer does precisely nothing to the *other* pointer. Double free is relatively harmless, you usually get a nice crash or noticable memory corruption. What zeroing deleted pointers also gives you is protection against some dangling pointer bugs. Those can be very difficult to track down when the dangling pointer usage is only brief after the free and the bug only manifests itself every full moon. Tor itself is small and fast enough to be run with a memory debugger. Someone is hopefully doing that and this is a moot point.

1 0

Remove NULL checks for *_free() calls
by Michael McConville 31 Aug '15

31 Aug '15

free() is specified to be NULL-safe, and I don't know of any implementations that violate this. Tor's *_free() functions conform, although relaycache_free() prints a warning (which I remove in the below diff). I checked every *_free() function for NULL-safety before removing conditions for it. This includes an OpenSSL function or two. This is only a first pass. I got bored, and I wanted to make sure that there's interest in committing this. :) diff --git a/src/common/backtrace.c b/src/common/backtrace.c index a2d5378..0aa8a17 100644 --- a/src/common/backtrace.c +++ b/src/common/backtrace.c @@ -176,8 +176,7 @@ install_bt_handler(void) char **symbols; int depth = backtrace(cb_buf, MAX_DEPTH); symbols = backtrace_symbols(cb_buf, depth); - if (symbols) - free(symbols); + free(symbols); } return rv; diff --git a/src/common/torgzip.c b/src/common/torgzip.c index 4f23407..3158b96 100644 --- a/src/common/torgzip.c +++ b/src/common/torgzip.c @@ -403,9 +403,7 @@ tor_gzip_uncompress(char **out, size_t *out_len, inflateEnd(stream); tor_free(stream); } - if (*out) { - tor_free(*out); - } + tor_free(*out); return -1; } diff --git a/src/common/tortls.c b/src/common/tortls.c index 7447822..23b1dcf 100644 --- a/src/common/tortls.c +++ b/src/common/tortls.c @@ -625,10 +625,8 @@ tor_tls_create_certificate(crypto_pk_t *rsa, goto done; error: - if (x509) { - X509_free(x509); - x509 = NULL; - } + X509_free(x509); + x509 = NULL; done: tls_log_errors(NULL, LOG_WARN, LD_NET, "generating certificate"); if (sign_pkey) @@ -722,8 +720,7 @@ tor_x509_cert_free(tor_x509_cert_t *cert) { if (! cert) return; - if (cert->cert) - X509_free(cert->cert); + X509_free(cert->cert); tor_free(cert->encoded); memwipe(cert, 0x03, sizeof(*cert)); tor_free(cert); @@ -1328,12 +1325,9 @@ tor_tls_context_new(crypto_pk_t *identity, unsigned int key_lifetime, crypto_pk_free(rsa_auth); if (result) tor_tls_context_decref(result); - if (cert) - X509_free(cert); - if (idcert) - X509_free(idcert); - if (authcert) - X509_free(authcert); + X509_free(cert); + X509_free(idcert); + X509_free(authcert); return NULL; } @@ -2035,8 +2029,7 @@ tor_tls_finish_handshake(tor_tls_t *tls) "a v2 handshake on %p.", tls); tls->wasV2Handshake = 1; } - if (cert) - X509_free(cert); + X509_free(cert); #endif if (SSL_set_cipher_list(tls->ssl, SERVER_CIPHER_LIST) == 0) { tls_log_errors(NULL, LOG_WARN, LD_HANDSHAKE, "re-setting ciphers"); @@ -2319,8 +2312,7 @@ tor_tls_verify(int severity, tor_tls_t *tls, crypto_pk_t **identity_key) r = 0; done: - if (cert) - X509_free(cert); + X509_free(cert); if (id_pkey) EVP_PKEY_free(id_pkey); @@ -2353,8 +2345,7 @@ tor_tls_check_lifetime(int severity, tor_tls_t *tls, r = 0; done: - if (cert) - X509_free(cert); + X509_free(cert); /* Not expected to get invoked */ tls_log_errors(tls, LOG_WARN, LD_NET, "checking certificate lifetime"); diff --git a/src/common/util.h b/src/common/util.h index 8bb4505..9ba9d9a 100644 --- a/src/common/util.h +++ b/src/common/util.h @@ -107,8 +107,8 @@ extern int dmalloc_free(const char *file, const int line, void *pnt, STMT_END #else /** Release memory allocated by tor_malloc, tor_realloc, tor_strdup, etc. - * Unlike the free() function, tor_free() will still work on NULL pointers, - * and it sets the pointer value to NULL after freeing it. + * Unlike the free() function, tor_free() sets the pointer value to NULL + * after freeing it. * * This is a macro. If you need a function pointer to release memory from * tor_malloc(), use tor_free_(). diff --git a/src/ext/eventdns.c b/src/ext/eventdns.c index a0c7ff2..cfc3344 100644 --- a/src/ext/eventdns.c +++ b/src/ext/eventdns.c @@ -1923,9 +1923,7 @@ server_request_free(struct server_request *req) rc = --req->port->refcnt; } - if (req->response) { - mm_free(req->response); - } + mm_free(req->response); server_request_free_answers(req); @@ -3216,8 +3214,7 @@ load_nameservers_with_getnetworkparams(void) } done: - if (buf) - mm_free(buf); + mm_free(buf); if (handle) FreeLibrary(handle); return status; diff --git a/src/ext/tinytest_demo.c b/src/ext/tinytest_demo.c index c07f099..7279216 100644 --- a/src/ext/tinytest_demo.c +++ b/src/ext/tinytest_demo.c @@ -169,8 +169,7 @@ test_memcpy(void *ptr) end: /* This time our end block has something to do. */ - if (mem) - free(mem); + free(mem); } void diff --git a/src/or/buffers.c b/src/or/buffers.c index 85fcbc6..e5d2894 100644 --- a/src/or/buffers.c +++ b/src/or/buffers.c @@ -1014,7 +1014,7 @@ fetch_var_cell_from_evbuffer(struct evbuffer *buf, var_cell_t **out, result = 1; done: - if (free_hdr && hdr) + if (free_hdr) tor_free(hdr); return result; } @@ -2410,8 +2410,7 @@ generic_buffer_set_to_copy(generic_buffer_t **output, } } #else - if (*output) - buf_free(*output); + buf_free(*output); *output = buf_copy(input); #endif return 0; diff --git a/src/or/channel.c b/src/or/channel.c index af09502..b1dc63e 100644 --- a/src/or/channel.c +++ b/src/or/channel.c @@ -917,10 +917,8 @@ channel_force_free(channel_t *chan) channel_clear_remote_end(chan); /* Get rid of cmux */ - if (chan->cmux) { - circuitmux_free(chan->cmux); - chan->cmux = NULL; - } + circuitmux_free(chan->cmux); + chan->cmux = NULL; /* We might still have a cell queue; kill it */ TOR_SIMPLEQ_FOREACH_SAFE(cell, &chan->incoming_queue, next, cell_tmp) { diff --git a/src/or/config.c b/src/or/config.c index 6e782de..e3d7721 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -7263,11 +7263,9 @@ init_cookie_authentication(const char *fname, const char *header, goto done; } - /* If we've already set the cookie, free it before re-setting - it. This can happen if we previously generated a cookie, but - couldn't write it to a disk. */ - if (*cookie_out) - tor_free(*cookie_out); + /* Free this cookie before re-setting it. This can happen if we + * previously generated a cookie, but couldn't write it to a disk. */ + tor_free(*cookie_out); /* Generate the cookie */ *cookie_out = tor_malloc(cookie_len); diff --git a/src/or/ext_orport.c b/src/or/ext_orport.c index e8c8aa6..b4f4cab 100644 --- a/src/or/ext_orport.c +++ b/src/or/ext_orport.c @@ -476,9 +476,7 @@ connection_ext_or_handle_cmd_useraddr(connection_t *conn, /* record the address */ tor_addr_copy(&conn->addr, &addr); conn->port = port; - if (conn->address) { - tor_free(conn->address); - } + tor_free(conn->address); conn->address = tor_dup_addr(&addr); return 0; @@ -509,11 +507,8 @@ connection_ext_or_handle_cmd_transport(or_connection_t *conn, return -1; } - /* If ext_or_transport is already occupied (because the PT sent two - * TRANSPORT commands), deallocate the old name and keep the new - * one */ - if (conn->ext_or_transport) - tor_free(conn->ext_or_transport); + /* deallocate the ext_or_transport's old name and keep the new one */ + tor_free(conn->ext_or_transport); conn->ext_or_transport = transport_str; return 0; @@ -643,7 +638,6 @@ connection_ext_or_start_auth(or_connection_t *or_conn) void ext_orport_free_all(void) { - if (ext_or_auth_cookie) /* Free the auth cookie */ - tor_free(ext_or_auth_cookie); + tor_free(ext_or_auth_cookie); } diff --git a/src/or/onion_tap.c b/src/or/onion_tap.c index 487cbee..4645ca4 100644 --- a/src/or/onion_tap.c +++ b/src/or/onion_tap.c @@ -75,7 +75,7 @@ onion_skin_TAP_create(crypto_pk_t *dest_router_key, return 0; err: memwipe(challenge, 0, sizeof(challenge)); - if (dh) crypto_dh_free(dh); + crypto_dh_free(dh); return -1; } diff --git a/src/or/rendservice.c b/src/or/rendservice.c index db6bc4b..1fb5245 100644 --- a/src/or/rendservice.c +++ b/src/or/rendservice.c @@ -1746,7 +1746,7 @@ rend_service_receive_introduction(origin_circuit_t *circuit, (unsigned)circuit->base_.n_circ_id); err: status = -1; - if (dh) crypto_dh_free(dh); + crypto_dh_free(dh); if (launched) { circuit_mark_for_close(TO_CIRCUIT(launched), reason); } diff --git a/src/or/replaycache.c b/src/or/replaycache.c index 569e073..f327fa7 100644 --- a/src/or/replaycache.c +++ b/src/or/replaycache.c @@ -18,10 +18,8 @@ void replaycache_free(replaycache_t *r) { - if (!r) { - log_info(LD_BUG, "replaycache_free() called on NULL"); + if (!r) return; - } if (r->digests_seen) digestmap_free(r->digests_seen, tor_free_); diff --git a/src/or/routerparse.c b/src/or/routerparse.c index c2206f1..71bcb7e 100644 --- a/src/or/routerparse.c +++ b/src/or/routerparse.c @@ -3840,8 +3840,7 @@ assert_addr_policy_ok(smartlist_t *lst) static void token_clear(directory_token_t *tok) { - if (tok->key) - crypto_pk_free(tok->key); + crypto_pk_free(tok->key); } #define ALLOC_ZERO(sz) memarea_alloc_zero(area,sz) diff --git a/src/test/test.c b/src/test/test.c index e10e260..d978f78 100644 --- a/src/test/test.c +++ b/src/test/test.c @@ -572,14 +572,10 @@ test_rend_fns(void *arg) rend_encoded_v2_service_descriptor_free(smartlist_get(descs, i)); smartlist_free(descs); } - if (parsed) - rend_service_descriptor_free(parsed); - if (generated) - rend_service_descriptor_free(generated); - if (pk1) - crypto_pk_free(pk1); - if (pk2) - crypto_pk_free(pk2); + rend_service_descriptor_free(parsed); + rend_service_descriptor_free(generated); + crypto_pk_free(pk1); + crypto_pk_free(pk2); tor_free(intro_points_encrypted); } diff --git a/src/test/test_buffers.c b/src/test/test_buffers.c index e8fce12..8cc1b61 100644 --- a/src/test/test_buffers.c +++ b/src/test/test_buffers.c @@ -189,10 +189,8 @@ test_buffers_basic(void *arg) } done: - if (buf) - buf_free(buf); - if (buf2) - buf_free(buf2); + buf_free(buf); + buf_free(buf2); } static void @@ -362,10 +360,8 @@ test_buffer_copy(void *arg) } done: - if (buf) - generic_buffer_free(buf); - if (buf2) - generic_buffer_free(buf2); + generic_buffer_free(buf); + generic_buffer_free(buf2); } static void diff --git a/src/test/test_crypto.c b/src/test/test_crypto.c index dbaec61..71a94f8 100644 --- a/src/test/test_crypto.c +++ b/src/test/test_crypto.c @@ -269,10 +269,8 @@ test_crypto_aes(void *arg) done: tor_free(mem_op_hex_tmp); - if (env1) - crypto_cipher_free(env1); - if (env2) - crypto_cipher_free(env2); + crypto_cipher_free(env1); + crypto_cipher_free(env2); tor_free(data1); tor_free(data2); tor_free(data3); @@ -412,10 +410,8 @@ test_crypto_sha(void *arg) tt_mem_op(d_out1,OP_EQ, d_out2, DIGEST_LEN); done: - if (d1) - crypto_digest_free(d1); - if (d2) - crypto_digest_free(d2); + crypto_digest_free(d1); + crypto_digest_free(d2); tor_free(mem_op_hex_tmp); } diff --git a/src/test/test_dir.c b/src/test/test_dir.c index 855746e..bf7ce59 100644 --- a/src/test/test_dir.c +++ b/src/test/test_dir.c @@ -346,20 +346,17 @@ test_dir_formats(void *arg) dirserv_free_fingerprint_list(); done: - if (r1) - routerinfo_free(r1); - if (r2) - routerinfo_free(r2); - if (rp2) - routerinfo_free(rp2); + routerinfo_free(r1); + routerinfo_free(r2); + routerinfo_free(rp2); tor_free(rsa_cc); tor_free(buf); tor_free(pk1_str); tor_free(pk2_str); - if (pk1) crypto_pk_free(pk1); - if (pk2) crypto_pk_free(pk2); - if (rp1) routerinfo_free(rp1); + crypto_pk_free(pk1); + crypto_pk_free(pk2); + routerinfo_free(rp1); tor_free(dir1); /* XXXX And more !*/ tor_free(dir2); /* And more !*/ } @@ -2315,32 +2312,19 @@ test_a_networkstatus( tor_free(consensus_text); tor_free(consensus_text_md); - if (vote) - networkstatus_vote_free(vote); - if (v1) - networkstatus_vote_free(v1); - if (v2) - networkstatus_vote_free(v2); - if (v3) - networkstatus_vote_free(v3); - if (con) - networkstatus_vote_free(con); - if (con_md) - networkstatus_vote_free(con_md); - if (sign_skey_1) - crypto_pk_free(sign_skey_1); - if (sign_skey_2) - crypto_pk_free(sign_skey_2); - if (sign_skey_3) - crypto_pk_free(sign_skey_3); - if (sign_skey_leg1) - crypto_pk_free(sign_skey_leg1); - if (cert1) - authority_cert_free(cert1); - if (cert2) - authority_cert_free(cert2); - if (cert3) - authority_cert_free(cert3); + networkstatus_vote_free(vote); + networkstatus_vote_free(v1); + networkstatus_vote_free(v2); + networkstatus_vote_free(v3); + networkstatus_vote_free(con); + networkstatus_vote_free(con_md); + crypto_pk_free(sign_skey_1); + crypto_pk_free(sign_skey_2); + crypto_pk_free(sign_skey_3); + crypto_pk_free(sign_skey_leg1); + authority_cert_free(cert1); + authority_cert_free(cert2); + authority_cert_free(cert3); tor_free(consensus_text2); tor_free(consensus_text3); @@ -2348,18 +2332,12 @@ test_a_networkstatus( tor_free(consensus_text_md3); tor_free(detached_text1); tor_free(detached_text2); - if (con2) - networkstatus_vote_free(con2); - if (con3) - networkstatus_vote_free(con3); - if (con_md2) - networkstatus_vote_free(con_md2); - if (con_md3) - networkstatus_vote_free(con_md3); - if (dsig1) - ns_detached_signatures_free(dsig1); - if (dsig2) - ns_detached_signatures_free(dsig2); + networkstatus_vote_free(con2); + networkstatus_vote_free(con3); + networkstatus_vote_free(con_md2); + networkstatus_vote_free(con_md3); + ns_detached_signatures_free(dsig1); + ns_detached_signatures_free(dsig2); } /** Run unit tests for generating and parsing V3 consensus networkstatus diff --git a/src/test/test_replay.c b/src/test/test_replay.c index a02c160..538b2df 100644 --- a/src/test/test_replay.c +++ b/src/test/test_replay.c @@ -27,7 +27,7 @@ test_replaycache_alloc(void *arg) tt_assert(r != NULL); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } @@ -51,7 +51,7 @@ test_replaycache_badalloc(void *arg) tt_assert(r == NULL); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } @@ -90,7 +90,7 @@ test_replaycache_miss(void *arg) tt_int_op(result,OP_EQ, 0); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } @@ -116,7 +116,7 @@ test_replaycache_hit(void *arg) tt_int_op(result,OP_EQ, 1); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } @@ -147,7 +147,7 @@ test_replaycache_age(void *arg) tt_int_op(result,OP_EQ, 0); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } @@ -175,7 +175,7 @@ test_replaycache_elapsed(void *arg) tt_int_op(elapsed,OP_EQ, 100); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } @@ -206,7 +206,7 @@ test_replaycache_noexpire(void *arg) tt_int_op(result,OP_EQ, 1); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } @@ -248,7 +248,7 @@ test_replaycache_scrub(void *arg) tt_int_op(digestmap_size(r->digests_seen),OP_EQ, 0); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } @@ -292,7 +292,7 @@ test_replaycache_future(void *arg) tt_int_op(elapsed,OP_EQ, 0); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } @@ -335,7 +335,7 @@ test_replaycache_realtime(void *arg) replaycache_scrub_if_needed(r); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } diff --git a/src/test/test_routerset.c b/src/test/test_routerset.c index 9bd0c12..b13ec40 100644 --- a/src/test/test_routerset.c +++ b/src/test/test_routerset.c @@ -1144,8 +1144,7 @@ NS(test_main)(void *arg) tt_int_op(r, OP_EQ, 0); done: - if (set != NULL) - routerset_free(set); + routerset_free(set); } country_t @@ -1186,8 +1185,7 @@ NS(test_main)(void *arg) tt_int_op(smartlist_contains_string(set->list, "{??}"), OP_EQ, 1); done: - if (set != NULL) - routerset_free(set); + routerset_free(set); } country_t @@ -1249,8 +1247,7 @@ NS(test_main)(void *arg) tt_int_op(smartlist_contains_string(set->list, "{a1}"), OP_EQ, 1); done: - if (set != NULL) - routerset_free(set); + routerset_free(set); } country_t diff --git a/src/test/test_status.c b/src/test/test_status.c index cbc8af1..7e18b5d 100644 --- a/src/test/test_status.c +++ b/src/test/test_status.c @@ -145,8 +145,7 @@ NS(test_main)(void *arg) tor_free(actual); done: - if (actual != NULL) - tor_free(actual); + tor_free(actual); } #undef NS_SUBMODULE @@ -226,8 +225,7 @@ NS(test_main)(void *arg) tor_free(actual); done: - if (actual != NULL) - tor_free(actual); + tor_free(actual); } #undef NS_SUBMODULE diff --git a/src/test/test_util.c b/src/test/test_util.c index 0a5783e..a4341d9 100644 --- a/src/test/test_util.c +++ b/src/test/test_util.c @@ -1707,8 +1707,7 @@ test_util_gzip(void *arg) tt_int_op(21,OP_EQ, len2); done: - if (state) - tor_zlib_free(state); + tor_zlib_free(state); tor_free(buf2); tor_free(buf3); tor_free(buf1);

4 4

Re: [tor-dev] Hash Visualizations to Protect Against Onion Phishing
by ncl＠cock.li 30 Aug '15

30 Aug '15

I came across this thread from the weekly news post for this week, so please excuse me if I've missed some from just skimming through the posts. Having randomart/gravatars/poems/etc seems like a rather interesting topic, but seriously adding it to tor, there seems to be a few problems in my mind: a) This doesn't stop someone from phishing if the target has never seen the hs address before. (proving identities is another issue though I guess, the focus on this discussion being how to implement TOFU.) b) People's memories are imperfect and even if with a system that may generate wildly distinct results even with similar addresses, remembering a number of those will become a blur. c) This all seems rather complicated. Since the point seems to just be keeping a record that addresses match once you're reasonably sure you've found the right one, wouldn't something of an "address book" be much simpler and easier? It might not even need to be a feature of tor/tbb, but maybe just a tip to users. It could be something as simple as a gpg-encrypted text file if you're worried about leaking sites you visit. (I hope I don't get much about using "gpg" and "simple" in the same sentence.) Another few things popped up in my mind while thinking about this: - Should tbb distribute hsts preload-like lists for HS's (eg for securedrops?) - A set of guidelines should be published on how an HS owner should prove their identity. (wouldn't want another sigaint incident!) - Can/should a system be set up to monitor HS addresses that are similar to existing ones? - For HS's which do not need to be as anonymous, should a tor-specific CA be created, or be encouraged to try and use a CA as a means of extra verification? A tor-specific CA might be better, since an attacker might be able to get their phishing cert signed. If the previous point is implemented, more precautions could be put in place to verify an HS's identity.

1 0

7th and last status report for OnioNS
by Jesse V 28 Aug '15

28 Aug '15

Happy Friday everyone, This is my last status report for the Summer of Privacy program, but I think I can end my reports on a good note. * At the suggestion of several people, I rewrote the networking infrastructure. Before, OnioNS-client and OnioNS-HS contacted the servers over Tor circuits, and OnioNS-server sent messages to each other over unencrypted TCP/IP links P2P-style. Now, the servers bind to localhost and are powered by hidden services, so all server-server communication occurs Ricochet-style. This is superior because it provides a significant increase to network attacks, works around the problem of distributing another TCP port in the consensus, and allows Tor relay administrators to run OnioNS servers without having to punch yet another hole in their firewall. I don't need anonymity for server P2P communication, so I will certainly be using the single onion service infrastructure when it becomes available. * All OnioNS servers now manage Ed25519 keypairs. In my design, authoritative Quorum servers will use their key for authenticated denial-of-existence and to prevent regular name servers from forging responses, but this infrastructure is not fully in place yet. When OnioNS merges into Tor, this keypair would be each router's signing key or at least a keypair signed by the signing key. * Servers now save newly-received Records to disk to prevent them. The cache file is loaded when the server starts up. * OnioNS-HS now saves newly-validated Records to disk before attempting to upload them. This is incredibly handy to prevent having to re-preform all the proof-of-work if the upload fails. * OnioNS-HS no longer has a dependency on little-t-tor. As s7r wisely points out, some people may have installed tor from git. I also added a flag to specify the number of worker threads, which can help reduce the system requirements if the HS is hosted on a VM with minimal system resources. * OnioNS-client no longer logs all Tor Browser activity. I used this for debugging, but it's no longer worth compromising user privacy. The software also correctly shuts down when the Tor Browser closes; in the process of fixing this I also discovered that it's not a good idea to misinterpret the documentation and run an application containing "kill(0, SIGTERM);". The result was quite unexpected. * In addition to intercepting all *.tor domains, OnioNS-client now rewrites "check.torproject.org" to another domain that shows that OnioNS is enabled in the browser. Before, users had to visit "example.tor" to confirm that the OnioNS software is running, but this was problematic because if OnioNS wasn't running, they get an error message because their exit node cannot resolve "example.tor" on the Internet DNS. Now these failures no longer leak. * I've stopped packaging my own build of jsoncpp, so I added a dependency for a system installation. Fortunately, Ubuntu/Mint, Debian, and Fedora all have that library in their repositories. * Logs now include the date and time, which is quite handy. * Numerous bugfixes, most notably I fixed the bug where the recipient would fail to understand a message longer than 500 bytes. To summarize the state of the project at the end of the SoP program: * All of the infrastructure for OnioNS is in place. There are still a few protocols left to finish off, but all big tasks are complete. The client-side and HS-side software is pretty reliable and stable at this point. * Although the software lacks in-line documentation, I have gone to great lengths to increase its readability and overall organization. * OnioNS runs just fine on Debian, Ubuntu, Mint, and Fedora, although I do not have any support for Windows or OS X. I'm asking for help from any Windows developer to help port the client software over there, please talk to me about that. * I have full intentions of continuing to maintain the OnioNS project. Please keep an eye on https://github.com/Jesse-V?tab=repositories and I will post here when I push out releases. I'm very close to the next beta test. * Once the OnioNS software is fully ready, no modifications to Tor should be necessary to merge OnioNS into the Tor network. Thanks everyone for the help, it's been a great summer project! Jesse V.

1 0

patch to improve consensus download decompress performance
by starlight.2015q3＠binnacle.cx 28 Aug '15

28 Aug '15

3 2

Triaged some TorCoreTeam201508 tickets; please review
by Nick Mathewson 26 Aug '15

26 Aug '15

Hi! I've moved all the TorCoreTeam201508 tickets to TorCoreTeam201509 or out entirely. I've also moved some of them to the 0.2.8 milestone, and tentatively assigned the PostFreeze027 ticket to others. If I'm wrong about any of those, please feel free to fix 'em! Now I'm moving on to the 0.2.7 milestone as a whole. In general, any ticket in 0.2.7 that isn't tagged with PostFreeze027 is not going to be a candidate for merge after 1 Sep, so please keep that in mind. (You can add the tag to your own tickets if you want, but please do so judiciously and in moderation.) cheers, -- Nick

1 1

FSCONS CFP extended
by tordevmuc＠encambio.com 26 Aug '15

26 Aug '15

Hello list, Organizers of the Free Society Conference and Nordic Summit (FSCONS) taking place in Goeteborg, Sweden on 7-8 November have extended the CFP and seek speakers [1] for the event. Particularly relevant to us is the track: Everyday Crypto ...and being that at least one group friendly to Tor is already scheduled, it would be a welcome gesture to have a Tor lecture or workshop as well. Anyone interested in this should contact Stian (in Cc) with a speaking/workshop proposal. [1] https://fscons.org/2015/cfp.html Cheers, Michael

1 0

Hash Visualizations to Protect Against Onion Phishing
by George Kadianakis 26 Aug '15

26 Aug '15

Hello, this mail lays down an idea for a TBB UI feature that will make it slightly harder to launch phishing attacks against hidden services. The idea is based on hash visualizations like randomart [0] and key poems: ------------------- | o=. | | o o++E | | + . Ooo. | | + O B.. | | = *S. | | o | | | | | | | ------------------- The idea came up during a discussion with Jeff Burdges in CCC camp. This is a heavily experimental idea and there are various unresolved research and UX issues here, but we hope that we will motivate further study. The aim is to make it harder to phish people who click untrusted onion links. Think of when you click an onion link on a forum, or when a friend sends you an onion URL. The problem is that many people don't verify the whole onion address, they just trust the onion link or verify the first few characters. This is bad since an attacker can create a hidden service with a similar onion address very easily. There are currently ready-made scripts that people have been using to launch impersonation attacks against real hidden services. The suggested improvement here is for TBB to provide additional visual fingerprints that people can use to verify the authenticity of a hidden service. So when TBB connects to a hidden service, it uses the onion address to generate a randomart or key poem and makes them available for the user to examine. Here is an experimental mockup just to illustrate the idea: https://people.torproject.org/~asn/tbb_randomart/randomart_mockup.png The idea is that you hash (or scrypt!) the onion address, and then you make a visualization using the hash output. This forces the phishing attacker to generate a similar onion address _and_ similar hash visualizations. We assume that this will be harder to do than simply faking a similar onion address, which increases the startup cost for such an attacker. This is the basic concept. Now, here are some thoughts: - What hash visualizations can we use here? The SSH randomart is an obvious idea, and we can even have it colored since we are not in a terminal. Then we have the key poem idea, which generates a poem from a key. I don't think this is used by a deployed system currently. Then we could imagine music-based hash fingerprints, where the onion address corresponds to a small tune that is played when you visit an onion. Then there are even more crazy ideas like the "Dynamic Security Skins" paper [1]. So for example, TBB could generate a unique UI theme for each hidden service. - Of course, none of the above ideas is perfect. Actually most of them suck. For example, when it comes to randomart, many people are colorblind to some degree and most people are not good at recognizing subtle color differences. Furthermore, given a randomart, it's easy [2] to generate similar randomarts. However we hope that most of those similar randomarts will not correspond to a public key that is similar to the original one. When it comes to key poems, given even a moderately sized dictionary leads to pretty big poems. We are talking about poems of 24 random words, which is not something that most people can remember. Much more research needs to be done here. - Even though all these techniques are flawed in some way or another, we hope that by deploying them we increase the cost of the attacker. If a few of these techniques are implemented, a phishing attacker will have to spend time generating similar visualizations, because she does not know whether the user actually looks at them and which one the user prefers. Also, this feature only requires a TBB addon/patch and no modifications to the Tor protocol whatsoever, which makes it slightly easier to prototype and experiment with. - On the other hand, this might be a terrible idea for multiple reasons. From the UX perspective, it will confuse people who don't expect to see crazy visuals or poems on their browser. Our hope here is that this feature will be hidden by most users, and will only be used by people who understand it. However, this exact logic is what causes bad UI. Also, from a security perspective this might encourage people to not spend time to verify the whole onion address (currently 16 chars, but will be extended to 54 chars or so with prop224), and instead rely on the stupid randomart. Some real UX research needs to be done here, before we decide something terrible. - Finally, a positive thing with this idea is that it nicely complements directories of onion addresses like search engines and human-memorable systems. In the future, people who visit the same onion address using a search engine all the time, will have an extra way of verifying its authenticity. In any case, this is just a crazy pants idea, so please send your feedback to make it more useful, or to kill it completely! Cheers!~ [0]: http://undeadly.org/cgi?action=article&sid=20080615022750 http://users.ece.cmu.edu/~adrian/projects/validation/validation.pdf [1]: http://www.eecs.berkeley.edu/~tygar/papers/Phishing/Battle_against_phishing… [2]: http://www.dirk-loss.de/sshvis/drunken_bishop.pdf

9 11

Design for onionsite certification and use with Let's Encrypt
by Paul Syverson 26 Aug '15

26 Aug '15

Hi Alec, Seth, Peter, Mike, all, I'm enthused about the progress Alec reported about the Onion RFC for certs for onion addresses in recent tor-dev posts and elsewhere. I wanted to further discuss a design for binding .onion addresses with registered (route-insecure) addresses. This ties in to in-person discussions had with Seth, Peter, and Mike back in June about how this all dovetails with Let's Encrypt and Tor Browser, which is why I am also addressing this message to them directly. I hope they can comment on whether this design seems realistic in that regard and any major caveats, stumbling blocks, etc. I'll start with a description of goals and complementarity comments about readability of onion addresses themselves, and other recent tor-dev discussion topics. I did a partially related post to tor-assistants on one-sided onion services back in June that covered perhaps too many alternatives concerning onion services and too many goals and too much of the motivation, and none of that adequately separated. I think it left most scratching their heads. This is an attempt to be a bit narrower and hopefully clearer. Those not interested in even the briefly described motivations and background set out here can skip below to the high-level design itself. Goals, Caveats, Complementarity to other recently discussed related topics A main goal is to give people a way to provide route-secure access to their websites in somewhat the same way that the current certificate and https protocol infrastructure lets them provide data-secure access to their website. I would really like to have a version of this be an offering as part of obtaining a certificate from Let's Encrypt because I would like it to encourage people to offer route-secure versions of their sites in the same way that Let's Encrypt as currently put forth is meant to encourage them to offer data-secure versions of their sites. Having this built into something like Let's Encrypt should make it easy for users to set up onionsites to provide security for their websites. The design should to be neutral between double onion services (services where connections involve a Tor circuit from the client and a Tor circuit from the server, such as the currently deployed design) and single onion services (basically just having a Tor circuit from the client). There's a draft Tor Proposal by John Brooks, Roger Dingeldine, and me on single onion services that I believe John should be making available soon, but I want to leave such details aside. I'm taking single onion services as the paradigmatic typical case, but unless it creates a big problem I would like to assume both single and double onion services will be compatible. Obviously an onion service tied to a registered domain doesn't cover many important uses of onion services, but it should cover many existing use cases. Note also that wanting to offer network-location protection for a service can be compatible with having a registered domain name for that service (and whether or not there was any attempt to obscure information about the registrant of the domain name). In some cases it is not compatible, but not necessarily. I think this is basically complementary to ways to make onion addresses more readable, recognizable. I'm OK with whatever an address is that will be acceptable to the RFC and that maintains the current self-authenticating property (not getting into quibbles about computational strength of that self-authentication), as long as it remains something that will fit into a cert as described below. I'm also leaving as an extension mentioned at the end below, offering an onion service for someone's site but not associated with a domain name she has registered. (E.g. an onionsite tied to Mary's Wordpress Blog, with, e.g., the goal being more about guarantees of binding to Mary than about guarantees of binding Wordpress.) I think that is another important and useful case, which we discussed in our W2SP paper, but I'd like to mostly leave it aside for now. High-level Design Creating the DV Cert At least the same DV level of checking should occur as for existing registered domain names. So the email check should include the onion name that is being bound as well as the route-insecure name(s). For simplicity, I am assuming a single onion address and possibly a small number of registered domain names, although I'm guessing doing this for a similarly small number of onion addresses might be made to work as well. (I'm assuming no wildcards, but maybe I'm not being ambitious enough.) Besides a check at the registered-domain name(s) a check should also be made that the onionsite verifies association with the registered-domain site(s). It is not as reasonable to assume email infrastructure exists corresponding to the onion address is in place. Instead a validation query protocol will be needed that simply connects to the onionsite and asks if it is acceptable to certify association of the onionsite with the registered-domain(s). Only if all DV checks complete successfully should the CA be willing to issue the Cert. The cert obtained will have the onion address listed as a SAN (subjectAltName) in the certificate. Connecting to an onionsite by the client I assume that the default HTTPS-everywhere ruleset will be updated to include a direction of route-insecure addresses to onion addresses for sites that hold appropriate certificates. It would be reasonable to have this update occur initially along with the certification process. HTTPS-everywhere rules should differentiate whether they are being requested by Tor Browser or another browser. If by Tor Browser, I assume(?) the redirection is straightforward: If a Tor-Browser request is to connect to a route-insecure address, HTTPS-everywhere should redirect this to an onion address. At that point everything should proceed as normal for connecting to an onion address. If another browser it could be a setup config option whether clients can choose to be redirected via tor2web or simply always sent to a route-insecure address. I will assume for simplicity that all requests for route-insecure addresses by other browsers simply send to a route-insecure HTTPS address in the ruleset (if available). I'm going to also assume that requests for onion addresses for other browsers simply fail, although if the tor2web option was available and chosen at the time of setup, then there is another question how to offer this to the client, perhaps as an HTTPS Everywhere setting. Comments on the feasibility, usefulness, design etc. of the tor2web option would be bonus, but of course I'm most wanting to know about the viability of the most basic version of things. If the Tor-Browser request is to connect to an onion address, proceed as normal except that it can now be redirected by HTTPS Everywhere to an https connection to the address. Certified connection to such an onionsite should work and be indicated as normal for any site with a DV Cert. End basic description Web of trust extension W had suggested in the w2sp paper that people could bind their route-insecure address to their onion address with a gpg key. One rationale is that there is an existing web of trust that can be leveraged, and existing mechanisms to do the verification. This would allow not just securing of human-meaningful addresses and connections but also certification by more human-meaningful trust relations than the usual CA. It also allows things like binding a wordpress blog to an onion address as mentioned above so people need not have a registered domain to have a human-meaningful address for a route-insecure site for which they would like to offer a route-secure alternative. Drawbacks include: 1. There is no simple automated significant infrastructure to support this. The Monkeysphere plugin is out there, and would probably be leveraged to support something like this, but... 2. PGP/GPG remains something of a geek tool. That is possibly changing slowly, but perhaps it would be better not to wait for that. Also, it's yet another thing to learn about, so... If onion keys could be themselves linked in a PGP-like web of trust, then this could be more directly relevant and meaning to people operating on the web, especially those unfamiliar with PGP-like notions. This would of course require things like the check and indication being either built into the browser or as a plugin. And it would similarly for people deciding when to sign another's key require an easy interface and easy to understand criteria as well as mechanisms for that to all happen securely. I think this holds more hope for successful widespread web of trust to complement the X.509 type trust hierarchy that the PGP plan would support. How to decide whether a site is trusted depending what each of these trust mechanisms indicate would also need to be worked out and might again be configurable with standard defaults.

3 3

Video of my presentation on domain fronting (PETS 2015)
by David Fifield 26 Aug '15

26 Aug '15

My presentation on domain fronting (the meek pluggable transport in Tor), which I gave at PETS 2015 on June 30, 2015, is online. This page has the video and a copy of the slides. It is about 17 minutes long. https://www.bamsoftware.com/talks/fronting-pets2015/ Here is the paper on which the talk is based, by Chang Lan, Rod Hynes, Percy Wegmann, Vern Paxson, and me: https://www.bamsoftware.com/papers/fronting/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev August 2015