@resist_berlin_ @torproject Yes, awareness and education is a part of it. You can make TB prioritize .onion sites when it becomes aware of them, so only the initial request to a website should go to the regular website, then the user is redirected to the .onion and can continue their browsing 🙂
There is also an alternative feature which is the "alt-srv" HTTP standard, which allows the connections to be "silently upgraded to a .onion" (the address bar doesn't change in this case).
@thearabcynic @resist_berlin_ @torproject I don't think there is any state shared between the two sites on the client side for such validation to happen, but I think there is ongoing work to have x509 certificates validating Onions and vice versa.
I personally think the security guarantees from onions are stronger than those of the TLS/x509 world, but it is an interesting future, where those two worlds can meet, this work opens up for 🙂
@ahf Is there a (hidden) preference I need to activate to make Tor-Browser 9.5a11 show the purple badge?
Because I can't get it show up here with a page that already successfully does an opportunistic onion via alt-svc header.
HTTP response header shows correctly in curl(1).
@ahf The alt-svc was only mentioned to underline that I know this site has a working onion site.
I would only expect the purple banner to show up when an onion-location header is in fact available. Which it is.
Nope, doesn't show on your page as well.
Interestingly your's does auto redirect to the onion site though, but no purple banner.
Using 9.5a11 (based on Mozilla Firefox 68.7.0esr) (64-bit) on macOS.
@MacLemon Did you enable in the preferences that it should auto-redirect? If yes, I don't think the banner shows up when auto-redirection is in place. I can ask tomorrow how the feature is supposed to work *together* with alt-svc. I have no idea about the semantics there.
@ahf Yes, just experimented with that setting. Only auto-redirects when set to always. Now it also shows the purple-banner.
Might it be related to using a subdomain of the onion domain? like `foo.<domain>.onion` instead of the plain `<domain>.onion`?
I don't expect it to work *together* with alt-svc. Also doesn't change when removing the alt-svc header.
Leaving the only differences being me using a subdomain of the onion and mine being a single hop onion.
@MacLemon Hm, interesting. I don't think the fact that you are a single hop onion should matter here, since that is not known to the browser. Your header is: `Onion-Location: http://foo.<public key>.onion/` ?
@ahf I wouldn't expect the single hop onion to make a difference either. It's just the only things I could identify being differences.
I'm using `Onion-Location: http://domain.tld.<public_key>.onion/` to be exact.
I wouldn't think it *should* make a difference, since that's a totally valid and working onion address. Unless there's restrictions on that in place.
Haven't found any documentation on the header yet.
@MacLemon It's still only in an Alpha release, so I doubt there are much documentation yet. Heck, I think in theory the semantics could even change before the final release. I just enabled it to experiment with the feature now that the Alpha release was out.
I'm gonna try tomorrow to change my site to use a subdomain and see if I can reproduce the behavior you're reporting.
@ahf I can perfectly reproduce it now. It's clearly the subdomain use.
@MacLemon I have passed on the description of the problem to one of our browser engineers! Thanks for debugging this 🙂
@ahf If you created a ticket, I'm happy to add to it if need be.
@MacLemon I'll wait and see what he says on IRC tomorrow 😃
@ahf Thanks, just read through it and certainly meeting all the criteria. I guess I've debugged it and it's complicated. Tor-Browser's behaviour is technically correct, but very confusing to the user.
I'll write that up and add to the ticket.
@MacLemon Sounds good. Thank you!
@MacLemon Hey, did you ever get around having a look at https://trac.torproject.org/projects/tor/ticket/34118 ? We are unsure if you managed to solve the issue or if there is an issue in the code in TB? We haven't been able to reproduce it.
@ahf Svc-alt is weird in behaviour, because Tor-Browser is unable to tell the user where it sent a request being it directly to the domain, or via the proxy.
It does though send subsequent requests after the first load of a page with Svc-Alt header to the onion domain via proxy, but with Host: and SNI Headers of the original domain.
It's completely transparent to the user, they have no way to tell what's actually going on. But you get HTTPS+h2 via Tor with your standard LE cert.
@MacLemon Yeah. The semantics of alt-srv (and a lot of the new HTTP2 behaviours from IETF) are often "odd". It took me a while to wrap my head around it.
I personally see alt-svc as a positive feature since it opportunistically can remove load from the scarce exit node resource in the network. I think it lacks the educational aspect of letting the user know they are using onions, which may or may not matter at all.
@ahf To speed things up for Tor users and save on Exit bandwidth is the exact reason we use that.
At least having the info available where a request was sent somewhere in the browser console would make debugging this a *LOT* easier though. :-)
I just temporarily remove the subdomain part and now the purple banner *does* show up. So it certainly is a limitation there. Don't know it that is intentional or not.
If yes, we'd need to rebuild all our hosts to use separate onion hostnames.
@MacLemon I remember when I was trying out alt-srv when CF announced it for their .onion support, and the lack of debugging abilities inside of Firefox made it very hard to figure out if Firefox was even using the alt-svc or not.
I have no idea if they have added support for alt-svc in the web inspector in the normal Firefox release cycle (Tor is on ESR), but I hope one day the web inspector will be made more aware of the feature.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!