Topic: Silk Road: anonymous marketplace. Feedback requested :) - page 31. (Read 152817 times)

People were discussing tor and deepweb on 4chan and Bitcoin came up:

"its legit. Most common is LSD since its so easy to ship.
they have an online currency they use....BTC which is about .86cent : 1BTC"

Not going to replicate all the comments but a bunch of people were discussing silkroad.

That is obvious.

Also, after the latest events (wikileaks etc) government has probably already dispatched somebody to investigate the "Bitcoin case".
For now, perhaps they may be just observing what is happening here, without taking any actions. But later... who knows ?

Of course i know that this may sound a little paranoid, but it's better to be safe than sorry. If you want to be really safe, there is nothing better than assuming that you are already being tracked / observed / spied upon.

beware man! The FBI/etc. is already tracking you!

If you go with the two PC route for getting orders / decrypting orders make sure to use a write blocker with the USB or better yet use CD.

Let me know if you want some help with this.

Yes, we are working on implementing that into our site's one-time contribution option.  Meantime, you can just send them to my email, ian at freetalklive.com via MtGox

Thanks!

I enjoyed listening to this episode today. Have you thought about accepting Bitcoin for donations yet?

It's hour number two of the episode dmp1ce linked: http://traffic.libsyn.com/ftl/FTL2011-03-16.mp3 (Hour 2 starts at approx 40 mins in.)

Audience size varies by when we are on, but the 2nd hour is carried on more radio stations than our first.  Add to our dozens of stations a few thousand internet listeners.  Not a huge show, but also not small either.

Saved. That info will be handy in the future. FYI the OP will likely not respond to that but I guarantee you he would've seen it.

Holy magnum opus, Batman!  This is an excellent analysis.  I've printed it off for further reading and digestion when I have more time.  Thanks for the contribution.

You should definitely update the screenshot on silkroadmarket.org from time to time, so that users won’t be discouraged by a low transaction count etc.

This method of taking orders protects from a large number of attacks. It requires two computers; a laptop/netbook and another machine of any type. You should use Tor and a randomly selected WiFi hotspot (not near where you live) to download GPG encrypted messages. Now turn off your WiFi (it should be possible to fully remove hardware support for WiFi as well) and bring your laptop back to the base location. Use a truecrypted thumb drive to transfer the orders from your mobile machine to your secondary machine. The secondary machine must at no time in its life after it is used connect to the internet. I have heard about some very hard to remove rootkits that can even infect firmware in hardware and reinfect a machine from there, even after a full drive wipe. Now decrypt the order forms on this machine, and remember to securely wipe them after you are done with them.

This prevents a hacker from spying on your customers addresses if they are capable of hacking your machine. If you just use a mobile unit, a hacker could root your machine and steal the encryption keys that are used to decrypt customer orders. They could just spy on you when you decrypt the orders. Decrypting the orders on a machine that never has access to the internet removes the risk that they can transmit back. They could theoretically compromise your stationary machine by using the USB as a vector, but the compromise will be incapable of communicating information (like your keys, you screen) back to the attacker.

Using WiFi acts as a fail-safe against an attacker capable of tracing Tor (with any potential attack). Even if the attacker manages to break your anonymizer, you are protected by random WiFi. Using WiFi offers strong anonymity if it is randomly selected and used for a short period of time. Using WiFi like this also protects you from mebership revealment attacks. Normally, an attacker who can determine that your pseudonym and your real identity use Tor is capable of combining these bits of information to significantly narrow in on your identity with a datamining attack (by intersecting the pool of Tor users in an area with the pool of drug vendors shipping from that area). Using WiFi is one of the better techniques for defending from this attack, because it prevents most attackers from being able to determine your real identity uses Tor.

WiFi does come with risks of its own. It is possible for an attacker who can root your machine to determine your geolocation to with in a few meters of accuracy with a WPS (WiFi Positioning System), WPS companies drive around entire countries with WiFi sniffing equipment and record publicly broadcast MAC addresses of Wifi adapters. During this time they also record their GPS location. This allows a user to use a wireless card to see the MAC addresses in their area. If they forward this data to a WPS server, their rough GPS coordinates (to with in a few meters of accuracy) will be determined.

