No, this article states directly what most people are really saying. People say that NSA controls quite a few exit nodes, but we're not really sure how many. If they controlled a lot, they could deanonymize Tor traffic. According to TFA, NSA knows full well exactly this and tried it, but couldn't gain control of a sufficient number of exit nodes. That's not surprising, it really would take controlling quite a lot of exit nodes.
The more real danger is mentioned in the article, also. Your computer and the connection from the exit node to the site you're visiting are the main weaknesses in Tor. The exit node has an ideal man-in-the-middle position over your traffic, and the NSA is one of the most benign malicious actors running exit nodes. Any HTTP connection over Tor is idiotic and any HTTPS session should be examined carefully.
You can whitelist on Linux and Windows systems, too, if you include modifying the driver-loading process. It can be reasonably easily done on either system. But common out-of-the-box OSes have wide-ranging support for drivers that they load automatically.
They should have sent it 4 point one character per page.
No. You should have a good reason for telling them "no", then you should tell them "no" with your reason, and get lawyers involved. Pretending to technically comply with a court order while making an obviously obstructive, bad-faith effort is a good way to ensure that things go rapidly downhill for you.
Yes, everyone should turn on HTTPS PFS modes, ECDHE and DHE. PFS does prevent decrypting passively-collected data streams, requiring an active MITM to decrypt.
However, I don't see how it's necessarily true that you would be able to detect these MITM if they have the SSL private key. (If they don't have the SSL private key, it's rather easy to detect.)
Actually Man-in-the-Middle transparent proxies, which intercept and monitor SSL/TLS traffic, are now standard in most corps. You don't get a browser alert since the corporate "fake" CA is pre-installed as trusted in your browsers by the corp's IT.
Common, yes, but painfully easy to detect. But then, if you don't have the privileges to install a new browser, install a VM, or modify the system's root certs, you certainly can't claim it's your computer. It's certainly not your Internet connection. What do you expect using someone else's computer and someone else's Internet connection?
And... using Deep Packet Inspection, the protocol will not just be matched versus the destination port, so your genius attempts to ssh to your external server running on tcp/443, will not only be blocked, you will be flagged and tagged.
Sure, for some small set of protocols that can be easily identified accurately with DPI. Ones that aren't using SSL. (Yes of course they can detect SSL and yes of course they can just block SSL connections. What did you expect?)
The CA never has a copy of the SSL certificate necessary for doing key exchange.
The public certificate is what is signed by the CA. It's also handed out to anyone that asks for an SSL connection, so it's hardly secret. The private key is only ever held by the certificate owner, not by the CA.
If a CA is complicit (or gives you a copy of their key), you can create a pretty good MITM by generating a new keypair with the target's information (obtained from the public cert) and signing that. However, you cannot duplicate their public certificate or even have your fake certificate have the same fingerprint as theirs. So if someone initiating an SSL connection has seen the target's public certificate in the past and remembered the fingerprint -- or if they have received the fingerprint through a non-compromised channel -- then your attack is detectable.
The only way to MITM undetectably is to have your public cert be exactly the same as theirs, which means that you need their private key. The only one with the private key is the target, not the CA.
It's already been done many times, in a variety of ways, by researchers (mostly using general-purpose hardware). It doesn't require much paranoia at all.
How do they "load software to track who is downloading"? Do thumb drives now have the capability to execute software on their own?
Sometimes! But let's use an easier attack. Put a thumb drive plus some custom hardware into a thumb drive case. Easy to do. The hardware enumerates as both a thumb drive and, say, a USB audio-device driver that is present on most stock Linux distributions and has a particular buffer overflow vulnerability that allows arbitrary code execution. That sort of vulnerability is reasonably common and has happened in the past. Engineering that hardware is not hard. When the system enumerates the USB audio device, it loads that driver and the driver performs setup by talking to the USB device and requesting information. The evil device sends back responses to the driver that trigger the buffer overflow and execute device-provided code.
You could make this fairly system-independent by putting a number of fake devices in there that exercise different vulnerabilities. Or you could determine what the connecting operating system is (and what drivers it has available) by looking at how it enumerates. You can even have your device use soft reconnects to try out different vulnerable drivers. (You would have the computer-facing port actually connect to a hub. Also easy to engineer up.)
Can that software access your files and ID you over a USB port?
So, yes.
Don't assume that because something looks like a flash drive, it actually is. And don't connect unknown peripherals to your computer -- they talk directly to drivers.
How do you know it's a storage device? It's just something with a USB port that happens to look vaguely like a storage device. But with USB, it's pretty trivial to do something like have that USB device present itself to the system as a storage device, mouse, and keyboard.
There's also no shortage of vulnerabilities in the USB stack. A buffer overflow in a USB driver, for example. This is all handled during enumeration, when (with any operating system), the user has little control over the OS's behavior.
That is an enormous logical leap. Silk Road was running a high-profile, long-running Tor service, which is inherently dangerous and certainly more dangerous than many other applications of Tor. Is there evidence that suggests they were particularly skilled in doing so safely? There are also a number of well-known (and nearly-unavoidable) attacks against the Tor design. They are difficult, but then, they've been running a high-profile site for a long time, which makes it a lot easier to be targeted by even difficult attacks.
Finally, there are plenty of ways for an operation that large to be undone that are much more likely compromise of Tor itself. Most of these things are solved by conventional police work because (a) "real" evidence looks a lot better in a trial and (b) people are a lot better at making mistakes than most security technologies.
Fork what? BitTorrent the client? There are already tons of BitTorrent clients. BitTorrent the peer-to-peer sharing protocol? It's already a protocol built mostly out of optional extensions and client-specific additions. BitTorrent the conceptual network in which the protocol operates? The "networks" of different torrents are completely independent except for DHT. There is zero benefit to splitting it up whatsoever.
They're useful to geologists, and often to other scientists, sometimes, but not in this context.
Yes, pretty much no climate we could reach is really unprecedented on Earth. The ice ages are pretty cold. Other eras were quite hot and high in CO2. Hell, in still other eras, there was no oxygen in the atmosphere.
What's relevant is the climate of the last few thousand years and, to a lesser extent, the modern geologic era, because it's what our civilization is dependent on. Sure, if the climate goes all to hell, there will still be life on Earth. There will still even be humans on Earth. Just a lot fewer of them for quite a while, plus catastrophic economic losses.
Most satellites have vaguely the same dimensions. A shuttle that "carries satellites" carries most kinds of satellites. Also, most of them are put into orbit by conventional rockets, rather than the shuttle.
Yes it's called a "Loan" and it's what happens when you buy a $600 toy with $50 and someone tells you they need $20 a month until they have $600 from you.
At least for some carriers, the price under contract and the off-contract price are the same. So none of the money you're paying them per month is for the phone. It's then not a loan, and the "cost" of the phone is the opportunity cost of being under that contract as opposed to being able to purchase different service. Depending on where you live, this opportunity cost could be zero. Imagine, say, Verizon is the only carrier that actually works in your neighborhood.
On a PC, remote arbitrary code execution is usually considered a game-over event, because PC apps are usually not sandboxed and the user running them usually has way too many permissions already.
I think that really depends on the PC. If it's a regular consumer PC, that's a couple of the reasons. There are more. Regular consumer PCs are almost entirely single-user machines on uninteresting networks. The major benefit to hacking a consumer PC is obtaining the user's data, which is naturally available in a user context (because of poor sandboxing).
Plenty of PCs, though, are more serious machines with multiple users, on interesting networks, or otherwise useful for long-term compromise. Long-term compromise, and doing other interesting things, really requires privilege escalation. Sure, there are lots of privilege-escalation vulnerabilities in desktop operating systems, but they keep getting fixed, so having them is actually relevant.
people still often really aren't that interested in exploits that already require code execution
I disagree. Privilege-escalation vulnerabilities are still pretty popular, just not as broadly applicable as remote code execution vulnerabilities.
Phone OSes, on the other hand, were built with sandboxing in mind from the start, and do not expect the attacker to be able to attack other apps.
That's the major interesting thing about this: that compromise of one app can cause the WeChat app to disclose potentially-sensitive data.
already successfully installed their own software on your phone
No, they're just able to execute code on your phone (in the context of some piece of software installed on your phone). There are plenty of approaches to remote code execution that are not the same as installing.
should be the least of your concerns at this point
While more or less true, vulnerabilities that enable you to do something dangerous with remote code execution capabilities are a major class of vulnerability. Just executing code in the context of some arbitrary application on the phone isn't necessarily very useful until you can do something evil with it.
I'm not sure that effect is oxidation, but otherwise, yes. The good way to do that is with a decanter, though, rather than just opening the bottle. The bottle's small neck limits airflow. If you're going to expose it to air, might as well do it fast.
Slashdot Mirror
Organizations like the CIA. The NSA doesn't really do PR or propaganda, just SIGINT.
No, this article states directly what most people are really saying. People say that NSA controls quite a few exit nodes, but we're not really sure how many. If they controlled a lot, they could deanonymize Tor traffic. According to TFA, NSA knows full well exactly this and tried it, but couldn't gain control of a sufficient number of exit nodes. That's not surprising, it really would take controlling quite a lot of exit nodes.
The more real danger is mentioned in the article, also. Your computer and the connection from the exit node to the site you're visiting are the main weaknesses in Tor. The exit node has an ideal man-in-the-middle position over your traffic, and the NSA is one of the most benign malicious actors running exit nodes. Any HTTP connection over Tor is idiotic and any HTTPS session should be examined carefully.
You can whitelist on Linux and Windows systems, too, if you include modifying the driver-loading process. It can be reasonably easily done on either system. But common out-of-the-box OSes have wide-ranging support for drivers that they load automatically.
I don't assume, I read a number of descriptions of what happened.
The lawyers you engage in step 3 would be happy to explain why trying to "creatively" make bad-faith efforts is not a smart approach.
To what is "or someone talking to the target" referring?
The only one with the private key is the target. A person communicating over SSL with the target doesn't have the target's private key.
If you want to undetectably MITM an SSL encryption, you need to acquire the SSL private key from the target. Is that more clear?
They should have sent it 4 point one character per page.
No. You should have a good reason for telling them "no", then you should tell them "no" with your reason, and get lawyers involved. Pretending to technically comply with a court order while making an obviously obstructive, bad-faith effort is a good way to ensure that things go rapidly downhill for you.
Yes, everyone should turn on HTTPS PFS modes, ECDHE and DHE. PFS does prevent decrypting passively-collected data streams, requiring an active MITM to decrypt.
However, I don't see how it's necessarily true that you would be able to detect these MITM if they have the SSL private key. (If they don't have the SSL private key, it's rather easy to detect.)
That's why they originally asked for the data for only the one user.
Actually Man-in-the-Middle transparent proxies, which intercept and monitor SSL/TLS traffic, are now standard in most corps. You don't get a browser alert since the corporate "fake" CA is pre-installed as trusted in your browsers by the corp's IT.
Common, yes, but painfully easy to detect. But then, if you don't have the privileges to install a new browser, install a VM, or modify the system's root certs, you certainly can't claim it's your computer. It's certainly not your Internet connection. What do you expect using someone else's computer and someone else's Internet connection?
And ... using Deep Packet Inspection, the protocol will not just be matched versus the destination port, so your genius attempts to ssh to your external server running on tcp/443, will not only be blocked, you will be flagged and tagged.
Sure, for some small set of protocols that can be easily identified accurately with DPI. Ones that aren't using SSL. (Yes of course they can detect SSL and yes of course they can just block SSL connections. What did you expect?)
The CA never has a copy of the SSL certificate necessary for doing key exchange.
The public certificate is what is signed by the CA. It's also handed out to anyone that asks for an SSL connection, so it's hardly secret. The private key is only ever held by the certificate owner, not by the CA.
If a CA is complicit (or gives you a copy of their key), you can create a pretty good MITM by generating a new keypair with the target's information (obtained from the public cert) and signing that. However, you cannot duplicate their public certificate or even have your fake certificate have the same fingerprint as theirs. So if someone initiating an SSL connection has seen the target's public certificate in the past and remembered the fingerprint -- or if they have received the fingerprint through a non-compromised channel -- then your attack is detectable.
The only way to MITM undetectably is to have your public cert be exactly the same as theirs, which means that you need their private key. The only one with the private key is the target, not the CA.
If you follow this link, you have failed the first test of computing with minimal trust.
If it actually goes to crystallographic software and you use that software, you've failed the second and third tests.
It's already been done many times, in a variety of ways, by researchers (mostly using general-purpose hardware). It doesn't require much paranoia at all.
How do they "load software to track who is downloading"? Do thumb drives now have the capability to execute software on their own?
Sometimes! But let's use an easier attack. Put a thumb drive plus some custom hardware into a thumb drive case. Easy to do. The hardware enumerates as both a thumb drive and, say, a USB audio-device driver that is present on most stock Linux distributions and has a particular buffer overflow vulnerability that allows arbitrary code execution. That sort of vulnerability is reasonably common and has happened in the past. Engineering that hardware is not hard. When the system enumerates the USB audio device, it loads that driver and the driver performs setup by talking to the USB device and requesting information. The evil device sends back responses to the driver that trigger the buffer overflow and execute device-provided code.
You could make this fairly system-independent by putting a number of fake devices in there that exercise different vulnerabilities. Or you could determine what the connecting operating system is (and what drivers it has available) by looking at how it enumerates. You can even have your device use soft reconnects to try out different vulnerable drivers. (You would have the computer-facing port actually connect to a hub. Also easy to engineer up.)
Can that software access your files and ID you over a USB port?
So, yes.
Don't assume that because something looks like a flash drive, it actually is. And don't connect unknown peripherals to your computer -- they talk directly to drivers.
How do you know it's a storage device? It's just something with a USB port that happens to look vaguely like a storage device. But with USB, it's pretty trivial to do something like have that USB device present itself to the system as a storage device, mouse, and keyboard.
There's also no shortage of vulnerabilities in the USB stack. A buffer overflow in a USB driver, for example. This is all handled during enumeration, when (with any operating system), the user has little control over the OS's behavior.
It's not good.
That is an enormous logical leap. Silk Road was running a high-profile, long-running Tor service, which is inherently dangerous and certainly more dangerous than many other applications of Tor. Is there evidence that suggests they were particularly skilled in doing so safely? There are also a number of well-known (and nearly-unavoidable) attacks against the Tor design. They are difficult, but then, they've been running a high-profile site for a long time, which makes it a lot easier to be targeted by even difficult attacks.
Finally, there are plenty of ways for an operation that large to be undone that are much more likely compromise of Tor itself. Most of these things are solved by conventional police work because (a) "real" evidence looks a lot better in a trial and (b) people are a lot better at making mistakes than most security technologies.
Fork what? BitTorrent the client? There are already tons of BitTorrent clients. BitTorrent the peer-to-peer sharing protocol? It's already a protocol built mostly out of optional extensions and client-specific additions. BitTorrent the conceptual network in which the protocol operates? The "networks" of different torrents are completely independent except for DHT. There is zero benefit to splitting it up whatsoever.
Man, good thing I didn't say, "what's relevant is the recorded ice coverage history of the last few thousand years"!
Geologic time scales aren't useful.
They're useful to geologists, and often to other scientists, sometimes, but not in this context.
Yes, pretty much no climate we could reach is really unprecedented on Earth. The ice ages are pretty cold. Other eras were quite hot and high in CO2. Hell, in still other eras, there was no oxygen in the atmosphere.
What's relevant is the climate of the last few thousand years and, to a lesser extent, the modern geologic era, because it's what our civilization is dependent on. Sure, if the climate goes all to hell, there will still be life on Earth. There will still even be humans on Earth. Just a lot fewer of them for quite a while, plus catastrophic economic losses.
Most satellites have vaguely the same dimensions. A shuttle that "carries satellites" carries most kinds of satellites. Also, most of them are put into orbit by conventional rockets, rather than the shuttle.
With all the money I'd save by using a different carrier, I could recoup the cost of moving in 30 or 40 years!
Yes it's called a "Loan" and it's what happens when you buy a $600 toy with $50 and someone tells you they need $20 a month until they have $600 from you.
At least for some carriers, the price under contract and the off-contract price are the same. So none of the money you're paying them per month is for the phone. It's then not a loan, and the "cost" of the phone is the opportunity cost of being under that contract as opposed to being able to purchase different service. Depending on where you live, this opportunity cost could be zero. Imagine, say, Verizon is the only carrier that actually works in your neighborhood.
On a PC, remote arbitrary code execution is usually considered a game-over event, because PC apps are usually not sandboxed and the user running them usually has way too many permissions already.
I think that really depends on the PC. If it's a regular consumer PC, that's a couple of the reasons. There are more. Regular consumer PCs are almost entirely single-user machines on uninteresting networks. The major benefit to hacking a consumer PC is obtaining the user's data, which is naturally available in a user context (because of poor sandboxing).
Plenty of PCs, though, are more serious machines with multiple users, on interesting networks, or otherwise useful for long-term compromise. Long-term compromise, and doing other interesting things, really requires privilege escalation. Sure, there are lots of privilege-escalation vulnerabilities in desktop operating systems, but they keep getting fixed, so having them is actually relevant.
people still often really aren't that interested in exploits that already require code execution
I disagree. Privilege-escalation vulnerabilities are still pretty popular, just not as broadly applicable as remote code execution vulnerabilities.
Phone OSes, on the other hand, were built with sandboxing in mind from the start, and do not expect the attacker to be able to attack other apps.
That's the major interesting thing about this: that compromise of one app can cause the WeChat app to disclose potentially-sensitive data.
already successfully installed their own software on your phone
No, they're just able to execute code on your phone (in the context of some piece of software installed on your phone). There are plenty of approaches to remote code execution that are not the same as installing.
should be the least of your concerns at this point
While more or less true, vulnerabilities that enable you to do something dangerous with remote code execution capabilities are a major class of vulnerability. Just executing code in the context of some arbitrary application on the phone isn't necessarily very useful until you can do something evil with it.
I'm not sure that effect is oxidation, but otherwise, yes. The good way to do that is with a decanter, though, rather than just opening the bottle. The bottle's small neck limits airflow. If you're going to expose it to air, might as well do it fast.