The browsers, as a sign of protest, could make the 451 default page warn the user that access to the requested page has been blocked due to censorship. If plenty people see that threatening page while browsing the internet, they may take things more seriously.
There does not appear to exist any single piece of evidence that DLP (discrete logarithm problem) will benefit from algorithms running in polynomial time. The recent work of Antoine Joux that they are referring to (one of which I assume to be http://arxiv.org/pdf/1306.4244v1.pdf) provides improvements of quasi-polynomial agorithms for breaking DLP. But there is no reason to believe that these improvements can lead to a polynomial-time attack. And as long as this does not happen, those attacks can still be defeated by increasing the key size.
If 90% of slashdot's traffic is used to send HTML, then that is their bottleneck, and it's where it is most effective to apply compression (Amdahl's law).
This attack has little to do with SSL itself or the cryptosystems used. It's more about the preservation of size when encrypting. Combined with compression, information about the amount of entropy in the plaintext is leaked. If you are allowed to manipulate parts of the plaintext a lot of times, then amount of entropy leakage provides with an answer to the question "does the injected substring appear anywhere else in the plaintext?".
Open the Net panel of Firebug on this page and then refresh it a couple of times. Order the HTTP requests by Size. You will see that the HTML of this page is takes the vast majority of bandwidth. Images are simply a "304 Not modified", whereas the HTML is a "200 OK" of ~41KB at this time. So in case of Slashdot, HTML is the bandwidth bottleneck, not images.
Some information simply does not change from one request to the other. In case of facebook, my name appears on the top blue bar on every page. An attacker can therefore extract my name using this technique.
This is quite an ingenious attack, but I am very surprised it has taken people so long to find it, as it is very straightforward and easy to understand conceptually. Makes you wonder "how did I not think of that".
Although it may seem like the requirements of a successful attack are difficult to achieve, this may not be the case. It is usually very easy to inject some plain-text in the source code of webpages.
That means that an attacker can extract secret information from a lot of the HTTPS pages that you're visiting.
When I first read about this attack, the first fix that came into my mind was to just append/* [random text of random size] */ to all text/html responses.
But this may cause troubles: if the random padding is too large, the purpose of compression is defeated. If it is too small, workarounds may be found.
Maybe it is time to start thinking of algorithms that perform compression and encryption together, not separately?
> someone in the comments below brought the example up of using company logos and you type the name Sounds like something the computers can do better at than humans.
> Imagine this, I pose the question as a human verification, "What color was George Washington's favorite white horse?" But would a computer be able to easily ask questions that itself cannot answer, but a human can? It sounds like a set of formulations would have to be hardcoded, such as: "What [trait] was [person]'s favorite [trait value] [object]? -> [color]". But these formulations can also be hardcoded in the bot, so this is not really a solution.
The fact that factorization is in NP is completely irrelevant. It is not known to be NP-complete. However, the fact that factorization has remained a hard problem for such a long time indicates that it is not very likely that someone knows how to solve it easily.
They are merely saying that there is no general fix against iframe timing attacks. You can fix individual attacks (such as the visited links one). However, it is likely that ingenious hackers with plenty of time on their hands will find other rendering operations which reveal information when timed. The coders cannot simply add random sleep()s too all conceivable operations that it performs, the browsers nowadays are slow enough as it is.
I do not see why the excess paranoia and fuss is all about. Sharing data privately does *not* work in a model where you do not trust anyone.
If you are sharing non-sensitive data, then it is usually an acceptable compromise to trust very large companies such as Google. You acknowledge that a government or Google is not motivated enough to "look" at your data, although you realize there is no guarantee that they cannot do so. You just believe that the data is not worthy enough for them to care.
When you (A) are sharing sensitive data by e-mail with (B), you are implicitly trusting many parties: CAs or government/ISP, GMail and B. While you do intend to trust B, you do not intend to trust anyone else with such valuable data. This is *your* mistake or ignorance. Just because the idea is to trust CAs implicitly it does not mean you have to trust them with everything. The more valuable the data, the less compromise you afford to make in trust. This leaves you with having to distribute your public key to B without trusting anyone else. You can achieve this by splitting your key and distributing it in multiple mediums: video+audio skype calls, stenography, phone calls etc. The more mediums, the higher degree of trust.
It is your responsibility and in your best interest to weigh the value of your data and take proportional effort in protecting it.
If a government controls a CA and would like to see your communications with a server that it does not control, all it can do is mount a MITM attack while you are communicating with that server. Afterwards, it misses its window of opportunity: if the government wants to decrypt the logged communication at a later time, it cannot do so. The damage it can do by controlling a CA is pretty limited.
That depends on what kind of data you are referring to. If you are talking about e-mails, then intelligent beings usually realize that very sensitive data is not to be stored there.
For storing your own data, that you are not planning on sharing with anyone, cloud storage such as Dropbox works wonderfully with Truecrypt. A strong password assures you no-one will ever get access to your cloud data, unless you are forced to reveal the password. Truecrypt also offers plausible deniability using a hidden volume, in case you are forced to reveal your password.
If you are planning on sharing very sensitive data and you are aware that the government or someone else is as motivated to obtain that data as to go through the trouble of MITM attacks, then one good solution is to distribute your public key over a Skype audio+video call.
Now, if you believe the government is as motivated as to try to fake both your and his voice and movement of lips, then you would have to split your public key and distribute it through multiple mediums (stenography on an youtube video? mailing lists?).
There *are* some ways of protecting your data ainst a government or anyone else if it is valuable enough.
It appears a habit of the slashdot commenters to discuss how badly a government would be able to screw you over, completely missing a simple fact: the amount of effort any government would put into seeing your data is proportional to how valuable they believe it is. They will not mount a MITM attack on you using a controlled CA just to see your vacation pictures. The privacy of your data does not only rely solely on how abusive a government is, but also on how much effort and thought you put in keeping it private. When dealing with highly sensitive data, it is your obligation to be paranoid, not to trust governments, CAs, companies, ISPs etc. and go to great lengths to assure no-one can gain access to your information.
A government would probably not be able to perform a MITM attack to the masses, as someone would eventually figure it out (pubkeys being different all of a sudden). On the other side, if you are talking about a government going through the trouble of targeting a specific individual with a MITM attack, then he either has powerful enemies or is a suspect. Either way, one is usually aware of being in such a situation. It would therefore be foolish to not take additional precautions to protect yourself.
I assume using around 12 styluses of fixed position would have allowed for much faster bruteforce (10 for the digits, 2 for the ok buttons). Moving a stylus around is simply too slow compared to down-up movements.
Slashdot Mirror
That would be incorrect in case of HTTPS.
The browsers, as a sign of protest, could make the 451 default page warn the user
that access to the requested page has been blocked due to censorship. If plenty
people see that threatening page while browsing the internet, they may take
things more seriously.
Collisions are exponentially unlikely, therefore practically impossible for large bitstrings.
I find it the most painful when I hibernate my laptop with FF having ~30 tabs open. Resuming from hibernate makes FF unbearably slow sometimes.
There does not appear to exist any single piece of evidence that DLP (discrete logarithm problem)
will benefit from algorithms running in polynomial time. The recent work of Antoine Joux that they
are referring to (one of which I assume to be http://arxiv.org/pdf/1306.4244v1.pdf) provides
improvements of quasi-polynomial agorithms for breaking DLP. But there is no reason to believe
that these improvements can lead to a polynomial-time attack. And as long as this does not happen,
those attacks can still be defeated by increasing the key size.
Maybe it reduces memory usage by storing everything on the disk instead. HDDs are fast enough anyway.
On Windows7 64bit, my FF currently takes 1.7GB, and I have 23 tabs open. I've seen it do far worse
to me though. Here, a screenshot:
http://i.imgur.com/VuzNwtr.png
Are the governments doing more powerful research than the rest of the world combined?
If 90% of slashdot's traffic is used to send HTML, then that is their bottleneck,
and it's where it is most effective to apply compression (Amdahl's law).
This attack has little to do with SSL itself or the cryptosystems used. It's more about the preservation of size when encrypting. Combined with compression, information about the amount of entropy in the plaintext is leaked. If you are allowed to manipulate parts of the plaintext a lot of times, then amount of entropy leakage provides with an answer to the question "does the injected substring appear anywhere else in the plaintext?".
Open the Net panel of Firebug on this page and then refresh it a couple of times. Order the HTTP requests by Size. You will see that the HTML of this page is takes the vast majority of bandwidth. Images are simply a "304 Not modified", whereas the HTML is a "200 OK" of ~41KB at this time.
So in case of Slashdot, HTML is the bandwidth bottleneck, not images.
Some information simply does not change from one request to the other. In case of facebook, my name appears on the top blue bar on every page. An attacker can therefore extract my name using this technique.
They just make you visit a malicious website, at which point they can force you to make as many HTTPS requests as they want. They use img src IIRC.
This is quite an ingenious attack, but I am very surprised it has taken people so long to find it, as it is very straightforward and easy to understand conceptually. Makes you wonder "how did I not think of that".
Although it may seem like the requirements of a successful attack are difficult to achieve, this may not be the case.
It is usually very easy to inject some plain-text in the source code of webpages.
On facebook:
https://www.facebook.com/photo.php/INJECT_WHATEVER_YOU_WANT_HERE/
If you view the source of that URL you can see the text "INJECT_WHATEVER_YOU_WANT_HERE" appears 3 times in the source code.
By appending the query string, on youtube:
https://www.youtube.com/watch?v=hLkugwOYbFw&INJECT_WHATEVER_YOU_WANT_HERE
And on google:
https://www.google.com/?INJECT_WHATEVER_YOU_WANT_HERE
That means that an attacker can extract secret information from a lot of the HTTPS pages that you're visiting.
When I first read about this attack, the first fix that came into my mind was to just append /* [random text of random size] */ to all text/html responses.
But this may cause troubles: if the random padding is too large, the purpose of compression
is defeated. If it is too small, workarounds may be found.
Maybe it is time to start thinking of algorithms that perform compression and encryption together, not separately?
While this has the sounding of a very wise saying, I really doubt it is anywhere close to being true.
> someone in the comments below brought the example up of using company logos and you type the name
Sounds like something the computers can do better at than humans.
> Imagine this, I pose the question as a human verification, "What color was George Washington's favorite white horse?"
But would a computer be able to easily ask questions that itself cannot answer, but a human can? It sounds like
a set of formulations would have to be hardcoded, such as: "What [trait] was [person]'s favorite [trait value] [object]? -> [color]".
But these formulations can also be hardcoded in the bot, so this is not really a solution.
Because we all know computers are terrible at doing arithmetic and solving simple equations
Care to elaborate?
The fact that factorization is in NP is completely irrelevant. It is not known to be NP-complete.
However, the fact that factorization has remained a hard problem for such a long time indicates
that it is not very likely that someone knows how to solve it easily.
They are merely saying that there is no general fix against iframe timing attacks. You can fix individual attacks (such as the
visited links one). However, it is likely that ingenious hackers with plenty of time on their hands will find other rendering operations which reveal information when timed. The coders cannot simply add random sleep()s too all conceivable operations that it performs, the browsers nowadays are slow enough as it is.
I do not see why the excess paranoia and fuss is all about. Sharing data privately
does *not* work in a model where you do not trust anyone.
If you are sharing non-sensitive data, then it is usually an acceptable compromise
to trust very large companies such as Google. You acknowledge that a government
or Google is not motivated enough to "look" at your data, although you realize there
is no guarantee that they cannot do so. You just believe that the data is not worthy
enough for them to care.
When you (A) are sharing sensitive data by e-mail with (B), you are implicitly trusting
many parties: CAs or government/ISP, GMail and B. While you do intend to trust B,
you do not intend to trust anyone else with such valuable data. This is *your* mistake
or ignorance. Just because the idea is to trust CAs implicitly it does not mean you have
to trust them with everything. The more valuable the data, the less compromise you
afford to make in trust.
This leaves you with having to distribute your public key to B without trusting anyone else.
You can achieve this by splitting your key and distributing it in multiple mediums:
video+audio skype calls, stenography, phone calls etc. The more mediums, the
higher degree of trust.
It is your responsibility and in your best interest to weigh the value of your data and
take proportional effort in protecting it.
If a government controls a CA and would like to see your communications with a server that it does not control, all it can do is mount a MITM attack while you are communicating with that server. Afterwards, it misses its window of opportunity: if the government wants to decrypt the logged communication at a later time, it cannot do so. The damage it can do by controlling a CA is pretty limited.
That depends on what kind of data you are referring to. If you are talking about e-mails,
then intelligent beings usually realize that very sensitive data is not to be stored there.
For storing your own data, that you are not planning on sharing with anyone, cloud
storage such as Dropbox works wonderfully with Truecrypt. A strong password assures
you no-one will ever get access to your cloud data, unless you are forced to reveal the password.
Truecrypt also offers plausible deniability using a hidden volume, in case you are
forced to reveal your password.
If you are planning on sharing very sensitive data and you are aware that the government
or someone else is as motivated to obtain that data as to go through the
trouble of MITM attacks, then one good solution is to distribute your public key
over a Skype audio+video call.
Now, if you believe the government is as motivated as to try to fake both your and
his voice and movement of lips, then you would have to split your public key and
distribute it through multiple mediums (stenography on an youtube video? mailing lists?).
There *are* some ways of protecting your data ainst a government or anyone else if
it is valuable enough.
It appears a habit of the slashdot commenters to discuss how badly a government
would be able to screw you over, completely missing a simple fact: the amount of
effort any government would put into seeing your data is proportional to how valuable
they believe it is. They will not mount a MITM attack on you using a controlled
CA just to see your vacation pictures. The privacy of your data does not only rely
solely on how abusive a government is, but also on how much effort and thought you put
in keeping it private.
When dealing with highly sensitive data, it is your obligation to be paranoid, not to trust
governments, CAs, companies, ISPs etc. and go to great lengths to assure no-one can gain
access to your information.
A government would probably not be able to perform a MITM attack to the masses, as someone would eventually figure it out (pubkeys being different all of a sudden). On the other side, if you are talking about a government going through the trouble of targeting a specific individual with a MITM attack, then he either has powerful enemies or is a suspect. Either way, one is usually aware of being in such a situation. It would therefore be foolish to not take additional precautions to protect yourself.
I assume using around 12 styluses of fixed position would have allowed for much faster bruteforce (10 for the digits, 2 for the ok buttons). Moving a stylus around is simply too slow compared to down-up movements.