analogist

6 tahun yang laludiscuss

Ah yes, enforcing the law, which, “in its majestic equality, forbids rich and poor alike to sleep under bridges, to beg in the streets, and to steal their bread.”

analogist

7 tahun yang laludiscuss

So you think there is no difference in guilt between being a war criminal’s arm dealer and being a war criminal’s grocer?

analogist

9 tahun yang laludiscuss

> PS: your mention of that Twitter account is creepy.

With no context, I agree. But I'm not exactly stalking engineers here - there was literally a direct link to that twitter from the Fastmail updates mailing list that went out, when customers were notified of the NYI datacenter move. Made me do a double take.

analogist

9 tahun yang laludiscuss

Hi Bron. I'm a customer of both Fastmail and GSuite, and I have enjoyed your service for a few years now. I still use Fastmail for some things, like sieve, and very much will continue paying just for the ongoing development of open-standard email like JMAP. But there are definitely a few things that I can't shake when I learned about them that very much pertains to the security mindset that prevents me from moving my primary emails onto Fastmail.

Security paradigms have been steadily moving beyond a hard-boundary-soft-center, to a defense-in-depth, distrust-your-own-services model. I was alarmed to learn last year, for example, that you use OpenVPN with fixed symmetric keys (--secret) rather than TLS with any forward secrecy (--tls-auth) for VPN between your NYI and AMS datacenters. https://blog.fastmail.com/2016/12/19/secure-datacentre-inter...

Presumably, running datalinks like this means you would have to have perfect trust in your long term key management and rotation. Is that something you plan on improving in the future?

Similarly -- I stumbled on this entirely by accident after your blog post about moving datacenters -- that your head of security ops & infrastructure tweeted "I will probably root my phone soon because Samsung's emoji set is worse than not having convenient OTA updates" https://twitter.com/robn/status/919194089920311296

I don't want to conflate anything -- a tweet on an engineer's own time about their personal devices isn't by itself a security problem. But it does reflect on the security mindset. If you had a BYOD policy, and this phone did end up being flashed to Lineage and be 3 patch levels behind (esp with Android's track record of RCE-via-media CVEs), this could definitely become a weakness on your entire infrastructure, and thereby on all of us as customers.

This is the type of thing I couldn't shake after learning about it. Of course, trust has to be placed somewhere. You have to be able to place trust on your ops and your infrastructure, but that's also a process, not a checkbox. People and devices can be trusted a little less in the overall security system, to provide redundant security. Could you clarify your position on how your staff is trained about the human weak points, security as a lifestyle if you're security and ops, and how your security mindset incorporates defense in depth?

analogist

9 tahun yang laludiscuss

> I’m not willing to stick my neck out

> empathy gap

Maybe if you were more open to helping them with threats to their livelihood, dignity, and well-being, they’d be more open to helping you with yours?

I don’t know, just a thought.

analogist

9 tahun yang laludiscuss

@bascule addresses deterministic password managers as a category here:

https://tonyarcieri.com/4-fatal-flaws-in-deterministic-passw...

Certainly you’ve considered these points, and I’m interested in hearing your responses to these points if you’re using this scheme yourself and want others to use it.

I’m particularly interested in point 4 where, unlike traditional password managers like 1Password and Lastpass, where you need both the password and some form of data access, the leakage of my master password (say by a shoulder surfing security camera at any time) literally means every credential can be derived from scratch at any time.

analogist

9 tahun yang laludiscuss

This is so obvious that the first thing I would do is look to see if they've addressed it in some way, instead of assuming incompetence.

If you have gone through the process of being charitable-first, instead of dismissive-first, then you would notice that they have explicitly spent engineering hours on this exact problem by using an SRP-based session key exchange for mutual authentication (and additional session encryption, in addition to TLS). [1] [2]

It's not easy to engineer for both security and usability, so I especially appreciate it when someone spends the time to accomplish both.

[1] https://blog.agilebits.com/2015/11/11/how-1password-for-team... [2] https://1password.com/files/1Password%20for%20Teams%20White%...

analogist

9 tahun yang laludiscuss

Because they don't transmit your encryption password.

