stribika · KommX · Jun 21, 2015 · Jun 21, 2015 · Jun 21, 2015 · Jun 21, 2015
diff --git a/_layouts/no.html b/_layouts/no.html
@@ -0,0 +1,14 @@
+<!DOCTYPE html>
+<html>
+
+  {% include head.html %}
+
+  <body>
+    <div class="page-content">
+      <div class="wrapper">
+        {{ content }}
+      </div>
+    </div>
+  </body>
+
+</html>
diff --git a/_posts/2015-01-04-secure-secure-shell.md b/_posts/2015-01-04-secure-secure-shell.md
@@ -34,6 +34,7 @@ Both provide [forward secrecy][forward-secrecy] which the NSA hates because they
 The server and the client will end up with a shared secret number at the end without a passive eavesdropper learning anything about this number.
 After we have a shared secret we have to derive a cryptographic key from this using a key derivation function.
 In case of SSH, this is a hash function.
+[Collision attacks][sloth] on this hash function have been proven to allow downgrade attacks.
 
 DH works with a multiplicative group of integers modulo a prime.
 Its security is based on the hardness of the [discrete logarithm problem][dlp].
@@ -59,11 +60,14 @@ Pb          <-- Pb = Sb * G
 s = Sa * Pb     s = Sb * Pa
 k = KDF(s)      k = KDF(s)</code></pre>
 
-OpenSSH supports 8 key exchange protocols:
+OpenSSH supports 11 key exchange protocols:
 
 1. [curve25519-sha256][libsshdoc]: ECDH over [Curve25519][curve25519] with SHA2
 1. [diffie-hellman-group1-sha1][rfc4253]: 1024 bit DH with SHA1
 1. [diffie-hellman-group14-sha1][rfc4253]: 2048 bit DH with SHA1
+1. [diffie-hellman-group14-sha256][dh-draft]: 2048 bit DH with SHA2
+1. [diffie-hellman-group16-sha512][dh-draft]: 4096 bit DH with SHA2
+1. [diffie-hellman-group18-sha512][dh-draft]: 8192 bit DH with SHA2
 1. [diffie-hellman-group-exchange-sha1][rfc4419]: Custom DH with SHA1
 1. [diffie-hellman-group-exchange-sha256][rfc4419]: Custom DH with SHA2
 1. ecdh-sha2-nistp256: ECDH over NIST P-256 with SHA2
@@ -73,18 +77,18 @@ OpenSSH supports 8 key exchange protocols:
 We have to look at 3 things here:
 
 * *ECDH curve choice*:
-  This eliminates 6-8 because [NIST curves suck][nist-sucks].
+  This eliminates 9-11 because [NIST curves suck][nist-sucks].
   They leak secrets through timing side channels and off-curve inputs.
   Also, [NIST is considered harmful][bullrun] and cannot be trusted.
 * *Bit size of the DH modulus*:
   This eliminates 2 because the NSA has supercomputers and possibly unknown attacks.
   1024 bits simply don't offer sufficient security margin.
 * *Security of the hash function*:
-  This eliminates 2-4 because SHA1 is broken.
+  This eliminates 2, 3, and 7 because SHA1 is broken.
   We don't have to wait for a second preimage attack that takes 10 minutes on a cellphone to disable it right now.
 
-We are left with 1 and 5.
-1 is better and it's perfectly OK to only support that but for interoperability (with Eclipse, WinSCP), 5 can be included.
+We are left with 1 and 8, as well as 4-6 which were added in [OpenSSH 7.3][73release].
+1 is better and it's perfectly OK to only support that but for interoperability (with Eclipse, WinSCP), 8 can be included.
 
 Recommended `/etc/ssh/sshd_config` snippet:
 
@@ -99,7 +103,7 @@ Recommended `/etc/ssh/ssh_config` snippet:
 Host *
     KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256</code></pre>
 
-If you chose to enable 5, open `/etc/ssh/moduli` if exists, and delete lines where the 5th column is less than 2000.
+If you chose to enable 8, open `/etc/ssh/moduli` if exists, and delete lines where the 5th column is less than 2000.
 
 <pre><code id="server-moduli-filter">awk '$5 > 2000' /etc/ssh/moduli > "${HOME}/moduli"
 wc -l "${HOME}/moduli" # make sure there is something left
@@ -149,8 +153,8 @@ If you don't want that, remove any `ssh-keygen` commands from the init script.
 
 <pre><code id="server-keygen">cd /etc/ssh
 rm ssh_host_*key*
-ssh-keygen -t ed25519 -f ssh_host_ed25519_key < /dev/null
-ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null</code></pre>
+ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null
+ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N "" < /dev/null</code></pre>
 
 ### Client authentication
 
