5 ms·

I'm not sure how this is a whack-a-mole game. If you run a single-server hidden service, the NSA can track it (unless you think otherwise - tried to initiate d

I'm not sure how this is a whack-a-mole game. If you run a single-server hidden service, the NSA can track it (unless you think otherwise - tried to initiate discussion here[1]). Once they track it, they will get your hosting provider to cooperate and before you know it, your server has been imaged and that irrevocable .onion private key is in the authorities' hands. The most you'll see from your end was some downtime, which a cooperative host (an assumption here, granted) would cover up for the FBI (status update: rack/sector/DC failure at XXX). They can now impersonate your server, MitM you, the works. After that, in order to move, you have to literally move to another onion address. What you're saying makes sense if there is anyone who habitually rotates servers as a matter of OPSEC, but that sounds like an invitation for disaster. AFAICT the name of the game isn't whack-a-mole, because when the NSA sees the mole, it will whack it. It's "bury the mole in the moleyard" - multiple mirrors so as to make locating the actual service very unlikely. [1] https://news.ycombinator.com/item?id=8568667 https://news.ycombinator.com/item?id=8568667

zanny 12y ago
I'm wondering why they would image the server. Did SR2 not use full disc encryption using LUKS? How would they be able to access anything on it, I know if I were running SR2 I'd have the longest private key ever stored in my brain to decrypt the drives.
- wmf 12y ago
  If you're in San Francisco, how do you type the disk password into a server in Iceland? Through a BMC with clownshoes security?
  - deleted 12y ago
    [deleted]
- yourad_io 12y ago
  > I'm wondering why they would image the server. For offline analysis and to be used as evidence, presumably. > Did SR2 not use full disc encryption using LUKS? (...) longest private key ever So the process for you would be slightly different: There would be a "power outage" in your rack, your encrypted disk would be imaged and (unencrypted) bootloader would be bugged. Then they'd wait for you to see that your server had some issues, upon which time you'd have two choices: -enter your private key to resume the service. -abandon the server. The correct choice would be (2), but you don't have enough information to make that call.
  - feld 12y ago
    It's not log bugging your bootloader can magically send your password for the key off the server. They would have to be watching and be very quick, but I'm sure they'd want to see the server start to boot to ensure they have it. I'd compare the bootloader to a known good image as an early boot step and if it isn't what you expect immediately start destroying data. :-)
    - yourad_io 12y ago
      I meant "power outage" as the pretext that would justify (to the HS owner) why the server has been power-cycled (assuming they decided to cooperate with the FBI/whoever). Here's how I would do it: - I assume that your hard drives are in RAID. I gamble that they're in RAID 1 - most typical - and strip one out while the server is still running. Some kernel messages are logged, whatever. - I start imaging the disk. If it isn't a mirror of the other after all, I strip the remaining drive(s) out and start imaging them too. - While the disk(s) is/are transferring, I patch both your boot loader and your kernel with a rootkit. This should be laughably easy for the level of adversary we're talking about. - When the disk(s) are done, I power cycle your server. I may cold-boot your RAM and get the passphrases there if i'm lucky. The downtime was either seconds (if it kept going with one RAID 1 disk) or <however long the imaging takes>. - When you realise your service is down you may contact customer support. In that case they will respond (with their usual timing) about something-something-blown-fuse-UPS in your rack. - When you log onto your server, you will most likely be faced with the passphrase input and most likely will go for it, but even if you don't... > I'd compare the bootloader to a known good image as an early boot step If you do so after you've given away the passphrase, you've lost already. Destroying the data won't help, as they have the encrypted copy of it and you just gave them the key. I don't think you could detect a good boot/OS rootkit remotely at all. One would cover for the other. You can't unplug the disk and examine it. You can't plug a read-only drive in and boot some forensic tool. All you have is your lying bootloader and your lying OS. Your encrypted partition doesn't protect the integrity of the binaries there either, as after it's been decrypted, the rootkit would happily intercept any values that would give it away. I'm not sure how you could ensure hardware security without ensuring physical security. Usually, physical access == pwned. Maybe TPM changes/will change that, but I somehow doubt it. Some other routes not covered here (probably easier, heh): Getting host to decrypt your TLS/KVM session where you typed the passphrase in the first place, malware in firmware on misc devices, etc.
duaneb 12y ago
> Once they track it, they will get your hosting provider to cooperate and before you know it, This is the whackamole I was talking about. The time between when they identify the server and getting the provider to comply is enough in certain countries to set up an alternative location. Hosting companies aren't gonna want to play this game forever, ESPECIALLY if they're getting good money out of it.
- yourad_io 12y ago
  So you'd just move servers every X months no matter what, or would you be tipped off somehow during that time window? If it's the first, that's pretty hardcore. Migrations are a pain for most people. Unless the system was built to migrate painlessly... Hm.
  - deftnerd 12y ago
    Set up the site so all the database transactions take place in memcache or redis and every 10 minutes it's written into encrypted entries on some kind of distributed blockchain (Datacoin, Namecoin, etc). Use Docker to wrap up the front-end and make it easy and portable. You can then spin up a new iteration of the site on a new VPS in a matter of moments. It can download the DB entries from that blockchain, decrypt, and then keep the DB in memcache/redis. To speed things up, you can also do daily encrypted DB dumps to a DHT address and write the DHT address into the blockchain to bootstrap the service restart. Once the DB is bootstrapped and caught up, the site can register itself on the Onion network and since it'll be the newest entry, traffic will start ending up at the new site pretty quickly. Such a system could be automated pretty quickly where a person could register VPS's at Linode, Digital Ocean, AWS, etc. Then write some kind of encrypted config file into a blockchain so the site software would pull down the config and make the transition to the new provider automatically. Could be an automated daily move and by using a blockchain as an intermediary for communications it prevents worries about making mistakes with accidentally leaking IP addresses at each new service provider.

