Reporter looking to talk about the Silk Road Case / Special Agent Chris Tarbell

Fri Feb 13 21:05:25 UTC 2015

Partial information = partial answer.

I do not know the case so maybe questions I will ask have obvious answers.

The only way to understand how the backend server behaves is to see its
whole configuration, namely 'Exhibit 6' which I cannot seem to find.
Do you have a direct link to it?

It would also be interesting to know where the agent attempted to connect
*from*. If he already had access to the front-end server through
comprimission, he could then initiate connections from there successfully.
Is it said he managed to connect to that backend directly from outside the
infrastructure? That looks improbable to me since I consider people behind
such activities hiding on Tor network know what they are doing and are most
probably paranoid.
---
*B. R.*

On Fri, Feb 13, 2015 at 8:34 PM, Matthew Phelan <matthew.phelan at gawker.com>
wrote:

> Hey all, esteemed members of this Nginx mailing list.
>
>
> I'm a freelance reporter (former Onion headline writer and former chemical
> engineer) trying to gather some kind of technical consensus on a part of
> the Silk Road pretrial that seems to have become mired in needless
> ambiguity. Specifically, the prosecution's explanation for how they were
> able to locate the Silk Road's Icelandic server IP address.
>
> You may have seen Australian hacker Nik Cubrilovic's long piece
> <https://www.nikcub.com/posts/analyzing-fbi-explanation-silk-road/> on
> how it, at least, appears that the government has submitted a deeply
> implausible scenario for how they came to locate the Silk Road server. Or Bruce
> Scheiener's comments
> <https://www.schneier.com/blog/archives/2014/10/how_did_the_fed.html>. Or
> someone else's. (The court records are hyperlinked in the article, but they
> can be found here
> <http://www.scribd.com/doc/238796613/Silk-Road-Prosecution-4th-Amendment-Rebuttall>
> and here
> <http://ia700603.us.archive.org/21/items/gov.uscourts.nysd.422824/gov.uscourts.nysd.422824.57.0.pdf>,
> if you'd rather peruse them without Nik's logic prejudicing your own
> opinion. In addition, here
> <http://cdn.arstechnica.net/wp-content/uploads/2014/10/horowitzdec.pdf>'s
> the opinion of defendant Ross Ulbricht's lawyer Josh Horowitz, himself a
> technical expert in this field, wherein he echoes Nik Cubrilovic's critical
> interpretation of the state's discovery disclosures.)
>
> I'm hoping that your collective area of expertise in Nginx might allow
> some of you to comment on this portion of the case, ideally on the record,
> for an article I'm working on.
>
> My goal is to amass many expert opinions on this. It seems like a very
> open and shut case that beat reporters covering it last October gave a
> little too much "He said. She said."-style false equivalency.
>
> I know this is a cold call. PLEASED TO MEET YOU!
>
> *Here, below, is the main question, I believe:*
>
> This portion of the defense's expert criticism
> <http://cdn.arstechnica.net/wp-content/uploads/2014/10/horowitzdec.pdf>
> of the prosecution's testimony from former SA Chris Tarbell
> <http://ia700603.us.archive.org/21/items/gov.uscourts.nysd.422824/gov.uscourts.nysd.422824.57.0.pdf>
> (at least) appears the most clear cut and definitive:
>
> ¶ 7. Without identification by the Government, it was impossible to
> pinpoint the 19 lines in the access logs showing the date and time of law
> enforcement access to the .49 server.
>
> 23. The “live-ssl” configuration controls access to the market data
> contained on the .49 server. This is evident from the configuration line:
>           root /var/www/market/public
> which tells the Nginx web server that the folder “public” contains the
> website content to load when visitors access the site.
>
> 24. The critical configuration lines from the live-ssl file are:
>           allow 127.0.0.1;
>           allow 62.75.246.20;
>           deny all;
> These lines tell the web server to allow access from IP addresses
> 127.0.0.1 and 65.75.246.20, and to deny all other IP addresses from
> connecting to the web server. IP address 127.0.0.1 is commonly referred to
> in computer networking as “localhost” i.e., the machine itself, which would
> allow the server to connect to itself. 65.75.246.20, as discussed ante, is
> the IP address for the front-end server, which must be permitted to access
> the back-end server. The “deny all” line tells the web server to deny
> connections from any IP address for which there is no specific exception
> provided.
>
> 25. Based on this configuration, it would have been impossible for Special
> Agent Tarbell to access the portion of the .49 server containing the Silk
> Road market data, including a portion of the login page, simply by entering
> the IP address of the server in his browser.
>
> Does it seem like the defense is making a reasonably sound argument here?
> Are there any glaring holes in their reasoning to you? Etc.? (I would
> gladly rather have an answer to this that is filled with qualifiers and
> hedges than no answer at all, and as such, hereby promise that I will
> felicitously include all those qualifiers and hedges when quoting.)
>
> Any other observations on this pre-trail debate would also be welcome.
>
> Thanks for your time, very, very, sincerely.
>
> Best Regards,
> Matthew
> --
>
> *Matthew D. Phelan*
> "editorial contractor"
>
> *Black Bag ▴ Gawker <http://blackbag.gawker.com>*
> @CBMDP <https://twitter.com/CBMDP> // twitter
> 917.859.1266 // cellular telephone
> matthew.phelan at gawker.com // PGP Public Key
> <http://pgp.mit.edu/pks/lookup?op=get&search=0x11E842642C4B4E99> // email
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150213/142a9f56/attachment-0001.html>