5 ms·

I'm a fan of tor and the work they do, but doesn't this sound like security through obscurity? Anyone with the address can upload files without logging in. I k

by berbec 8y ago

I'm a fan of tor and the work they do, but doesn't this sound like security through obscurity? Anyone with the address can upload files without logging in. I know Onion addresses are huge and the chance of someone scanning to upload is tiny, but I remember saying the same thing about IPv4. "There's 256^4 addresses, of course I can run an unsecured FTP. What could go wrong?" I'd like to see some simple one-time-use password option. It doesn't even have to be enabled by default, just having it there would be a big step. HTTPS would be great, but I understand the difficulty of that hurdle. (If Let's Encrypt is out there - .onion isn't a dirty word!)

epoch_100 8y ago
For what it's worth, there is some degree of password protection: the OnionShare links include a slug that must be included in order for files to be shared. Quoting the article, > By default, OnionShare addresses look http://[tor-address].onion/[slug] http://[tor-address].onion/[slug], where the slug is two random words out of a list of words 7,776 words (technically, this is a 2-word diceware passphrase). > The idea is that if an attacker could figure out the tor-address part of the address, they still can't download the files you're sharing, or upload files to your computer, without first knowing the slug. The slug is, essentially, a password.
godelski 8y ago
> I'd like to see some simple one-time-use password option. I also agree with this. But I think the "delete once files are downloaded" kinda fulfills this. It does become insecure if someone else accesses it first, but then you know that someone else downloaded the data, right? For the multiple sharing I think a password would be a really nice feature. You could have that done on the user side, but a good password implementation would be awesome.
freedomben 8y ago
This is no more "security through obscurity" than say Amazon S3 signed URLs or SSH keys. They are long enough that your odds of guessing it correctly are way small. Is it possible? Sure, but so would be guessing somebody's SSH private key. This is why I suspect they emphasized sending the URL through a secure medium (since you are basically sharing a password): > So long as you share the unguessable web address in a secure way (like pasting it in an encrypted messaging app), no one but you and the person you're sharing with can access your files. And also why they feel comfortable describing the web address as "unguessable" > I'd like to see some simple one-time-use password option. That sounds like a nice feature, although I wonder how practical it would be. I often have to refresh web pages in Tor due to timeouts and stuff. If you burned your one time password and the connection timed out, you're SOL without the person running the server issuing you a new one. A good idea tho for people willing to make that usability tradeoff.
agumonkey 8y ago
I wonder if scrambled distributed chunks over torrent would be useful. Btw who works on tor replacement or improvement ?
- lapinot 8y ago
  Related work; on the deniable side: shadowsocks, a proxy designed to look like https traffic, wireguard may fulfill the same kind of goal (using generic session protocols like the noise framework might help deniability); on the generic p2p internet/web: gnunet (large project, quite experimental, has naming, routing/transport, some application protocols).
  - agumonkey 8y ago
    many thanks
lapinot 8y ago
Just to clarify, HTTPS would not be of any use if the sole verification you make is technical (eg like letsencrypt which verifies that you indeed control the endpoint, vs say <commercial CA> that may verify IRL that you are the social entity you say you are). tldr: if you trust the onion address to be correct, the connection is already end-to-end encrypted to the only person that generated and thus controls the endpoint. I didn't look into onion addresses in some time so correct me if i'm wrong, but basically the address is a certificate: a locator and a key (both being the same thing but still). Links are authenticating by default, as if you bundled a letsencrypt certificate in the url. Some keywords to explore further: cjdns (same thing on osi level 3), capability-based security (tying an name [in the sense of URN] and a key), content-based addressing (can be seen as a variant when content is static, in tor the name points to a channel and not a blob so the content is the key).
belorn 8y ago
From a security perspective, if I give a person a know https url and a password, it is indistinguishable from a know https url with the password appended in the path. There is even a standard where you can write https://username:password@example.com/ https://username:password@example.com/ Any distinguishable security property will have to come from elsewhere, such as the web server detecting a brute force scan and blocking the request. Tor can't do this so it has to rely on the address length alone, which now can be 56 characters of A-Z and numbers 2-7. I do not know how plausible it would be to scan the whole key space, but I suspect the tor project considered this when they increase the key size with version 3. In comparison scanning the whole IPv4 network takes around 45m for the zmap project. Let's Encrypt developers have stated interest in .onion, see: https://community.letsencrypt.org/t/if-when-will-le-support-onion-addresses/341/81 https://community.letsencrypt.org/t/if-when-will-le-support-... The additional considerations in regard to tor is that all traffic is already end-to-end encrypted with identity being served through the address. In regard to https there isn't much left, beyond enabling standards like http2 which explicitly require https and browser security features which are only enabled when visiting a https website.
lohszvu 8y ago
Onions broadcast themselves to the directory to they can be accessed

