Neutrinos are not charged. Therefore they don't give off Cherenkov radiation.
I'm under the impression that it's the "reverse" of n -> p + e + v_e'; n + v_e -> p + e that is the usual reaction that is needed - probably the e then gives off Cherenkov radiation.
As much as I *hate* to stick up for Bush, the truth of the matter is that Saddam bluffed and we called him on it. He did everything he could to make everyone believe he had WMDs.
While I appreciate it's now Bush's best ally in the middle east, Saddam had a problem with a large neighbour he had been fighting wars with on and off for decades. He was "forced" to walk a tightrope - on the one hand he wanted to discourage an invasion from his neighbour by pretending to have WMD and at the same time discouraging an invasion from the US by admitting that he didn't have any.
Of course, since America (and the UK) invaded Iraq, Iran has been a paragon of virtue and is Bush's best friend and is no longer having anything to do in, or any designs on, Iraq.
Not sure if you're talking about superluminal travel or subluminal travel.
Theory already allows slower than light travel. You're spaceship would have to be big. VERY big. But if we really wanted to we could probably send mankind to the nearest stars with current technology.
But superluminal travel is a different kettle of fish. There are only two possible universes, one where there's an upper limit in the speed of information and another where there is no upper limit. The two universes have very different characteristics and our universe appears to be the smaller. It's hard to think of a way where you can transmit matter without also allowing information transfer.
Of course, even today faster than light travel is possible by current theory - but only by points A and B separating faster than light, not by allowing points A and B to communicate faster than light. Effectively this means that the speed of light is only constant locally. Maybe it would be possible to reverse the expansion and shrink the universe so that although the speed of light would still be an upper limit, communication between A and B could occur in less time than light could make the journey in a flat universe.
But I'd wager that faster than light travel in the special relativity sense is, and always will be, impossible.
No offense, but you're assuming that somebody who bothers to set up a MITM using a trusted cert (rather than the quite easy approach of an MITM using an untrusted one) isn't going to notice that the site you're requesting lacks a trusted cert?
Think about this. Lets assume I'm going to be the bad guy launching the MITM. Lets also assume that I've got the Verisign private key from verisign. Lets further assume that I can mount a MITM attack against you. (maybe I'm the NSA or something)
Case 1: You connect to a site that is using a cert signed by one of the big CAs. It's 99.9% certain that your browser will accept this cert without a warning so I should generate a MITM cert signed by verisign.
Case 2: You connect to a site that is using a cert signed by someone I don't recognise. Lets also assume that you've added that cert to your trusted list. So I should still generate a MITM cert signed by verisign so that your browser generates no warning.
Case 3: You connect to a site that is using a cert signed by someone I don't recognise. But you haven't added the cert to your trusted list. Now I should generate a MITM cert signed by something random so that your browser does generate a warning.
But I, as the NSA, cannot distinguish between case 2 and case 3. So I might just as well sign everything by verisign. And in case 3, the only warning you will get is that the popup doesn't appear which you are more likely to miss than that an unexpected popup does appear which would be the effect for case 2.
The problem that I'm trying to solve is "Is this the same machine I connected to last time". If you're using SSH then the first time you connect to a machine you get a message along the lines of "Host key not recognised: do you want to continue" and depending on your paranoia you can check fingerprints, call up the sysadmin etc to make sure you've got the right machine. After that it's silent unless the host key changes at which point you get a message along the lines of "WARNING HOST KEY HAS CHANGED. SOMEONE MIGHT BE DOING SOMETHING NASTY. AGENT FORWARDING DISABLED".
Browsers don't do that. And I don't know why not. At the end of the day it doesn't really matter who signed the original cert - if you trust verisign then the first time you connect to a site, if you get a verisign signed cert then you can just accept it. If you don't then you'll have to do some more investigating. But after that, if the key changes for that site then you should be worried.
Of course, I suspect that many websites change their keys arbitrarily and don't get the same csr re-signed each year but just generate a new one. But that is a problem with the website, not with the way certs ought to be being used.
It only guarantees that the domain of the site you've connected to matches the domain in your browser bar.
So I set up a company usesave. It doesn't really matter what the company was going to do.
I then get a cert from verisign for my usesave company.
I then setup www.usesave.co.uk, and maybe even phish people with "you must check your details" and wait for people to typo www.icesave.co.uk or click on links in the phishing email.
Of course, hopefully, the site will get shut down quickly, but it's unlikely to be quickly enough not to catch some people out. The steps above might have cost me a few hundred pounds. I can set it all up and then "disappear" before actually triggering the phish. During the setup time my website is displaying a "How to save the environment by reusing the stuff you throw away: Coming soon"
But instead, icesave could have had their own root cert. And despite being an online bank, you do still have some paperwork from them which could have included the fingerprint of their root cert.
Now I can explicitly allow icesave's root cert and it doesn't matter if someone sets up usesave. If I typo it I won't recognise their root cert so I'll be alerted to the typo.
Of course, browsers don't make this at all easy to do. And, of course, icesave could still give their fingerprint on their paperwork (they don't).
For less critical transactions it's less important. If I'm just buying something online then the verisign checks are probably fine. I'm not likely to have any good way of verifying the companies cert. But there's no loss of security by still having a self signed cert - it's actually impossible for me to tell if the people I'm talking to are crooks - and verisign confirming that yes, I've really connected to the crooks and the good guys haven't intercepted my connection really doesn't help me.
What certs really give is the potential to confirm that the person you're talking to today is the same as the person you were talking to yesterday. But that's not the way they're used at all.
I don't thing you've actually read my original post. Either that or you haven't understood.
The MITM can add root certs to the client and has a root cert in the client that they can control.
Yes, it's possible for the MITM to make any site behave the way it used to. That is by definition and there's no way to prevent it.
But you have a choice of ways it works for sites that you control.
1. No popups etc. Everything looks identical. Only if you decide to go and look at the certificate independently of your browsing will you be able to detect that your expected root cert has been substituted. If the phone rings as you connect you might even forget whether you've actually checked it this time or not when you return to your browsing.
2. Popup every time. Now you have to make a decision whether to accept that root cert every time. Of course you can always just press OK. Then your security just degenerates to case 1. But you explicitly have to make the choice _not_ to check the certificate.
I do check (especially if I'm at a web cafe). And I also know the first couple of words of the fingerprint of the cert.
Of course I could also check by bringing up the cert but I have to remember to do that.
Self signed certificates don't prevent attacks but they do mean that the attack cannot easily be automated."
Umm. No.
These attacks can be very very easily automated.
1 - Spot SSL connection and become a proxy. 2 - When server sends certificate, read all the fields and create new certificate with identical ones but a different public/private key pair. 3 - sign this with a random, and still unknown CA 4 - Send this new one on to the client. You now have two SSL sessions going, and the client doesn't have a clue what happened.
I disagree.
The MITM has to somehow determine whether the client knows the root cert or not.
If the client knows the root cert then the MITM has to sign the new certificate with a root cert known to the client (and in my case the supposed MITM controls the client and therefore can always do this)
If the client doesn't know the root cert then the MITM has to sign the new certificate with a root cert unknown to the client.
In case 1 the interception is completely invisible. You have to explicitly go and check the certificate to see if the root cert has changed from the expected value. And if you do nothing at all then everything will work.
In case 2 you will get a popup and you will have to accept the cert for the session. If you chose not to "view details" and check the fingerprint then that is your choice but you've still got to make an explicit choice whether to accept the certificate or not.
In the case of wholescale interception of every ssl connection the assumption will be that the client will know the root cert.
I've had certificates signed by verisign (might have been Thwarte - was a while ago now) for a small company. It really isn't difficult in the UK to setup a company and get the necessary paperwork to jump through the hoops to get a certificate.
The problem is that sites like: https://www.securesuite.co.uk/rbs/tdsecure/opt_in.jsp I'm expected to trust for everything even when I get unexpectedly redirected to them from another website and yet my certificate looked pretty much identical to that one.
If my bank asked me to go to "other bank" in order to pay money into my account at my bank and said "You'll be able to confirm that it really is other bank because they'll have paperwork signed by us to prove it" then yes, I would trust my bank.
I was using a natwest debit card (who happen to be owned by RBS).
The site didn't work properly (I just got a blank page) but it was supposed to be asking me for various letters from a password for my card for the "verified by visa" scheme.
Was it a scam site that didn't work or was it the real site that didn't work? Can you tell from the certificate?
"When is it acceptable to encourage users to accept a self-signed SSL cert?"
The answer is: Never.
What is the point of being sure that no one can intercept your communication all the way from your browser to the server if you don't know who you are talking to in the first place?
If someone knocked to your door and asked for your money would you give it to him because he has a bulletproof truck so the money will be safe all the way to whatever it is going to? Or would you trust the guy in the truck because he showed you a self-signed document saying: "I am authorised to do what I'm doing. Signed: me." Of course not!
But you'd be happy if you'd arranged with your bank for a truck to come and pick up the money, and when the truck arrived and you asked to see his documentation he said "Here it is, guaranteed by Fred Bloggs over there." And you have no relationship with Fred Bloggs (although you guess your bank does because the driver says so!) and no comeback against Fred Bloggs if he screws up even if he does have a relationship with your bank.
Quite frankly what I'd want is my bank having its own root cert that was self signed. I can confirm with my bank that I've got the right cert. And then when the driver turns up he can say "Here it is, guaranteed by your bank". And if the bank has screwed up and let some third party get hold of their root cert private key then I've got a relationship with the bank and I can sue them.
And when I communicate with my bank I should be able to give them my root cert and then they can check I'm who I say I am (they can use other methods as well if they don't think that is secure enough)
IIRC the hmrc website (UK TAX) allows you to use client side certificates to communicate with them but doesn't allow self signed ones. But why not? Is hmrc more confident that verisign can tell who I am than hmrc itself is? As a result I don't use a client side certificate.
IMO, self signed certificates can be more secure. And for the site in question there's a risk of governments strongarming the certificate authorities to provide signed certificates so the government can launch MITM attacks.
I have a https website on my home machine that occasionally I connect to from work.
Now I get a popup about how the certificate issuer isn't recognised etc.
If someone at work (who controls the browser, the proxy, the network etc) decided to sniff all SSL traffic - which they could do with a MITM attack because they control at least one of the allowed root certs in the browser - my popup would disappear (unless they were very careful)
Likewise, my mail servers all use self signed certificates. Again, someone trying to attack me by getting verisign (or whoever) to sign a certificate, will not work.
Self signed certificates don't prevent attacks but they do mean that the attack cannot easily be automated.
(Actually I have a single self signed root cert that I then use to sign all my other certs rather than each cert being self signed)
It's swings and roundabouts. Verisign et al have built a whole industry out of convincing people to trust them more than the person's own bank.
I'm surprised we don't already see spam attempting to get people to install new root certs. (Or maybe we do - almost all the spam I get gets stopped by greylisting or caught by spamassassin)
Looks like CO2 is a solid at room temperature at around 4000 atmospheres. I'd never seen the phase diagram plotted out beyond about 100 atmospheres before.
Not sure about helium. If it can sublimate then it's going to be way up the phase diagram at enormous pressure at or close to the critical temperature. But it can definitely go straight from the superfluid state to the vapour state.
It's quite bizarre when you watch He4 transition to superfluid as you reduce the pressure. It's boiling away vigourously and then suddenly all the boiling stops (and it becomes quite difficult to see because it's refractive index is so close to 1)
IMO Clarity is important but it's not the most important thing when writing code.
1. Correctness. If the code doesn't work (as it was supposed to have been designed to do) then it's wrong. It doesn't matter how beautiful it is. I've worked with people who have provided a library plus API for some functionality and I've been unable to get it to work EVER. They've claimed that they've tested it. I've been unable to find any case that works. In the end I was forced to rewrite it from scratch. (I've yet to receive any beautiful code that fails like this - unless you count pretty boxes for comments and correctly indented as beautiful)
2. Robustness. I'm not talking about ability to handle unexpected input here - that comes under correctness. I'm talking about if someone needs to make a change in the future to support some new requirements, how robust is the code to a small change leaving (most of) the old functionality still working correctly. Many many years ago I remember working on some code (DOS code to drive hardware over serial port) that had some timing constraints (of the order of 1/100s) but nothing exceptionally difficult to achieve even in those days. The code mostly worked (although it failed intermittently) but was so sensitive to changes that moving a bit of functionality out into a subroutine would affect the timing enough to cause it to fail most of the time. In the end, the only solution was to rewrite from scratch.
3. Clarity. Once the other two are fulfilled then clarity is important. But most of the time it's pretty hard to fulfill both 1 and 2 without also giving 3. Mostly 3 becomes alerting people to weird quirks in the code that have been done for a reason but aren't necessarily obvious at first glance. Comments are dangerous because they can be wrong even if the code is correct and robust. The very best code is correct, robust and doesn't need comments at all. Comments can break 2 - a small change to the code can silently break the comment. If the comment is at a high enough level then comments can sometimes be robust against small changes to the code. And some things are impossible to do in a small compact piece of code - then you need a small compact comment to give you the overview. Sometimes low level comments are required in code because requirements have changed so variable or function names no longer make sense in the new context. Of course, in an ideal world, we'd go and fix all those names everywhere.
Solution to the current bubble: When the contract becomes due, pull up to the trader's office with a tanker truck and flood the building with the crude. That'll teach'em not to speculate.
Erm.... That's what happens.
Most of the time, the speculator closes out his contract before delivery, i.e. he finds someone else who wants delivery (or who is contracted to deliver but doesn't have any oil).
But occasionally the speculator gets caught with his pants down. On the third of October 2006, the spot price for Natural Gas in the UK went negative. There were people contracted to take delivery of the gas and they had to pay someone else to take it off their hands.
IIRC with quantum cloning you can get 5/6 fidelity in a universal quantum cloning machine. This is an upper limit. Any higher and weird, impossible, things like faster than light communication become possible. Lab implementations have made it into the 80%+ fidelity bracket.
Non universal quantum cloning has been less studied. In some cases it's obvious and trivial what the best implementation is (100% for cloning a photon in a known polarization state - just put a lightbulb behind a polarization filter at the correct angle). In other cases it's not obvious (I think unknown) what the best approach might be.
For an ideal UCM, 83.3% of the time you get the same result as the original would have done.
Although this sounds very high, it's not that high when you consider a naive UCM that doesn't touch the original but just creates a second particle/photon in a random state gets 75% fidelity - 50% of the time both measurements will come out correct and 50% of the time one of them will so 3/4 measurements give the correct result.
Get the herd in a froth about some minor issue -- changing a detention limit from 28 to 42 days
This is all part of the plan to get the limit up from 7 days to 90 days.
Yes really.
In 2000 the limit for holding terrorist suspects without charge was 7 days. (Terrorism Act 2000) 2003 it went to 14 days 2006 it went to 28 days 2009(ish) will be 42 days. (Maybe there'll be a compromise of 38 days or something)
The 2006 raise was a stab at 90 days with Tony B realizing that he could never sell it and the Lords and Commons compromised on 28 days. But by 2007 the Government had already put the wheels in motion to extend it again.
Personally I think 7 days is too much. I realize that inevitably there has to be a short period unless you are going to charge people instantly but I'd like to see the Lords amending this bill down to 72 hours plus the ability to question after charge. Not going to happen though.
what are you doing by looking? taking some energy away? converting the photon into something else? you must be doing something what is that something?
You're collapsing the wavefunction into an eigenfunction of the Hamiltonian and measuring the corresponding eigenvalue.
But NOBODY knows what that means in the real world. You can grind out the maths to dozens of places of decimals and find that you get the same results from the theory as you get from the experiment. But the model doesn't really help us understand what a measurement in the real world actually is, just allows us to predict what the (possible) results will be.
Back in the 1960's (1969 IIRC) Bell proved that it doesn't matter how you design your hidden variable theory, there are experiments that will give different results from what QM predicts.
The most famous of these experiments was done by Aspect in 1982. He found that the results were compatible with QM and incompatible with ANY local hidden variable theory.
Ever since then people have been trying to come up with theories that can explain the EPR effect. Causality going backwards in time, many worlds, but, to date, nobody has come up with any (even theoretical) experiment that can give us any handle on what might really be happening "under the hood".
And a few people have been looking for loopholes in the various experiments that would mean that a hidden variable theory could still be true.
FTL communication is IMPOSSIBLE. It VIOLATES CAUSALITY.
What that means, in plain English, is that A can cause B but B can happen before A.
This is hard to grasp because we believe in a universal time and a preferred reference frame. But however intuitive that might be we've got to let go and accept the fact that we can have two events where it's impossible to decide which happened first and which happened second.
I read through your page but it's missing the most important part of this particular experiment.
You don't need to use entangled photons to set up a secure communication link, although you can use them to do this.
Where this experiment gets really weird, going back to your two coins glued onto a piece of wood analogy, is that Bob and Alice set off in spaceships at high speed with their boxes sealed.
At some later point in time, each opens the box and has a look to see what state their coin is in.
They then start exchanging signals to try and work out which one opened the box first and caused the wave function to collapse. But it turns out that BOTH of them are convinced that they were first (and both of them can prove that they are right and that the other is wrong - this is what is means when we talk about spacelike events - it's impossible for one to have caused the other because we cannot even decide which one was first)
The coin analogy breaks down in another important way - it's relatively obvious that in the coin case despite the coins being sealed in the box, they could already have made their decision (this is what is known as a hidden variable).
A slightly better analogy would be to consider two dice that are correlated. But instead of just being able to make a measurement of what number is on top, they can also make a measurement of whether the die is left or right handed (if you put one on the top and two towards you, then whether three is on the left or right face).
Now when you throw our hypothetical dice it can also turn "inside out" and change from left to right handed. Now comes the QM bit - if you measure what number is on top then you cannot tell if it's left or right handed but if you measure if it's left or right handed then you cannot tell what number is on top. (and making either measurement destroys all knowledge of any previous measurement of the other variable)
Alice and Bob take their two entangled dice, sealed in the box, away and then, just before they open the box, make a random choice whether to measure what number is on top or whether the die is left or right handed. Once they've done that they get back together.
If one has measured what number is on top and the other whether it's left or right handed then they throw their results away and start again (note that it's very important that they do not agree in advance what they are going to do so throwing away roughly half their results is inevitable) but some of the time they'll independently decide to measure the same variable.
Whatever Alice measures, whether it's L/R or 1/2/3/4/5/6, Bob gets the same result. But we already know that the die cannot both have its L/R state and its 123456 defined simultaneously, therefore something about the measurement must have affected the die. In Bob's world it was his measurement that affected the die and Alice just got a predictable result, but in Alice world their roles are reversed.
AFAICT, there's nothing really new in this experiment using the ISS. When Alice and Bob do the experiment in the lab their measurement events are still spacelike. But it's hard to get away from the idea that the lab frame is a preferred frame.
Until Alice and Bob make their measurements we really do find that the cat is both dead and alive.
But what does "measurement" mean? If we really were using dead/alive cats to do this experiment (currently we lack the ability to keep something the size of a cat in a superposition of states) then presumably the cat knows if it's alive. But where/how does this stop. If not a cat, what about a mouse? An amoeba? A virus? A protein? an O2 molecule? An atom? An electron?
I think currently we're up to the atom or small molecule point with still no sign of QM breaking down.
There are ways around these conceptual problems, many worlds being one.
Slashdot Mirror
Neutrinos are not charged. Therefore they don't give off Cherenkov radiation.
I'm under the impression that it's the "reverse" of n -> p + e + v_e'; n + v_e -> p + e that is the usual reaction that is needed - probably the e then gives off Cherenkov radiation.
Tim.
As much as I *hate* to stick up for Bush, the truth of the matter is that Saddam bluffed and we called him on it. He did everything he could to make everyone believe he had WMDs.
While I appreciate it's now Bush's best ally in the middle east, Saddam had a problem with a large neighbour he had been fighting wars with on and off for decades. He was "forced" to walk a tightrope - on the one hand he wanted to discourage an invasion from his neighbour by pretending to have WMD and at the same time discouraging an invasion from the US by admitting that he didn't have any.
Of course, since America (and the UK) invaded Iraq, Iran has been a paragon of virtue and is Bush's best friend and is no longer having anything to do in, or any designs on, Iraq.
Tim.
Doh!
You're = your
smaller = former
Not sure if you're talking about superluminal travel or subluminal travel.
Theory already allows slower than light travel. You're spaceship would have to be big. VERY big. But if we really wanted to we could probably send mankind to the nearest stars with current technology.
But superluminal travel is a different kettle of fish. There are only two possible universes, one where there's an upper limit in the speed of information and another where there is no upper limit. The two universes have very different characteristics and our universe appears to be the smaller. It's hard to think of a way where you can transmit matter without also allowing information transfer.
Of course, even today faster than light travel is possible by current theory - but only by points A and B separating faster than light, not by allowing points A and B to communicate faster than light. Effectively this means that the speed of light is only constant locally. Maybe it would be possible to reverse the expansion and shrink the universe so that although the speed of light would still be an upper limit, communication between A and B could occur in less time than light could make the journey in a flat universe.
But I'd wager that faster than light travel in the special relativity sense is, and always will be, impossible.
Tim.
No offense, but you're assuming that somebody who bothers to set up a MITM using a trusted cert (rather than the quite easy approach of an MITM using an untrusted one) isn't going to notice that the site you're requesting lacks a trusted cert?
Think about this. Lets assume I'm going to be the bad guy launching the MITM. Lets also assume that I've got the Verisign private key from verisign. Lets further assume that I can mount a MITM attack against you. (maybe I'm the NSA or something)
Case 1: You connect to a site that is using a cert signed by one of the big CAs. It's 99.9% certain that your browser will accept this cert without a warning so I should generate a MITM cert signed by verisign.
Case 2: You connect to a site that is using a cert signed by someone I don't recognise. Lets also assume that you've added that cert to your trusted list. So I should still generate a MITM cert signed by verisign so that your browser generates no warning.
Case 3: You connect to a site that is using a cert signed by someone I don't recognise. But you haven't added the cert to your trusted list. Now I should generate a MITM cert signed by something random so that your browser does generate a warning.
But I, as the NSA, cannot distinguish between case 2 and case 3. So I might just as well sign everything by verisign. And in case 3, the only warning you will get is that the popup doesn't appear which you are more likely to miss than that an unexpected popup does appear which would be the effect for case 2.
The problem that I'm trying to solve is "Is this the same machine I connected to last time". If you're using SSH then the first time you connect to a machine you get a message along the lines of "Host key not recognised: do you want to continue" and depending on your paranoia you can check fingerprints, call up the sysadmin etc to make sure you've got the right machine. After that it's silent unless the host key changes at which point you get a message along the lines of "WARNING HOST KEY HAS CHANGED. SOMEONE MIGHT BE DOING SOMETHING NASTY. AGENT FORWARDING DISABLED".
Browsers don't do that. And I don't know why not. At the end of the day it doesn't really matter who signed the original cert - if you trust verisign then the first time you connect to a site, if you get a verisign signed cert then you can just accept it. If you don't then you'll have to do some more investigating. But after that, if the key changes for that site then you should be worried.
Of course, I suspect that many websites change their keys arbitrarily and don't get the same csr re-signed each year but just generate a new one. But that is a problem with the website, not with the way certs ought to be being used.
Tim.
It only guarantees that the domain of the site you've connected to matches the domain in your browser bar.
So I set up a company usesave. It doesn't really matter what the company was going to do.
I then get a cert from verisign for my usesave company.
I then setup www.usesave.co.uk, and maybe even phish people with "you must check your details" and wait for people to typo www.icesave.co.uk or click on links in the phishing email.
Of course, hopefully, the site will get shut down quickly, but it's unlikely to be quickly enough not to catch some people out. The steps above might have cost me a few hundred pounds. I can set it all up and then "disappear" before actually triggering the phish. During the setup time my website is displaying a "How to save the environment by reusing the stuff you throw away: Coming soon"
But instead, icesave could have had their own root cert. And despite being an online bank, you do still have some paperwork from them which could have included the fingerprint of their root cert.
Now I can explicitly allow icesave's root cert and it doesn't matter if someone sets up usesave. If I typo it I won't recognise their root cert so I'll be alerted to the typo.
Of course, browsers don't make this at all easy to do. And, of course, icesave could still give their fingerprint on their paperwork (they don't).
For less critical transactions it's less important. If I'm just buying something online then the verisign checks are probably fine. I'm not likely to have any good way of verifying the companies cert. But there's no loss of security by still having a self signed cert - it's actually impossible for me to tell if the people I'm talking to are crooks - and verisign confirming that yes, I've really connected to the crooks and the good guys haven't intercepted my connection really doesn't help me.
What certs really give is the potential to confirm that the person you're talking to today is the same as the person you were talking to yesterday. But that's not the way they're used at all.
Tim.
I don't thing you've actually read my original post. Either that or you haven't understood.
The MITM can add root certs to the client and has a root cert in the client that they can control.
Yes, it's possible for the MITM to make any site behave the way it used to. That is by definition and there's no way to prevent it.
But you have a choice of ways it works for sites that you control.
1. No popups etc. Everything looks identical. Only if you decide to go and look at the certificate independently of your browsing will you be able to detect that your expected root cert has been substituted. If the phone rings as you connect you might even forget whether you've actually checked it this time or not when you return to your browsing.
2. Popup every time. Now you have to make a decision whether to accept that root cert every time. Of course you can always just press OK. Then your security just degenerates to case 1. But you explicitly have to make the choice _not_ to check the certificate.
I do check (especially if I'm at a web cafe). And I also know the first couple of words of the fingerprint of the cert.
Of course I could also check by bringing up the cert but I have to remember to do that.
Tim.
Self signed certificates don't prevent attacks but they do mean that the attack cannot easily be automated."
Umm. No.
These attacks can be very very easily automated.
1 - Spot SSL connection and become a proxy.
2 - When server sends certificate, read all the fields and create new certificate with identical ones but a different public/private key pair.
3 - sign this with a random, and still unknown CA
4 - Send this new one on to the client. You now have two SSL sessions going, and the client doesn't have a clue what happened.
I disagree.
The MITM has to somehow determine whether the client knows the root cert or not.
If the client knows the root cert then the MITM has to sign the new certificate with a root cert known to the client (and in my case the supposed MITM controls the client and therefore can always do this)
If the client doesn't know the root cert then the MITM has to sign the new certificate with a root cert unknown to the client.
In case 1 the interception is completely invisible. You have to explicitly go and check the certificate to see if the root cert has changed from the expected value. And if you do nothing at all then everything will work.
In case 2 you will get a popup and you will have to accept the cert for the session. If you chose not to "view details" and check the fingerprint then that is your choice but you've still got to make an explicit choice whether to accept the certificate or not.
In the case of wholescale interception of every ssl connection the assumption will be that the client will know the root cert.
Tim.
Also see my other reply.
I've had certificates signed by verisign (might have been Thwarte - was a while ago now) for a small company. It really isn't difficult in the UK to setup a company and get the necessary paperwork to jump through the hoops to get a certificate.
The problem is that sites like:
https://www.securesuite.co.uk/rbs/tdsecure/opt_in.jsp
I'm expected to trust for everything even when I get unexpectedly redirected to them from another website and yet my certificate looked pretty much identical to that one.
Tim.
If my bank asked me to go to "other bank" in order to pay money into my account at my bank and said "You'll be able to confirm that it really is other bank because they'll have paperwork signed by us to prove it" then yes, I would trust my bank.
I recently got redirect to this site when buying rail ticket from http://www.nationalexpresseastcoast.com/
https://www.securesuite.co.uk/rbs/tdsecure/opt_in.jsp?
I was using a natwest debit card (who happen to be owned by RBS).
The site didn't work properly (I just got a blank page) but it was supposed to be asking me for various letters from a password for my card for the "verified by visa" scheme.
Was it a scam site that didn't work or was it the real site that didn't work? Can you tell from the certificate?
Or should it have directed me to
https://secure1.securesite.co.uk/
instead?
(I've removed all the get parameters that were on the original URL)
What about if I'd ended up at:
https://sourceforge.net/
or
https://www.trustedcomputinggroup.org/?
How can I tell which one of those I should be trusting with my credit card details and which I should be afraid of?
Tim.
"When is it acceptable to encourage users to accept a self-signed SSL cert?"
The answer is: Never.
What is the point of being sure that no one can intercept your communication all the way from your browser to the server if you don't know who you are talking to in the first place?
If someone knocked to your door and asked for your money would you give it to him because he has a bulletproof truck so the money will be safe all the way to whatever it is going to? Or would you trust the guy in the truck because he showed you a self-signed document saying: "I am authorised to do what I'm doing. Signed: me." Of course not!
But you'd be happy if you'd arranged with your bank for a truck to come and pick up the money, and when the truck arrived and you asked to see his documentation he said "Here it is, guaranteed by Fred Bloggs over there." And you have no relationship with Fred Bloggs (although you guess your bank does because the driver says so!) and no comeback against Fred Bloggs if he screws up even if he does have a relationship with your bank.
Quite frankly what I'd want is my bank having its own root cert that was self signed. I can confirm with my bank that I've got the right cert. And then when the driver turns up he can say "Here it is, guaranteed by your bank". And if the bank has screwed up and let some third party get hold of their root cert private key then I've got a relationship with the bank and I can sue them.
And when I communicate with my bank I should be able to give them my root cert and then they can check I'm who I say I am (they can use other methods as well if they don't think that is secure enough)
IIRC the hmrc website (UK TAX) allows you to use client side certificates to communicate with them but doesn't allow self signed ones. But why not? Is hmrc more confident that verisign can tell who I am than hmrc itself is? As a result I don't use a client side certificate.
Tim.
IMO, self signed certificates can be more secure. And for the site in question there's a risk of governments strongarming the certificate authorities to provide signed certificates so the government can launch MITM attacks.
I have a https website on my home machine that occasionally I connect to from work.
Now I get a popup about how the certificate issuer isn't recognised etc.
If someone at work (who controls the browser, the proxy, the network etc) decided to sniff all SSL traffic - which they could do with a MITM attack because they control at least one of the allowed root certs in the browser - my popup would disappear (unless they were very careful)
Likewise, my mail servers all use self signed certificates. Again, someone trying to attack me by getting verisign (or whoever) to sign a certificate, will not work.
Self signed certificates don't prevent attacks but they do mean that the attack cannot easily be automated.
(Actually I have a single self signed root cert that I then use to sign all my other certs rather than each cert being self signed)
It's swings and roundabouts. Verisign et al have built a whole industry out of convincing people to trust them more than the person's own bank.
I'm surprised we don't already see spam attempting to get people to install new root certs. (Or maybe we do - almost all the spam I get gets stopped by greylisting or caught by spamassassin)
Tim.
Hmm, Actually it looks like I'm wrong. http://www.chemicalogic.com/download/phase_diagram.html
Looks like CO2 is a solid at room temperature at around 4000 atmospheres. I'd never seen the phase diagram plotted out beyond about 100 atmospheres before.
Tim.
room-temperature dry ice
I'm missing something? At room temperature CO2 is a gas or a liquid. A little above room temperature and it's always a gas.
Tim.
All materials sublimate
Not sure about helium. If it can sublimate then it's going to be way up the phase diagram at enormous pressure at or close to the critical temperature. But it can definitely go straight from the superfluid state to the vapour state.
It's quite bizarre when you watch He4 transition to superfluid as you reduce the pressure. It's boiling away vigourously and then suddenly all the boiling stops (and it becomes quite difficult to see because it's refractive index is so close to 1)
Tim.
IMO Clarity is important but it's not the most important thing when writing code.
1. Correctness. If the code doesn't work (as it was supposed to have been designed to do) then it's wrong. It doesn't matter how beautiful it is. I've worked with people who have provided a library plus API for some functionality and I've been unable to get it to work EVER. They've claimed that they've tested it. I've been unable to find any case that works. In the end I was forced to rewrite it from scratch. (I've yet to receive any beautiful code that fails like this - unless you count pretty boxes for comments and correctly indented as beautiful)
2. Robustness. I'm not talking about ability to handle unexpected input here - that comes under correctness. I'm talking about if someone needs to make a change in the future to support some new requirements, how robust is the code to a small change leaving (most of) the old functionality still working correctly. Many many years ago I remember working on some code (DOS code to drive hardware over serial port) that had some timing constraints (of the order of 1/100s) but nothing exceptionally difficult to achieve even in those days. The code mostly worked (although it failed intermittently) but was so sensitive to changes that moving a bit of functionality out into a subroutine would affect the timing enough to cause it to fail most of the time. In the end, the only solution was to rewrite from scratch.
3. Clarity. Once the other two are fulfilled then clarity is important. But most of the time it's pretty hard to fulfill both 1 and 2 without also giving 3. Mostly 3 becomes alerting people to weird quirks in the code that have been done for a reason but aren't necessarily obvious at first glance. Comments are dangerous because they can be wrong even if the code is correct and robust. The very best code is correct, robust and doesn't need comments at all. Comments can break 2 - a small change to the code can silently break the comment. If the comment is at a high enough level then comments can sometimes be robust against small changes to the code. And some things are impossible to do in a small compact piece of code - then you need a small compact comment to give you the overview. Sometimes low level comments are required in code because requirements have changed so variable or function names no longer make sense in the new context. Of course, in an ideal world, we'd go and fix all those names everywhere.
Tim.
Solution to the current bubble: When the contract becomes due, pull up to the trader's office with a tanker truck and flood the building with the crude. That'll teach'em not to speculate.
Erm.... That's what happens.
Most of the time, the speculator closes out his contract before delivery, i.e. he finds someone else who wants delivery (or who is contracted to deliver but doesn't have any oil).
But occasionally the speculator gets caught with his pants down. On the third of October 2006, the spot price for Natural Gas in the UK went negative. There were people contracted to take delivery of the gas and they had to pay someone else to take it off their hands.
Tim.
Although it's not a strong reason, the existence of a monopole would require charge to be quantized.
Tim.
IIRC with quantum cloning you can get 5/6 fidelity in a universal quantum cloning machine. This is an upper limit. Any higher and weird, impossible, things like faster than light communication become possible. Lab implementations have made it into the 80%+ fidelity bracket.
Non universal quantum cloning has been less studied. In some cases it's obvious and trivial what the best implementation is (100% for cloning a photon in a known polarization state - just put a lightbulb behind a polarization filter at the correct angle). In other cases it's not obvious (I think unknown) what the best approach might be.
For an ideal UCM, 83.3% of the time you get the same result as the original would have done.
Although this sounds very high, it's not that high when you consider a naive UCM that doesn't touch the original but just creates a second particle/photon in a random state gets 75% fidelity - 50% of the time both measurements will come out correct and 50% of the time one of them will so 3/4 measurements give the correct result.
Tim.
Get the herd in a froth about some minor issue -- changing a detention limit from 28 to 42 days
This is all part of the plan to get the limit up from 7 days to 90 days.
Yes really.
In 2000 the limit for holding terrorist suspects without charge was 7 days. (Terrorism Act 2000)
2003 it went to 14 days
2006 it went to 28 days
2009(ish) will be 42 days. (Maybe there'll be a compromise of 38 days or something)
The 2006 raise was a stab at 90 days with Tony B realizing that he could never sell it and the Lords and Commons compromised on 28 days. But by 2007 the Government had already put the wheels in motion to extend it again.
Personally I think 7 days is too much. I realize that inevitably there has to be a short period unless you are going to charge people instantly but I'd like to see the Lords amending this bill down to 72 hours plus the ability to question after charge. Not going to happen though.
Tim.
what are you doing by looking? taking some energy away? converting the photon into something else? you must be doing something what is that something?
You're collapsing the wavefunction into an eigenfunction of the Hamiltonian and measuring the corresponding eigenvalue.
But NOBODY knows what that means in the real world. You can grind out the maths to dozens of places of decimals and find that you get the same results from the theory as you get from the experiment. But the model doesn't really help us understand what a measurement in the real world actually is, just allows us to predict what the (possible) results will be.
Tim.
Physicists aren't overlooking this at all.
This is called a local hidden variable theory.
Back in the 1960's (1969 IIRC) Bell proved that it doesn't matter how you design your hidden variable theory, there are experiments that will give different results from what QM predicts.
The most famous of these experiments was done by Aspect in 1982. He found that the results were compatible with QM and incompatible with ANY local hidden variable theory.
Ever since then people have been trying to come up with theories that can explain the EPR effect. Causality going backwards in time, many worlds, but, to date, nobody has come up with any (even theoretical) experiment that can give us any handle on what might really be happening "under the hood".
And a few people have been looking for loopholes in the various experiments that would mean that a hidden variable theory could still be true.
Tim.
It ISN'T useful for FTL communication.
FTL communication is IMPOSSIBLE. It VIOLATES CAUSALITY.
What that means, in plain English, is that A can cause B but B can happen before A.
This is hard to grasp because we believe in a universal time and a preferred reference frame. But however intuitive that might be we've got to let go and accept the fact that we can have two events where it's impossible to decide which happened first and which happened second.
Tim.
I read through your page but it's missing the most important part of this particular experiment.
You don't need to use entangled photons to set up a secure communication link, although you can use them to do this.
Where this experiment gets really weird, going back to your two coins glued onto a piece of wood analogy, is that Bob and Alice set off in spaceships at high speed with their boxes sealed.
At some later point in time, each opens the box and has a look to see what state their coin is in.
They then start exchanging signals to try and work out which one opened the box first and caused the wave function to collapse. But it turns out that BOTH of them are convinced that they were first (and both of them can prove that they are right and that the other is wrong - this is what is means when we talk about spacelike events - it's impossible for one to have caused the other because we cannot even decide which one was first)
The coin analogy breaks down in another important way - it's relatively obvious that in the coin case despite the coins being sealed in the box, they could already have made their decision (this is what is known as a hidden variable).
A slightly better analogy would be to consider two dice that are correlated. But instead of just being able to make a measurement of what number is on top, they can also make a measurement of whether the die is left or right handed (if you put one on the top and two towards you, then whether three is on the left or right face).
Now when you throw our hypothetical dice it can also turn "inside out" and change from left to right handed. Now comes the QM bit - if you measure what number is on top then you cannot tell if it's left or right handed but if you measure if it's left or right handed then you cannot tell what number is on top. (and making either measurement destroys all knowledge of any previous measurement of the other variable)
Alice and Bob take their two entangled dice, sealed in the box, away and then, just before they open the box, make a random choice whether to measure what number is on top or whether the die is left or right handed. Once they've done that they get back together.
If one has measured what number is on top and the other whether it's left or right handed then they throw their results away and start again (note that it's very important that they do not agree in advance what they are going to do so throwing away roughly half their results is inevitable) but some of the time they'll independently decide to measure the same variable.
Whatever Alice measures, whether it's L/R or 1/2/3/4/5/6, Bob gets the same result. But we already know that the die cannot both have its L/R state and its 123456 defined simultaneously, therefore something about the measurement must have affected the die. In Bob's world it was his measurement that affected the die and Alice just got a predictable result, but in Alice world their roles are reversed.
AFAICT, there's nothing really new in this experiment using the ISS. When Alice and Bob do the experiment in the lab their measurement events are still spacelike. But it's hard to get away from the idea that the lab frame is a preferred frame.
Tim.
Cats are not both alive and dead.
Exactly. But QM says they are.
H polarized photon = Cat dead. V polarized photon = Cat alive. 45 degree polarized photon = Cat dead, 135 degree polarized photon = Cat alive.
Until Alice and Bob make their measurements we really do find that the cat is both dead and alive.
But what does "measurement" mean? If we really were using dead/alive cats to do this experiment (currently we lack the ability to keep something the size of a cat in a superposition of states) then presumably the cat knows if it's alive. But where/how does this stop. If not a cat, what about a mouse? An amoeba? A virus? A protein? an O2 molecule? An atom? An electron?
I think currently we're up to the atom or small molecule point with still no sign of QM breaking down.
There are ways around these conceptual problems, many worlds being one.
Tim.