In most parts of the world, everyone uses the government ISP already. That's a given.
This software is installed in an ISP that's beyond the control of the censors. I don't think Merit Network or the University of Colorado are going to worry much about whether they or their users are breaking the network laws of some random country halfway around the world.
They had the Psiphon folks doing the operations side of things. There's a presumption that the users can get the Psiphon software through some mechanism, and install it on their computers. I guess the Psiphon bundle includes the public key, maybe hidden in some way, maybe not, but in any case if they've figured out some way to sneak the Psiphon bundle past the bad guys, sneaking the public key past the bad guys seems like it wouldn't be any harder.
TFA doesn't provide much technical info, but the papers it links to explain this in some detail.
In a nutshell, crypto and steganography: using the public key of the system, the client hides a signal in a TLS connection, which the TapDance station can recognize because it knows the private key. If you don't know the private key, the TLS connection looks like an ordinary stream of encrypted TLS records. In fact, it is a valid TLS connection, so the server doesn't think anything is weird about it either.
If you can remember all your passwords, you aren't using strong, unique passwords for each of your accounts. Remembering passwords is what your keychain/lastpass/etc is for.
Some people used Tcl because for a while, it was the only way to use Tk, and Tk was handy.
But people who used Tcl for the sake of Tcl shouldn't be watched over, for their own good.
Oh, never mind. I saw the USENIX in the URL and jumped to a conclusion. It's just the Workshop on Offensive Technologies. Perfectly appropriate for that.
USENIX used to be one of my favorite conferences. Important work was presented there. Or at least work that, at the time, seemed like it had the potential to be important, although no program committee has yet been perfect at foreseeing the future...
Good grief, we know this is Slashdot so reading TFA is generally scoffed at, but at least read past the first sentence of a summary. The Subject of my post says it all. It is trivial to set up a proxy so that customer => Cloud service which can't be blocked => TOR.
You wrote that a proxies "aren't really necessary". I was responding to that. Good grief, indeed.
If you'd like to move the goalposts by claiming that the summary isn't want you wrote, that's fine. I'll respond to your claim that proxies are easy to set up. Yes, they are. And they're really easy to block too, if someone is motivated to do so. If they weren't difficult to block, there would be laws in place that would make them harder to set up.
The TLS handshake passes the name of the host being connected to (for the purpose of fetching its certificate) in plaintext. So if a site isn't being blocked, it's just a matter of time before the ISPs close this trivial loophole.
The next step is to ask for a different certificate that is being used on the same IP, by hacking the TLS handshake to specify a different hostname in the handshake than it uses in the HTTP request it sends later. This will probably just annoy whoever ends up paying for the bandwidth, and the loophole will get closed eventually.
They'd be 2.2 miles away, and they don't make noise. I have been much closer to similar windmills, and they're nearly silent--the wind itself is noisier.
Noise is wasted energy. Modern designs make very little.
I tested HWE on a few test systems before rolling it out across the rest of my systems. Long story short, several of the test systems had intermittent networking problems after the upgrade, which caused the systems to hang until power-cycled.
In my environment, stability is more important than having the latest gee-whiz features, and due to slashed budgets, supporting new hardware is a problem I don't have, so it's not worth the trouble to try to use the Trusty kernel right now.
This is unfortunate. I was hoping to not upgrade my Ubuntu 12.04 systems for another year or two, until the systemd dust settles, and I know other people in the same boat.
Yeah, if that's what happened. But that's not what the article says.
It says that on March 21st, Google had already fixed the flaw and rolled out the patches internally. Fine; they get to cover their own asses first. No argument.
I've worked with the IETF on several RFCs. I'm also familiar with the challenges that the Tor project faces daily, and what they have to do to stay ahead of the entities trying to break Tor. I think for Tor to even stop to talk to the IETF would be an waste of their time; Tor needs to be nimble, and the IETF standards process is painfully, horribly slow and unable to move quickly on anything. Given that Tor releases updates on a cycle that is shorter than the normal time a draft spends in the AD review queue, by the time an RFC got to the standards track it would already be out-of-date.
Slashdot Mirror
I'm guessing that this infatuation with scooters will end very quickly in many cities once there's snow and ice on the roads.
Geez.
In most parts of the world, everyone uses the government ISP already. That's a given.
This software is installed in an ISP that's beyond the control of the censors. I don't think Merit Network or the University of Colorado are going to worry much about whether they or their users are breaking the network laws of some random country halfway around the world.
They had the Psiphon folks doing the operations side of things. There's a presumption that the users can get the Psiphon software through some mechanism, and install it on their computers. I guess the Psiphon bundle includes the public key, maybe hidden in some way, maybe not, but in any case if they've figured out some way to sneak the Psiphon bundle past the bad guys, sneaking the public key past the bad guys seems like it wouldn't be any harder.
TFA (well, the second one, the USENIX paper) makes it clear that there are already two ISPs running this software.
Not a tier-1 ISP, granted, but MERIT carries a pretty large chunk of the traffic in and out of the Midwest. It's a start.
TFA doesn't provide much technical info, but the papers it links to explain this in some detail.
In a nutshell, crypto and steganography: using the public key of the system, the client hides a signal in a TLS connection, which the TapDance station can recognize because it knows the private key. If you don't know the private key, the TLS connection looks like an ordinary stream of encrypted TLS records. In fact, it is a valid TLS connection, so the server doesn't think anything is weird about it either.
If you can remember all your passwords, you aren't using strong, unique passwords for each of your accounts. Remembering passwords is what your keychain/lastpass/etc is for.
Some people used Tcl because for a while, it was the only way to use Tk, and Tk was handy. But people who used Tcl for the sake of Tcl shouldn't be watched over, for their own good.
Oh, never mind. I saw the USENIX in the URL and jumped to a conclusion. It's just the Workshop on Offensive Technologies. Perfectly appropriate for that.
USENIX used to be one of my favorite conferences. Important work was presented there. Or at least work that, at the time, seemed like it had the potential to be important, although no program committee has yet been perfect at foreseeing the future...
This just seems like a silly joke taken too far.
Good grief, we know this is Slashdot so reading TFA is generally scoffed at, but at least read past the first sentence of a summary. The Subject of my post says it all. It is trivial to set up a proxy so that customer => Cloud service which can't be blocked => TOR.
You wrote that a proxies "aren't really necessary". I was responding to that. Good grief, indeed.
If you'd like to move the goalposts by claiming that the summary isn't want you wrote, that's fine. I'll respond to your claim that proxies are easy to set up. Yes, they are. And they're really easy to block too, if someone is motivated to do so. If they weren't difficult to block, there would be laws in place that would make them harder to set up.
The TLS handshake passes the name of the host being connected to (for the purpose of fetching its certificate) in plaintext. So if a site isn't being blocked, it's just a matter of time before the ISPs close this trivial loophole.
The next step is to ask for a different certificate that is being used on the same IP, by hacking the TLS handshake to specify a different hostname in the handshake than it uses in the HTTP request it sends later. This will probably just annoy whoever ends up paying for the bandwidth, and the loophole will get closed eventually.
They'd be 2.2 miles away, and they don't make noise. I have been much closer to similar windmills, and they're nearly silent--the wind itself is noisier. Noise is wasted energy. Modern designs make very little.
That would be the sect that lined up again and again to buy tickets for "American Sniper"
The underscores are awful. Almost invisible.
Plus one informative.
This isn't a call for a boycott.
Well, let's see what TFA says:
Not only REFUSE to see the movie, but spread the word to as many men as possible.
What part of the word "boycott" do you not understand?
I tested HWE on a few test systems before rolling it out across the rest of my systems. Long story short, several of the test systems had intermittent networking problems after the upgrade, which caused the systems to hang until power-cycled.
In my environment, stability is more important than having the latest gee-whiz features, and due to slashed budgets, supporting new hardware is a problem I don't have, so it's not worth the trouble to try to use the Trusty kernel right now.
This is unfortunate. I was hoping to not upgrade my Ubuntu 12.04 systems for another year or two, until the systemd dust settles, and I know other people in the same boat.
Yeah, if that's what happened. But that's not what the article says.
It says that on March 21st, Google had already fixed the flaw and rolled out the patches internally. Fine; they get to cover their own asses first. No argument.
Then a week went by.
They haven't been in the press enough recently...
I want to know, but I also don't want to know.
Whatever it was, I can tell that it was chewy. And that I've lost my appetite.
I've worked with the IETF on several RFCs. I'm also familiar with the challenges that the Tor project faces daily, and what they have to do to stay ahead of the entities trying to break Tor. I think for Tor to even stop to talk to the IETF would be an waste of their time; Tor needs to be nimble, and the IETF standards process is painfully, horribly slow and unable to move quickly on anything. Given that Tor releases updates on a cycle that is shorter than the normal time a draft spends in the AD review queue, by the time an RFC got to the standards track it would already be out-of-date.
The real powerhouse in speech recognition tech isn't MIT -- it's BBN, at the other end of Cambridge.
Interest, yes. Cash, no.
That's what being very poor means.