Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tor Browser 11.0

blog.torproject.org

Post reply on HN
Print view View original

11–20 of 100 posts

Re: Tor Browser 11.0

#11

Post by sowithit »

superkuh wrote: post #7
the_other wrote: post #6

Earlier quoted context omitted.

I’ve not been following Tor protocol news. Is this good for users?

Yes, it probably is. Most people use tor because they just want a pseudoanonymous proxy to the clear web. For them the switch to v3 internally is important and probably required. For users of the .onion and onion services in general it's more split but I think most would say v2 going away is good. Soon it will be possible to spoof v2 domain prefixes at a feasible cost. I personally don't like that v2 is being shut of…

I am curious: why can't you redirect your community to a new v3 address? Deprecating v2 onion services has been publicly planned for several years now, and it is being done for security reasons (e.g. name collisions and weak crypto). Honestly, it would seem irresponsible of the Tor community not to stop supporting insecure versions of Tor.

Re: Tor Browser 11.0

#12

Post by fsflover »

superkuh wrote: post #7
the_other wrote: post #6

Earlier quoted context omitted.

I’ve not been following Tor protocol news. Is this good for users?

Yes, it probably is. Most people use tor because they just want a pseudoanonymous proxy to the clear web. For them the switch to v3 internally is important and probably required. For users of the .onion and onion services in general it's more split but I think most would say v2 going away is good. Soon it will be possible to spoof v2 domain prefixes at a feasible cost. I personally don't like that v2 is being shut of…

You may be interested in I2P then.

Re: Tor Browser 11.0

#13

Post by I_Byte »

superkuh wrote: post #7
the_other wrote: post #6

Earlier quoted context omitted.

I’ve not been following Tor protocol news. Is this good for users?

Yes, it probably is. Most people use tor because they just want a pseudoanonymous proxy to the clear web. For them the switch to v3 internally is important and probably required. For users of the .onion and onion services in general it's more split but I think most would say v2 going away is good. Soon it will be possible to spoof v2 domain prefixes at a feasible cost. I personally don't like that v2 is being shut of…

The depreciation of v2 addresses is the best course of action in this case. v2 addresses consist of the first 80 bits of the SHA-1 hash of the hidden services 1024 bit public RSA key. This sentence alone is enough to make any cryptographer cringe, it is really bad! (SHA-1 has been shown to be broken and it is suspected that 1024 bit RSA can be cracked by any determined well funded state actor)

Also, Tor Project has had v2 address depreciation on it's roadmap for 2 years now, they have given hidden service operators plenty of time to prime their community for the v2 --> v3 switch. This gradual change is way better than scrambling to depreciate v2 addresses in response to some state actor publicly breaking the RSA keys of v2 hidden services.

> I thought I owned my tor domain

You may now, but if v2 is kept around soon you won't be the only one with the domains private key.

Re: Tor Browser 11.0

#14

Post by 0des »

helios_invictus wrote: post #8
the_other wrote: post #6

Earlier quoted context omitted.

I’ve not been following Tor protocol news. Is this good for users?

Yes, but like IPV4 to IPV6 transition it's work.

It's most like going from https to https2 (whatever that may be) in that it changes the fundamental systems beneath it resulting in having stronger keys, longer keys, composed with different tech.

Re: Tor Browser 11.0

#15

Post by 0des »

helios_invictus wrote: post #8
the_other wrote: post #6

Earlier quoted context omitted.

I’ve not been following Tor protocol news. Is this good for users?

Yes, but like IPV4 to IPV6 transition it's work.

It's most like going from http to https in that it changes the fundamental systems beneath it resulting in having stronger keys, longer keys, composed with different tech. You notice the new onion addresses are much longer, and created differently, this is that change.

Re: Tor Browser 11.0

#16

Post by wolverine876 »

zamadatix wrote: post #10
wolverine876 wrote: post #9

I've wondered about the fact that (AFAIK) Tor routes only TCP: 1. Is that (still) correct? 2. Can't web pages include non-TCP traffic, and if so, is it routed via Tor? For example, doesn't some some streaming media use UDP? 3. QUIC doesn't use TCP (deliberately, I think). Won't that affect Tor's long-term viability if everyone eventually moves to QUIC?

1. For now 2. That kind of traffic mostly died out with plugins like Flash, streaming media today is usually encapsulated in small frequent chunks over the same https channels as the rest of the page are delivered as that's what's available in JS/native. WebRTC reintroduced some UDP stuff and can be used for streaming but is still mostly used for peer to peer calls. 3. https://gitweb.torproject.org/tor-browser-spec.g…

Thank you!

2. So there is some non-TCP traffic. What happens when you load that page in Tor Browser, for example? Does it leak back to your clear Internet connection? Is it simply dropped? This seems like a critical issue.