WPS attacks can be protected from somewhat by using a Virtual Machine. Virtual Machines like Virtual Box virtualize an operating system as well as hardware. If used correctly, a Virtual Machines only direct connection to the host machine is through a hardware hypervisor. This means an attacker who is capable of compromising an application run inside the virtual machine is stuck unless they can also find a jailbreaking vulnerability in the hypervisor. Your virtual machine should use NAT for connections rather than bridged adapters for ultimate isolation of the virtual environment. Since Virtual Box also virtualizes a network adapter, the attacker who can compromise an application in the VM can not access your real network adapter with out jailbreaking the VM. This prevents them from seeing the WiFi MAC addresses around you.

Although using WiFi + Tor + Virtual Machines + Two Machines (with one that never connects to the internet) should be enough to prevent all critical technical attacks on vendors, further security measures can be taken as well. The following steps should contain the risk of a technical compromise to such that it results only in degraded security for the vendor rather than the likely ability to take the vendor down (fail safe). These following steps can further increase the security of the Vendor to the point that there is unlikely to be a significant technical degradation of security (reduce chance of fail).

One of the steps that can be taken to further security is the isolation and compartmentalization of processes, particularly network facing processes. Much like how Virtual Machines can compartmentalize the host and guest OS (isolating the processess in the guest from the host), this other type of Virtualization can isolate process on the guest from each other. An attacker who finds a vulnerability in the jailed processes is incapable of spreading to other processes with out first compromising the virtualization scheme. One of the implementations of this technique is called BSDjails. Chroot is perhaps a more well known (although far less secure) version of this virtualization technique.

Mandatory access controls (MAC) can be used to add further isolation and compartmentalization. Usually an OS uses discretionary access controls (DAC) by default. This type of access scheme is defined with users and groups with permissions assigned to them. This type of access control tends to make it easier for an attacker to spread through the OS after initial compromise as well as have an easier time to compromise in the first place. For example with a DAC you may run Firefox with the user Bob. An attacker who can compromise Firefox now has the access controls of Bob. Mandatory access controls are defined by processes and objects. In this case Firefox will have a profile, with access granted to objects it requires to run correctly. Now if an attacker compromises Firefox they are restricted to the Firefox process profile permissions instead of Bobs permisions. Breaking out of a MAC profile requires a compromise for the Kernel.

Som mandatory access control systems offer even more options. The TrustedBSD profile gives the ability to create multi-level-security systems. This is a very advanced security technique and unfortunately I am not really able to understand it well enough to explain it. It is usually quite complicated to write a profile, but many MAC implementations come with prewritten profiles for various applications and only require the user to enable the prewritten profile.

There are ways to protect against a class of attacks known as buffer overflows. Essentially, a buffer overflow is when an application does not properly manage memory pointers. Programs written in languages that do not manage memory for you (C for example) are vulnerable to this type of attack if the programmers make mistakes (very common for consumer level software).  The attacker floods the application with data until an allocated area of memory is filled, but because the programmers made a mistake in memory management the attack is capable of sending data past this point into other areas of memory. If the attacker is capable of doing this they can  fill up an area of memory with attack code and then try to get the application to launch the attack code with the applications permission level.

One of the ways to protect from this sort of attack is to use a hardening compiler time program like the GCC stack smash protector. If you compile source code with this module called, it will try to automatically harden the code against these types of attack as it compiles it. This can protect from coding mistakes on the part of those who write the application. GCC stack smash protector is included in many operating systems and can be downloaded and installed on many others.

Another way to protect from buffer overflows is to use memory randomization techniques. One method of doing this is using a position independent executable (PIE) module during compile. Some operating systems, most notably OpenBSD, automatically use memory randomization for all applications. Memory randomization reduces the risk of a buffer overflow becaue it makes it harder for the attacker to guess where in memory their attack code overflows to. They need to guess the location in memory when they try to get to application to launch the code, if they guess incorrectly the application will likely crash with out code execution. 32 bit processors can only protect partially from these attacks because they have a small number of potential locations in memory and can be brute forced. 64 bit processors with memory randomization essentially prevent traditional buffer overflow attacks, however particularly sophisticated attackers have found ways around this. PIE is used by default for several high risk applications (like Firefox) on many operating systems. It can be manually applied during compile time by the user on many others. Full memory randomization is available on OpenBSD by default.

