4 ms·

KCI Attacks against TLS (2015)

29 points by 0x0 10y ago

lucb1e 10y ago
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+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 http://because.a.tweet.doesnt.fit.lucb1e.com/?text=Text%3A+o...
- 0x0 10y ago
  It seems to be something about how when client certificates are forced to be used, the calculation of the TLS master secret can be re-calculated by the MITMing party (who also has the private key required for part of the calculation), and can therefore decrypt the main traffic flow between the client and the server, and also because the master secret calculation works out, the client ends up believing the server has proven its identity? Also something about "fixed DH" handshakes.
- pfg 10y ago
  The research paper[1] has more details. AIUI, knowing the client certificate's private key allows the attacker to calculate the TLS master secret if the server supports a non-ephemeral (EC)DH cipher and the attacker has access to a valid certificate (with certain properties) for the site (not the private key, just the certificate, which can be obtained by visiting the site, from Certificate Transparency logs or other sources). [1]: https://www.usenix.org/system/files/conference/woot15/woot15-paper-hlauschek.pdf https://www.usenix.org/system/files/conference/woot15/woot15...
- baby 10y ago
  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
pfg 10y ago
Note that this attack was published about a year ago. (It's only mentioned in the footer, so might be easy to miss.)
- deleted 10y ago
  [deleted]

29 points by 0x0 10y ago

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+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 http://because.a.tweet.doesnt.fit.lucb1e.com/?text=Text%3A+o...

0x0 10y ago
It seems to be something about how when client certificates are forced to be used, the calculation of the TLS master secret can be re-calculated by the MITMing party (who also has the private key required for part of the calculation), and can therefore decrypt the main traffic flow between the client and the server, and also because the master secret calculation works out, the client ends up believing the server has proven its identity? Also something about "fixed DH" handshakes.
pfg 10y ago
The research paper[1] has more details. AIUI, knowing the client certificate's private key allows the attacker to calculate the TLS master secret if the server supports a non-ephemeral (EC)DH cipher and the attacker has access to a valid certificate (with certain properties) for the site (not the private key, just the certificate, which can be obtained by visiting the site, from Certificate Transparency logs or other sources). [1]: https://www.usenix.org/system/files/conference/woot15/woot15-paper-hlauschek.pdf https://www.usenix.org/system/files/conference/woot15/woot15...
baby 10y ago
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

pfg 10y ago

Note that this attack was published about a year ago. (It's only mentioned in the footer, so might be easy to miss.)

deleted 10y ago
[deleted]