Isn't it obvious? They wanted him gone. This is just like what happened to Kim Dotcom - the US government/elite wanted him gone, so they used whatever methods they wanted, executed by the Law Enforcement, to try and remove him. Sure, they might lose in court now, but most of the damage is done - Megavideo is gone, Silk Road is gone - just what they wanted. EDIT: I guess the biggest problem here is that the people res…
https://en.wikipedia.org/wiki/DeLorean_Motor_Company#Downtur... Also, isn't there a new Silk Road already?
There is a new Silk Road and a plethora of successful alternatives. Far from shutting down darknet markets they really just gave them more publicity and now have 20 sites to go after instead of one.
Ah, key management, the bane of any asymmetric crypto system! My draft specified TOFU; if a site was previously signed and no signature is attached, don't allow any JS. If the signature doesn't match the key cached in the browser, go full noscript.
Wouldn't I typically want my Tor Browser to not record any details about sites I have previously visited? Seems like a lot of work for modestly more security.
Disclaimer: This was an idea that nobody ever showed interest in and therefore I never put forth the effort to refine and flesh out. Feel free to take it and run with it if you have better ideas.
I also have an idea to stop the FBI from gaining any meaningful information via Javascript exploits: PGP or Ed25519 sign all .js files and have a browser that only executes signed code. Not only do you need to obtain access to the server, you also need the private key of its operator. (Which should be kept offline for signing.) If they don't surrender the key, then you cannot compromise their visitors. This can also…
That's a cool idea, but it comes with a lot of overhead. Javascript files are one of the most heavily-cached on the web, and by signing them with PGP, you cripple your caching ability. Or am I missing something?
At this point I feel I'm missing something as we now have two legal documents going "Nuh uh!" - "Yuh huh!" FBI's Explanation[1] states (Page 4, Footnote #5) that the admin himself kept logs explaining that there were frequent IP leaks due to misconfiguration of the web server. At this point aren't we lead to believe that he showed multiple cases of mismanagement. From this can we not call bullshit on the very definit…
Well, that's the thing - they are not providing packet traces even though they were doing a forensic investigation, putting their methodology into doubt. Also, there are no logs indicating that they were successful in what they were trying to do. Even if they were successful, they said that "headers of some of the packets"..." as the source" contained the ip of the server. If it was coming from the TOR network, that would not be the case. Furthermore, since HTTP is a request and response protocol, a request would first have to have been made to the host. A reply would not come without first making the request. That being said, supposedly it was the captcha box. However, that server was only setup to reply to 127.0.0.1 and the backend server. There's no way they would have gotten access to it from the regular web without going through tor, by the methods they describe. You can see the last date the files were modified, and since the "investigator" told what time they accessed the server, we can see that the server was configured not to allow access except through tor. Since he had made a log of ip leaks, I'm pretty sure the guy was on top of security issues, as this is not something he'd overlook.
A tarball is not a disk image and - in my view - is seriously shaky as evidence in a criminal trial. I had always imagined - apparently incorrectly - that evidence-gathering requirements in this area would have been more along the lines of imaging the disk bit-for-bit in a controlled, well documented procedure onto another disk which is immediately made read-only in hardware before being placed in the chain of custod…
All computer evidence is basically Law Enforcement's word that it is real. It is really scary because of how simple planting things are in the context of a tarball or a log file.
It was pretty obvious that the FBI was lying (or misrepresenting or whatever weasel word you want to use) in their original claims. The real question in my mind, which still remains unanswered, is why? The most optimistic explanation is that they just botched the investigation and then spectacularly confused the prosecution as they were preparing their claims. I'd rather not think too hard about the most pessimistic…
They changed their story because the truth is that they violated the 4th amendement rights of anyone who browsed Silk Road for a period of time. They executed drive-by Javascript code on the computers of hundreds of unknowing silk road users, without a warrant. At worst, that's extremely illegal, and at best, it's in a definite gray area. I don't blame the FBI for trying to cover it up. (Citation -- wired article I r…
Quite an interesting read. Summary? Silk Road used a pair of nginx servers, one as front-end, one as back-end. The server images (captured forensically) show that the then-in-place configuration made it impossible for the FBI agent to do what he claims, that is, connect to the back-end by using the server's IP address (the allow/deny settings forbade this). The log files on the servers lack entries to support FBI cla…
> 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.
Unless I missed something, this is the only point in the document where the defense suggests that they couldn't find the log lines provided by the FBI. It seems like a weak claim, since they could have said "could not locate" or "could not find", and suggests that there could have been multiple non-.onion or non-frontend accesses to the frontend and backend servers respectively. Surely the expert would know to 'grep -v', and that should make it easy to determine any access that came from other than the prescribed addresses. This suggests that the logs contradict the claims of inaccessibility.
From a legal perspective, why does it matter how the FBI got access to the server or determined it was a Silk Road server? I assume they got a warrant for the server itself, and therefore the evidence found on the server is a candidate for inclusion in the trial.
Say the FBI used a power drill to put holes in people until they got the information they want.
I also have an idea to stop the FBI from gaining any meaningful information via Javascript exploits: PGP or Ed25519 sign all .js files and have a browser that only executes signed code. Not only do you need to obtain access to the server, you also need the private key of its operator. (Which should be kept offline for signing.) If they don't surrender the key, then you cannot compromise their visitors. This can also…
How does the browser get the public key in order to verify the signature? And how is this any different from just serving scripts over HTTPS?
You could just make it an HTML meta tag which specifies trusted keys. And add an attribute to the script tag which contains the signature.
Might need to disable inline JavaScript, though. And double-check that meta tags are only meaningful when located in their proper place in the head tag.
I don't like the HTTP header idea, 'cause it precludes static content unless you modify the web server. And I don't like external files which are automatically read by the browser because then you run into namespace problems. Keeping everything in the HTML document provides tidy isolation.
Well, fuck. Regardless of the rest, if the government's story changed in a factual way before vs. after the government acquired the Silk Road server ... well, further confirmation that parallel construction is in use and the "foreign tools" are being used in domestic cases. "the account by former Special Agent Tarbell in his Declaration differs in important respects from the government’s June 12, 2013, letter to Icel…
> "[...]For instance, former SA Tarbell asserts that, “[w]hen I typed the Subject IP Address into an ordinary (non-Tor) web browser, a part of the Silk Road login screen (the CAPTCHA prompt) appeared.” Tarbell Decl. at ¶ 8. As explained below, based upon the Nginx server configuration files provided in discovery, that was not possible. "
I've not been following this closely, so the following question is based just on the above. How do we know that the configuration files that we have now (the ones that would make it impossible to show the login screen to an ordinary browser) were the ones in place at the time Tarbell claims to have seen the login screen via an ordinary browser?