there are some techniques which could arguably increase the anonymity of Tor against certain attacks (generally increasing its risk to other attacks). It is dangerous to play with Tor configurations and generally suggested against unless you fully understand the risks. Traffic analysis is a complicated area of study and surprising effects from small changes are common. One way to potentially increase the anonymity provided by Tor is to use less than three entry guards. The most dangerous attacks on the Tor network require that your entry guard is malicious or the ISP of your entry guard is malicious. Selecting three entry guards means that you are selecting three potentially malicious nodes, where as selecting one entry guard means you are selecting only one potentially compromised node. The obvious downside to using a single entry guard is in the realms of speed. If your client selects a single slow entry guard your connection will be bottlenecked by that. The less obvious downside is that you may make yourself more vulnerable to attacks that are protected by from blending in with the crowd (normal Tor clients use three entry guards, you use one, thus you do not blend in with the crowd). How significant these attacks are is currently not known (by me anyway).

Another potentially advantageous way of configuring Tor could be the use of  bridge nodes as your entry points. Using a bridge will reduce the level of multiplexing between you and the first hop on the network and give you a significantly smaller set size (not many people use bridges). This probably makes it significantly easier for you to be traced through the internet than it would be for a normal Tor user. However, you will be protected from a local attacker (your ISP, the WiFi hotspot you use) determining that you use the Tor network with IP based attacks. Such an attacker could still use Traffic fingerprinting attacks to detect that you are a part of the network, but this is more difficult. Tor bridges provide a fairly weak level of membership concealment, but this is a quite important atribute for vendors to have as they leak geolocation intelligence with mail. Tor bridges should be considered by vendors who do not wish to use better techniques for membership concealment (Random WiFi, VPS/N entry, Hacked Cable Modem).

Using a different network to enter traffic than you exit through can protect from most Tor focused attacks (meaning attackers who are only in postions to watch Tor traffic). Many attackers meet this criteria, although more sophisticated attackers are of course in position to watch the traffic of many networks and even entire parts parts the globe.  Using a different network to enter than to exit traffic is a good idea for this reason alone. Another advantage of using a different network to enter than exit traffic is significant membership concealment. A local attacker can be prevented from using IP based attacks to determine that you are accessing the Tor network. Using private VPS over public VPN is a significant improvement against membership concealment attacks, it is better if you enter through a 'cover server' that is not publicly known as an anonymizer. Potential disadvantages of entering through something other than Tor are lack of crowding (especially with a private VPS). The trade offs between untraceability and membership concealment need to be carefully considered by vendors, both are important for us but in many configurations strengthening one will decrease the other. Tor by default has little protection from membership concealment, although it does obscure membership from weak attackers when not run as a relay (unlike I2P for example which offers no protection).

Running Tor as a relay instead of just a client has advantages and disadvantages. The advantage of running Tor as a relay server are increased resistance to timing attacks (one of the main and most effective attacks to be used against Tor). The disadvantages of running as a relay include reduced protection from intersection attacks (this is particularly important and dangerous if you use real time communications like instant messages). Another disadvantage is the total inability to conceal membership. Running Tor as a relay is dangerous for our threat model and should be avoided.

However, you can protect from timing attacks by running your own Tor servers in datacenters (obviously with no links to you) and using them to enter traffic. Since you own them you know they are not malicious unless they have been compromised. This can offer you strong resistance to all sorts of end to end attacks. It can also be expensive to do with out sticking out from the crowd because you will need to run three Tor servers to do this.

One of the most important things you must do to increase the security of Tor is properly configure your browser. TorButton is considered a required plugin if you want any anonymity from moderately active attackers (although hidden services may lessen the requirement for TorButton somewhat). TorButton protects from many simple browser based side channel attacks. It also adds crowding where it can, for example it spoofs a common browser fingerprint. TorButton protects users from commiting several mistakes that could compromise their anonymity, for example toggling things like Cookies between anonymous and non-anonymous sessions.

Hidden Services increase the security/anonymity of Tor for clients and offer servers increased anonymity and security from some attackers. Tor hidden servers do not offer particularly strong anonymity, there are several attacks for tracing them that many agencies are probably capable of. However, Tor Hidden services increase the cost of these attacks and more importantly they buy time. It may take an attacker a few weeks or months to find the servers location instead of no time at all.  Low level attackers are incapable of deanonymizing hidden services and mid level attackers are frusturated.

