Certificate Patrol (https://addons.mozilla.org/en-US/firefox/addon/6415) watches for changes in SSL certificates and alerts you to those changes, so you can decide if someone is pulling an SSL MITM attack on you. If the Chinese routers are running SSL interceptors (e.g., Cisco's IronPort or Bluecoat's ProxySG), then you will see alerts that the SSL certs you last got from within the US are different in China.
SSH's -D option activates the built-in SOCKS proxy in the SSH client, so all you have to do is:
ssh -D 8080 -N trustedhost
then configure your browser to use a SOCKS5 proxy on localhost:8080 (and also to use the proxy for DNS lookups, otherwise you leak the DNS names of the sites you browse to).
[...] this should come with a warning from a browser, no question, but my users will know the site and the cert.
Knowing the site doesn't help if a MITM is watching all the sensitive traffic flowing in both directions. And will your users really know the cert? Do your users have cert hashes memorized, or are they using the excellent "Certificate Patrol" Firefox add-on (https://addons.mozilla.org/en-US/firefox/addon/6415) that alerts users to changes in certs over time?
The fact that, when users visit your site, their browser will flip out, raise a "security warning" and lie to them saying your certificate is "invalid".
It depends on what "invalid" means. A lot of people consider an SSL/TLS cert to be valid if the signature chain contains only trusted CAs. If joeblow.com uses a self-signed cert (and joeblow.com is not itself a trusted CA), that cert is useless for validating the identity of the server. Yes, you get encryption, but that's only half of what SSL/TLS is for.
The world's shortest explaination of Godel's Incompleteness Theorem by Raymond Smullyan.
We have some sort of machine that prints out statements in some sort of language. It need not be a statement-printing machine exactly; it could be some sort of technique for taking statements and deciding if they are true. But lets think of it as a machine that prints out statements. In particular, some of the statements that the machine might (or might not) print look like these:
P*x (which means that the machine will print x) NP*x (which means that the machine will never print x) PR*x (which means that the machine will print xx) NPR*x (which means that the machine will never print xx)
For example, NPR*FOO means that the machine will never print FOOFOO. NP*FOOFOO means the same thing. So far, so good.
Now, lets consider the statement NPR*NPR*. This statement asserts that the machine will never print NPR*NPR*.
Either the machine prints NPR*NPR*, or it never prints NPR*NPR*. If the machine prints NPR*NPR*, it has printed a false statement. But if the machine never prints NPR*NPR*, then NPR*NPR* is a true statement that the machine never prints.
So either the machine sometimes prints false statements, or there are true statements that it never prints. So any machine that prints only true statements must fail to print some true statements. Or conversely, any machine that prints every possible true statement must print some false statements too.
That works for you and me, but this was a system invented to create secure Web browsing for everyone (including non-technical people). It can be argued that it doesn't do that.
A decade ago, I observed that commercial certificate authorities protect you from anyone from whom they are unwilling to take money. That turns out to be wrong; they don't even do that much.
Unfortunately, through a confluence of sloppy design, naked commercial maneuvering, and bad user interfaces, today's web browsers have evolved to accept certificates issued by a surprisingly large number of root authorities, from tiny, obscure businesses to various national governments. And a certificate from any one of them is usually sufficient to bless any web connection as being "secure".
For instance, Firefox 3.6 comes with a CA cert built-in from TÜRKTRUST Elektronik Sertifika Hizmet Salaycs, whoever they are. It's self-signed and doesn't expire until 2015. There are well over 100 CA certs in Firefox 3.6. We basically have to trust every one of those organizations not to snoop our SSL traffic. There has to be a better way.
[...] or run a script to fetch the cert from the site (using the openssl command-line util) and compare it to a known-good copy of the cert before you visit the site.
Such a script would do something equivalent to these manually entered commands:
Of course, file knowngood-gmailcert.txt should be under your physical control at all times (i.e, on CD/DVD or mounted read-only via TrueCrypt). If the certs fail to match, it's either because your SSL traffic is being intercepted by a MITM attack or the old cert expired and a new one was issued (this will happen periodically). If it's the latter, you can fetch the updated cert via a trusted channel (i.e., not from work) and repeat.
The certs obtained this way will be base64-encoded. To dump one in human-readable form, do this:
Would this not also require a redirect to a domain other then mail.google.com?
Nobody other then google should be able to generate a certificate for mail.google.com
SSL interceptors (such as the one made by Bluecoat) work by intercepting IP traffic bound for port 443. They pull a MITM attack on you by making a new SSL connection to the actual site, extracting the site's public key from the real cert, wrapping it in a forged cert that is signed by their CA cert. All the IT department has to do is install the interceptor's CA cert into each employee's browser (IE lets the domain admin do it remotely) so that the forged cert appears to be valid.
So you either check for IT-installed CA certs in your browser (the Certificate Patrol add-on helps with Firefox), or run a script to fetch the cert from the site (using the openssl command-line util) and compare it to a known-good copy of the cert before you visit the site.
While I might not like that google reads all my email, at least I can be sure that it gets from their servers to my computer without being read by snoopers.
Unless you verify that the cert your browser gets for mail.google.com has not been replaced by SSL interception software, you cannot be certain your mail isn't being snooped by your employer (or even your employer's upstream provider). A nice tool for detecting changed SSL certs is the Certificate Patrol add-on for Firefox (https://addons.mozilla.org/en-US/firefox/addon/6415).
Quantum mechanics would like to have a word with you.
And Chaos Theory as well. Hell, you can get lots of very random bits by running the Entropy Gathering Daemon (http://egd.sourceforge.net/) configured to fetch weather satellite photos of the Web. It's not quantum randomness, but chaos works too.
The universe extends so far in every direction that no matter where you look, you get objects receding from you at the speed of light.
Just to be clear, the highest redshift object is galaxy IOK-1 with a redshift of z = 6.96, which is nowhere near high enough for the object to be moving away from us at nearly the speed of light.
If your boss demands a password, you have to give it, by law. If he demands you give it to another person, or 20 other people, you have to give it, by law.
What insane country do you live in where not obeying what your boss is a crime? In the US private sector, employees enter a contract with their employers. Not doing what your boss says is probably a violation of that contract (which will likely get you fired), but it won't get you prosecuted for a crime.
I qualified the above with "in the US private sector", because this doesn't apply to certain public sector jobs (i.e., elected/appointed officials), public safety jobs, and, of course, the military.
Are you seriously suggesting a government should be able to force a private company to stop working on its own product and work on some other organization's product? That's a slippery slope that leads to a world I don't want to live in.
And has that ever happened in the history of antitrust litigation?
If Bill or Amy flip a coin, then instantly the other one KNOWS the other person flipped a coin at that point in time.
Nobody has said that. How can Bill's measurement force Amy to make her measurement at the same time? That's not possible. Especially since "at the same time" has no meaning for spacelike-separated events (cf. the Relativity of Simultaneity).
This is what happens: Bill measures a random value. Amy measures a random value. The two values are both random, but 100% correlated with each other. Bill knows what value Amy measures and vice versa, but no information has been transmitted, because the values are random.
I don't think you can tell when a particle is measured without measuring it which then collapses the waveform anyway.
Sort of. Neither side can tell when the wavefunction collapses due to the other side performing a measurement. Both sides see completly random (but correlated) results from their measurements. It is that randomness that prevents superluminal signaling.
We shall entangle two particles and you shall have one and I shall have one. You will "collapse the waveform" or whatever these Star Trek raised modern physicists want to call it on an even second to send a "1" and on an odd second to send a "0". Since I will instantly see the change on my magic fairy dust atom we shall be able to send information by measuring the time of the change. Sure, our bandwidth won't be real hot, but it's a good experiment, no?
No. You will not "instantly see the change" to your entangled particle/atom. You must perform a measurement that _always_ gives a random result. The only thing QM promises (and it's quite a promise) is that your random measurement result will always be perfectly correlated to the random measurement result at the other end. This happens even if the two measurement events are so far apart there is not enough time for a signal to move at lightspeed between them.
He can't. He's basically saying that his measurements will impose a pattern on the series of particles one one side, and a correlated pattern on the series of particles on the other side. The _problem_ is that the patterns are random on both sides.
Seriously, FTL signaling enables reverse causality (i.e., future events affecting past events). And that just isn't going to happen.
Slashdot Mirror
Certificate Patrol (https://addons.mozilla.org/en-US/firefox/addon/6415) watches for changes in SSL certificates and alerts you to those changes, so you can decide if someone is pulling an SSL MITM attack on you. If the Chinese routers are running SSL interceptors (e.g., Cisco's IronPort or Bluecoat's ProxySG), then you will see alerts that the SSL certs you last got from within the US are different in China.
SSH's -D option activates the built-in SOCKS proxy in the SSH client, so all you have to do is:
then configure your browser to use a SOCKS5 proxy on localhost:8080 (and also to use the proxy for DNS lookups, otherwise you leak the DNS names of the sites you browse to).
See "How to Break Out from Inside a Draconian Firewall": http://technotes-fran.blogspot.com/2009/11/how-to-break-out-from-inside-draconian.html
[...] this should come with a warning from a browser, no question, but my users will know the site and the cert.
Knowing the site doesn't help if a MITM is watching all the sensitive traffic flowing in both directions. And will your users really know the cert? Do your users have cert hashes memorized, or are they using the excellent "Certificate Patrol" Firefox add-on (https://addons.mozilla.org/en-US/firefox/addon/6415) that alerts users to changes in certs over time?
The fact that, when users visit your site, their browser will flip out, raise a "security warning" and lie to them saying your certificate is "invalid".
It depends on what "invalid" means. A lot of people consider an SSL/TLS cert to be valid if the signature chain contains only trusted CAs. If joeblow.com uses a self-signed cert (and joeblow.com is not itself a trusted CA), that cert is useless for validating the identity of the server. Yes, you get encryption, but that's only half of what SSL/TLS is for.
The world's shortest explaination of Godel's Incompleteness Theorem by Raymond Smullyan.
We have some sort of machine that prints out statements in some sort of language. It need not be a statement-printing machine exactly; it could be some sort of technique for taking statements and deciding if they are true. But lets think of it as a machine that prints out statements. In particular, some of the statements that the machine might (or might not) print look like these:
For example, NPR*FOO means that the machine will never print FOOFOO. NP*FOOFOO means the same thing. So far, so good.
Now, lets consider the statement NPR*NPR*. This statement asserts that the machine will never print NPR*NPR*.
Either the machine prints NPR*NPR*, or it never prints NPR*NPR*. If the machine prints NPR*NPR*, it has printed a false statement. But if the machine never prints NPR*NPR*, then NPR*NPR* is a true statement that the machine never prints.
So either the machine sometimes prints false statements, or there are true statements that it never prints. So any machine that prints only true statements must fail to print some true statements. Or conversely, any machine that prints every possible true statement must print some false statements too.
If my calculations are correct, when this baby hits eighty-eight miles per hour... you're gonna see some serious shit.
Oh, wait. That was the Flux Capacitor not the Oscillation Overthruster. I always get those two confused.
Or delete them.
That works for you and me, but this was a system invented to create secure Web browsing for everyone (including non-technical people). It can be argued that it doesn't do that.
A decade ago, I observed that commercial certificate authorities protect you from anyone from whom they are unwilling to take money. That turns out to be wrong; they don't even do that much.
Unfortunately, through a confluence of sloppy design, naked commercial maneuvering, and bad user interfaces, today's web browsers have evolved to accept certificates issued by a surprisingly large number of root authorities, from tiny, obscure businesses to various national governments. And a certificate from any one of them is usually sufficient to bless any web connection as being "secure".
For instance, Firefox 3.6 comes with a CA cert built-in from TÜRKTRUST Elektronik Sertifika Hizmet Salaycs, whoever they are. It's self-signed and doesn't expire until 2015. There are well over 100 CA certs in Firefox 3.6. We basically have to trust every one of those organizations not to snoop our SSL traffic. There has to be a better way.
[...] or run a script to fetch the cert from the site (using the openssl command-line util) and compare it to a known-good copy of the cert before you visit the site.
Such a script would do something equivalent to these manually entered commands:
Of course, file knowngood-gmailcert.txt should be under your physical control at all times (i.e, on CD/DVD or mounted read-only via TrueCrypt). If the certs fail to match, it's either because your SSL traffic is being intercepted by a MITM attack or the old cert expired and a new one was issued (this will happen periodically). If it's the latter, you can fetch the updated cert via a trusted channel (i.e., not from work) and repeat.
The certs obtained this way will be base64-encoded. To dump one in human-readable form, do this:
HTTPS won't help you if your company's IT department has admin access to your machine. SSL interceptors are commercially available that can do a Man-in-the-Middle (MITM) attack on your secure connection (thus exposing your encrypted traffic to snooping). See http://searchsecurity.techtarget.com.au/articles/35660-TUTORIAL-How-SSL-encrypted-Web-connections-are-intercepted for details.
Would this not also require a redirect to a domain other then mail.google.com?
Nobody other then google should be able to generate a certificate for mail.google.com
SSL interceptors (such as the one made by Bluecoat) work by intercepting IP traffic bound for port 443. They pull a MITM attack on you by making a new SSL connection to the actual site, extracting the site's public key from the real cert, wrapping it in a forged cert that is signed by their CA cert. All the IT department has to do is install the interceptor's CA cert into each employee's browser (IE lets the domain admin do it remotely) so that the forged cert appears to be valid. So you either check for IT-installed CA certs in your browser (the Certificate Patrol add-on helps with Firefox), or run a script to fetch the cert from the site (using the openssl command-line util) and compare it to a known-good copy of the cert before you visit the site.
While I might not like that google reads all my email, at least I can be sure that it gets from their servers to my computer without being read by snoopers.
Unless you verify that the cert your browser gets for mail.google.com has not been replaced by SSL interception software, you cannot be certain your mail isn't being snooped by your employer (or even your employer's upstream provider). A nice tool for detecting changed SSL certs is the Certificate Patrol add-on for Firefox (https://addons.mozilla.org/en-US/firefox/addon/6415).
Quantum mechanics would like to have a word with you.
And Chaos Theory as well. Hell, you can get lots of very random bits by running the Entropy Gathering Daemon (http://egd.sourceforge.net/) configured to fetch weather satellite photos of the Web. It's not quantum randomness, but chaos works too.
The universe extends so far in every direction that no matter where you look, you get objects receding from you at the speed of light.
Just to be clear, the highest redshift object is galaxy IOK-1 with a redshift of z = 6.96, which is nowhere near high enough for the object to be moving away from us at nearly the speed of light.
If your boss demands a password, you have to give it, by law. If he demands you give it to another person, or 20 other people, you have to give it, by law.
What insane country do you live in where not obeying what your boss is a crime? In the US private sector, employees enter a contract with their employers. Not doing what your boss says is probably a violation of that contract (which will likely get you fired), but it won't get you prosecuted for a crime.
I qualified the above with "in the US private sector", because this doesn't apply to certain public sector jobs (i.e., elected/appointed officials), public safety jobs, and, of course, the military.
Two words: secret sharing
The Executive, Legislature, and Court are supposed to balance each other.
The Legislature in no way has complete primacy in the US form of representative democracy.
True. If anything, the Executive branch has evolved to have primacy over the others (cf. http://en.wikipedia.org/wiki/Imperial_presidency).
and work on Firefox instead.
Are you seriously suggesting a government should be able to force a private company to stop working on its own product and work on some other organization's product? That's a slippery slope that leads to a world I don't want to live in.
And has that ever happened in the history of antitrust litigation?
I deleted my account too, but I was able to do via the Web interface, without involving customer services.
If Bill or Amy flip a coin, then instantly the other one KNOWS the other person flipped a coin at that point in time.
Nobody has said that. How can Bill's measurement force Amy to make her measurement at the same time? That's not possible. Especially since "at the same time" has no meaning for spacelike-separated events (cf. the Relativity of Simultaneity).
This is what happens: Bill measures a random value. Amy measures a random value. The two values are both random, but 100% correlated with each other. Bill knows what value Amy measures and vice versa, but no information has been transmitted, because the values are random.
I don't think you can tell when a particle is measured without measuring it which then collapses the waveform anyway.
Sort of. Neither side can tell when the wavefunction collapses due to the other side performing a measurement. Both sides see completly random (but correlated) results from their measurements. It is that randomness that prevents superluminal signaling.
So does this mean it is possible to send information using entangled particles, but we just have no idea how to do it?
No. Superluminal signaling leads to reverse causality (future events affecting past events), and that's widely considered impossible.
We shall entangle two particles and you shall have one and I shall have one. You will "collapse the waveform" or whatever these Star Trek raised modern physicists want to call it on an even second to send a "1" and on an odd second to send a "0". Since I will instantly see the change on my magic fairy dust atom we shall be able to send information by measuring the time of the change. Sure, our bandwidth won't be real hot, but it's a good experiment, no?
No. You will not "instantly see the change" to your entangled particle/atom. You must perform a measurement that _always_ gives a random result. The only thing QM promises (and it's quite a promise) is that your random measurement result will always be perfectly correlated to the random measurement result at the other end. This happens even if the two measurement events are so far apart there is not enough time for a signal to move at lightspeed between them.
Weird, huh?
He can't. He's basically saying that his measurements will impose a pattern on the series of particles one one side, and a correlated pattern on the series of particles on the other side. The _problem_ is that the patterns are random on both sides.
Seriously, FTL signaling enables reverse causality (i.e., future events affecting past events). And that just isn't going to happen.