Hi all,
I know the discussion on how best to support UDP applications over Tor has
dragged on for a long time, so I thought what better to do than to throw
another item to bikeshed into the discussion :)
On a more serious note I think running Tor over QUIC would provide several
advantages - both f
Moin,
I've posted my thoughts on a potential solution to this in GitLab:
https://e.as207960.net/w4bdyj/9xhwJKBpklMvCk1U
It'd be great to hear some of your views on this.
Q
--
Any statements contained in this email are personal to the author and are
not necessarily the
Is there a reason why this proposal extends the existing username/password
auth, instead of defining a new SOCKS5 authentication type? c.f.
https://e.as207960.net/w4bdyj/5dQ6fT3QLm2aTfUx
--
Any statements contained in this email are personal to the author and are
not ne
> The relays do not have a proper configuration, the standard nickname, etc.
Why not make an image that has an install wizard to set nicknames etc, and
keeps other settings up to date to best current practices?
Saying that you *must* have digested the inner workings of Tor first is a
little elitis
s (similar to DANE) ?
>
> Doing this would allow TOR service providers to not rely on certificate
> authorities, control their TLS certificates directly (self signed) and *do
> not need at all to renew it*.
>
> happy to chat further
> Raph
>
> --- Original Message ---
1:02:28PM +0100, Q Misell via tor-dev wrote:
> > Security Considerations:
> > The second layer descriptor is encrypted and MACed in a way that only
> a party
> > with access to the secret key of the hidden service could manipulate
> what is
> > published there.
Hi all,
I've spent some time working on ACME for Tor hidden services (you may have
seen discussion of this work on the onion-advisors mailing list). Full
details of the project are available at https://e.as207960.net/w4bdyj/AX8Ffqsd
Attached is my proposal for a change to the Tor Rendezvous Speci
