Hi Shawn!
On Mon, 13 Nov 2023 at 15:54, Shawn Webb
wrote:
> I agree that infoleaks, especially of .onion DNS requests, is
> problematic. However, I disagree that prohibiting it in broadly
> monocultured libraries (libcurl) is an advisable approach.
>
If Curl is outright banning ".onion" at the
Hi! I'm one of the authors of RFC 7686.
Although myself and Appelbaum[1] are cited on it, the document is the
result of a huge amount of argument and input from many people (shout out
to Mark Nottingham most especially, whom I feel should have gotten an
author credit) on various IETF maillists, an
On Tue, 16 Jun 2020 at 12:15, meskio wrote:
> I'm wondering if it will make sense to use Onion-Location in V2 onion
> services
> to advertise the V3 onion. So existing known V2 services can use it to
> upgrade
> their users to V3.
>
> AFAIK right now tor-browser ignores the Onion-Location header
1) the best and proper way to redirect from site A to site B is to use
"Location:" and/or an appropriate 3xx code. It already works.
2) having an "h2o" ALPN for Alt-Svc would literally make things worse,
retard adoption, confuse implementations, break almost all of my future
plans for onionificati
On 27 April 2018 at 19:48, Damian Johnson wrote:
> > OnionBalance requires STEM support for V3
>
> Hi Alec, would you mind clarifying what you need from Stem? As far as
> I'm aware Stem supports v3 onion service creation...
> ...
> I'm unaware of the ball being in my court on any v3 Onion Service
It's not just about getting the protocol stack right, but also the
ancillary software environment; people keep asking me for "V3 support in
EOTK" and my stock response is this:
BEGIN
OnionBalance requires STEM support for V3, before it can be updated
(possibly a substantial rewrite will
On 31 Dec 2017 12:22, "teor" wrote:
Are you aware that there's already a checksum in v3 onion
service addresses?
No I was not*, that's great!
"The onion address of a hidden service includes its identity public key,
a
version field and a basic checksum."
It would be great to get the huma
On 31 December 2017 at 11:46, Alec Muffett wrote:
>
> ...so that any UX component which wants to help the user can highlight (in
> red? or bold?) where the problem is, picking out a chunk of 12 characters
> which contain the typo:
>https://www4acth47i6kxnvkewtm6
On 31 December 2017 at 02:46, nullius wrote:
> For the foregoing reasons, I will propose that subdomain data, if any, be
> kept separate from the Bech32 coding. It may be either kept in a separate
> string, or somehow affixed with a special delimiter either before or after
> the Bech32 represent
Thanks! That's very interesting! TIL :-)
What would you propose to do with subdomains, like
www.facebookcorewwwi.onion? Or is that outside the scope of your proposal?
- alec
On 31 Dec 2017 00:53, "nullius" wrote:
> # Synopsis
>
> The Bech32 standard for error-correcting base32 strings was dev
I think it's important to point out that a Tor client is never
guaranteed to hold a *definitive* consensus.
That's why I say "(mostly) definitive" in my text - my feeling is that a
locally-held copy of the consensus to be queried is going to be on average
of far higher quality, completeness, and
On 15 Nov 2017 12:18, "Iain R. Learmonth" wrote:
Is this not what TorDNSEL does?
https://www.torproject.org/projects/tordnsel.html.en
Hi Iain!
That certainly sounds like it will give you the answer! But although it
would give the right kind of answer, it is not what I am asking for.
At the sc
Apologies, I am waiting for a train and don't have much bandwidth, so I
will be brief:
1) There is no point in issuing to anyone unless
they are accessing via an exit node.
2) It's inefficient to issue the header upon every web access by every
person in the world; when the header is only releva
On 14 October 2017 at 19:43, dawuud wrote:
>
> Plaintext communications intermediaries like tor2web violate the end
> to end principle and the principle of least authority. If we as the
> Tor community are committed to human rights then it follows we would
> abolish terrible things like tor2web or
On 27 September 2017 at 22:25, Ben Laurie wrote:
> Your survey is obviously massively biased towards users of Tor. It
> would be really interesting to know what non-users think.
Yes and no; I can totally see that from a user-experience perspective, it
would be exciting research to rock up to s
Interesting.
Do we have a consensus on the length of the "run them in parallel" /
cutover period from old-to-new?
I would be inclined to keep older addresses around for up to 3 years before
trying to kill them entirely, because of such tor-adoption-curve concerns.
NB: this would still be massive
Also: just because it's HTTP/S running over a different network stack,
doesn't make it a new scheme.
Just because your dinner arrives on a different plate doesn't mean the
recipe has changed. :-)
On 14 Aug 2017 8:53 am, "Andreas Krey" wrote:
> On Sun, 13 Aug 2017 17:06:20 +, Ryan Carboni wr
On 8 April 2017 at 03:23, Yawning Angel wrote:
> On Fri, 7 Apr 2017 11:44:03 +0100
> Alec Muffett wrote:
> > If I was in charge, I would say that we risk overthinking this, and it
> > would be better to:
> >
> >- mandate use of fully DNS-compliant syntax, in
>
> > I suggest that we require all address suffixes to end with .onion;
> > other TLDs are not reserved like .onion is, and maybe we shouldn't
> > squat any we haven't squatted already.
>
> FWIW it's not at all clear to me that this is a concern that IETF or
> ICANN will care about.
Hi.
My name
On 5 April 2017 at 15:11, Ian Goldberg wrote:
> I believe the danger Alec was wanting to avoid was that someone (not the
> onion service owner) could take an existing onion address, bump the
> version number (which wouldn't change the vanity beginning of the
> address), and upload the very same d
Following the Layer-2 Addressing analogy means that Ian, here:
> If the daily descriptor uploaded to the point
>> Hash(onionaddr, dailyrand) contained Hash(onionaddr, dailyrand) *in* it
>> (and is signed by the master onion privkey, of course), then tor
>> could/should check that it reached that
On 3 April 2017 at 16:59, Ian Goldberg wrote:
> How about this, though: I know that Tor doesn't want to be in the business
> > of site reputation, but what if (eg) Protonmail offers a Onion "Safe
> > Browsing" extension some day, of known-bad Onions for malware reasons?
> That's a quite good mo
On 3 Apr 2017 3:48 p.m., "Ian Goldberg" wrote:
The other thing to remember is that didn't we already say that
facebookgbiyeqv3ebtjnlntwyvjoa2n7rvpnnaryd4a.onion
and
face-book-gbiy-eqv3-ebtj-nlnt-wyvj-oa2n-7rvp-nnar-yd4a.onion
will mean the same thing? So we're already past the "one (st)ring
On 3 April 2017 at 13:04, George Kadianakis wrote:
> I'm calling it weird because I'm not sure how an
> attacker can profit from being able to provide two addresses that
> correspond to the same key, but I can probably come up with a few
> scenarios if I think about it.
Hi George!
I'll agree i
>
> We could leave the version field outside the AONT, though, but commit to
> changing the paramaters of the AONT (in particular, the domain
> separation constant?) if we change the version number, so that an
> adversary changing the version number to "2" would just cause the client
> to throw an
Hi,
So: a bunch of us were discussing Prop224 Onion addresses, and their
UX-malleability.
Specifically: that there are small bit fields in the current Prop224 Onion
Address schema (eg: version, and other future structure?) which can be
tweaked or amended without otherwise changing the functionali
For the sake of documentation I thought I would share this here:
I have a (test) Hidden Service, running vanilla tor 0.2.6.10
The HS torrc is:
ControlPort 9051
DataDirectory /home/alecm/tor-dev/data
SafeLogging 0
Log info stdout
HiddenServiceDir /home/alecm/tor-dev/hs
HiddenServicePo
> On Nov 2, 2015, at 20:39, Paul Syverson wrote:
>
> On Mon, Nov 02, 2015 at 09:05:26PM +0200, George Kadianakis wrote:
>> Hello,
>>
>> as you might know, the IETF recently decided to formally recognize .onion
>> names
>> as special-use domain names [0].
>>
>> This means that normal browsers
> On Nov 6, 2015, at 4:56 PM, teor wrote:
> Do we need both single onion services (Proposal 252) and rendezvous single
> onion services?
I would say they are both desirable, and that we could/should have both.
RSOS is great for adoption, the rendezvous step enables NAT-punching and yet
lowers
> On Nov 6, 2015, at 4:16 PM, teor wrote:
> Hi all,
Hiya!
> Is there any reason an onion service would want to temporarily switch from
> 1-hop to 3-hop paths?
> Is it ok if we force operators to restart the tor instance when onion service
> path lengths change?
Well - as a user of RSOS, give
> On Oct 26, 2015, at 11:34, Alec Muffett wrote:
>> Of course. All the cases where you set up a hidden service
>> exactly because your host is behing a NAT.
>> Like the webcam raspi I'm just booting up.
>
> We run our tor daemons in a enclave network which can
> On Oct 1, 2015, at 06:15, Andreas Krey wrote:
>
>> Are there any use cases that:
>> * need NAT punching,
>> * don't need service location anonymity, and
>> * would benefit from lower latency?
>
> Of course. All the cases where you set up a hidden service
> exactly because your host is behing
> Let's use your idea of "if one IP fails and TTL expired then re-fetch".
> This could also make it "easier" to identify people connecting to
> Facebook. As your client guard, I see you do the fetch + IP/RP dance (3
> circuits in short period of time where two are killed). I wait 2 hours
> and then
i...@tvdw.eu wrote:
> Hi Alec,
Hi Tom! I love your proposal, BTW. :-)
> Most of what you said sounds right, and I agree that caching needs TTLs (not
> just here, all caches need to have them, always).
Thank you!
> However, you mention that one DC going down could cause a bad experience for
typo:
> alecm: and this persists for up to 24h, even though the outage was only 10
> minutes
Also, I neglected to observe that linear polling of A-E seeking a descriptor
suggests A will be hammered whilst J is nearly idle.
Some entropy in IP selection would be a good thing.
-a
g, or making client balance themself randomly could be also an idea
dgoulet: definitely there is some content here for tor-dev - I don't have a
good answer but it should definitely be addressed
alecm: proper random selection of IP would be beneficial for load-balancing;
not perfect, but
s likely to need to change? Or might there be a need to encode >
315 bits / 63 chars total?
-a
—
Alec Muffett
Security Infrastructure
Facebook Engineering
London
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev ma
r humanity finding
solutions to apparently high-friction technologies, but it also clearly hampers
broader inclusiveness, the latter arguably being one of Tor’s most important
goals:
http://mashable.com/2014/10/24/hacks-facebook-rooms/
<http://mashable.com/2014/10/24/hacks-facebook-rooms/>
>>
> I wonder if a better way forward is to focus on tools (e.g., a petname
> system in Tor Browser) to automate dealing with onion addresses rather
> than making them easier to deal with for humans.
I worked on implementing the X.500 Directory Project which had similar goals
for e-mail addresse
t Mechanical
> Turk).
Nicely volunteered, Ben! :-)
/me wonders how much ux-testing the “dotted quad” received…
-a :-)
—
Alec Muffett
Security Infrastructure
Facebook Engineering
London
signature.asc
Description: Message signed with OpenPGP using GPGMail
atisfied
and reasonably secure.
And the XXX can be checked by the browser and tell the user that they’ve
goofed-up cut/paste/typing-it-in. And then they bookmark it once it loads.
- alec
—
Alec Muffett
Security Infrastructure
Facebook Engineering
London
signature.asc
Description: Mess
—
Alec Muffett
Security Infrastructure
Facebook Engineering
London
> On Aug 8, 2015, at 2:05 PM, Roger Dingledine wrote:
>
> https://urldefense.proofpoint.com/v1/url?u=https://trac.torproject.org/projects/tor/ticket/15622&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=PKCvk5ihsZdnlobu
Gah, I am evidently having a bad day with e-mail, so I am going to send a typo
correction with this and then go do something else instead.
Corrections in caps, below.
—
Alec Muffett
Security Infrastructure
Facebook Engineering
London
> On Aug 8, 2015, at 2:14 PM, Alec Muffett wr
factors. :-)
- alec
—
Alec Muffett
Security Infrastructure
Facebook Engineering
London
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin
>
> On Aug 8, 2015, at 12:36 PM, Alec Muffett wrote:
>
> 9) appending a credit-card-like “you typed this properly” extra few
> characters checksum over the length might be helpful (10..15 bits?) - ideally
> this might help round-up the count of characters to a full field,
Hello All!
Details: https://www.facebook.com/facebookcorewwwi/posts/703469239759799
<https://www.facebook.com/facebookcorewwwi/posts/703469239759799>
Summary: new EV-style SSL certificate rolls out to facebookcorewwwi.onion next
week.
- alec
—
Alec Muffett
Security Infrastructure
Fa
46 matches
Mail list logo