by berbec 8y ago

epoch_100 8y ago

For what it's worth, there is some degree of password protection: the OnionShare links include a slug that must be included in order for files to be shared. Quoting the article, > By default, OnionShare addresses look http://[tor-address].onion/[slug] http://[tor-address].onion/[slug], where the slug is two random words out of a list of words 7,776 words (technically, this is a 2-word diceware passphrase). > The idea is that if an attacker could figure out the tor-address part of the address, they still can't download the files you're sharing, or upload files to your computer, without first knowing the slug. The slug is, essentially, a password.

godelski 8y ago

> I'd like to see some simple one-time-use password option. I also agree with this. But I think the "delete once files are downloaded" kinda fulfills this. It does become insecure if someone else accesses it first, but then you know that someone else downloaded the data, right? For the multiple sharing I think a password would be a really nice feature. You could have that done on the user side, but a good password implementation would be awesome.

freedomben 8y ago

This is no more "security through obscurity" than say Amazon S3 signed URLs or SSH keys. They are long enough that your odds of guessing it correctly are way small. Is it possible? Sure, but so would be guessing somebody's SSH private key. This is why I suspect they emphasized sending the URL through a secure medium (since you are basically sharing a password): > So long as you share the unguessable web address in a secure way (like pasting it in an encrypted messaging app), no one but you and the person you're sharing with can access your files. And also why they feel comfortable describing the web address as "unguessable" > I'd like to see some simple one-time-use password option. That sounds like a nice feature, although I wonder how practical it would be. I often have to refresh web pages in Tor due to timeouts and stuff. If you burned your one time password and the connection timed out, you're SOL without the person running the server issuing you a new one. A good idea tho for people willing to make that usability tradeoff.

agumonkey 8y ago

I wonder if scrambled distributed chunks over torrent would be useful. Btw who works on tor replacement or improvement ?

lapinot 8y ago
Related work; on the deniable side: shadowsocks, a proxy designed to look like https traffic, wireguard may fulfill the same kind of goal (using generic session protocols like the noise framework might help deniability); on the generic p2p internet/web: gnunet (large project, quite experimental, has naming, routing/transport, some application protocols).
- agumonkey 8y ago
  many thanks

lapinot 8y ago

Just to clarify, HTTPS would not be of any use if the sole verification you make is technical (eg like letsencrypt which verifies that you indeed control the endpoint, vs say <commercial CA> that may verify IRL that you are the social entity you say you are). tldr: if you trust the onion address to be correct, the connection is already end-to-end encrypted to the only person that generated and thus controls the endpoint. I didn't look into onion addresses in some time so correct me if i'm wrong, but basically the address is a certificate: a locator and a key (both being the same thing but still). Links are authenticating by default, as if you bundled a letsencrypt certificate in the url. Some keywords to explore further: cjdns (same thing on osi level 3), capability-based security (tying an name [in the sense of URN] and a key), content-based addressing (can be seen as a variant when content is static, in tor the name points to a channel and not a blob so the content is the key).

belorn 8y ago

From a security perspective, if I give a person a know https url and a password, it is indistinguishable from a know https url with the password appended in the path. There is even a standard where you can write https://username:password@example.com/ https://username:password@example.com/ Any distinguishable security property will have to come from elsewhere, such as the web server detecting a brute force scan and blocking the request. Tor can't do this so it has to rely on the address length alone, which now can be 56 characters of A-Z and numbers 2-7. I do not know how plausible it would be to scan the whole key space, but I suspect the tor project considered this when they increase the key size with version 3. In comparison scanning the whole IPv4 network takes around 45m for the zmap project. Let's Encrypt developers have stated interest in .onion, see: https://community.letsencrypt.org/t/if-when-will-le-support-onion-addresses/341/81 https://community.letsencrypt.org/t/if-when-will-le-support-... The additional considerations in regard to tor is that all traffic is already end-to-end encrypted with identity being served through the address. In regard to https there isn't much left, beyond enabling standards like http2 which explicitly require https and browser security features which are only enabled when visiting a https website.

lohszvu 8y ago

Onions broadcast themselves to the directory to they can be accessed