No, I meant what I said. "https.example.com" is an example of a host supporting HTTPS, yet the browser accesses it by default as "http://https.example.com". You don't seem to have understood what I said at all.
Because of the lack of widely adopted HTTPS, browsers are default-HTTP. So if you type https.example.com in your browser, it will first try to access it by HTTP. Sure, the host is sometimes nice enough to redirect you immediately to HTTPS. But the redirection happens over HTTP (because that's how you accessed the website). Therefore, a MITM can easily prevent such a redirect and keep you in the HTTP land (see sslstrip tool), where attacks are a child's play. So unless your victims are paranoid enough to check the address bar to make sure "https" appears, or manually write https:/// in front of their links, or use an addon such as "HTTPS Everywhere", then providing HTTPS doesn't matter much. What addons like HTTPS Everywhere do is they have a huge lists of websites known to support HTTPS, and they force the browser to go default-https instead.
In my opinion, good solutions would include: a) make HTTPS-everywhere part of the browsers; b) add some proper authentication and encryption in HTTP2.0 instead of bitching that it's the wrong layer. it's clear no-one is going to adopt HTTPS
widely anytime soon; most websites require you to login, meaning you can perform encrypted key exchange (EKE) with them, which allows for two-way authentication, plus encryption optionally; c) widely adoption of something like this: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security - not very useful, but still an improvement
As you said, it is the all-or-nothing that concerns me. I am not claiming that sandboxing would magically solve all problems and that successful exploits would never be able to do any harm. But being able to mount an attack such as "someone using MS Office somewhere might use it to open sensible data, which we can steal" is not the same as mounting an attack like "we can use MS Office to collect all stored passwords from all browsers and send them to us. And to spawn a keylogger". The MS Office should have no business accessing the sensible data of other applications or their memory space for that matter. I don't believe that the fact that Windows allows everything to stick its head where it does not belong is really an unsolvable problem.
Antiviruses are blacklisting, code signing is whitelisting. Both bad solutions in a world where we have so many apps that keeping track of all of them is very difficult. Besides, code signing does not solve the problem of too relaxed permissions. In the situation presented in the article, MS Office is a signed piece of software.
Yes, this is a major issue, but I don't believe it to be one without a solution, should one really bother to come up with a good implementation.
On a mobile phone, you (as an application) can refuse to run if an user does not grant access to a resource (such as webcam), because you know for sure that every phone has an webcam. This blackmailing procedure may not be so successful on a PC, where if the owner refuses to grant access to his webcam to an app, the OS can make it such that it is impossible for the app to distinguish between "the PC has no webcam" and "the PC has an webcam but you do not have access to it". Doing this for most resources should make it a lot more difficult for apps to trick users into granting more permissions than they need.
I have been saying this for ages. It is embarassing that the concept of "antivirus" still exists. Its main purpose is to enforce a huge blacklist of.exe files that can harm you. Instead of keeping track of million of apps that are evil, why not just apply some least privilege principles and sandboxing already so that we can run an application without granting it access to all our resources?
It comes as no surprise that everything gets moved to the web nowadays. One can safely open a website without worrying that all his personal data can be accessed (such as Firefox stored passwords). On the other hand, opening an application requires complete trust in the author, which is simply too much to ask most of the time. Look how well "apps" have evolved in mobile platforms. It is quite natural to prefer apps to websites, because it can be easier to have something run on startup and be easily accessible whenever you want, as opposed to having to go through a browser. They generally have less overhead and are more powerful. If Windows had a decent package manager and proper privilege separation we would probably be living in a different world today.
For anyone who claims stuff like "but Windows has UAC", obligatory xkcd: http://xkcd.com/1200/
> The more important question, however, is why did the alleged "needless use of > RSA" trigger such a huge red flag for you? What is the reason we should not > use RSA?
Because public-key cryptography, while being super awesome and very useful in many situations, is orders of magnitude slower than private-key cryptography (not only RSA, but everything that needs to deal with exponentiations and multiplications of 2048bit numbers). When I hear about hard-disk I/O and synchronization, I think of encryption that must have almost no speed penalty (see Truecrypt). Storing data in a way that can be retrieved only by the same person who stored it is certainly not a good use-case for an asymmetric cryptosystem with huge overhead. If I have to open 10000 file handles then the overhead of decrypting 10000 filekeys with RSA will not be negligible.
> If two files are identical (or even start off identical), having them > encrypted to different cypher texts is a nice bonus to have.
Any Mode of operation that is not broken provides this feature, as the IV is chosen at random. You do not need different keys to provide this feature (hint: try running "echo -n a|openssl aes-128-cbc -k test -a" multiple times on a terminal). Moreover, even if you do use different keys for each file, those keys can still be encrypted with symmetric crypto. Key-encrypting-key can be achieved with symmetric crypto alone. The use of public key crypto appears only when those messages need to be authenticated, signed or when multiple parties are involved somehow. Unless you do more fancy stuff, such as distributed encrypted file systems or encrypted computation/databases, data storage alone has little to gain from public key crypto.
As for the backup example, that does not make much sense. Why would a machine need to look at any of the contents to perform a backup? Encrypted data should in general be indistinguishable from random data (plausible deniability and all). To backup encrypted data you simply copy it, there's no need to decrypt anything. I see no reason why a backup machine should have any additional insight on my data. And besides, how would that even work? What would the backup machine be able to do? Decrypt? Encrypt? Encrypting new files sounds useless for backupping (because you can't read the old ones). Decrypting on the other hand, if provided to the backups machines, means that they can read everything.
> And the bottom line is that all of the above just boils down to "industry > best practices". It is the exact same thing PGP does when encrypting files > and messages.
Truecrypt only uses AES. PGP uses public-key cryptography because it needs to sign and authenticate messages (e.g. to prove that an e-mail has the author it claims it has), which is a totally different usecase than what you have.
Do not get me wrong. This is not personal and I'm not attacking you, so stop being so defensive. I simply made an initial comment that the devs don't seem to know what they're doing in regards to crypto, and then you challenged me and I simply detailed why I made the claim. I appreciate and respect open-source work, but unless you can back up your design choices with pertinent arguments, try to swallow criticism more easily. There's a reason why "don't make your own crypto" is a rule of thumb for programmers. Unless you're working in the field, let the experts deal with this. Or go study. "I have some crypto knowledge" is not enough to justify modifying existent mode of operations such as CBC.
> 3. RSA is needed because you do not want to encrypt all files involved using the same symmetric key, but you also don't want the secret your backup depends on to need constant updating. With this scheme, you only need to reliably and securely store one key (the RSA key), but each file is encrypted with a different key.
a) You do not want to encrypt all files involved using the same symmetric key. Care to explain why? There is nothing wrong with using the same key for multiple files. Anyway, if the main key is leaked then all the keys can be derived, so how is this different than using a single key? What additional security does this give? Is there a scenario in which a single-key symmetric approach does not survive an attack but your approach does?
b) With this scheme, you only need to reliably and securely store one key And this is different from symmetric crypto how? Where does the need for asymmetry come from? Does the set of people capable of doing one direction of the operation differ from the set of people that can do it backwards? Even if you use different keys for each file, you can still encrypt each of those keys with your master key, which can still be symmetric.
It sounds to me like Rsyncrypto have no idea what they're doing: "Rsyncrypto is a modified encryption scheme. It is based on industry standard AES for symmetric encryption, as well as RSA for having different keys for each file while allowing a single key to decrypt all files. It even uses an encryption mode that is based on CBC.
Rsyncrypto does, however, do one thing differently. It changes the encryption schema from plain CBC to a slightly modified version. This modification ensures that two almost identical files, such as the same file before an after a change, when encrypted using rsyncrypto and the same key, will produce almost identical encrypted files. This means that both objectives can be achieved simultaneously. "
Inventing their own crypto? Using public-key crypto for no good reason?
They obviously cannot discern a robot from a human over the wire, that sounds impossible to do currently. What they can probably do is make an estimate on how likely it is that a certain request comes from a script rather than a human being and then use that estimate to make a CAPTCHA of difficulty proportional to the likelihood. I wish there was a good alternative to our current CAPTCHAs, but I can't think of any (refrain from commenting if you are going to suggest something dumb that will surely not work, such as asking the user to do simple arithmetic).
I can confirm that this happens for Tor exit nodes. They serve their CAPTCHAs to third-party websites as well, and if it so happens that you want to use a website via Tor that uses their CAPTCHA on login, the challenges they give you simply cannot be solved. I am not exaggerating, I have been trying for ten minutes in the past to login on a certain website via Tor and was unable to. Finally, I found the solution at the time: you have to go to google's login page one time and then all the CAPTCHA's start becoming readable.
My point was that to get access to the web interface in the first place you need the wireless key. That is the thing preventing people from getting into your home network. Should they manage to get that key and infiltrate into your network, getting access to your router's web ui is almost always easy (almost no-one changes the default password or changes it to some bruteforceable one). And if one knows the network key, he can sniff the packets of everyone else as long as he catch their handshake with the AP (should work for WEP/WPA-PSK/WPA2-PSK, but not Enterprise stuff). I am pretty sure he can also perform DNS spoofing and MITM by impersonating the router and broadcasting a more powerful signal (if you know the network key, there is not much that someone else on the network can do to distinguish you from their real router). That being said, I don't see an attacker as gaining too much of an advantage by knowing your web ui password in most of the cases.
You cannot just put people in prison for taking dumb shortcuts in programming, that's ridiculous. The purpose of the backdoor was to be able to internally use some features supported by the web interface without reimplementing them. They decided that the code that needs those features should just query the router's own web interface, but that required a password, so they just added a secret user-agent to bypass it internally.
Also, you cannot realistically believe that this puts any banking transaction at risk. Those are usually protected by SSL, not your router. And access to your home network is usually preventing by using wireless security such as WPA2, not by having a password to your wireless' web interface. Almost no user has a non-default non-guessable router ui password anyway.
Either you misunderstand the way Tor works or I fail to see what you are trying to say. How do you propose police "update their tactics to include Tor"?
I am not suggesting anything, nor defending any sort of monitoring. I'm saying that figuring out exactly what is the best way to proceed is a hard problem, and the typical slashdotter seems to trivialize it, ignoring the fact that both sides have drawbacks. It is completely different from "banning Tor is like banning cars omg freedom! my feelings!". I completely understand the mentality of "we need to allow some bad to happen because the good we get in exchange outweighs the bad", but one needs to acknowledge that this *is* a tradeoff and complete anonymity does not come for free in a society. Exactly how much the society has to pay, in terms of bad guys getting away and evil being done, I doubt anyone knows. But the US has many enemies and I don't think it's easy to predict what will happen if they stop monitoring.
The analogy here is a bit stretched. Both cars and Tor are tools that can be used for good and bad, but the former does not make it impossible for authorities to enforce the law when one is doing bad things. Tor, on the other hand, allows pedophiles and whomever to use the tool for the bad without suffering the consequences. I am a crypto geek and a fan of Tor, but people just need to get their heads out of their butts already and realize that this is a hard problem. The tradeoff between the amount of anonymity you get and how well laws can be enforced is real and choosing where to draw the line is nontrivial and subject to a lot of controversy. It is quite clear that NSA and whoever else is doing these things have been crossing any reasonable line, but don't oversimplify the issue at hand by making bloody car analogies.
There will probably be fewer repetitive jobs that a monkey can do and more jobs that require intelligence and knowledge. This might be unfair to those who were born really ungifted. If only we had an education system able to figure out what is an individual good at and what he enjoys doing.
tl;dr He tried it upon friends' suggestion, was bad, friends said "BRO IT WAS FAEK". This reminded him of when he also had a bad coffee someplace else.
Slashdot Mirror
No, I meant what I said. "https.example.com" is an example of a host supporting HTTPS, yet the browser accesses
it by default as "http://https.example.com". You don't seem to have understood what I said at all.
Because of the lack of widely adopted HTTPS, browsers are default-HTTP. So if you type https.example.com in your browser,
it will first try to access it by HTTP. Sure, the host is sometimes nice enough to redirect you immediately to HTTPS. But the
redirection happens over HTTP (because that's how you accessed the website). Therefore, a MITM can easily prevent such a
redirect and keep you in the HTTP land (see sslstrip tool), where attacks are a child's play. So unless your victims are paranoid enough to
check the address bar to make sure "https" appears, or manually write https:/// in front of their links, or use an addon such as "HTTPS Everywhere", then providing HTTPS doesn't matter much.
What addons like HTTPS Everywhere do is they have a huge lists of websites known to support HTTPS, and they force the browser to go default-https instead.
In my opinion, good solutions would include:
a) make HTTPS-everywhere part of the browsers;
b) add some proper authentication and encryption in HTTP2.0 instead of bitching that it's the wrong layer. it's clear no-one is going to adopt HTTPS
widely anytime soon; most websites require you to login, meaning you can perform encrypted key exchange (EKE) with them, which allows for two-way authentication, plus encryption optionally;
c) widely adoption of something like this: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security - not very useful, but still an improvement
As you said, it is the all-or-nothing that concerns me. I am not claiming that sandboxing
would magically solve all problems and that successful exploits would never be able to do
any harm. But being able to mount an attack such as "someone using MS Office somewhere might use it
to open sensible data, which we can steal" is not the same as mounting an attack like "we can use MS Office
to collect all stored passwords from all browsers and send them to us. And to spawn a keylogger". The MS Office
should have no business accessing the sensible data of other applications or their memory space for that matter.
I don't believe that the fact that Windows allows everything to stick its head where it does not belong is really an unsolvable problem.
Antiviruses are blacklisting, code signing is whitelisting. Both bad solutions in a world
where we have so many apps that keeping track of all of them is very difficult.
Besides, code signing does not solve the problem of too relaxed permissions. In the
situation presented in the article, MS Office is a signed piece of software.
Yes, this is a major issue, but I don't believe it to be one without a solution, should one really bother
to come up with a good implementation.
On a mobile phone, you (as an application) can refuse to run if an user does not grant access to
a resource (such as webcam), because you know for sure that every phone has an webcam.
This blackmailing procedure may not be so successful on a PC, where if the owner refuses to grant
access to his webcam to an app, the OS can make it such that it is impossible for
the app to distinguish between "the PC has no webcam" and "the PC has an webcam but
you do not have access to it". Doing this for most resources should make it a lot more difficult
for apps to trick users into granting more permissions than they need.
I have been saying this for ages. It is embarassing that the concept of "antivirus" still exists. .exe files that can harm you. Instead
Its main purpose is to enforce a huge blacklist of
of keeping track of million of apps that are evil, why not just apply some least privilege
principles and sandboxing already so that we can run an application without granting it
access to all our resources?
It comes as no surprise that everything gets moved to the web nowadays. One can safely
open a website without worrying that all his personal data can be accessed (such as Firefox
stored passwords). On the other hand, opening an application requires complete trust in the author,
which is simply too much to ask most of the time. Look how well "apps" have evolved in mobile
platforms. It is quite natural to prefer apps to websites, because it can be easier to have something run on startup
and be easily accessible whenever you want, as opposed to having to go through a browser. They
generally have less overhead and are more powerful. If Windows had a decent package manager
and proper privilege separation we would probably be living in a different world today.
For anyone who claims stuff like "but Windows has UAC", obligatory xkcd: http://xkcd.com/1200/
Could we take this offline (e.g. IM)? Discussing this way seems highly counterproductive.
> The more important question, however, is why did the alleged "needless use of
> RSA" trigger such a huge red flag for you? What is the reason we should not
> use RSA?
Because public-key cryptography, while being super awesome and very useful in
many situations, is orders of magnitude slower than private-key
cryptography (not only RSA, but everything that needs to deal with
exponentiations and multiplications of 2048bit numbers).
When I hear about hard-disk I/O and synchronization, I think of
encryption that must have almost no speed penalty (see Truecrypt).
Storing data in a way that can be retrieved only by the same person who stored
it is certainly not a good use-case for an asymmetric cryptosystem with huge
overhead. If I have to open 10000 file handles then the overhead of decrypting
10000 filekeys with RSA will not be negligible.
> If two files are identical (or even start off identical), having them
> encrypted to different cypher texts is a nice bonus to have.
Any Mode of operation that is not broken provides this feature, as
the IV is chosen at random. You do not need different keys to provide this
feature (hint: try running "echo -n a|openssl aes-128-cbc -k test -a" multiple
times on a terminal). Moreover, even if you do use different keys for each file,
those keys can still be encrypted with symmetric crypto.
Key-encrypting-key can be achieved with symmetric crypto alone. The use of
public key crypto appears only when those messages need to be authenticated,
signed or when multiple parties are involved somehow. Unless you do more fancy
stuff, such as distributed encrypted file systems or encrypted computation/databases,
data storage alone has little to gain from public key crypto.
As for the backup example, that does not make much sense. Why would a machine
need to look at any of the contents to perform a backup? Encrypted data should
in general be indistinguishable from random data (plausible deniability and
all). To backup encrypted data you simply copy it, there's no need to decrypt
anything. I see no reason why a backup machine should have any additional
insight on my data. And besides, how would that even work?
What would the backup machine be able to do? Decrypt? Encrypt? Encrypting new
files sounds useless for backupping (because you can't read the old ones).
Decrypting on the other hand, if provided to the backups machines, means that
they can read everything.
> And the bottom line is that all of the above just boils down to "industry
> best practices". It is the exact same thing PGP does when encrypting files
> and messages.
Truecrypt only uses AES. PGP uses public-key cryptography because it needs to
sign and authenticate messages (e.g. to prove that an e-mail has the author it
claims it has), which is a totally different usecase than what you have.
Do not get me wrong. This is not personal and I'm not attacking you, so stop
being so defensive. I simply made an initial comment that the devs don't seem
to know what they're doing in regards to crypto, and then you challenged me and
I simply detailed why I made the claim. I appreciate and respect open-source work, but
unless you can back up your design choices with pertinent arguments, try to
swallow criticism more easily. There's a reason why "don't make your own
crypto" is a rule of thumb for programmers. Unless you're working in the
field, let the experts deal with this. Or go study. "I have some crypto
knowledge" is not enough to justify modifying existent mode of operations such
as CBC.
> 3. RSA is needed because you do not want to encrypt all files involved using the same symmetric key, but you also don't want the secret your backup depends on to need constant updating. With this scheme, you only need to reliably and securely store one key (the RSA key), but each file is encrypted with a different key.
a) You do not want to encrypt all files involved using the same symmetric key.
Care to explain why? There is nothing wrong with using the same key for multiple files.
Anyway, if the main key is leaked then all the keys can be derived, so how is this different than
using a single key? What additional security does this give? Is there a scenario in which a single-key symmetric approach
does not survive an attack but your approach does?
b) With this scheme, you only need to reliably and securely store one key
And this is different from symmetric crypto how? Where does the need for asymmetry come from? Does the
set of people capable of doing one direction of the operation differ from the set of people that can do it backwards?
Even if you use different keys for each file, you can still encrypt each of those keys with your master key, which can
still be symmetric.
Knowing plaintext and ciphertext does not make retrieving the key easier for real cryptosystems.
It sounds to me like Rsyncrypto have no idea what they're doing:
"Rsyncrypto is a modified encryption scheme. It is based on industry standard AES for symmetric encryption, as well as RSA for having different keys for each file while allowing a single key to decrypt all files. It even uses an encryption mode that is based on CBC.
Rsyncrypto does, however, do one thing differently. It changes the encryption schema from plain CBC to a slightly modified version. This modification ensures that two almost identical files, such as the same file before an after a change, when encrypted using rsyncrypto and the same key, will produce almost identical encrypted files. This means that both objectives can be achieved simultaneously. "
Inventing their own crypto? Using public-key crypto for no good reason?
They obviously cannot discern a robot from a human over the wire, that sounds impossible to do currently.
What they can probably do is make an estimate on how likely it is that a certain request comes from a script
rather than a human being and then use that estimate to make a CAPTCHA of difficulty proportional to the likelihood.
I wish there was a good alternative to our current CAPTCHAs, but I can't think of any (refrain from commenting if
you are going to suggest something dumb that will surely not work, such as asking the user to do simple arithmetic).
I can confirm that this happens for Tor exit nodes. They serve their CAPTCHAs to third-party
websites as well, and if it so happens that you want to use a website via Tor that uses their
CAPTCHA on login, the challenges they give you simply cannot be solved. I am not exaggerating,
I have been trying for ten minutes in the past to login on a certain website via Tor and was unable
to. Finally, I found the solution at the time: you have to go to google's login page one time and then
all the CAPTCHA's start becoming readable.
large percentage[citation needed].
Also, controlling some exit nodes is not really sufficient to identify you (unless they think
it's you but they are not sure).
> The Linux man pages (documenting the Linux API)
No.
My point was that to get access to the web interface in the first place you need the wireless key. That is the thing preventing people from getting into your home network. Should they manage to get that key and infiltrate into your network, getting access to your router's web ui is almost always easy (almost no-one changes the default password or changes it to some bruteforceable one). And if one knows the network key, he can sniff the packets of everyone else as long as he catch their handshake with the AP (should work for WEP/WPA-PSK/WPA2-PSK, but not Enterprise stuff). I am pretty sure he can also perform DNS spoofing and MITM by impersonating the router and broadcasting a more powerful signal (if you know the network key, there is not much that someone else on the network can do to distinguish you from their real router). That being said, I don't see an attacker as gaining too much of an advantage by knowing your web ui password in most of the cases.
is usually prevented*
I think it is? http://tsd.dlink.com.tw/downloads2008detailgo.asp
Someone commented on another website with this link: https://gist.github.com/ccpz/6960941 which shows
the backdoor string being defined in some config.
You cannot just put people in prison for taking dumb shortcuts in programming, that's ridiculous. The purpose of
the backdoor was to be able to internally use some features supported by the web interface without reimplementing them.
They decided that the code that needs those features should just query the router's own web interface, but that required
a password, so they just added a secret user-agent to bypass it internally.
Also, you cannot realistically believe that this puts any banking transaction at risk. Those are usually protected
by SSL, not your router. And access to your home network is usually preventing by using wireless security
such as WPA2, not by having a password to your wireless' web interface. Almost no user has a non-default
non-guessable router ui password anyway.
Either you misunderstand the way Tor works or I fail to see what you are trying to say.
How do you propose police "update their tactics to include Tor"?
I am not suggesting anything, nor defending any sort of monitoring. I'm saying that figuring out
exactly what is the best way to proceed is a hard problem, and the typical slashdotter seems to trivialize
it, ignoring the fact that both sides have drawbacks. It is completely different from "banning Tor is like
banning cars omg freedom! my feelings!".
I completely understand the mentality of "we need to allow some bad to happen because the good
we get in exchange outweighs the bad", but one needs to acknowledge that this *is* a tradeoff and
complete anonymity does not come for free in a society. Exactly how much the society has to pay,
in terms of bad guys getting away and evil being done, I doubt anyone knows. But the US has many
enemies and I don't think it's easy to predict what will happen if they stop monitoring.
The analogy here is a bit stretched. Both cars and Tor are tools that can be used for good and bad,
but the former does not make it impossible for authorities to enforce the law when one is doing bad things.
Tor, on the other hand, allows pedophiles and whomever to use the tool for the bad without suffering
the consequences.
I am a crypto geek and a fan of Tor, but people just need to get their heads out of their butts already
and realize that this is a hard problem.
The tradeoff between the amount of anonymity you get and how well laws can be enforced is real and
choosing where to draw the line is nontrivial and subject to a lot of controversy. It is quite clear that NSA
and whoever else is doing these things have been crossing any reasonable line, but don't oversimplify the
issue at hand by making bloody car analogies.
There will probably be fewer repetitive jobs that a monkey can do and more jobs that require intelligence and knowledge.
This might be unfair to those who were born really ungifted. If only we had an education system able
to figure out what is an individual good at and what he enjoys doing.
Is there any reason to believe that Tor is weakened by PRISM?
tl;dr He tried it upon friends' suggestion, was bad, friends said "BRO IT WAS FAEK". This reminded him of when he also had a bad coffee someplace else.