I've been in internet cafes in Beijing, and the PCs are commodity level, with no special customizations. The government isn't going to make the cafe owners take special percautions. When it looks like there's any sort of a software problem, step one is to Ghost the hard disk with a bootable CD-ROM.
Executables on CD-ROMs or USB keys with HTTPort or similar is probaly the correct solution. The extent to which ordinary worms and viruses naturally play havoc with public PCs make detection of such subterfuge very difficult. The officials involved are more interested in assuring their superiors that they are on top of the problem than actually stifling dissent. As long as they can make an example of a few people per year, the rest of the country will probably be able to use google groups, yahoo mail, etc., with impunity.
Eventually one of the people made an example of will be seen to hae espused a popular or logical viewpoint, and there will be pressure to cut back on the iron fist. Then the fun begins.
A self-limiting one, as excessive humidity condenses into reflective clouds, whereas CO2 does not condense, absorbing infrared in proportion to its concentration. It doesn't matter how many variables and feedback loops are in the system, the facts remain that the increase in CO2 from fossil fuels is forcing far more energy into the atmosphere than before the advent of coal mining, and that amount of added energy is greater than the difference retained from H2O between dry air, disolved wet air, and condensed cloud cover.
I believe Rice's Theorem only applies if your computational model allows for infinite storage (or something equivalent).
On the contrary, both the halting problem and predicting another program's output are indecidable with finite and infinite resources.
The easiest way to explain it is that you need all the possible inputs to map out all the possible outputs, and with conditional branch loops there are an infinite number of both.
I know a couple longshoremen, and they say that the biggest time waster of work-to-rule at the Port of Oakland is the requirement that you need to get the foreman's signature for each parcel unloaded, after it's inspected for damage and before it gets put loaded on ground transport. And the foreman is supposed to personally examine the parcel before signing. (I.e., that's one signature for every container, one at a time, over the whole day.) The foreman has the ability to waive this requirement, if requested and agreed by the entire crew.
So, what happens is, the foreman (who is also union), stops getting any requests to waive the signature exemption, and spends the entire day with a clipboard doing paperwork. Clearly the foreman can't be held responsble for this action, and management doesn't really have a way to lean on the drivers and crane operators to kick in the exemption.
But, it isn't exactly what most people think of "work-to-rule." There's a good reason for the set-up, because the crane operators are forklift drivers need a way to protect themselves from damage claims. But it seems to me a little more like a strike action, even though it isn't, than simply strict "work-to-rule."
It seems that the best obscured and encrypted application-layer HTTP tunnel is HTTPort, which is very popular in Saudi Arabia.
However, it's clear that China doesn't block HTTPS/SSL or even SSH, so any of the ordinary transport-layer proxies would do, as would simple ssh-based port forwarding.
...to about the same extent that U.S. trafic enforcement is obliged to crack down on people failing to use their turn signals. I.e., hundreds of thousands of violations for every one warning, let alone citation.
When I joined the company, we did a 30-day analysis and review. I interviewed the top managers inside the company and a handful of people outside and asked, "Where do we go with this thing?" [SCO] had come down from being $1 billion in value down to about $5 million, it was a few quarters from being out of cash, and what became very clear to me early on was that there was a lot of value in the Unix intellectual property that wasn't being optimized.
Setting this up is a bit beyond "the non-technical PC user"
They don't have to set up the HTTPort servers. But if they wanted to, it's no more difficult than running an installer on their broadband-connected home PC.
The real problem is that when you don't block things like SSH, you can log when and where such connections are going. When you do, determined users migrate to something like HTTPort, and now you loose the ability to track such connections.
HTTP application layer firewalls are not just used for blocking outgoing stuff, you can run them infront of webservers to protect against a variety of exploits/overflows
You must be referring to IIS. Wouldn't it be better to just use a web server without vulnerabilities than spend for an external patching system?
Forcing everyone out the same few, comparatively unusual gates is far better than leaving them all open.
The more you make people go through things that don't appear to be gates, the less you can keep track of what is coming and going.
If you have SSH ports open, at least you can log the traffic. If you force users to rely on an HTTP application layer tunnel like HTTPort, then you'll never know what they are doing or where they are doing it.
Egress filtering. Application-level firewalls. This is EXACTLY what they exist for.
Sadly, they exist more to make a quick buck by giving ignorant admins a false sense of security.
Transports which tunnel through the HTTP application layer (not just SSH on port 80) using fully obscured forms of encryption are prevalent and readily available to the non-technical PC user. Such applications are very popular in Saudi Arabia and China, for example, primarily because there are presently no proxies capable of blocking them.
As soon as such proxies appear, the HTTP application layer tunnels will implement polymorphic protocols. There is no hint of evidence that the proxies have any chance of keeping up.
It is well known in the steganography community that any open channel, even email, is transparently insecure. Unless such channels are closely monitored by a professional cryptoanalyst, there is no chance that they can reliably prevented from carrying unwanted traffic.
No really, blocking SSH/ESP and tracking HTTPS is a reasonable suggestion -- if anything, I'd say the above doesn't go far enough.
Reasonable? Pointless.
Applications which tunnel through the HTTP application layer (not just SSH o port 80) using fully obscured forms encryption are prevalent and readily available to the non-technical PC user. Such applications are very popular in Saudi Arabia and China, for example. Primarily because there are, at this time, no proxies capable of blocking them.
And as soon as such proxies appear, the HTTP application layer tunnels will go polymorphic in their protocols. There is no hint of evidence that the proxies have any chance of keeping up.
It is well-known to the steganography community that any open channel, even email, are insecure. Unless such channels are closely monitored by a professional cryptographer, there is no chance that they can reliably be monitored to prevent unfriendly traffic.
[In October 2003, U.S. Treasury Secretary John Snow] declared, "... I am confident that this economic recovery will now be sustained and will produce loads of new jobs. Everything we know about economics indicates that the sort of economic growth expected for next year, 3.8 to 4 per cent, will translate into two million new jobs from the third quarter of this year to the third quarter of next year. That's an average of about 200,000 new jobs a month.... Jobs are always a lagging indicator which follows economic growth.
I would stake my reputation on employment growth happening before Christmas."
As if anyone remaining in the Bush administration has a good reputation to begin with.
Microsoft, [the Israeli Finance Ministry] said, "has recently broken its policy of unified pricing of products worldwide. In Thailand and England there were
reductions of hundreds of percent" on products that it sells.
Now that's the kind of discount I'd sure like to see more of!
Didn't Linus say that the files don't even contain code?
No, they have a few macros. The funny thing is that two of those macros have a very minor bug in that they aren't threadsafe (using static instead of automatic temporary variables.) So if SCO claims they own those... then who the hell owns the threadsafe SysV header file macros that predate Linus' files?
And if you can guess the original value of any of the length-sized blocks you can xor the pad out and decrypt the whole document from this point onwards....
Good point. Start from the middle of the file and wrap around?
Also two files encrypted with the same key will use the exact same pad.
Yeah, I remembered that one last night. Salt the keyphrase with a random 32 bits; append the salt to the cyphertext. No longer the same algorithm for encrypting and decripting. Any way around that which keeps the same algorithm?
The fact that [3DES]'s been studied for several years before being accepted as a standard ?
Please correct me if I am wrong, but last I heard, there is still an unresolved question about a trapdoor in DES.
It takes a lot to have a secure algorithm.
I think that may be something of a myth. Are there any reasonable attacks against XORing with a chain of secure hashes? MD5 has been around for over a decade, and nobody thinks it can be reversed yet. There aren't even any known collisions as far as I know.
Slashdot Mirror
I've been in internet cafes in Beijing, and the PCs are commodity level, with no special customizations. The government isn't going to make the cafe owners take special percautions. When it looks like there's any sort of a software problem, step one is to Ghost the hard disk with a bootable CD-ROM.
Try HTTPort, an encrypting steganographing proxy. It's a hard problem to tell HTTPort traffic from ordinary http traffic.
Eventually one of the people made an example of will be seen to hae espused a popular or logical viewpoint, and there will be pressure to cut back on the iron fist. Then the fun begins.
The easiest way to explain it is that you need all the possible inputs to map out all the possible outputs, and with conditional branch loops there are an infinite number of both.
So, what happens is, the foreman (who is also union), stops getting any requests to waive the signature exemption, and spends the entire day with a clipboard doing paperwork. Clearly the foreman can't be held responsble for this action, and management doesn't really have a way to lean on the drivers and crane operators to kick in the exemption.
But, it isn't exactly what most people think of "work-to-rule." There's a good reason for the set-up, because the crane operators are forklift drivers need a way to protect themselves from damage claims. But it seems to me a little more like a strike action, even though it isn't, than simply strict "work-to-rule."
Yeah, I've never had any trouble finding the recipies I needed on the net.
n/t
However, it's clear that China doesn't block HTTPS/SSL or even SSH, so any of the ordinary transport-layer proxies would do, as would simple ssh-based port forwarding.
...to about the same extent that U.S. trafic enforcement is obliged to crack down on people failing to use their turn signals. I.e., hundreds of thousands of violations for every one warning, let alone citation.
It looks like India could be joining Saudi Arabia and China in the list of countries where HTTPort is an essential install.
thanks
Back on topic, this story can explains the article all too well.
They don't have to set up the HTTPort servers. But if they wanted to, it's no more difficult than running an installer on their broadband-connected home PC.
The real problem is that when you don't block things like SSH, you can log when and where such connections are going. When you do, determined users migrate to something like HTTPort, and now you loose the ability to track such connections.
You must be referring to IIS. Wouldn't it be better to just use a web server without vulnerabilities than spend for an external patching system?
The more you make people go through things that don't appear to be gates, the less you can keep track of what is coming and going.
If you have SSH ports open, at least you can log the traffic. If you force users to rely on an HTTP application layer tunnel like HTTPort, then you'll never know what they are doing or where they are doing it.
Sadly, they exist more to make a quick buck by giving ignorant admins a false sense of security.
Transports which tunnel through the HTTP application layer (not just SSH on port 80) using fully obscured forms of encryption are prevalent and readily available to the non-technical PC user. Such applications are very popular in Saudi Arabia and China, for example, primarily because there are presently no proxies capable of blocking them.
As soon as such proxies appear, the HTTP application layer tunnels will implement polymorphic protocols. There is no hint of evidence that the proxies have any chance of keeping up.
It is well known in the steganography community that any open channel, even email, is transparently insecure. Unless such channels are closely monitored by a professional cryptoanalyst, there is no chance that they can reliably prevented from carrying unwanted traffic.
Reasonable? Pointless.
Applications which tunnel through the HTTP application layer (not just SSH o port 80) using fully obscured forms encryption are prevalent and readily available to the non-technical PC user. Such applications are very popular in Saudi Arabia and China, for example. Primarily because there are, at this time, no proxies capable of blocking them.
And as soon as such proxies appear, the HTTP application layer tunnels will go polymorphic in their protocols. There is no hint of evidence that the proxies have any chance of keeping up.
It is well-known to the steganography community that any open channel, even email, are insecure. Unless such channels are closely monitored by a professional cryptographer, there is no chance that they can reliably be monitored to prevent unfriendly traffic.
...just like it was 50 years ago.
As if anyone remaining in the Bush administration has a good reputation to begin with.
They're obviously listening. As Mekkab said, "Use the promotional code 'LINUX; and get thousands off your Microsoft installation costs!"
Quoth the article:
Now that's the kind of discount I'd sure like to see more of!
Propose a campground as the next venue.
No, they have a few macros. The funny thing is that two of those macros have a very minor bug in that they aren't threadsafe (using static instead of automatic temporary variables.) So if SCO claims they own those... then who the hell owns the threadsafe SysV header file macros that predate Linus' files?
Good point. Start from the middle of the file and wrap around?
Yeah, I remembered that one last night. Salt the keyphrase with a random 32 bits; append the salt to the cyphertext. No longer the same algorithm for encrypting and decripting. Any way around that which keeps the same algorithm?
Please correct me if I am wrong, but last I heard, there is still an unresolved question about a trapdoor in DES.
I think that may be something of a myth. Are there any reasonable attacks against XORing with a chain of secure hashes? MD5 has been around for over a decade, and nobody thinks it can be reversed yet. There aren't even any known collisions as far as I know.