They could just operate a .onion to work around the whole thing. I think they already do?
scihub22266oqcxt.onion [1]
Good luck to ACS getting a .onion address seized... WHatever their legal injunction says.
Further, it can be integrated well within the current DNS infrastructure - granted, without the censorship/security protections offered by the natively decentralized nature of running a full node yourself. There's absolutely no reason a DNS server couldn't maintain a list of entries for .bit domains.
- You need to install a special browser
- The connection is going to be pretty slow
- Poor security due to no https; an exit node could inject bad stuff into downloaded PDFs
- Unreliability, as of right now sci-hub.tw is fine for me, but the .onion won't load at all. I've found other sites with both .onion and normal URLs to be similarly less reliable.
no, only tor
> - The connection is going to be pretty slow
not really
> - Poor security due to no https; an exit node could inject bad stuff into downloaded PDFs
there is no exit node for hidden services, the domain name is the public key, you get end-to-end crypto without https
> - Unreliability, as of right now sci-hub.tw is fine for me, but the .onion won't load at all. I've found other sites with both .onion and normal URLs to be similarly less reliable.
well, that depends ...
However the CA/B rules that allow certificates for .onion at all (it's not an Internet TLD and private names were outlawed years ago for good reason) require the certs to be validated to a named organisation. So if you aren't legal or insist on real anonymity then that's not going to work for you.
Could you explain what you mean by that?
The Tor hidden services actually being used (as evidenced by the .onion address given above being relatively short) are what's called "v2" hidden services. You will see other people saying, oh, this is all fixed, Tor hidden services are much safer now. And maybe v3 really is better, although their documentation sure has a lot of TODO / FIXME lines for a "finished" protocol version. But that doesn't matter so long as in reality it's v2 hidden services people are using, so that's the subject of my critique.
The first scary thing is a v2 hidden service's uniqueness depends upon 80-bits from a SHA-1 hash. Technically although SHA-1 is broken that's not a hole in this part on its own, but for comparison HTTPS is using SHA-256. 80-bits is also worryingly small. I clearly can't guess my way to an 80-bit second pre-image using what I know today, but if a further crumbling of SHA-1 gives me a boost maybe it's possible.
Next is the public key crypto used, this is 1024-bit RSA. I think you might technically be allowed to still do this in HTTPS, but I haven't seen it for years, everybody is either 2048 or 4096 bits, or they've moved to an elliptic curve that's stronger.
Now, I should be clear all this seemed pretty good when Tor was invented, and the new stuff in Hidden Services v3 is pretty good today. But cryptographic recommendations don't age very well, and Tor sat on this problem for far too long, if the above .onion name was a v3 name and I was seeing widespread reliance on v3 hidden services I'd have shut up.
Do you have some sort of citation or source on that? I would love to read about a reputable cryptographer taking apart Tor's network security (if only so we can improve it).
Look at https://blog.torproject.org/tors-fall-harvest-next-generatio... .
There was a conference also where they were explaining the new crypto but I can't find it right now.
EDIT: It was at defcon 25, here is the VOD: https://www.youtube.com/watch?v=Di7qAVidy1Y