Hi!
Just an idea: What about announcing that your site is also available via onion-service by sending an x-onion HTTP response header on your HTTPS website?
For example: The clearweb site https://www.torproject.org/ could send a header like this: x-onion:http://examplefoobarbaz.onion/
Or in case you can actually provide a valid TLS certificate for your Onion: x-onion:https://examplefoobarbaz.onion/
Another idea would be to also provide the fingerprint of the to-be-expected TLS certificate. This could look like so:
x-onion:cert-sha256="1h89m/yelEy6l1poFiXZQbJ1s6BkrOquBl7Fd+0EOO0="; https://examplefoobarbaz.onion/ Similar to what is done with HPKP headers, but without pinning.
Follow up question: How could this be done with non-HTTP services? (XMPP, SMTP, etc.)
Best regards @MacLemon
I have little useful opinion to add to this right now, but there is already an existing draft for an "Alternate Service" header - which may be relevant or inspirational:
https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-09 https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-09
At scale it might be costly to issue a header to all browsers in order to advertise an alternate service to some small fraction of people whom are actually able to (or desire) to use it.
Perhaps only issuing the header to people who access from an exit node, might reduce that cost?
-a
On Feb 4, 2016, at 14:16, MacLemon tor@maclemon.at wrote:
Hi!
Just an idea: What about announcing that your site is also available via onion-service by sending an x-onion HTTP response header on your HTTPS website?
For example: The clearweb site https://www.torproject.org/ could send a header like this: x-onion:http://examplefoobarbaz.onion/
Or in case you can actually provide a valid TLS certificate for your Onion: x-onion:https://examplefoobarbaz.onion/
Another idea would be to also provide the fingerprint of the to-be-expected TLS certificate. This could look like so:
x-onion:cert-sha256="1h89m/yelEy6l1poFiXZQbJ1s6BkrOquBl7Fd+0EOO0="; https://examplefoobarbaz.onion/ Similar to what is done with HPKP headers, but without pinning.
Follow up question: How could this be done with non-HTTP services? (XMPP, SMTP, etc.)
Best regards @MacLemon _______________________________________________ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
On Thu, Feb 04, 2016 at 03:36:44PM +0000, Alec Muffett wrote:
Perhaps only issuing the header to people who access from an exit node, might reduce that cost?
Even so, and especially then, this sound like an easy way for someone operating a rogue exit node to get persistent MitM on non-HTTPS sites.
Martijn.
Alec Muffett:
I have little useful opinion to add to this right now, but there is already an existing draft for an "Alternate Service" header - which may be relevant or inspirational:
https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-09
At scale it might be costly to issue a header to all browsers in order to advertise an alternate service to some small fraction of people whom are actually able to (or desire) to use it.
Martijn Grooten:
On Thu, Feb 04, 2016 at 03:36:44PM +0000, Alec Muffett wrote:
Perhaps only issuing the header to people who access from an exit node, might reduce that cost?
Even so, and especially then, this sound like an easy way for someone operating a rogue exit node to get persistent MitM on non-HTTPS sites.
Could onion services be announced via ALPN maybe?
[Reply inline]
Am 06.02.2016 3:43 nachm. schrieb "Martijn Grooten" < martijn@lapsedordinary.net>:
On Thu, Feb 04, 2016 at 03:36:44PM +0000, Alec Muffett wrote:
Perhaps only issuing the header to people who access from an exit node,
might
reduce that cost?
Even so, and especially then, this sound like an easy way for someone operating a rogue exit node to get persistent MitM on non-HTTPS sites.
So accept this header just on https connections and all is well.
I thought of using DNS to advertise onion services via SRV records but that requires DNSsec, to protect against stripping/downgrade attacks.
Best regards
Mirco Bauer
Martijn.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQEcBAEBAgAGBQJWtgSPAAoJEI5dMs9dIv8ZijgH/jFDIGdwtmnRgMUmEwhxq/hA RO650YLi5MOvaL030bWURSQdMlA40bsCnJCrWKIUv0PdOe4Ml2NHG6Tb2Z7cGZ4c n3deflDpPrX7FD8HhI26ftrVkEv+1jOD7crfpCUJegijx8Q+YykR2IPVabZgaOZo vgi6mJN4LMqb7n5FVdyKOJ2JhowS+ss7xWZetrzpFhk5JUe6f/oYGfDtkUwfYhgx i5YnBACAjEF1cXVeu1vi1y9Yd3ILy3+YFDdpxl/ub8yHGx2/SQMYICBZpVIlhio3 0Oh7RWc6dOKIve7+61DVTnkZES9cHbNaQ97NOLMjKDZ7HJKvj/THsiHAy6m8vYc= =jZnh -----END PGP SIGNATURE-----
tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
On 7 February 2016 at 05:10, Mirco Bauer meebey@meebey.net wrote:
[Reply inline]
Am 06.02.2016 3:43 nachm. schrieb "Martijn Grooten" martijn@lapsedordinary.net:
On Thu, Feb 04, 2016 at 03:36:44PM +0000, Alec Muffett wrote:
Perhaps only issuing the header to people who access from an exit node, might reduce that cost?
Even so, and especially then, this sound like an easy way for someone operating a rogue exit node to get persistent MitM on non-HTTPS sites.
So accept this header just on https connections and all is well.
Agreed, this is how applying most security headers work (HSTS, HPKP). Instead of defining a new header why not use Alt-Srv? I'm not sure of it's status, but it was explicitly made for advertising other methods of contacting a service.
-tom
tor-onions@lists.torproject.org
-
Alec Muffett -
MacLemon -
Martijn Grooten -
Mirco Bauer -
ncl＠cock.li -
Tom Ritter