
KCI Attacks against TLS (2015) - 0x0
https://kcitls.org/
======
pfg
Note that this attack was published about a year ago. (It's only mentioned in
the footer, so might be easy to miss.)

------
lucb1e
They do a lot of effort to try to make it accessible and understandable for
non-technical people, but as someone who appeared in Hacker Monthly once with
an article on how TLS works, I have a hard time getting through the
abstractions.

From what I get, it installs a client certificate* and then it gets fuzzy... I
assume they spoof the cert as if it were from the site they are targeting.
Then the only logical thing is that the client, when communicating with the
server (the one targeted in the cert), uses a key from that cert instead of
generating a random (ephemeral) one to communicate with the server. And since
the cert was installed by the attacker, the attacker now has the key to the
connection.

But that's mostly speculation based on a few keywords here and there. Don't
take it as being truth.

* Which is a perfectly legitimate action. Normal TLS authenticates the server (so you know you're talking to Hacker News for example and not to a MITM attacker); this client cert authenticates the client to the server.

If anyone cares for a rant, this is my thoughts from what I read of the
research paper:
[http://because.a.tweet.doesnt.fit.lucb1e.com/?text=Text%3A+o...](http://because.a.tweet.doesnt.fit.lucb1e.com/?text=Text%3A+over+a+thousand+characters.+Content%3A+zero.%0D%0A%0D%0A%3E+Protection+of+Internet+communication+is+becoming+more+common+in+many+products%2C+as+the+demand+for+privacy+in+an+age+of+state-
level+adversaries+and+crime+syndicates+is+steadily+increasing.%0D%0A%0D%0AOkay.%0D%0A%0D%0A%3E+The+industry+standard+for+doing+this+is+TLS.%0D%0A%0D%0AYeah.%0D%0A%0D%0A%3E+The+TLS+protocol+supports+a+multitude+of+key+agreement+and+authentication+options+which+provide+various+different+security+guarantees.%0D%0A%0D%0AIndeed.%0D%0A%0D%0A%3E+Recent+attacks+showed+that+this+plethora+of+cryptographic+options+in+TLS+%28including+long+forgotten+government+backdoors%2C+which+have+been+cunningly+inserted+via+export+restriction+laws%29+is+a+Pandora%92s+box%2C+waiting+to+be+pried+open+by+heinous+computer+whizzes.%0D%0A%0D%0ASure.%0D%0A%0D%0A%3E+Novel+attacks+lay+hidden+in+plain+sight.%0D%0A%0D%0A...%0D%0A%0D%0A%3E+Parts+of+TLS+are+so+old+that+their+foul+smell+of+rot+cannot+be+easily+distinguished+from+the+flowery+smell+of+%91strong%92+cryptography+and+water-
tight+security+mechanisms.%0D%0A%0D%0AKinda.%0D%0A%0D%0A%3E+With+an+arcane+%28but+well-
known+among+some+theoretical+cryptographers%29+tool%2C+we+put+new+cracks+into+Pandora%92s+box%2C+achieving+a+full+break+of+TLS+security.%0D%0A%0D%0AGo+on...%0D%0A%0D%0A%3E+This+time%2C+the+tool+of+choice+is+KCI%2C+or+Key+Compromise+Impersonation.%0D%0A%0D%0AYeah+that+tells+me+nothing.%0D%0A%0D%0A%3E+The+TLS+protocol+includes+a+class+of+key+agreement+and+authentication+methods+that+are+vulnerable+to+KCI+attacks%3A+non-
ephemeral+Diffie-Hellman+key+exchange+with+fixed+Diffie-
Hellman+client+authentication+%96+both+on+elliptic+curve+groups%2C+as+well+as+on+classical+integer+groups+modulo+a+prime.%0D%0A%0D%0AI+once+had+a+teacher+that+would+fail+your+exam+for+a+sentence+that+long.+In+any+case%2C+okay%2C+this+strengthens+some+suspicions+but+CAN+WE+GET+TO+THE+POINT%3F%0D%0A%0D%0A%3E+We+show+that+TLS+clients+that+support+these+weak+handshakes+pose+serious+security+concerns+in+modern+systems%2C+opening+the+supposedly+securely+encrypted+communication+to+full-
blown+Man-in-the-
Middle+%28MitM%29+attacks.%0D%0A%0D%0AAlright%2C+here+it+comes.%0D%0A%0D%0A%3E+This+paper+%28pdf%29+discusses+and+analyzes+KCI+attacks+in+regard+to+the+TLS+protocol.%0D%0A%0D%0AWELL+I+FIGURED%0D%0A%0D%0A%3E+We+present+an+evaluation+of+the+TLS+software%0D%0A%0D%0Aokay+fuck+this+shit)

~~~
baby
The issue is pretty easy to comprehend once you understand how a Diffie-
Hellman key exchange works.

Imagine you go to myCompany.com and you do a key exchange with both of your
public keys.

* your public key: g^a mod n

* your company's public key: g^b mod n

where g and n are public parameters that you agreed on. Let's ignore n: here,
both ends can create the shared secret by doing either (g^b)^a or (g^a)^b

so (other dude's public key)^(my private key)

If you know either one of them's private key, you can observe the other public
key (it's public!) and compute the shared secret. Then you have enough to
replace one of the end in the TLS communication.

So here if you replace the client's certificate with your own keypair, or know
the private key of the certificate, you can guess whatever key exchange they
try to do with that certificate. From that key exchange you can compute the
session keys and replace any end during the following communications.

Most implementations rarely use plain DH though, and instead only offer
ephemeral DH or RSA (which are not vulnerable).

EDIT: The paper contradicts me here:

> Support for fixed DH client authentication has been very recently added to
> the OpenSSL 1.0.2 branch.

EDIT2: From the paper, it looks like this attack is/was practical:

> the attacker, under the hood, interferes with the connection initialization
> to facebook, and forces the client to use an insecure handshake with client
> authentication, requesting the previously installed certificate from the
> system.

How does facebook have these non-ephemeral DH ciphersuites?

-> from the paper, the server doesn't even need to use a static DH ciphersuite. If it has an ECDSA certificate, and didn't specify that it's only to be used to sign then you can use it for the attack (the keyUsage field in the certificate is apparently never used correctly, the few values listed in this RFC[1] tell you how to correctly limit the authorized usages of your public key)

How can you trigger the client to use this ciphersuite?

-> just reply with a serverHello only displaying static ECDH in its ciphersuite list (contrarily to ECDHE, notice the last E for ephemeral). Then show the real ECDSA certificate (the client will interpret that as a ECDH cert because of the fake ciphersuites) and then ask the client for the specific cert you know the private key of.

In addition to the ECDSA -> ECDH trumpery, this is all possible because none
of these messages are signed at that moment. They are later authenticated via
the shared secret, but it is too late =) I don't know if TLS 1.3 is doing
better in this regard.

It also seems to me that in the attack, instead of installing a client cert
you could just install a CA cert and MITM ALL TLS connections. (Except the
pinned ones.) But then, this attack is more sneaky, and it's another way of
doing exactly this.

Damn I ended up writing way too much :|

[1]:
[https://tools.ietf.org/html/rfc3280#section-4.2.1.3](https://tools.ietf.org/html/rfc3280#section-4.2.1.3)

~~~
lucb1e
Great explanation, that cleared the whole thing up. Thank you!