There are potential techniques for increasing the anonymity of a hidden service. The main weakness of a hidden service is the ease with which the entry guards can be detected. An attacker with a few nodes on the tor network can identify a hidden services entry guards merely by sending many connection requests to it and sending time modulated streams, waiting for one of their relay nodes to be selected (the relay node can then detect the modulated stream to identify the entry guard). After the entry guards are located the attacker has two ways to continue the attack. They could contact the entry guard owner and ask them to log. If they can not do this for whatever reason, they could contact the government in the jurisdiction of the entry guard and ask them to log externally. They could also hack the entry guard or physically tap it themselves. Another option would be DDOSING entry guards simultaneously to force rotation, waiting for an attacker controled entry guard to be selected.

Hidden services could select to use multiple chained  guard nodes to add further hops/jurisdictions and significantly increase the cost/complexity of locating them with this sort of attack. Disadvantages of this include the skill level required to implement it (currently requires changes to the Tor source code prior to compile) as well as significantly decreased speed and reliability of the hidden service for every additional hop. This will also not protect additionally from other types of attack.

Against a 'lower/mid-level' adversary, a default Tor hidden service effectively provides about the same level of untraceability for a server as using a one hop encrypted proxy would provide for a client. It is worth noting that the security provided by Tor's unique encryption system still provides added benefits against certain types of attack that normal one hop encrypted proxies do not have (high resistance to local traffic fingerprinting attacks, for example).

Tor hidden services also offer client to server encryption. This removes the risk of a malicious exit node spying on user traffic. It also makes the connection between the client and the server impossible for an adversary to eavesdrop on communications (although classification of the encrypted stream is still possible due to lack of 'link masking' in Tor). Tor hidden services provide only 80 bit authentication, this is significantly weaker bit-strength authentication than SSL provides. 80 bits are still probably enough to prevent any attacker (with out a quantum computer) from masquerading as a hidden service.

Hidden services offer clients significant security advantages. As it is more difficult for an adversary to locate a hidden service than a normal server, it is less probable that an attacker can position themselves to do end to end attacks. Many of the attackers who are still capable of positioning themselves for end to end timing attacks will still have a more difficult time to do so than they would against a client accessing a non-hidden service. Hidden services make it impossible for malicious exit nodes to inject application layer exploits in the return stream. Hidden services actually act as a sort of application layer firewall between the clients that interact with it (hacking a client will first require the compromise of the hidden service, thus giving clients a potentially large increase in resistance from hackers). Hidden services more than triple a clients protection from the weakest type of log trace attack, with 10 nodes between any two clients (instead of 3 for non-hidden service connecting Tor users)

against an attacker  who is only capable of identifying a hidden services .onion and following log trails, hidden services require the collection of 10 logs (versus three for a non-hidden service client).

Got a connection via TOR. Don't know why, but seems to be fixed. If the problem comes back, I will look in the logs.

The radio show is Free Talk Live and the Bitcoin and Silk Road episode can be downloaded here.   FTL_Ian would have to tell you how big the audience is now but I know they have a lot of radio affiliates.

I like the Silk Road website very much.  It has really opened my eyes to some of the great services that can be created by using Tor and Bitcoin together.  It is too bad no weapons are available on the market right now because I would be interested in trading for a handgun.   Although, pirated media is interesting to me as well.

How cool!  Is there a recording online somewhere?  How big is your audience?

I showed it to a friend and we browsed around a bit. Though, I checked again now, and now I am getting errors. The vidalia logs show:

[Notice] Closing stream for '[scrubbed].onion': hidden service is unavailable (try again later).

On the other hand, even over the past few days, I had no problem on some onions. I was testing coin tumbler a few days ago and it just stopped (I can see the transactions in the block chain, its just sitting there so frustratingly!). However, I haven't had any connection issues, and I have been watching the site obsessively since it has some of my coins

So I don't know what to tell you about connection issues. I am curious though, I may turn up debug logging and see if anything comes up. I really want to see hidden services take off

I run mine 24/7. It's a bridge node.

I get that sometimes but I usually just refresh and it's okay. Of course, I only visit out of curiosity and ever buy anything, okay, DEA?

My TOR node usually needs about 5-10 minutes to properly "heat up" and get connected to other nodes and it that time no page works for me.
After that, it runs normally.

Maybe you all should start the note and let it work for some time, and try it later.

Thanks for this awesome idea, silkroad.  I am so impressed, I promoted it on my national radio program tonight.  Hope you don't mind the publicity.

I was able to access the site last night, but now am getting: 504 Connect to ianxz6zefk72ulzz.onion:80 failed: SOCKS error: host unreachable

I am using the Tor Browser as your site suggests.

Looking forward to hearing more positive experiences from users.