Re: [tor-talk] alt-svc supported by TBB

2018-09-21 Thread Mike Tigas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, Sep 21, 2018 at 9:31 AM Andreas Krey  wrote:
>
> On Thu, 20 Sep 2018 12:38:56 +, Dave Warren wrote:
> ...
> > >Using the test page at https://perfectoid.space/test.php I get either
> > >red or yellow exclusively, no amount of refreshing and/or changing
> > >circuits seems to get green which confirms my own testing on a site I
> > >operate that is participating in the beta.
> >
> > I've been monkeying around a bit, and I can sometimes get this to work,
> > but very infrequently.
>
> It works some of the time. One point: On first load the page
> cannot be green - you need one round to fetch the alt-svc
> header before you can actually go and use that.
>
> But then it would be helpful if the site showed how it comes
> to the conclusion of a color - it seems I'm getting a lot of
> red in spite of obviously using tor. (Looks like it is relying
> on cloudflare's judgement via IPCOUNTRY.)
>
> Once yellow after a 'new circuit' the reload gives a green page.

Right, it doesn't look like https://perfectoid.space/test.php is
consistently setting `alt-svc` for me.

Even when it does, it doesn't *seem* that TBB (8.5a1) isn't going over
.onion there for me? Never see that page turn green, even after a
yellow page. Maybe some issue with that site itself and/or the
particularly complex/long alt-svc that CF is generating? ("alt-svc:
h2="cflarexljc3rw355ysrkrzwapozws6nre6xsy3n4yrj7taye3uiby3ad.onion:443";
ma=86400; 
persist=1,h2="cflarenuttlfuyn7imozr4atzvfbiw3ezgbdjdldmdx7srterayaozid.onion:443";
ma=86400; 
persist=1,h2="cflares35lvdlczhy3r6qbza5jjxbcplzvdveabhf7bsp7y4nzmn67yd.onion:443";
ma=86400; 
persist=1,h2="cflareusni3s7vwhq2f7gc4opsik7aa4t2ajedhzr42ez6uajaywh3qd.onion:443";
ma=86400; 
persist=1,h2="cflareki4v3lh674hq55k3n7xd4ibkwx3pnw67rr3gkpsonjmxbktxyd.onion:443";
ma=86400; 
persist=1,h2="cflarejlah424meosswvaeqzb54rtdetr4xva6mq2bm2hfcx5isaglid.onion:443";
ma=86400; 
persist=1,h2="cflaresuje2rb7w2u3w43pn4luxdi6o7oatv6r2zrfb5xvsugj35d2qd.onion:443";
ma=86400; 
persist=1,h2="cflareer7qekzp3zeyqvcfktxfrmncse4ilc7trbf6bp6yzdabxuload.onion:443";
ma=86400; 
persist=1,h2="cflareub6dtu7nvs3kqmoigcjdwap2azrkx5zohb2yk7gqjkwoyotwqd.onion:443";
ma=86400; 
persist=1,h2="cflare2nge4h4yqr3574crrd7k66lil3torzbisz6uciyuzqc2h2ykyd.onion:443";
ma=86400; persist=1")

> Also bad: Firefox doesn't seem to show whether the alt-svc
> was used for a request.

Yeah, that's already an open issue that's on the roadmap AFAIK: [1]

Also, I don't remember where I saw this, but I believe there's some
hope to get a UX like [2]
(i.e., rather than auto-switch, the user should have explicit input on
it. This is related to some discussion about possibly using alt-svc in
an evil way to get a TBB user to a uniquely-generated onion domain and
do other things with that?)

In any case, I did a quick test on propublica.org *not* using
cloudflare's built-in onion service feature (since we're running our
own with our own EV cert anyway), and wanted to mention it here:

Set `alt-svc: h2="www.propub3r6espa33w.onion:443"; ma=300`, and looks
like TBB (8.5a1) actually did silently switch over to using the onion
for the connection. As above, there'd generally be no outward
indication to the user that this has happened, except I'd actually
configured the onion proxying bits (right now running nginx) to throw
the browser a 302 redirect to the onion domain if the HTTP Host header
isn't the onion domain. So, I'd inadvertently set this up to work
where the user actually does get fully redirected over to the onion.

(I've since taken off the alt-svc header, since that was just a quick
test and I'll need to figure out if that's behavior we want in lieu of
the TBB UI getting an explicit user interaction before moving to the
alt-svc. But figured that's worth mentioning for folks who _do_ want
to easily make a clearnet domain redir TBB to an onion domain.)

[1]: https://trac.torproject.org/projects/tor/ticket/27590
[2]: https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png

- --
Mike Tigas
https://mike.tig.as/
-BEGIN PGP SIGNATURE-
Comment: https://mike.tig.as/pgp/

iQIzBAEBCgAdFiEEGzfVMu3Uhpsce8OaFLh4upXaaEoFAluleSoACgkQFLh4upXa
aErVpQ//U36+ZpmgO4sKrc2NF13LFC0rdOxsPfNlEhXX7k/BUPt+VmbRlnOCwpTR
4go2T6i6q3xKnh2WQDsG0JIlmdvEOnMB5iFabvJn/4KOkh2k1TS8SMAwWvl3i2em
7vmomcduj+JasF3JS1TWJ+Wy1UHtnZ3k9snOCpQm2CnUgm9HTL7D2XM59EHtTHb3
PRw3F+m/1BroVV85KHcB4SJXZgMjnp+FMUrZ21bqyhtivmnREJDcktdjjWHiuuUf
sHPC/ytiH9WBDdgUA5Lg1RNajMgNsBFTc4VIit57pbRwUTwQMPxFbDQ2V3uaWbhm
o2ij82fqsYyNT25ROsiQDms2voerBbLw79xPEe5Nxg8F2MgAJ7f+i2eLJfqpAJ19
fsxYWv1WkL57eIN7PJRL8fmyQW8ocbnB3W+Sj58cA1+LXsQVedN0qKYAVa+nKg9Z
/Oa3UUbug/EddPSV02Amxy2VJNlu5Su3QPc3ggspVKiuvr4m9sziNlxo6X0i6cQJ
9F7u3Fu64ffyGuVFEsgsxTc/Q8F+ciK0o7Ds2gS24OjqNFKdTWHuC/AAZpeQqVW8
YAoGmnWdfl/2Q+swzXdUIbRKeHkqTjST4YAUB18O0KzIu6JLgVQo14sD8kzhnL2X
jv1iUpeGyyeXwxHUuHUWImbzWnm85RLCNv3x7eQ79WjSgjbNcI+ItwQBEwoAHRYh

[tor-talk] Tor 0.3.5.2-alpha is released

2018-09-21 Thread Nick Mathewson
Hello!

There's a new alpha Tor release! Because it's an alpha, you should
only run it if you're ready to find more bugs than usual, and report
them on trac.torproject.org.

The source code is available from the usual place on
www.torproject.org; if you build Tor from source, why not give it a
try? And if you don't build Tor from source, packages should be ready
over the coming days, with a Tor Browser alpha release very soon.

Here's what's new:

Changes in version 0.3.5.2-alpha - 2018-09-21
  Tor 0.3.5.2-alpha fixes several bugs in 0.3.5.1-alpha, including one
  that made Tor think it had run out of sockets. Anybody running a relay
  or an onion service on 0.3.5.1-alpha should upgrade.

  o Major bugfixes (relay bandwidth statistics):
- When we close relayed circuits, report the data in the circuit
  queues as being written in our relay bandwidth stats. This
  mitigates guard discovery and other attacks that close circuits
  for the explicit purpose of noticing this discrepancy in
  statistics. Fixes bug 23512; bugfix on 0.0.8pre3.

  o Major bugfixes (socket accounting):
- In our socket accounting code, count a socket as closed even when
  it is closed indirectly by the TLS layer. Previously, we would
  count these sockets as still in use, and incorrectly believe that
  we had run out of sockets. Fixes bug 27795; bugfix
  on 0.3.5.1-alpha.

  o Minor bugfixes (32-bit OSX and iOS, timing):
- Fix an integer overflow bug in our optimized 32-bit millisecond-
  difference algorithm for 32-bit Apple platforms. Previously, it
  would overflow when calculating the difference between two times
  more than 47 days apart. Fixes part of bug 27139; bugfix
  on 0.3.4.1-alpha.
- Improve the precision of our 32-bit millisecond difference
  algorithm for 32-bit Apple platforms. Fixes part of bug 27139;
  bugfix on 0.3.4.1-alpha.
- Relax the tolerance on the mainloop/update_time_jumps test when
  running on 32-bit Apple platforms. Fixes part of bug 27139; bugfix
  on 0.3.4.1-alpha.

  o Minor bugfixes (onion service v3):
- Close all SOCKS request (for the same .onion) if the newly fetched
  descriptor is unusable. Before that, we would close only the first
  one leaving the other hanging and let to time out by themselves.
  Fixes bug 27410; bugfix on 0.3.2.1-alpha.

  o Minor bugfixes (memory leak):
- Fix an unlikely memory leak when trying to read a private key from
  a ridiculously large file. Fixes bug 27764; bugfix on
  0.3.5.1-alpha. This is CID 1439488.

  o Minor bugfixes (NSS):
- Correctly detect failure to open a dummy TCP socket when stealing
  ownership of an fd from the NSS layer. Fixes bug 27782; bugfix
  on 0.3.5.1-alpha.

  o Minor bugfixes (rust):
- protover_all_supported() would attempt to allocate up to 16GB on
  some inputs, leading to a potential memory DoS. Fixes bug 27206;
  bugfix on 0.3.3.5-rc.

  o Minor bugfixes (testing):
- Revise the "conditionvar_timeout" test so that it succeeds even on
  heavily loaded systems where the test threads are not scheduled
  within 200 msec. Fixes bug 27073; bugfix on 0.2.6.3-alpha.

  o Code simplification and refactoring:
- Divide the routerlist.c and dirserv.c modules into smaller parts.
  Closes ticket 27799.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk


Re: [tor-talk] alt-svc supported by TBB

2018-09-21 Thread Andreas Krey
On Thu, 20 Sep 2018 12:38:56 +, Dave Warren wrote:
...
> >Using the test page at https://perfectoid.space/test.php I get either 
> >red or yellow exclusively, no amount of refreshing and/or changing 
> >circuits seems to get green which confirms my own testing on a site I 
> >operate that is participating in the beta.
> 
> I've been monkeying around a bit, and I can sometimes get this to work, 
> but very infrequently.

It works some of the time. One point: On first load the page
cannot be green - you need one round to fetch the alt-svc
header before you can actually go and use that.

But then it would be helpful if the site showed how it comes
to the conclusion of a color - it seems I'm getting a lot of
red in spite of obviously using tor. (Looks like it is relying
on cloudflare's judgement via IPCOUNTRY.)

Once yellow after a 'new circuit' the reload gives a green page.

Also bad: Firefox doesn't seem to show whether the alt-svc
was used for a request.

- Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk