Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Awless: A Mighty CLI for AWS

github.com

Post reply on HN
Print view View original

111–120 of 120 posts

Re: Awless: A Mighty CLI for AWS

#111

Post by developer2 »

OhSoHumble wrote: post #87
fxaguessy wrote: post #73

Earlier quoted context omitted.

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/f6389e75787390bd7797... ). We will let you know when we have something better, keeping everything transparent, as we will always do.

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.

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.

Re: Awless: A Mighty CLI for AWS

#113

Post by developer2 »

openasocket wrote: post #71
mcherm wrote: post #67

Earlier quoted context omitted.

> 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?

It's called a compression 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.

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.

Re: Awless: A Mighty CLI for AWS

#114

Post by heartsucker »

bdcravens wrote: post #76
heartsucker wrote: post #54

Earlier quoted context omitted.

The tool phones home. Their website doesn't have HTTPS. It's plausible that the tools phones home over an unencrypted channel (I didn't look, so I could be wrong). My overall impression is that they don't do security very well.

Anyone can release a project on Github; the project should be based on its merits, not how well an unrelated project is implemented. (and vice versa) A quick search of the repo of https:// and then http:// shows that the stats collection is apparently https.

Sure, and if we imagine a hypothetical entity that has 10 products with security holes and then releases and 11th, it might be worth looking at the 11th more suspiciously. Things don't happen in a vacuum.

Re: Awless: A Mighty CLI for AWS

#115

Post by hbbio »

bdcravens wrote: post #76
heartsucker wrote: post #54

Earlier quoted context omitted.

The tool phones home. Their website doesn't have HTTPS. It's plausible that the tools phones home over an unencrypted channel (I didn't look, so I could be wrong). My overall impression is that they don't do security very well.

Anyone can release a project on Github; the project should be based on its merits, not how well an unrelated project is implemented. (and vice versa) A quick search of the repo of https:// and then http:// shows that the stats collection is apparently https.

@heartsucker If you want to judge on previous things, we are the team that created http://opalang.org and have no tie at all with the company static and outsourced portal. Also, will be in Berlin soon, contact me will gladly meet there.

Re: Awless: A Mighty CLI for AWS

#117

Post by mcherm »

LeoPanthera wrote: post #68
mcherm wrote: post #67

Earlier quoted context omitted.

> 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?

The "CRIME" exploit relied on encrypted compressed data. https://en.wikipedia.org/wiki/CRIME_(security_exploit)

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.)

Re: Awless: A Mighty CLI for AWS

#118

Post by hbbio »

openasocket wrote: post #63

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 I…

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.

Re: Awless: A Mighty CLI for AWS

#120

Post by bashcoder »

hbbio wrote: post #118
openasocket wrote: post #63

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 I…

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…

How about you bump to 0.14 now, with this patch included? 0.13 is the Homebrew version, with data collection still enabled.
Post reply on HN