And they're using an Extended Validation certificate from DigiCert for it
CN = nytimes3xbfgragh.onion
OU = Technology
O = The New York Times Company
Object Identifier (2 5 4 15) = Private Organization
along with some other addresses
DNS Name: nytimes3xbfgragh.onion
DNS Name: graylady3jvrrxbe.onion
DNS Name: *.graylady3jvrrxbe.onion
DNS Name: *.dev.graylady3jvrrxbe.onion
DNS Name: *.stg.graylady3jvrrxbe.onion
DNS Name: *.nytimes3xbfgragh.onion
DNS Name: *.api.nytimes3xbfgragh.onion
DNS Name: *.api.dev.nytimes3xbfgragh.onion
DNS Name: *.api.stg.nytimes3xbfgragh.onion
DNS Name: *.blogs.nytimes3xbfgragh.onion
DNS Name: *.blogs.stg.nytimes3xbfgragh.onion
DNS Name: *.blogs5.stg.nytimes3xbfgragh.onion
DNS Name: *.dev.nytimes3xbfgragh.onion
DNS Name: *.dev.blogs.nytimes3xbfgragh.onion
DNS Name: *.newsdev.nytimes3xbfgragh.onion
DNS Name: *.prd.nytimes3xbfgragh.onion
DNS Name: *.sbx.nytimes3xbfgragh.onion
DNS Name: *.stg.nytimes3xbfgragh.onion
DNS Name: *.stg.blogs.nytimes3xbfgragh.onion
DNS Name: *.stg.newsdev.nytimes3xbfgragh.onion
DNS Name: www.bestsellers.nytimes3xbfgragh.onion
DNS Name: www.homedelivery.nytimes3xbfgragh.onion
Sometimes I wonder if it's a good idea to brute-force these kinds of "vanity" onion prefixes. Take a look at the addresses used in http://incoherency.co.uk/blog/stories/hidden-service-phishin... ; they brute-forced the same prefix with a different suffix. Would anyone really notice?
If they didn't use vanity names, then people would only remember the first/last few random characters and the phishing scheme could very well still work, just it'd be less readable for visitors. I don't think we can assume that if all the characters were random they would remember them all better.
I don't think people would remember them better if completely random. Rather, I think if they're completely random, people might correctly assume they can't, and remain appropriately skeptical; if they include a vanity prefix, people seem likely to remember the vanity prefix and somewhat less likely to pay attention to the rest.
If you're that easily phished, why are you using TOR at all?
You aren't being attentive enough for high risk activities. You lack proper verification channels, to confirm authenticity, which matters in this context. You lack the situational awareness to proceed safely.
Admit that you might not be cut out for what it takes to maintain a secure posture on the internet, if that's what gets you. Just stop pretending to try.
What we need is some way for the vast majority of the population who are not nearly as good at security as you are and never could be, to be able to access such sites securely.
Oh, I'd hazard a guess that the media is well-educated, and handily equipped with an agenda similar to advertisers and marketers employing dark patterns and pervasive analytics.
And I never claimed I was good at anything. But I did intend to point out that with advanced persistent threats in the mix, and nation state actors operating with effectively unlimited resources, failing to notice the difference between two vaguely similar nonces (in a situation where it matters) is going to get you hanged, depending on what you're trying to fly below radar.
.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.
Would it make any sense to use something like tor.nytimes.com to redirect to their hidden service on the other hand? To allow people to be sure they're hitting the correct endpoint on Tor. If you're on TOR you typically have access to the rest of the internet, at least depending on setup.
An HTTP redirect is a completely different thing from a CNAME record in the DNS.
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.)
It is a bit silly considering you can trivially brute onion addresses consisting entirely of words.
I just generated "omen coins car hoof.onion" right now, in a couple of seconds, with my laptop CPU. With a couple of GTX1080s you could easily find some much better .onions than the ones NYT chose.
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 month our servers will find approximately 44055283.1 onion addresses beginning with "nytimes".
At least with the wordlist² I use, without a prefix I discover approximately one "good" onion per 8 million random onions. Considering we've got a 7 character prefix for our 44 million onion candidates, so I'd expect a significantly better rate than just 1/8000000
So yeah, in a month you'd probably find at least 5 "better" onion addresses.
Extended Validation certificate is when a company go to a CA and provide a bunch of business documents and legal proof that they really own the company behind a name. Its not a technical aspect but human lawyer <-> human lawyer that establish a certificate. At the end if the validation is successful, the company get a technical signed document that in browsers shows up as a green lock and the name in green next to the URL.
> you now know that the website you want is actually who they say they are?
That's the idea. Of course, validation, while more thorough than for standard certs, still is not that reliable. My strong impression is that it could be fooled by anyone sufficiently motivated.
Not only that - in practice it's kind of meaningless, because if you were served a non-EV cert, you wouldn't notice. And there's usually other domains or subdomains that don't use the EV cert. It's mostly just a kind of token gesture by a business to claim they're more secure.
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.
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 <hostname known to be in server's /etc/exports> ; mount server:/directory /mnt ; hostname <previous host name>". 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 <medin@orion.arpa>
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 <jkh@violet.berkeley.edu>
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 <PERRY@vax.darpa.mil>
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 <jkh@violet.berkeley.edu>
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 <PERRY@vax.darpa.mil>
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.
Why do we think a lawyer would be less likely to be duped? If they are relying on physical paper and pen signatures...aren't those all incredibly easy to fake?
You get a green bar to know you're connecting to the NYT and the cert is issued for many additional addresses showing large coverage of their services and hinting at future use.
EV certs provide more than just encryption that a DV (domain validation) cert provides. DV just checks to make sure the domain is under control of whoever is asking for the cert.
EV ensures that the entity (person, corp, org, whatever) is in fact in control of the domain and is who they say they are.
Worth noting that a lot of the arguments in this article change when you're talking about Onion services.
Notably, Onion services tend to have URLs that are _very_ difficult for humans to remember (they're essentially just gibberish), and they're anonymous by default, meaning without an EV cert there's no easy way to check whether the service you're visiting is legitimate or not.
DV certs are also pretty useless for Onion services, since your connection is already encrypted and authenticated by Tor.
EV is mandatory for .onion HTTPS certificates - since onion hashes (the 'domain name') are even less meaningful as a form of identity than regular domains.
This is incorrect. Onion domain addresses already provide the same level of confidence as a DV certificate, because they are a public key of the server you are connecting to. There would be no additional value in issuing a DV certificate for an .onion domain.
Yes, but how do you know that you are actually connected to nytimes3xpfgragh.onion each time? DV lets you know that the onion site you connected to is the NYTimes, and not a privacy-attacking MITM site.
Did you notice that I changed the nytimes URL a tiny bit up there? nytimes3xbfgragh.onion is the real one. (Yes, there's no guarantee that someone else would be able to generate a specific alternate address, but one that also starts with nytimes is probably possible for a well-resourced attacker.)
The public key is encoded in the onion address, so the client can verify the server you connect to has the matching private key. This is part of the tor protocol, so happens always when talking to onion services.
Onion domains are a form of content addressing based on public key pairs. Normally onion domains aren't that readable as the nytimes one and look more like a bunch of random letters. (All nytimes did was generate many million key pairs until they found one that looked cool.)
If you fetch web pages from http://abc123.onion you bascially tell tor "connect me to whoever holds the certificate with fingerprint abc123". Any domain validated certificates on top of that is superfluous since you already know which certificate you are talking to. What you don't know is who holds it. This is where organizationally validated certificates can help.