@@ -182,7 +186,7 @@ Recommended `/etc/ssh/ssh_config` snippet:
 
 <pre><code id="client-auth-pubkey">Host *
     PubkeyAuthentication yes
-    HostKeyAlgorithms [email protected],[email protected],ssh-[email protected],ssh-ed25519,ssh-rsa</code></pre>
+    HostKeyAlgorithms [email protected],[email protected],ssh-ed25519,ssh-rsa</code></pre>
 
 Generate client keys using the following commands:
 
@@ -209,7 +213,7 @@ Create the ssh-user group with `sudo groupadd ssh-user`, then add each ssh user
 
 Symmetric ciphers are used to encrypt the data after the initial key exchange and authentication is complete.
 
-Here we have quite a few algorithms:
+Here we have quite a few algorithms (10-14 were removed in [OpenSSH 7.6][76release]):
 
 1. 3des-cbc
 1. aes128-cbc
@@ -237,7 +241,7 @@ We have to consider the following:
 * *Block size*:
   Does not apply to stream ciphers.
   At least 128 bits.
-  This eliminates 14 because CAST has a 64 bit block size.
+  This eliminates 13 and 14 because those have a 64 bit block size.
 * *Cipher mode*:
   The recommended approach here is to prefer [AE][ae] modes and optionally allow CTR for compatibility.
   CTR with Encrypt-then-MAC is provably secure.
@@ -284,7 +288,6 @@ Here are the available MAC choices:
 
 1. hmac-md5
 1. hmac-md5-96
-1. hmac-ripemd160
 1. hmac-sha1
 1. hmac-sha1-96
 1. hmac-sha2-256
@@ -293,7 +296,6 @@ Here are the available MAC choices:
 1. umac-128
 1. [email protected]
 1. [email protected]
-1. [email protected]
 1. [email protected]
 1. [email protected]
 1. [email protected]
@@ -320,12 +322,12 @@ The selection considerations:
 
 Recommended `/etc/ssh/sshd_config` snippet:
 
