Matrix, RAMBleed, Chaos Engineering, Two-man Rule, VPN Masking

• Matrix 1.0 is out - This is really nice. TLS certificates, room version 4, and alternate authentication methods and of course stable protocol specification. I really wish something this could take over WhatsApp. Also the Cross-signing devices with device signing keys is feature which I requested because it was just too annoying get keys verified, especially if using a web client. In this case it means that each session key should get verified, which was practically "null security" solution. Because no-one is ever going to do that. Options practically were, you'll accept any key, or you don't accept any key and basically block users with web-clients decrypting any of the messages. Even storing the keys didn't help, because the session key was anyway always regenerated, which was way annoying. Even if I could restore other keys from backup, the session key wasn't one of those options. That's why I suggested using user key to sign the session key, so the user key could be trusted instead of requiring separately assigning trust for each session key. Also lack of proper long term keys made chat histories often broken or very broken. Because there were lots of messages which the user didn't have decryption key for. Which was quite annoying. It's interesting to see, if this 1.0 release fixes this issue: Unable to Decrypt (UtD). Balancing security / usability. I also talked about web of trust concept, on channels. Because on encrypted channels, the device verification was practically impossible, if there were more than a few users and even then it's almost impossible. Of course there are channels, with different privacy requirement levels. I also suggested that those channels should have different level settings, which would make key verification more or less secure / painful depending on the need. Just like you can control channel history, you could control the encryption requirements. Nice to see Osborne 2, PDP-11 and VAX in examples, haha.
• RAMBleed - More fun, this is especially great time for virtualization security. All your data is leaking. Hopefully these vulnerabilities are had to exploit.
• Chaos Engineering - This is something I love. Because in this case problems are found before those become real problems. This is exact opposite what I'm unfortunately often hearing. "It's working always", so there's no need to cluster, availability zones, backup, fallback, retry or whatsoever. It seems that the Google got hit by this "it always works mentality" when their configuration was lost when all instances were shut down. I personally prefer fail safe systems, and it's totally normal that some components of the processing chain fail, and the recovery system should be automated and not require manual intervention. Which is slow and painful. In worst case the "it always works" mentality leads to system design, where the state after failure is complex and there's no automated or even straight forward manual way to recover, it's a total mess. Because there were no need to design the system operation keeping any kind of failure model in mind. After that good luck with recovery. It's seen that after such failure, there's no proper way to recover often at all. It's more or less data loss and a mess. Of course those things will eventually get resolved in "non technical way". Like lost orders, payments, etc via the customer service. But recovery can take weeks or months easily and never be "complete" in technical sense.
• Some security discussion like: Two-man rule , Buddy system and Separation of duties.
• Studied Stealth / VPN masking technologies, which put SSL VPN (OPENVPN / SSTP) inside OpenConnect, Anyconnect, GlobalProtect, ocsev or stunnel (SOCKS) tunnels using another protocol to hide another VPN protocol inside it using entry gateway in foreign country. kw: Cisco, Juniper, DTLS

2020-08-02