191–200 of 205 posts
This may not be the whole solution but it is a step in the right direction. Kudos to NYT for attention to this subset of readers.
People wanting to access NYT site via Tor, can just navigate to https://www.nytimes.com/ and it'll be significantly faster than the .onion equivalent.
This may not be the whole solution but it is a step in the right direction. Kudos to NYT for attention to this subset of readers.
Why is this a step in the right direction? Having a .onion service provides essentially zero benefit without a hidden backend. People wanting to access NYT site via Tor, can just navigate to https://www.nytimes.com/ and it'll be significantly faster than the .onion equivalent.
This isn't true, exits are currently in short supply. And onion services don't use exits, so it will result in a faster speed, especially since they may have made it as a single onion service[1].
[1] : https://web.archive.org/web/20161219230314/https://blog.torp...
Earlier quoted context omitted.
> //edit: if you want extra security. Launch TOR from a remote desktop. And I am not talking about the ones you buy from known VPN providers like NordicVPN or amazon web services. No, if you want extra security use Qubes OS with Whonix (it comes with it by default) for isolating the Tor process in a single VM and the browser in another - thereby prohibiting any leaks, unless an adversary has a VM escape RCE.
what about Tails?
Earlier quoted context omitted.
Don't forget to restart your ypserver! Also, never put this line in /etc/netgroup then rwall to it: universal (,,) http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8702.mm....
That was a fun read. Thanks for the link. On a somewhat related topic, I worry a lot about things on the internet disappearing, most often simply due to neglect (domain expiry, companies being bought, et c.) I try to save everything I can that I find interesting, in fear of it never being available again. That said, it makes me very happy to see emails from 1987 archived online--so happy that I've even saved a copy.
And Risks Digest: http://catless.ncl.ac.uk/Risks/4.73.html#subj10.1
I was one of the 743 people who received his rwall and immediately send him a message (which I've since lost) flaming about the evils of Sun RPC (and promising a longer flame). I saved his reply and some old email about it from the hackers_guild and tcp-ip mailing lists.
IIRC, the flame probably would have touched on the fact that among Sun RPC services, rcp.rwalld was hardly the worst offender: Sun's NFS rpc.mountd demon trusted the client's word on what its hostname is (it was passed from client to server as a parameter to the mount RPC call -- the server didn't check the ip address!), in order to authenticate the client's permission to mount a directory!
That's right, you actually could mount any NFS directory by going "hostname ; mount server:/directory /mnt ; hostname ". And you could usually use the equivalent of "tftp server:/etc/exports /tmp/server_exports" to discover a trusted hostname to use, because Suns were set up like that by default, out of the box!
Date: Tue, 31 Mar 87 12:02:53 PST From: jkh%violet.Berkeley.EDU@berkeley.edu (Jordan K. Hubbard) To: don@tumtum.cs.umd.edu Subject: re: flame flame flame
Thanks, you were nicer than most.. Here's the stock letter I've been sending back to people:
Thank you, thank you..
Now if I can only figure out why a lowly machine in a basement somewhere can send broadcast messages to the entire world. Doesn't seem right somehow.
Yours for an annoying network.
Jordan
P.S. I was actually experimenting to see exactly now bad a crock RPC was. I'm beginning to get an idea. I look forward to your flame.
Jordan
----
Jordan's rwall scribbled all over Dennis Perry's Interleaf windows (who Jordan incorrectly referred to as the Inspector General of the ARPAnet in the Pentagon, and who was "absolutely livid" and threatened to cut off UCB's ARPANET access). Things were pretty wide open back then, and Jordan's "little incident" really stirred up a hornet's nest!
There were some interesting followups from heavy duty dudes like Milo Medin and Dennis Perry on the h_g/tcp-ip mailing lists:
From: Milo S. Medin
Actually, Dennis Perry is the head of DARPA/IPTO, not a pencil pusher in the IG's office. IPTO is the part of DARPA that deals with all CS issues (including funding for ARPANET, BSD, MACH, SDINET, etc...). Calling him part of the IG's office on the TCP/IP list probably didn't win you any favors. Coincidentally I was at a meeting at the Pentagon last Thursday that Dennis was at, along with Mike Corrigan (the man at DoD/OSD responsible for all of DDN), and a couple other such types discussing Internet management issues, when your little incident came up. Dennis was absolutely livid, and I recall him saying something about shutting off UCB's PSN ports if this happened again. There were also reports about the DCA management types really putting on the heat about turning on Mailbridge filtering now and not after the buttergates are deployed. I don't know if Mike St. Johns and company can hold them off much longer. Sigh... Mike Corrigan mentioned that this was the sort of thing that gets networks shut off. You really pissed off the wrong people with this move!
Dennis also called up some VP at SUN and demanded this hole be patched in the next release. People generally pay attention to such people.
From: Jordan K. Hubbard
Well, I hope Sun patches the holes, Milo. I'm sorry that certain people chose to react as strongly as they did in our esteemed government offices, but I am glad that it raised enough fuss to possibly get the problem fixed. No data was destroyed, lost, or infiltrated, but some people got a whack on the side of the head for leaving the back door open. I'm not sure I can say that I'm all that sorry that this happened. rwall is certainly going to change on my machines, I can only hope that people concerned about being rwall'd over the net will tighten up their RPC. Those that don't care, should at least be aware of it.
From: Dennis G. Perry
Jordan, you are right in your assumptions that people will get annoyed that what happened was allowed to happen.
By the way, I am the program manager of the Arpanet in the Information Science and Technology Office of DARPA, located in Roslin (Arlington), not the Pentagon.
I would like suggestions as to what you, or anyone else, think should be done to prevent such occurances in the furture. There are many drastic choices one could make. Is there a reasonable one? Perhaps some one from Sun could volunteer what there action will be in light of this revelation. I certainly hope that the community can come up with a good solution, because I know that when the problem gets solved from the top the solutions will reflect their concerns.
Think about this situation and I think you will all agree that this is a serious problem that could cripple the Arpanet and anyother net that lets things like this happen without control.
dennis ———
From: Jordan K. Hubbard
Dennis,
Sorry about the mixup on your location and position within DARPA. I got the news of your call to Richard Olson second hand, and I guess details got muddled along the way. I think the best solution to this problem (and other problems of this nature) is to tighten up the receiving ends. Assuming that the network is basically hostile seems safer than assuming that it's benign when deciding which services to offer.
I don't know what Sun has in mind for Secure RPC, or whether they will move the release date for 4.0 (which presumably incorporates these features) closer, but I will be changing rwalld here at Berkeley to use a new YP database containing a list of "trusted" hosts. If it's possible to change RPC itself, without massive performance degradation, I may do that as well.
My primary concern is that people understand where and why unix/network security holes exist. I've gotten a few messages from people saying that they would consider it a bug if rwall didn't perform in this manner, and that hampering their ability to communicate with the rest of the network would be against the spirit of all it stands for. There is, of course, the opposite camp which feels that IMP's should only forward packets from hosts registered with the NIC. I think that either point of view has its pros and cons, but that it should be up to the users to make a choice. If they wish to expose themselves to potential annoyance in exchange for being able to, uh, communicate more freely, then so be it. If the opposite is true, then they can take appropriate action. At least an informed choice will have been made.
Yours for a secure, but usable, network.
From: Dennis G. Perry
Jordan, thanks for the note. I agree that we should discover and FIX holes found in the system. But at the same time, we don't want to have to shut the thing down until such a fix can be made. Misuse of the system get us all in a lot of trouble. The Arpanet has succeeded because of the self policing community. If this type of potential for disruption gets used by very many people, I guarentee that we all will not like the solution or fix proposed.
dennis ———
Earlier quoted context omitted.
Can you CNAME with onion domains? For example onion.nytimes.com CNAME nytimes3xbfgragh.onion Edit to clarify - more a technical pondering than a solution to anything
.onion addresses aren't resolved using the DNS system. So... no? I guess in theory a browser _could_ support something like that, but it'd be pretty unusual. I also think the idea of relying on DNS to resolve a hidden service would defeat a lot of the privacy and security guarantees associated with those services, so I don't think any browser serious about security would implement something like that.
Websites redirect all the time, there's 3 HTTP status codes for it.
Earlier quoted context omitted.
But can you easily get addresses that start with "nytimes" and end in words? (I'm genuinely curious btw)
I'd be inclined to go for something bit shorter for this, perhaps just "times", but yeah. Lets pretend we've got a $5000 budget. Quick back-of-the-envelope math shows that a 8xGTX1080¹ box will be able to generate ~3 onion addresses beginning with "nytimes" every second, we can afford 6.25 months of this. Instead of waiting a really long time, we'll rent multiple boxes and squeeze all that into one month. In that mon…
Earlier quoted context omitted.
I think it's more that he'd prefer that the media didn't cite "unverified" dossiers that they sourced from Buzzfeed [0], which were produced by a source with ties to the DNC [1][2]. [0]: https://www.nytimes.com/2017/01/23/opinion/why-buzzfeed-news... [1]: https://www.nytimes.com/2017/01/11/us/politics/donald-trump-... [2]: http://www.washingtontimes.com/news/2017/oct/24/dnc-clinton-...
> I'd agree here. There's no reason to discuss politics on HN when there are numerous other places to do so. HN is a forum about technology and the startup world, let's keep it about that.
The reason most political stories aren't a good fit here isn't that they aren't about tech or startups (both tech and startups overlap with politics quite a bit). It's because they inevitably lead to battles that destroy what HN is for. We can't be both, the same way a park can't be a war zone.
Earlier quoted context omitted.
.onion addresses aren't resolved using the DNS system. So... no? I guess in theory a browser _could_ support something like that, but it'd be pretty unusual. I also think the idea of relying on DNS to resolve a hidden service would defeat a lot of the privacy and security guarantees associated with those services, so I don't think any browser serious about security would implement something like that.
> guess in theory a browser _could_ support something like that, but it'd be pretty unusual. Websites redirect all the time, there's 3 HTTP status codes for it.
If you visit https://onion.nytimes.com/ and it sends you a 301 redirect to https://nytimes3xbfgragh.onion/ then yes, I'm pretty sure that'd work fine. However, if you perform a DNS lookup on `onion.nytimes.com` and receive in response a CNAME record pointing to `nytimes3xbfgragh.onion`, I seriously doubt the browser is going to respond to that by establishing a new Tor circuit to the named hidden service. Rather, it's most likely just going to do what every other DNS client does when it receives a CNAME record; it'll try to look up `nytimes3xbfgragh.onion` in the DNS. (And fail, because `.onion` is not a valid TLD in the regular DNS system.)
The NYT is so pro-establishment it is probably the last site on Earth that would have its domain taken away from them.
The Times has been blocked repeatedly, maybe even semi-permanently, in China. It gets blocked in other countries too, IIRC. In the U.S., the Times published Chelsea Manning's leaked State Dept documents, it broke the story on Hilary Clinton's email sever, it reported the Wikileaks' DNC emails for months up to the US presidential election, and now it aggressively goes after Trump. While it's imperfect, I don't see whi…
.onion is not for sites being blocked in China, you can just use tor and access the nytimes.com web site from there. .onion is for websites that get their domain confiscated by their domain providers or the feds, very unlikely to happen to the NYT. See what happened to sites such as the pirate bay or more recently the neo-nazi site dailystormer https://en.wikipedia.org/wiki/The_Daily_Stormer#Site_hosting...
Can someone explain... why?
From the article: > "Some readers choose to use Tor to access our journalism because they’re technically blocked from accessing our website; or because they worry about local network monitoring; or because they care about online privacy; or simply because that is the method that they prefer."