zanny 12y ago

I'm wondering why they would image the server. Did SR2 not use full disc encryption using LUKS? How would they be able to access anything on it, I know if I were running SR2 I'd have the longest private key ever stored in my brain to decrypt the drives.

wmf 12y ago
If you're in San Francisco, how do you type the disk password into a server in Iceland? Through a BMC with clownshoes security?
- deleted 12y ago
  [deleted]
yourad_io 12y ago
> I'm wondering why they would image the server. For offline analysis and to be used as evidence, presumably. > Did SR2 not use full disc encryption using LUKS? (...) longest private key ever So the process for you would be slightly different: There would be a "power outage" in your rack, your encrypted disk would be imaged and (unencrypted) bootloader would be bugged. Then they'd wait for you to see that your server had some issues, upon which time you'd have two choices: -enter your private key to resume the service. -abandon the server. The correct choice would be (2), but you don't have enough information to make that call.
- feld 12y ago
  It's not log bugging your bootloader can magically send your password for the key off the server. They would have to be watching and be very quick, but I'm sure they'd want to see the server start to boot to ensure they have it. I'd compare the bootloader to a known good image as an early boot step and if it isn't what you expect immediately start destroying data. :-)
  - yourad_io 12y ago
    I meant "power outage" as the pretext that would justify (to the HS owner) why the server has been power-cycled (assuming they decided to cooperate with the FBI/whoever). Here's how I would do it: - I assume that your hard drives are in RAID. I gamble that they're in RAID 1 - most typical - and strip one out while the server is still running. Some kernel messages are logged, whatever. - I start imaging the disk. If it isn't a mirror of the other after all, I strip the remaining drive(s) out and start imaging them too. - While the disk(s) is/are transferring, I patch both your boot loader and your kernel with a rootkit. This should be laughably easy for the level of adversary we're talking about. - When the disk(s) are done, I power cycle your server. I may cold-boot your RAM and get the passphrases there if i'm lucky. The downtime was either seconds (if it kept going with one RAID 1 disk) or <however long the imaging takes>. - When you realise your service is down you may contact customer support. In that case they will respond (with their usual timing) about something-something-blown-fuse-UPS in your rack. - When you log onto your server, you will most likely be faced with the passphrase input and most likely will go for it, but even if you don't... > I'd compare the bootloader to a known good image as an early boot step If you do so after you've given away the passphrase, you've lost already. Destroying the data won't help, as they have the encrypted copy of it and you just gave them the key. I don't think you could detect a good boot/OS rootkit remotely at all. One would cover for the other. You can't unplug the disk and examine it. You can't plug a read-only drive in and boot some forensic tool. All you have is your lying bootloader and your lying OS. Your encrypted partition doesn't protect the integrity of the binaries there either, as after it's been decrypted, the rootkit would happily intercept any values that would give it away. I'm not sure how you could ensure hardware security without ensuring physical security. Usually, physical access == pwned. Maybe TPM changes/will change that, but I somehow doubt it. Some other routes not covered here (probably easier, heh): Getting host to decrypt your TLS/KVM session where you typed the passphrase in the first place, malware in firmware on misc devices, etc.

duaneb 12y ago

> Once they track it, they will get your hosting provider to cooperate and before you know it, This is the whackamole I was talking about. The time between when they identify the server and getting the provider to comply is enough in certain countries to set up an alternative location. Hosting companies aren't gonna want to play this game forever, ESPECIALLY if they're getting good money out of it.

yourad_io 12y ago
So you'd just move servers every X months no matter what, or would you be tipped off somehow during that time window? If it's the first, that's pretty hardcore. Migrations are a pain for most people. Unless the system was built to migrate painlessly... Hm.
- deftnerd 12y ago
  Set up the site so all the database transactions take place in memcache or redis and every 10 minutes it's written into encrypted entries on some kind of distributed blockchain (Datacoin, Namecoin, etc). Use Docker to wrap up the front-end and make it easy and portable. You can then spin up a new iteration of the site on a new VPS in a matter of moments. It can download the DB entries from that blockchain, decrypt, and then keep the DB in memcache/redis. To speed things up, you can also do daily encrypted DB dumps to a DHT address and write the DHT address into the blockchain to bootstrap the service restart. Once the DB is bootstrapped and caught up, the site can register itself on the Onion network and since it'll be the newest entry, traffic will start ending up at the new site pretty quickly. Such a system could be automated pretty quickly where a person could register VPS's at Linode, Digital Ocean, AWS, etc. Then write some kind of encrypted config file into a blockchain so the site software would pull down the config and make the transition to the new provider automatically. Could be an automated daily move and by using a blockchain as an intermediary for communications it prevents worries about making mistakes with accidentally leaking IP addresses at each new service provider.