3. Thanks. Do you know when that was written? To save others clicking the link and finding the applicable section, I'll paste it below. Designing and building your own protocol for Internet transport, compatible with the entire net and performing competitively enough to be usable, sounds like quite a project for a small organization. Note that Google didn't do that; they used UDP for QUIC.

7 Tor Network Compatibility Concerns

Our final area of concern is continued compatibility of the Tor network with future versions of the HTTP proto- col. It is our understanding that there is a desire for future versions of HTTP to move to a UDP transport layer so that reliability, congestion control, and client mobility will be more directly under control of the client user agent.

At present, the Tor Network is only capable of carrying TCP traffic. While it will be possible to support the transit of UDP datagrams using our existing TCP overlay network without significant anonymity risks within a year’s time or sooner, it is unlikely that this level of support will be sufficient to warrant the use of a finely-tuned UDP version of HTTP rather than a TCP variant.

Long term, our goal is to transition the entire Tor network to our own datagram protocol with custom con- gestion and flow control to better support both native datagram transport and end-to-end flow control. However, additional research is still needed to examine the anonymity implications associated with this transition[12]. Our present estimate is that a full network transition to UDP is at least five years away.

We are also concerned that even after a full network transition to a datagram transport, it is likely that the congestion, flow, and reliability control of a UDP version of HTTP may still end up performing poorly over higher-latency overlay networks such as ours.

For these reasons, we are especially interested in ensuring that overlay networks are taken into account in the design of any UDP-based future versions of HTTP, and also prefer to retain the ability to use future HTTP versions over TCP, should the UDP implementations prove sub-optimal for our use case.

Re: Tor Browser 11.0

#17

Post by georgyo »

wolverine876 wrote: post #9

I've wondered about the fact that (AFAIK) Tor routes only TCP: 1. Is that (still) correct? 2. Can't web pages include non-TCP traffic, and if so, is it routed via Tor? For example, doesn't some some streaming media use UDP? 3. QUIC doesn't use TCP (deliberately, I think). Won't that affect Tor's long-term viability if everyone eventually moves to QUIC?

QUIC and HTTP3 are great technologies, but they are never likely to become the only protocol a service supports.

For one thing, convection to a website via one of those protocols first, and then a header informs the client that it can reconnect via QUIC/HTTP3. IE they have to have a working http 1 or 2 webserver first.

UDP is disallowed in many many places, and many ISPs treat UDP as hostile and rate limit it.

In the places it works, it provides some benefits. But we're unlikely to see it take over as the sole protocol any time soon.

Re: Tor Browser 11.0

#18

Post by wolverine876 »

georgyo wrote: post #17
wolverine876 wrote: post #9

I've wondered about the fact that (AFAIK) Tor routes only TCP: 1. Is that (still) correct? 2. Can't web pages include non-TCP traffic, and if so, is it routed via Tor? For example, doesn't some some streaming media use UDP? 3. QUIC doesn't use TCP (deliberately, I think). Won't that affect Tor's long-term viability if everyone eventually moves to QUIC?

QUIC and HTTP3 are great technologies, but they are never likely to become the only protocol a service supports. For one thing, convection to a website via one of those protocols first, and then a header informs the client that it can reconnect via QUIC/HTTP3. IE they have to have a working http 1 or 2 webserver first. UDP is disallowed in many many places, and many ISPs treat UDP as hostile and rate limit it. In the…

> we're unlikely to see it [QUIC] take over as the sole protocol any time soon

Agreed, but I'm not talking about soon. I mean the long term. Even FTP has been deprecated.

Re: Tor Browser 11.0

#19

Post by georgyo »

helios_invictus wrote: post #8
the_other wrote: post #6

Earlier quoted context omitted.

I’ve not been following Tor protocol news. Is this good for users?

Yes, but like IPV4 to IPV6 transition it's work.

Unlike IPv4 IPv6, there isn't an authority name service to advertise both connectable addresses. This makes discovery for the end user an explicit action.

If they cannot connect on V2, the method to discover v3 is almost definitely out of band and potentially in the prone to hijacking.

Re: Tor Browser 11.0

#20

Post by georgyo »

wolverine876 wrote: post #18
georgyo wrote: post #17

Earlier quoted context omitted.

QUIC and HTTP3 are great technologies, but they are never likely to become the only protocol a service supports. For one thing, convection to a website via one of those protocols first, and then a header informs the client that it can reconnect via QUIC/HTTP3. IE they have to have a working http 1 or 2 webserver first. UDP is disallowed in many many places, and many ISPs treat UDP as hostile and rate limit it. In the…

> we're unlikely to see it [QUIC] take over as the sole protocol any time soon Agreed, but I'm not talking about soon. I mean the long term. Even FTP has been deprecated.

I think when that starts to become a reality solutions will be discovered.

But since it is provably a non-issue today because it requires upgrading from TCP, it's going to be low priority.

Post reply on HN