whisk3rs

minor clarification: That is not what this article says. Ford's network does not include Tesla's superchargers.

Try a Tor hidden service, configured with the low-latency/lower-privacy settings. It is slower than many of the other solutions, but very reliable and very simple.

Free

Try Wireguard on port 4500; this is usually allowed by any firewall/filter that allows ipsec.

I have worked with implementations of an online digital goods marketplace built by someone who was clever but had no notion of formal accounting, ledgers, etc. Their implementation worked, but was only just barely adequate and would have been more useful with a chart of accounts. Prototyping against an API like this would have been an informative exercise for them and probably saved a lot of time.

Edit: spelling

What is the most effective way to encourage our elected representatives to correct this potential for violation of our rights?

This depends on what you mean by "properly" and "impossible" and "professional" and "forward".

Many professional name-brand corporations use Tor daily.

The only ports opened are those you configure to have onion services. Port limiting is one of the major features of firewalls.

You don't get to control source IP ranges, but those aren't generally trustworthy on the open internet anyway.

Also, the traffic isn't "forwarded" -- hidden services shouldn't be run on a relay, actually, so you're not forwarding anybody's traffic but your own.

Also, barring the recent attacks on discovery of onion services, connecting to a tor onion service allows you stronger security guarantees and MitM defense than TCP+DNS+IP routes.

tor hidden services. slow, but secure!

Does anybody know if there have been attempts to use this browser based P2P tech to create a decentralized Kat.cr replacement?