-<pre><code id="server-macs">MACs [email protected],[email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,[email protected]</code></pre>
+<pre><code id="server-macs">MACs [email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,[email protected]</code></pre>
 
 Recommended `/etc/ssh/ssh_config` snippet:
 
 <pre><code id="client-macs">Host *
-    MACs [email protected],[email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,[email protected]</code></pre>
+    MACs [email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,[email protected]</code></pre>
 
 # Preventing key theft
 
@@ -334,6 +336,13 @@ The NSA has a database of stolen keys - you do not want your key there.
 
 ## System hardening
 
+OpenSSH has some undocumented, and rarely used features.
+UseRoaming is one such feature with a known vulnerability.
+
+Recommended `/etc/ssh/ssh_config` snippet:
+<pre><code id="client-features">Host *
+   UseRoaming no</code></pre>
+
 This post is not intended to be a comprehensive system security guide.
 Very briefly:
 
@@ -451,9 +460,12 @@ I promise not to use `git push -f`.
 [libsshdoc]: http://git.libssh.org/projects/libssh.git/tree/doc/[email protected]
 [curve25519]: http://cr.yp.to/ecdh.html
 [rfc4253]: https://www.ietf.org/rfc/rfc4253.txt
+[dh-draft]: https://tools.ietf.org/html/draft-ietf-curdle-ssh-modp-dh-sha2-09
+[73release]: https://www.openssh.com/releasenotes.html#7.3
+[76release]: https://www.openssh.com/releasenotes.html#7.6
 [rfc4419]: https://www.ietf.org/rfc/rfc4419.txt
 [ed25519]: http://ed25519.cr.yp.to/
-[google-auth]: https://code.google.com/p/google-authenticator/wiki/PamModuleInstructions
+[google-auth]: https://github.com/google/google-authenticator/wiki/PAM-Module-Instructions
 [totp]: https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm
 [otp]: https://www.cl.cam.ac.uk/~mgk25/otpw.html
 [pam]: https://en.wikipedia.org/wiki/Pluggable_authentication_module
@@ -468,3 +480,4 @@ I promise not to use `git push -f`.
 [sssh-wiki]: https://github.com/stribika/stribika.github.io/wiki/Secure-Secure-Shell
 [changelog]: https://github.com/stribika/stribika.github.io/commits/master/_posts/2015-01-04-secure-secure-shell.md
 [bug779880]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779880
+[sloth]: https://www.mitls.org/downloads/transcript-collisions.pdf
diff --git a/_posts/2015-08-07-why-cyber-deterrence-is-bullshit.md b/_posts/2015-08-07-why-cyber-deterrence-is-bullshit.md
@@ -0,0 +1,46 @@
+---
+layout: post
+title: "Why cyber deterrence is bullshit"
+tags: [bullshit, cybercybercyber, deterrence]
+---
+
+You may have heard of [this brilliant idea](https://uk.businessinsider.com/us-retaliation-against-china-for-opm-hacks-2015-8).
+That's right, "hack back" as foreign policy.
+It does not and will never work.
+
+The reasons why this is utter bullshit should be all too obvious, but my Twitter account is locked and I have nothing better to do, so here goes:
+
+1. *The word cyber.*
+   Whenever you hear it, question the speaker's competence.
+1. *Easy access.*
+   To build nuclear weapons, you need: relatively rare fissionable materials, huge enrichment facilities, knowledge, and ICBMs.
+   To hack, you need: a computer, electricity, knowledge, and Internet access.
+   You may be able to deter a few rational entities capable of building nukes, but not every single child capable of hacking OPM.
+   There is nothing even close to perfect rationality on the Internet.
+1. *Attribution.*
+   Radars and satellites can clearly show where the missiles are coming from.
+   No such device exists for detecting the origin of a breach.
+   Attribution is purely guesswork, based on things like the language of strings found in the malware, source IPs, etc.
+   It's like sending a postcard, then trying to figure out who read it.
+   Does that sound like perfect detection?
+1. *Working defense.*
+   Missile defense systems are actually more dangerous that the nukes they are trying to defend against.
+   This is because they have a [very interesting property](https://en.wikipedia.org/wiki/Pre-emptive_nuclear_strike#Destabilizing_role_of_missile_defense):
+   They reduce the second strike capability of one side, making counterforce first strike the logical choice for the other.
+   The reason we are still all here, reading this post, is because covering large areas with such defenses is not feasible.
+   This is not the case for defending computers against intrusion.
+   Yes, attackers have a clear advantage over defenders, that is to say, hacking will always be possible.
+   But it is significantly more difficult, and the effect less devastating, if the opponent just doesn't have an OPM equivalent.
+   There goes your second strike.
+1. *It is not a fucking weapon.*
+   The damage caused by even the worst breaches is nowhere near the damage caused by a thermonuclear explosion.
+   Even conventional weapons cause more damage, and are more scary.
+   This is also supported by the fact that no sane person would risk armed conflict over hacking incidents.
+   No one is afraid of getting pwned.
+
+Today's attackers don't even need their advantage.
+They get in because we let them.
+We should focus on exploit mitigation (Grsecurity), isolation (Qubes), sandboxed multiprocess architectures (Chrome, qmail), encryption, and fixing shit.
+Instead we are wasting time trying to make the attribution dice work, listening to fumbling idiots threaten the Chinese, and looking for a magic security device that solves everything if we just connect it to the network.
+
+We know what to do and we know how to do it.
diff --git a/_posts/2015-11-23-service-discovery-and-authentication.md b/_posts/2015-11-23-service-discovery-and-authentication.md
@@ -0,0 +1,104 @@
+---
+layout: post
+title: "Service discovery and authentication"
+tags: [java,security,zookeeper,tls]
+---
+
+[ZooKeeper][zk] is a popular choice for service discovery in distributed systems.
+It is a hierarchical key-value store with very strong consistency guarantees.
+What makes it a good choice for service discovery is its capability to create temporary tree nodes that disappear when the session that created it is disconnected.
+Another important feature is sequential nodes - nodes that have a consistent counter appended to their name.
+You can use these for implementing distributed locking for example.
+This post is about the authentication problems that appear as a result of introducting service discovery into a distributed system.
+
+# Service discovery
+
+The exact details of implementing a [service discovery protocol][zksvc] using ZooKeeper is outside the scope of this document.
+I want to describe it in enough details so that we can understand its security properties.
+Each service that's running and ready to respond to requests opens a persistent connection to Zookeeper.
+What usually happens is there is a root node, say /services, and it creates a temporary, sequential node:
+
+<code>
+/services/foo-service-1 = https://somehost.inthecloud.internal:6666
+/services/foo-service-3 = https://otherhost.inthecloud.internal:12345
+</code>
+
+If you want to talk to this foo-service, you look in this root node and retrieve all the registered foo-service hostnames.
+You pick one randomly, or using round-robin, or what have you, and talk to that.
+If it fails, you try another.
+If you shut down foo-service, or it crashes, the temporary node is removed and other services will no longer try to talk to it.
+
+# Authenticating hostnames
+
+In the example above, we are using HTTPS URLs, so you probably want some kind of internal CA to sign the certificates.
+(You might want to use some different protocol, Kerberos maybe.)
+You connect to the host and you can be sure it's really that host, no one is eavesdropping, all the good things.
+
+There are two problems with this.
+First, you are using Zookeeper because you don't want to care about what host is running which service.
+You certainly don't want to sign a new certificate for each one, deploy the private key to that host, etc.
+You can do this.
+It is possible.
+You can even automate it if you don't mind having an online CA, that is not only easier to abuse, but also limits your availability.
+
+The second, and even more important problem is _authenticating the wrong thing_.
+What if ZooKeeper lies to you?
+What if a compromised service publishes a hostname for some other service?
+You connect to that, verify that its certificate is correct, and proceed talking to the wrong service without noticing anything is wrong.
+Now, ZooKeeper is capable of controlling who can write what node, so you can create a structure like this:
+
+<code>
+/services/foo-service/foo-service-1 = https://a.inthecloud.internal:6666
+/services/foo-service/foo-service-3 = https://b.inthecloud.internal:12345
+/services/bar-service/bar-service-0 = https://c.inthecloud.internal:6666
+/services/baz-service/baz-service-2 = https://d.inthecloud.internal:4444
+</code>
+
+You have to set up the permissions so that no one can write /services, the user running foo-service can only write /services/foo-service, etc.
+This still doesn't help if Zookeeper itself is compromised.
+
+This way we must trust Zookeeper and the CA.
+
+# Authenticating service names
+
+There is a better way.
+We don't care about the hostname, the same way we don't care about the IP address.
+We don't sign certificates for IP addresses.
+We can sign a certificate for the service name, as in, CN=foo-service.
+Actually, we don't even have to sign it - the (self-signed) certificate can be included with the code of its clients.
+
+The main disadvantage of this approach is having to write custom certificate validation code, which I have done in Java.
+In Java it's actually pretty simple, the interfaces of interest are [X509KeyManager][keyman] and [X509TrustManager][trustman].
+Some of the methods relating to CAs will be simple stubs.
+There are "extended" versions of both, with more methods you don't need.
+I will publish the code, but I did this at work, and have not had time to reimplement it in the public domain.
+
+This way we don't have to trust Zookeeper, and we don't have to trust the CA either (we don't have one).
+The only thing we do have to trust is that the certificates included in the code are correct, but if someone can change that, they can change the code too.
+
+There is still the matter of deploying the private keys to the hosts, but now it can be the same one for each instance of the same service.
+This could be on a NAS, or scp'd to the local machine before starting the service that needs it.
+Obviously we also have to trust that the ACLs will protect the private key but this is no worse than the previous method.
+
+# Authenticating the client
+
+We must not forget to authenticate the client certificate as well.
+This is usually not done for browsers, but for inter-service traffic it is essential.
+You might want to use a different CN if the same service is sometimes the server and sometimes the client.
+Or you can use the same certificate but I don't recommend it.
+If they are different you can use the CA system for client authentication and use the embedded cert system for server authentication.
+Either way, this means you have to embedd the certificate of the client in the server code.
+
+There are all these certificates embedded everywhere.
+It doesn't sound too maintainable, but what's really going on here is each service consists of 3 files:
+
+- A server JAR that runs the server and doesn't contain any certs.
+- A client JAR that's a library imported by the clients, and contains the cert for the service.
+- A certificate, to be used for client authentication. (Or not, you could use a CA here.)
+
+It's not that bad.
+
+[keyman]: https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/X509KeyManager.html
+[trustman]: https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/X509TrustManager.html
+[zk]: https://zookeeper.apache.org/
+[zksvc]: http://blog.arungupta.me/zookeeper-microservice-registration-discovery/
diff --git a/about.md b/about.md
@@ -8,7 +8,7 @@ I am stribika.
 I [write code](https://github.com/stribika) and I [tweet](https://twitter.com/stribika).
 Also, [stackoverflow](https://stackoverflow.com/users/128514/stribika).
 
-* PGP fingerprint: `9AB5 E3A6 0AE3 F091 0B86  056F CFB7 F248 7B01 6D87` and [public key](/assets/rsa-pubkey-7B016D87.txt)
+* PGP fingerprint: `0406 629F F94F 92BF DEE5  FDA7 A11E 98D6 4B0F C61E` and [public key](/assets/rsa-pubkey-4B0FC61E.txt)
 * OTR fingerprint: `4218BF59 537FED11 30D72874 423FECC4 75D849D8`
 * BTC address: `18JbJ37A5VW5FKpbaXgfeAixSyVVac6fa4`
 

diff --git a/assets/NSA-Emails-About-Snowden-s-Concerns.pdf b/assets/NSA-Emails-About-Snowden-s-Concerns.pdf
diff --git a/assets/no.png b/assets/no.png