6 ms·

I hate to pile on to the complaints about sending usage metrics to a server, but this is pretty funky. The metrics include the instance id, account id, a list o

I hate to pile on to the complaints about sending usage metrics to a server, but this is pretty funky. The metrics include the instance id, account id, a list of the commands run with timestamps, the region, a bunch of metadata about the number of VPCs, Subnets, IAM users and policies, etc. Which is kind of a lot to get, and definitely isn't anonymous. Why do they need to know how many VPCs, Subnets, IAM users, and IAM roles I have? Then there's how the data is sent. The metrics are converted to JSON, gzipped, then AES encrypted with a random key. The random key is then encrypted with a constant public key. the encrypted key and encrypted payload are serialized into some JSON, and is then POST-ed to an HTTPS URL. This seems unnecessarily convoluted, and even with my meager knowledge of crypto I already see some problems (compressing then encrypting is a no-no) which could spell trouble. Shouldn't you just need to upload the JSON of the metrics over an SSL connection?

mcherm 10y ago
> compressing then encrypting is a no-no Perhaps it is just my own meager understanding of cryptography, but I didn't know of anything that would make this a bad idea. Can you explain why it is potentially a problem?
- LeoPanthera 10y ago
  The "CRIME" exploit relied on encrypted compressed data. https://en.wikipedia.org/wiki/CRIME_(security_exploit) https://en.wikipedia.org/wiki/CRIME_(security_exploit)
  - YZF 10y ago
    It also relies on the ability of the attacker to inject their own data into the compressed content. Without that vector there's nothing special about compressed and encrypted data vs. any other encrypted data.
  - mcherm 10y ago
    Thanks, that was quite helpful. I would say that "compress, then encrypt is bad" is the wrong message to take away from this type of vulnerability. In the case of CRIME in particular, the issue was that: 1. The attacker provided part of the message. 2. The rest of the message contained a secret. 3. The entire message (attacker-provided-part and secret) were compressed together. We can stop there; the length of the compressed data now contains information about the similarity between the attacker-provided content and the secret. The correct lesson to take away from this is "do not compress a combination of attacker-provided content and secrets". Compressing before encrypting is perfectly sensible. (And, by the way, compressing after encrypting isn't better, it is useless since your encrypted content ought to be incompressible.)
- openasocket 10y ago
  It's called a compression oracle attack https://en.wikipedia.org/wiki/Oracle_attack https://en.wikipedia.org/wiki/Oracle_attack Basically, since you know about how big the plaintext is, and you can determine the size of the compressed payload by monitoring the traffic, so you can measure the amount of entropy in the plaintext. An example is the CRIME attack. But that involves a chosen plaintext attack, so I'm not sure if something can be done with this method.
  - developer2 10y ago
    This is the problem everyday developers, like myself, have with attack vectors on encryption and cryptography. We read up on Oracle attacks, and specific proven attacks like CRIME (and every other attack against openssl and crypto in general). Yet the majority of us can barely understand the basic details. The majority of the research written about the topic is published from the perspective of the top 1000 cryptographers on the planet. Whether the concepts are honestly too complex for "normal developers" to comprehend or whether the top experts in the field enjoy the superiority and exclusivity of being "in the know" while labelling the rest of us "stupid", the fact is nobody dumbs down the information involved to the point where 95% of us who work in technology can apply the knowledge to counter these attacks. The research is published with information that is far too low-level. Very few software developers, including the vast majority of engineers with degrees, understand the theory and math behind these issues. The best of the worst of us know not to roll our own crypto, but that is clearly the tip of the iceberg. Someone out there needs to figure out how to properly explain "Crypto for Dummies" if we ever want or expect the overall security of encryption to improve.
jvolkman 10y ago
> This seems unnecessarily convoluted Sounds like a standard hybrid approach. https://en.m.wikipedia.org/wiki/Hybrid_cryptosystem https://en.m.wikipedia.org/wiki/Hybrid_cryptosystem
- openasocket 10y ago
  I get that part, but I don't see why they are encrypting it in the first place. It's being sent over SSL, so why bother? Plus, hybrid cryptosystems exist because symmetric encryption is much faster than asymmetric, which matters for large amounts of data. But this is (even before compression) probably only about a kilobyte of data. Why have the extra complexity?
  - xyzzy123 10y ago
    Because you can then store it encrypted until you're ready to process it.
fxaguessy 10y ago
Thanks all for the feedback. We understood that the data collection could be done with much care. As a result, until we design a better way to send truly anonymous data, we have disabled the data collection (cf. https://github.com/wallix/awless/commit/f6389e75787390bd779773a5e253bdb7a5947ddc https://github.com/wallix/awless/commit/f6389e75787390bd7797...). We will let you know when we have something better, keeping everything transparent, as we will always do.
- OhSoHumble 10y ago
  How about you just... not collect data from people? Or, at the very least, have it be an opt-in option? I'll probably never use this just on principle.
  - skywhopper 10y ago
    Yeah, this is a huge trust violation. I'm glad people caught on to it quickly. You should not be phoning home with _anything_ from a tool like this without it being 100% opt-in and with huge warnings and alerts. Even if you do it with the most care and best of intentions, a bug could easily compromise security of the people using your tool by uploading too much or the wrong information to your servers. This is not a risk worth taking for you or any potential users of the software.
    - pmoriarty 10y ago
      This is symptomatic of the world we live in now. Some people don't even think twice about spying on their users.
    - hbbio 10y ago
      (creator here) Note that we got the feedback and disabled the collection until we do it right. Also, it got "caught" in the first comment about that because it was clearly written in a Disclaimer section in the README.
  - developer2 10y ago
    Because, whether or not we like it, the reality is that data collection is the #1 way for a product to eventually work towards profit? And even if it's a totally free, open-source project with no intention of profiting, too many developers feel like analytics is the only way to gather information to improve? Yeah, I don't agree either. It's annoying.
eanzenberg 10y ago
This is kinda why I avoid so many packages, even probably-safe stuff like iterm. I try to go vanilla as much as possible and avoid having to think hard of which service or app may be transmitting my data.
hbbio 10y ago
Let’s analyse the facts there. Metrics are converted to JSON, true, gzipped and AESed with a random key. It’s true. The random key is then encrypted with our public key. True as well, and perfectly fine. “This seems unnecessarily convoluted” No, this is the proper way to do! We don’t want to send data in cleartext. We don’t want to store data in cleartext in cloud servers neither. The statistics that we collected (PS: they are not anymore, we disabled the collection until we take time to explain what we collect and most importantly why) were then downloaded and analysed locally. AES encryption is perfectly fine and necessary in that case. Should we just rely on TLS as comments ask for, the statistics would be accessible by any one who has access to our AWS instance and infrastructure. And then: “compressing then encrypting is a no-no” This sounds like a recipe taken from a very precise attack (the CRIME attack, as explained in comments down the thread). However, this attack does not apply in this case. Ensues a long discussion on how we are supposedly incapable of implementing crypto, although it rather seems the comment author messes things up. Take away here: Judge for yourself! We want to simplify considerably how AWS infrastructures are created and managed with awless, give it a look. From version 0.0.14 on, no data will ever be collected without your consent.
- bashcoder 10y ago
  How about you bump to 0.14 now, with this patch included? 0.13 is the Homebrew version, with data collection still enabled.

mcherm 10y ago

> compressing then encrypting is a no-no Perhaps it is just my own meager understanding of cryptography, but I didn't know of anything that would make this a bad idea. Can you explain why it is potentially a problem?

LeoPanthera 10y ago
The "CRIME" exploit relied on encrypted compressed data. https://en.wikipedia.org/wiki/CRIME_(security_exploit) https://en.wikipedia.org/wiki/CRIME_(security_exploit)
- YZF 10y ago
  It also relies on the ability of the attacker to inject their own data into the compressed content. Without that vector there's nothing special about compressed and encrypted data vs. any other encrypted data.
- mcherm 10y ago
  Thanks, that was quite helpful. I would say that "compress, then encrypt is bad" is the wrong message to take away from this type of vulnerability. In the case of CRIME in particular, the issue was that: 1. The attacker provided part of the message. 2. The rest of the message contained a secret. 3. The entire message (attacker-provided-part and secret) were compressed together. We can stop there; the length of the compressed data now contains information about the similarity between the attacker-provided content and the secret. The correct lesson to take away from this is "do not compress a combination of attacker-provided content and secrets". Compressing before encrypting is perfectly sensible. (And, by the way, compressing after encrypting isn't better, it is useless since your encrypted content ought to be incompressible.)
openasocket 10y ago
It's called a compression oracle attack https://en.wikipedia.org/wiki/Oracle_attack https://en.wikipedia.org/wiki/Oracle_attack Basically, since you know about how big the plaintext is, and you can determine the size of the compressed payload by monitoring the traffic, so you can measure the amount of entropy in the plaintext. An example is the CRIME attack. But that involves a chosen plaintext attack, so I'm not sure if something can be done with this method.
- developer2 10y ago
  This is the problem everyday developers, like myself, have with attack vectors on encryption and cryptography. We read up on Oracle attacks, and specific proven attacks like CRIME (and every other attack against openssl and crypto in general). Yet the majority of us can barely understand the basic details. The majority of the research written about the topic is published from the perspective of the top 1000 cryptographers on the planet. Whether the concepts are honestly too complex for "normal developers" to comprehend or whether the top experts in the field enjoy the superiority and exclusivity of being "in the know" while labelling the rest of us "stupid", the fact is nobody dumbs down the information involved to the point where 95% of us who work in technology can apply the knowledge to counter these attacks. The research is published with information that is far too low-level. Very few software developers, including the vast majority of engineers with degrees, understand the theory and math behind these issues. The best of the worst of us know not to roll our own crypto, but that is clearly the tip of the iceberg. Someone out there needs to figure out how to properly explain "Crypto for Dummies" if we ever want or expect the overall security of encryption to improve.

jvolkman 10y ago

> This seems unnecessarily convoluted Sounds like a standard hybrid approach. https://en.m.wikipedia.org/wiki/Hybrid_cryptosystem https://en.m.wikipedia.org/wiki/Hybrid_cryptosystem

openasocket 10y ago
I get that part, but I don't see why they are encrypting it in the first place. It's being sent over SSL, so why bother? Plus, hybrid cryptosystems exist because symmetric encryption is much faster than asymmetric, which matters for large amounts of data. But this is (even before compression) probably only about a kilobyte of data. Why have the extra complexity?
- xyzzy123 10y ago
  Because you can then store it encrypted until you're ready to process it.

fxaguessy 10y ago

Thanks all for the feedback. We understood that the data collection could be done with much care. As a result, until we design a better way to send truly anonymous data, we have disabled the data collection (cf. https://github.com/wallix/awless/commit/f6389e75787390bd779773a5e253bdb7a5947ddc https://github.com/wallix/awless/commit/f6389e75787390bd7797...). We will let you know when we have something better, keeping everything transparent, as we will always do.

OhSoHumble 10y ago
How about you just... not collect data from people? Or, at the very least, have it be an opt-in option? I'll probably never use this just on principle.
- skywhopper 10y ago
  Yeah, this is a huge trust violation. I'm glad people caught on to it quickly. You should not be phoning home with _anything_ from a tool like this without it being 100% opt-in and with huge warnings and alerts. Even if you do it with the most care and best of intentions, a bug could easily compromise security of the people using your tool by uploading too much or the wrong information to your servers. This is not a risk worth taking for you or any potential users of the software.
  - pmoriarty 10y ago
    This is symptomatic of the world we live in now. Some people don't even think twice about spying on their users.
  - hbbio 10y ago
    (creator here) Note that we got the feedback and disabled the collection until we do it right. Also, it got "caught" in the first comment about that because it was clearly written in a Disclaimer section in the README.
- developer2 10y ago
  Because, whether or not we like it, the reality is that data collection is the #1 way for a product to eventually work towards profit? And even if it's a totally free, open-source project with no intention of profiting, too many developers feel like analytics is the only way to gather information to improve? Yeah, I don't agree either. It's annoying.

eanzenberg 10y ago

This is kinda why I avoid so many packages, even probably-safe stuff like iterm. I try to go vanilla as much as possible and avoid having to think hard of which service or app may be transmitting my data.

hbbio 10y ago

Let’s analyse the facts there. Metrics are converted to JSON, true, gzipped and AESed with a random key. It’s true. The random key is then encrypted with our public key. True as well, and perfectly fine. “This seems unnecessarily convoluted” No, this is the proper way to do! We don’t want to send data in cleartext. We don’t want to store data in cleartext in cloud servers neither. The statistics that we collected (PS: they are not anymore, we disabled the collection until we take time to explain what we collect and most importantly why) were then downloaded and analysed locally. AES encryption is perfectly fine and necessary in that case. Should we just rely on TLS as comments ask for, the statistics would be accessible by any one who has access to our AWS instance and infrastructure. And then: “compressing then encrypting is a no-no” This sounds like a recipe taken from a very precise attack (the CRIME attack, as explained in comments down the thread). However, this attack does not apply in this case. Ensues a long discussion on how we are supposedly incapable of implementing crypto, although it rather seems the comment author messes things up. Take away here: Judge for yourself! We want to simplify considerably how AWS infrastructures are created and managed with awless, give it a look. From version 0.0.14 on, no data will ever be collected without your consent.

bashcoder 10y ago
How about you bump to 0.14 now, with this patch included? 0.13 is the Homebrew version, with data collection still enabled.