Authentication is not done by sending them your encryption password, but instead the derivation of an SRP static secret (https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...) from your password (PBKDF, XOR'd with HKDF of the entropy-boosting pepper that they call the "Secret Key"), and performing a session key exchange handshake, basically like a (non-ephemeral) Diffie Hellman. They then encrypt all future communications (inside of TLS) with the transient session key.

This gets you three things in one swoop:

- Authentication of user

- Authentication of the server (if the remote server doesn't have the stored RSA counterpart of your derived SRP static secret, the exchange can't complete)

- An additional encrypted tunnel independent of TLS, so transport security isn't reliant solely on TLS (Cloudbleed, etc). (The contents being moved around are encrypted yet again)

And:

- User doesn't have to remember a separate password.

- The password and pepper never touch the network, only (non-reversible) session tokens do.

- Having access to traffic inside of TLS (corporate or malicious TLS endpoint interception, for example) still gets you nothing.

There are valid criticisms of 1Password, but you're literally criticizing them for something they've gone out of the way explicitly spent engineering hours solving in a way that not many services have even bothered thinking about.

analogist

9 tahun yang laludiscuss

That's pretty much correct, yeah. Due to exponentiation, length is almost everything in password security. Which means there's going to be a bunch of lengths at which brute force cracking is trivial, and then a very sharp rise in complexity, after which brute force cracking quickly becomes astronomical, and then absolutely impossible.

If you look at the current cracking benchmarks of GPUs (https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...), there is an easily quantifiable difference between bcrypt and MD5: 21 bits. (https://www.wolframalpha.com/input/?i=log2(200*%5E9)-log2(10...)

That means under current GPU architecture, bcrypt is basically like "adding 3-4 characters (or 1.5 diceware words)" for free to your password. Can you basically just add 3-4 characters to your password? Sure, but not without user friction, and certainly you can't think that way as the developer of the system, because you're trying to give a small leg up to even the most vulnerable by salting and bcrypt/PBKDF2/Argon hashing.

What about theoretical limits? Well, there is another way to approach this: Landauer's principle (https://en.wikipedia.org/wiki/Landauer%27s_principle), which considers the theoretical minimum energy of a bit flip of information - so this even covers future computing technologies. Even if you used up all available mass-energy in the entire sun, it is only theoretically possible to perform 2^225.2 operations (https://security.stackexchange.com/questions/6141/amount-of-...). 225 bits of entropy is roughly a 35-character (printable ASCII) password.

(Note that you can't do this with MD5 - it has only a 128-bit hash space, before preimage attacks, the best of which lowers it to 123 bits).

So the lesson is: use slow hashes to give some protection to the vulnerable and people whose password complexity is "on the edge". Use a password manager so that the rest of your passwords can be comfortably > 128 bits in complexity, without reuse. And then forget about passwords because after that, every other part of the security system becomes more important.

analogist

9 tahun yang laludiscuss

Wow. This is yet another example of the fatal combination of Rolling Your Own Crypto + Using OpenSSL Directly And Blowing Your Own Foot Off Because It Lets You.

  var cipher = crypto.createCipher('aes-256-ctr', key.toString('hex'))

Besides the completely fatal error of using derived and non-unique IVs (fatal as in, if you encrypt more than 1 item with it, it is exactly as good as plaintext because any two items encrypted with the same key+iv in CTR mode cancels out to plaintext), isn't using hex encoding vastly constraining the possible complexity-per-byte of the key?

A single hard-coded salt for key derivation:

  const key = crypto.pbkdf2Sync(auth, '0945jv209j252x5', 100000, 512, 'sha512');

Again, the salt is only lowercase alphanumeric. This makes this 120-bit salt really just a 77-bit salt. But since it's hard-coded and not randomly generated, it's a 0-bit salt.

Can everyone who is developing crypto apps Just Use NaCl/Libsodium?

analogist

9 tahun yang laludiscuss

Even conventional VPN is not enough. The Great Firewall of China (https://en.wikipedia.org/wiki/Great_Firewall) is a mix of DNS poisoning, deep packet inspection, and traffic and usage analysis based on real time ML. It is very smart and adaptive, and will block most mainstream VPN services, including IPSEC, standard OpenVPN, SSH tunnels, (of course) SOCKS and http proxies.

Besides blocking entire sections of the net outright (like Google address blocks), poisoning controversial domains, etc, even if it can't directly inspect the traffic due to good encryption (say in the instance of OpenVPN or IPSEC), it will slowly degrade and eventually null-route your traffic over the course of minutes, depending on its judgement of the likelihood (based on packet structure and history) that your activity isn't "normal" usage.

Currently the only functional ways of getting around the GFW is VPN through stunnel (TCP OpenVPN traffic re-wrapped in TLS, thus pretending to be https traffic, and incurring triple TCP performance penalties), similar convoluted protocols like Shadowsocks, obfsproxy, and other China specific tools.

analogist

9 tahun yang laludiscuss

Summary link by OSTIF, which includes a quick synopsis of both audits, and link to full report on OpenVPN 2.4 by OSTIF:

https://ostif.org/the-openvpn-2-4-0-audit-by-ostif-and-quark...

Matthew Green/Cryptography Engineering audit direct link, which focuses more heavily on the protocol design, as well as a 2.2->2.4 changelog audit:

https://www.privateinternetaccess.com/blog/2017/05/openvpn-2...

analogist

9 tahun yang laludiscuss

So you would be fine with your local restaurant "denying service" and locking the doors only when the food safety inspectors show up?

analogist

9 tahun yang laludiscuss

That seems to be pretty weak evidence of verification not being through TLS. There could easily be an additional connectivity check that is http-based (that was blocked by the captive portal) before proceeding onto a standard TLS handshake.

As 'klodolph mentions, there's a lot of layers of verification for software updates. Before install proceeds, the verification requires a cryptographic signature from an Apple authorization server in response to submitted device ID + hashes of the package to be installed. Then at boot time, the signature is verified again by the standard boot process (burnt-into-silicon Apple root CA pubkey verifies the bootloader integrity, which then verifies the iOS kernel integrity, which then re-hashes the update package and re-verifies the signatures to make sure there's not a rootkit or MITM interfering with hashing and verification). Only then is an update actually allowed to be installed.

analogist

9 tahun yang laludiscuss

I think a recurrent concern is OpenVPN's reliance on TLS, and its codebase complexity as a result of being built on OpenSSL--but with far less attention and resources and vuln hunting compared to say, actual browsers. Complexity + lack of auditing person-hours is never a good combo. (See https://twitter.com/tqbf/status/806646188158152705)

Matt Green's audit of OpenVPN, when completed, may lead to more light on the matter. Otherwise, we're just relying on informed intuitions.

analogist

9 tahun yang laludiscuss

I'm no expert, but intuitively it would seem that encryption-inside-encryption would be snake oil when they're meant to guard against the same layer/attack vector/threat model: for example, if you nest Serpent inside AES for a single local file encryption operation (ahem, TrueCrypt), that seems very gimmicky.

But if the encryption are supposed to protect separate and independent OSI layers or operation steps, then it would seem to me it's fully valid - specifically, in this case: - TLS dissolves inside HTTP-HTTPd endpoints or any reverse proxies, if used - additional SRP-negotiated AES dissolves inside client to the process doing key handling - final "actual" key encryption, handling at-rest encryption, and to make sure it's zero-knowledge to the storage handler

They seem to me to be guarding information leakage against very different parts of the key mangement process (storage, manipulation, http transport), and that doesn't seem to be snake oil to me.

analogist

9 tahun yang laludiscuss

Inside of TLS, 1Password uses an additional SRP handshake that negotiates a static secret (like a DHE), which 1Password uses to both authenticate the user and set up an additional AES-GCM transport encryption.

So even a full memory dump of what's transported in TLS should, as long as it's properly implemented, only reveal an SRP authentication session and subsequently symmetrically encrypted data.

(And inside that SRP-negotiated encryption should only be more symmetrically encrypted vault items, and RSA-encrypted vault keys. If properly implemented even complete TLS breaks do not break 1Password at all, even the cloud version. Properly implemented being the key words of course.)

analogist

9 tahun yang laludiscuss

As a neuroengineer working in the field, this is quite accurate. Understanding the compute architecture goes a loooong way - after all, acoustic RSA key extraction (https://www.tau.ac.il/~tromer/acoustic/) is possible. Whereas we're not exactly even sure how the brain is supposed to theoretically compute, other than that it's tremendously parallelized to a degree we don't quite fathom. The electronics explosion has primarily come out of computational motifs that rely on the lightspeed resolution of semiconductor gates and heavily rely on sequential processing, but the brain doesn't work this way AT ALL.

An important concept here is the 100-steps-rule (https://www.teco.edu/~albrecht/neuro/html/node7.html) - neurons are SLOW! You can out-jog most non-myelinated neural signals, and the vast majority of sensory and motor computations finish in the order of 100 "clock cycles".

Write me a computer vision algorithm that has enough parallelism to complete in 100 cycles, and we can talk about understanding the biological brain compute structure and true brain-computer interfaces.

analogist

9 tahun yang laludiscuss

Isn't that's just a description of all TLS? ECDHE/DHE key exchange is essentially employed on any non-poorly configured modern https site, TLS 1.0-1.3draft.

analogist

10 tahun yang laludiscuss

What can a technologist do about climate change? (2015)

http://worrydream.com/ClimateChange/

TL;DR: better energy production/transportation methods, data-driven tools for finding bottle necks in production systems, information distribution for infrastructure and coordination and energy demand, making better tools to collect, analyze, present, and change minds.

Basically the same talent and sweat we put into getting 1% more click through rate to put on the slide deck for the next VC funding pitch, except, you know, put towards not having our grandkids die. You know, that kind of stuff.

"If any 'founders' out there want to 'disrupt' our 401 ppm atmospheric CO2, or 'moonshot' ocean acidification, that would be cool"

"minimum viable planet"

Submissions

Two OpenVPN Audits by OSTIF+QuarksLab and Matt Green Completed

comments