Keys: KMS handles rotation of the master key automatically (http://docs.aws.amazon.com/kms/latest/developerguide/rotate-...). The ephemeral key used to encrypt values is changed any time a value is set.

Values: https://github.com/dcoker/biscuit#how-do-i-rotate-the-values

I generally have the same feeling, though https://github.com/go-gorp/gorp has worked very well for most of the database-heavy Go projects I've worked on over the last few years. It is just enough abstraction to be convenient and consistent and rarely gets in the way.

why shouldn't people have to rotate the underlying secrets?

a rogue employee who created a secret, or any engineer who had to access that secret to get their job done, is always going to be able to use that secret value, regardless of where the encrypted blob is stored.

seems like we should be making it easier to rotate secret values often and automatically.

For AWS users, KMS's GenerateDataKey is a simple way to store secrets locally in a way that reuses your IAM policies. You can also use grants and EncryptionContext to restrict the ability to decrypt secrets in a very fine-grained manner. As a bonus, all decrypts are logged in CloudTrail. The KMS docs are awful but if you're on AWS then it is worth checking out!

It is part of the Observer pattern: https://en.wikipedia.org/wiki/Observer_pattern

One common use case is in workflow systems. For example, you might "wait" for a bunch of files to exist before kicking off a job. This could be implemented as a bunch of "subjects" notifying when the files exist, and then the "observer" taking action when all of its subjects notify.

It is also used in UI frameworks to update visual representation when underlying data changes.

How do Yahoo, Google, Facebook, or others distinguish between state-sponsored actors and non-state-sponsored actors?

This page does not adequately address many of the practical questions that orgs with secrets should be asking.

Examples:

* Does it integrate with my existing infrastructure security policies? * Does it introduce a new set of principals for me to track and manage? * Are the configurations stored in a cleartext manner suitable for storing in version control? * Will the audit logs integrate with my existing audit log tooling? * Does it help or hinder continuous deployment? In other words, will my code be littered by conditionals to support non-prod jobs? * Can my devops team run this or does it require additional staffing? * How many layers is this adding between me and the security primitives offered by my platform (Windows AD, AWS IAM, etc) * Is it serverless, or does it require me to run additional servers? * How do I ensure continuity if the software is no longer actively developed? * Can it deploy secrets to dev and test environments in the same way? * What's the revocation story?

The answers to most of these questions for most of the tools that have made it to HN recently are not promising. For AWS the best choice seems to be using KMS directly and integrating your app with the declarative configuration tools AWS offers (IAM, CF, MFA).

Outside of AWS, Vault is the only one that I've seen which handles real-world end-to-end in a responsible way. For example, Vault is the only one that doesn't focus strictly on storing static values: Vault can integrate with services such as Postgres and SSH to dynamically provision time-limited credentials (https://vaultproject.io/docs/secrets/postgresql/index.html).

In addition to sanddancers comment, you can also do things like: - issue ephemeral certificates (with expiration in the near future) to allow a machine to perform an action but only for a certain amount of time (for example: to fetch credentials from a source to store in memory during machine provisioning). - use client certificates to authenticate your end-users for secure web apps. - easily build machine-to-machine trust models that take commercial CAs out of the picture

I'm excited to see more work being done to empower small engineering teams to take advantage of certificates. Lemur looks great, though many smaller organizations may find tools like "xca" to be adequate. xca is a simple GUI for certificate management: http://xca.sourceforge.net/

The MFA Condition is a huge win, and I'm surprised Amazon hasn't built this a tool to make this easier yet.

However, I question the merit of using two separate AWS accounts. While this separation of responsibility sounds nice in theory, doesn't it introduce additional maintenance burden because you now have two accounts to administer? You can't define or manage the roles in the 2nd account without credentials to do so.

Can you share screenshots of what the administration UI looks like?

Do you plan to support Individual 401ks for self-employed persons?

The dependence of 401k plans on companies might be an artifact of their genesis: 401k plans are designed to replace the "pension plans" of yore; as such, they are heavily regulated and each 401k is different. I've been told the legal documentation required for a 401k plan runs to the thousands of pages. Companies also want to manage the plans because, while supposedly cheaper to the company than pension plans, it still can affect their bottom line.

I'm excited to see that Square is advancing the art of secret management. This appears to be a very practical design and an improvement over most practices that I've seen in startups in SF.

That said, I hope that they continue to iterate on some fundamental design ideas:

(a) Attacks that can read arbitrary files from disk are far more common and simpler to execute than attacks that can read process memory. Leaving the unencrypted files available in a filesystem for a process to read leaves it open to this kind of attack, whereas using in-memory envelope decryption reduces the chance of this happening because there aren't remnants on the filesystem to deal with. Granted, this is difficult to do when depending on lots of open source software that expect secrets to be read from a file and is easier when you are building microservice daemons from scratch.

(b) It appears that the ability to acquire a secret is not revocable. Why is this useful? Often, you want a server to start, acquire secrets, and then drop the ability to acquire those secrets again. This reduces the risk of later attacks which get access to the system. Think of this as a similar pattern to how daemons will drop root privs after listening on a privileged port, or how nginx will drop privs after reading an SSL key.

(c) Keywhiz' uses a new service for managing the secrets. This presumably requires a server and other "big" components that exist alongside existing developer tools, and has a deployment burden for the host. Using envelope encryption would allow the secrets themselves to be stored in an encrypted form in the version control system, alongside the code they service. This gives you an audit log of changes to secrets that is integrated with the rest of your tools, rather than building a new system to do so.

Anybody interested in this space should definitely check out Amazon Key Management Service. I hope to see some open source implementations of AWS KMS in the near future!

Elite: Dangerous

Where do you get the BIN data?

I've been bitten by similar complexities around indirectly managing the database connection pool in Go, too. There might be a little too much magic in the library (such as successfully iterating to the end of a resultset implicitly releasing the results).

Finally, CSS that I can really trust!

Agree, the animation is distracting. I'd rather that the bar fade-in (quickly) in place. Otherwise, this is awesome, and I'm going to use it.

It is more accurate to say that RabbitMQ supports both fire-and-forget and producer-waits. The exact behavior is specified by a combination of how you configure exchanges and queues, and per-message settings, and how you write your client code. For example, your application can decide that some of the messages it injects into a queue are to be durable and others not. It is quite flexible (though the docs are lacking when it comes to specific advice for various use cases).

> I wouldn't recommend Revel to many (it's Play heritage isn't well suited to Go, IMO)

Can you elaborate on the issues you've had? I've used Revel on one project and it was totally adequate. The automatic reloading works well, and I built a reasonably complex data warehousing app in a few days with it. Other than some awkwardness in deployment and lack of built-in CSRF filter it seems great!