New TLS encryption-busting attack also impacts the newer TLS 1.3, is ECDHE_RSA also affected?












3















February 9, 2019: Source: New TLS encryption-busting attack also impacts the newer TLS 1.3



"Seven researchers from all over the world found --yet again-- another way to break RSA PKCS#1 v1.5, the most common RSA configuration used to encrypt TLS connections nowadays. Besides TLS, this new Bleichenbacher attack also works against Google's new QUIC encryption protocol as well."



Is TLS_ECDHE_RSA, and DHE_RSA, also affected? Or only TLS_RSA? If not please explain why.



Windows update example:



fe2.update.microsoft.com.nsatc.net offered
TLS_ECDHE_RSA_WITH_AES128_GCM_SHA384
x25519

EC Diffie-Hellman Server Params
Curve Type: named_curve (0x03)
Named Curve: x25519 (0x001d)
Pubkey Length: 32
Pubkey: e3267867db92a040eae6ea57bdb8e042680fa2e95da1e983...
Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
Signature Length: 256









share|improve this question



























    3















    February 9, 2019: Source: New TLS encryption-busting attack also impacts the newer TLS 1.3



    "Seven researchers from all over the world found --yet again-- another way to break RSA PKCS#1 v1.5, the most common RSA configuration used to encrypt TLS connections nowadays. Besides TLS, this new Bleichenbacher attack also works against Google's new QUIC encryption protocol as well."



    Is TLS_ECDHE_RSA, and DHE_RSA, also affected? Or only TLS_RSA? If not please explain why.



    Windows update example:



    fe2.update.microsoft.com.nsatc.net offered
    TLS_ECDHE_RSA_WITH_AES128_GCM_SHA384
    x25519

    EC Diffie-Hellman Server Params
    Curve Type: named_curve (0x03)
    Named Curve: x25519 (0x001d)
    Pubkey Length: 32
    Pubkey: e3267867db92a040eae6ea57bdb8e042680fa2e95da1e983...
    Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
    Signature Length: 256









    share|improve this question

























      3












      3








      3


      1






      February 9, 2019: Source: New TLS encryption-busting attack also impacts the newer TLS 1.3



      "Seven researchers from all over the world found --yet again-- another way to break RSA PKCS#1 v1.5, the most common RSA configuration used to encrypt TLS connections nowadays. Besides TLS, this new Bleichenbacher attack also works against Google's new QUIC encryption protocol as well."



      Is TLS_ECDHE_RSA, and DHE_RSA, also affected? Or only TLS_RSA? If not please explain why.



      Windows update example:



      fe2.update.microsoft.com.nsatc.net offered
      TLS_ECDHE_RSA_WITH_AES128_GCM_SHA384
      x25519

      EC Diffie-Hellman Server Params
      Curve Type: named_curve (0x03)
      Named Curve: x25519 (0x001d)
      Pubkey Length: 32
      Pubkey: e3267867db92a040eae6ea57bdb8e042680fa2e95da1e983...
      Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
      Signature Length: 256









      share|improve this question














      February 9, 2019: Source: New TLS encryption-busting attack also impacts the newer TLS 1.3



      "Seven researchers from all over the world found --yet again-- another way to break RSA PKCS#1 v1.5, the most common RSA configuration used to encrypt TLS connections nowadays. Besides TLS, this new Bleichenbacher attack also works against Google's new QUIC encryption protocol as well."



      Is TLS_ECDHE_RSA, and DHE_RSA, also affected? Or only TLS_RSA? If not please explain why.



      Windows update example:



      fe2.update.microsoft.com.nsatc.net offered
      TLS_ECDHE_RSA_WITH_AES128_GCM_SHA384
      x25519

      EC Diffie-Hellman Server Params
      Curve Type: named_curve (0x03)
      Named Curve: x25519 (0x001d)
      Pubkey Length: 32
      Pubkey: e3267867db92a040eae6ea57bdb8e042680fa2e95da1e983...
      Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
      Signature Length: 256






      encryption tls cryptography vulnerability






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked 7 hours ago









      TylerTyler

      707




      707






















          2 Answers
          2






          active

          oldest

          votes


















          4














          This article is poorly written. First, by this time, it's old news: the attack was made public over two months ago. Oddly there doesn't seem to have been a thread about this attack here before, but there was one on Cryptography Stack Exchange which you can read for an introduction to how the attack works.



          A second way in which this article is misleading is that this attack does not impact TLS 1.3 in itself. It impacts servers that support TLS 1.3 and older versions, if the attacker manages to downgrade the connection.



          “The most common RSA configuration used to encrypt TLS connections” is also misleading. It's technically true, in that it is the only TLS configuration that uses RSA for encryption, but in fact most TLS configurations that use RSA use it for signature, not for encryption.



          The attack works only against TLS_RSA cipher suites, i.e. against cipher suites that have RSA in their name but not DHE or ECDHE. It attacks RSA decryption. Cipher suites that use RSA signature, or that don't use RSA at all, are not affected.



          In order to perform the direct attack, the attacker has to convince the victims to use TLS ≤1.2 with an RSA-decryption cipher suite. It can often do that by hijacking the very beginning of the connection (it's a man-in-the-middle attack) and telling the client that it only supports TLS 1.2 (or some earlier version) and only RSA-decryption cipher suites. The client then sends a value encrypted with the server's public key, and the attacker must decrypt it to continue talking to the client. Normally decrypting the value requires the private key, but if the server is vulnerable to the attack, then the attacker is able to trick the server into decrypting that value by making many connections to the server with an RSA-decryption cipher suite, sending carefully-chosen ciphertexts and observing the precise timing of the server's response.



          Even if the client refuses to use RSA-decryption cipher suites, or indeed even if the client only supports TLS 1.3, it may still be vulnerable if the server uses the same RSA private key for decryption and for signature. To perform this variant of the attack, the attacker is once again a man-in-the-middle, and it uses an RSA-signature cipher suite to talk to the client. At some point the attacker needs to sign a value with the server's private key, and it does this as above by making many connections to the server with an RSA-decryption cipher suite.



          To protect against this attack, you can do any of the following:




          • Keep your server up to date. This is the best way to protect against every attack.

          • Disable RSA-decryption cipher suites on the server.

          • Disable RSA-decryption cipher suites on the client and not use the same RSA private key for decryption and signature on the server.






          share|improve this answer
























          • Thank you very much for taking the time to post this! Very much appreciated!

            – Tyler
            3 hours ago











          • I find the name "RSA-decryption cipher suite" a bit misleading since these are usually not called this way. These are actually cipher suites that use the RSA key exchange. But yes, RSA key exchange makes use of RSA decryption, but only for getting the pre-master secret and not for decryption of application data.

            – Steffen Ullrich
            25 mins ago





















          0














          Thank you for your answer, Gilles, apparently this has a name; (the first source never gave any name). Such appears to be the nature of everything crypto.



          https://robotattack.org/



          "ROBOT only affects TLS cipher modes that use RSA encryption. Most modern TLS connections use an Elliptic Curve Diffie Hellman key exchange and need RSA only for signatures. We believe RSA encryption modes are so risky that the only safe course of action is to disable them. Apart from being risky these modes also lack forward secrecy.



          By disabling RSA encryption we mean all ciphers that start with TLS_RSA. It does not include the ciphers that use RSA signatures and include DHE or ECDHE in their name. These ciphers are not affected by our attack.



          Based on some preliminary data we also believe the compatibility costs of disabling RSA encryption modes are relatively low. Cloudflare shared with us that around one percent of their connections use the RSA encryption modes. Disabling these modes on the HTTPS server operated by one of the authors caused no notable problems."






          share|improve this answer
























          • This does not look like an answer to (your own) question but instead as feedback to the answer by Gilles. But it was posted as answer. Please make yourself familiar on how this site works, i.e. that it is a strict Q+A site and not a discussion forum. Specifically the answers are not a discussion thread and they might be shown in different order for different users (like newest first, highest voted first etc). To give feedback to some user use the comment function instead.

            – Steffen Ullrich
            22 mins ago













          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "162"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          noCode: true, onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f203289%2fnew-tls-encryption-busting-attack-also-impacts-the-newer-tls-1-3-is-ecdhe-rsa-a%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          2 Answers
          2






          active

          oldest

          votes








          2 Answers
          2






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          4














          This article is poorly written. First, by this time, it's old news: the attack was made public over two months ago. Oddly there doesn't seem to have been a thread about this attack here before, but there was one on Cryptography Stack Exchange which you can read for an introduction to how the attack works.



          A second way in which this article is misleading is that this attack does not impact TLS 1.3 in itself. It impacts servers that support TLS 1.3 and older versions, if the attacker manages to downgrade the connection.



          “The most common RSA configuration used to encrypt TLS connections” is also misleading. It's technically true, in that it is the only TLS configuration that uses RSA for encryption, but in fact most TLS configurations that use RSA use it for signature, not for encryption.



          The attack works only against TLS_RSA cipher suites, i.e. against cipher suites that have RSA in their name but not DHE or ECDHE. It attacks RSA decryption. Cipher suites that use RSA signature, or that don't use RSA at all, are not affected.



          In order to perform the direct attack, the attacker has to convince the victims to use TLS ≤1.2 with an RSA-decryption cipher suite. It can often do that by hijacking the very beginning of the connection (it's a man-in-the-middle attack) and telling the client that it only supports TLS 1.2 (or some earlier version) and only RSA-decryption cipher suites. The client then sends a value encrypted with the server's public key, and the attacker must decrypt it to continue talking to the client. Normally decrypting the value requires the private key, but if the server is vulnerable to the attack, then the attacker is able to trick the server into decrypting that value by making many connections to the server with an RSA-decryption cipher suite, sending carefully-chosen ciphertexts and observing the precise timing of the server's response.



          Even if the client refuses to use RSA-decryption cipher suites, or indeed even if the client only supports TLS 1.3, it may still be vulnerable if the server uses the same RSA private key for decryption and for signature. To perform this variant of the attack, the attacker is once again a man-in-the-middle, and it uses an RSA-signature cipher suite to talk to the client. At some point the attacker needs to sign a value with the server's private key, and it does this as above by making many connections to the server with an RSA-decryption cipher suite.



          To protect against this attack, you can do any of the following:




          • Keep your server up to date. This is the best way to protect against every attack.

          • Disable RSA-decryption cipher suites on the server.

          • Disable RSA-decryption cipher suites on the client and not use the same RSA private key for decryption and signature on the server.






          share|improve this answer
























          • Thank you very much for taking the time to post this! Very much appreciated!

            – Tyler
            3 hours ago











          • I find the name "RSA-decryption cipher suite" a bit misleading since these are usually not called this way. These are actually cipher suites that use the RSA key exchange. But yes, RSA key exchange makes use of RSA decryption, but only for getting the pre-master secret and not for decryption of application data.

            – Steffen Ullrich
            25 mins ago


















          4














          This article is poorly written. First, by this time, it's old news: the attack was made public over two months ago. Oddly there doesn't seem to have been a thread about this attack here before, but there was one on Cryptography Stack Exchange which you can read for an introduction to how the attack works.



          A second way in which this article is misleading is that this attack does not impact TLS 1.3 in itself. It impacts servers that support TLS 1.3 and older versions, if the attacker manages to downgrade the connection.



          “The most common RSA configuration used to encrypt TLS connections” is also misleading. It's technically true, in that it is the only TLS configuration that uses RSA for encryption, but in fact most TLS configurations that use RSA use it for signature, not for encryption.



          The attack works only against TLS_RSA cipher suites, i.e. against cipher suites that have RSA in their name but not DHE or ECDHE. It attacks RSA decryption. Cipher suites that use RSA signature, or that don't use RSA at all, are not affected.



          In order to perform the direct attack, the attacker has to convince the victims to use TLS ≤1.2 with an RSA-decryption cipher suite. It can often do that by hijacking the very beginning of the connection (it's a man-in-the-middle attack) and telling the client that it only supports TLS 1.2 (or some earlier version) and only RSA-decryption cipher suites. The client then sends a value encrypted with the server's public key, and the attacker must decrypt it to continue talking to the client. Normally decrypting the value requires the private key, but if the server is vulnerable to the attack, then the attacker is able to trick the server into decrypting that value by making many connections to the server with an RSA-decryption cipher suite, sending carefully-chosen ciphertexts and observing the precise timing of the server's response.



          Even if the client refuses to use RSA-decryption cipher suites, or indeed even if the client only supports TLS 1.3, it may still be vulnerable if the server uses the same RSA private key for decryption and for signature. To perform this variant of the attack, the attacker is once again a man-in-the-middle, and it uses an RSA-signature cipher suite to talk to the client. At some point the attacker needs to sign a value with the server's private key, and it does this as above by making many connections to the server with an RSA-decryption cipher suite.



          To protect against this attack, you can do any of the following:




          • Keep your server up to date. This is the best way to protect against every attack.

          • Disable RSA-decryption cipher suites on the server.

          • Disable RSA-decryption cipher suites on the client and not use the same RSA private key for decryption and signature on the server.






          share|improve this answer
























          • Thank you very much for taking the time to post this! Very much appreciated!

            – Tyler
            3 hours ago











          • I find the name "RSA-decryption cipher suite" a bit misleading since these are usually not called this way. These are actually cipher suites that use the RSA key exchange. But yes, RSA key exchange makes use of RSA decryption, but only for getting the pre-master secret and not for decryption of application data.

            – Steffen Ullrich
            25 mins ago
















          4












          4








          4







          This article is poorly written. First, by this time, it's old news: the attack was made public over two months ago. Oddly there doesn't seem to have been a thread about this attack here before, but there was one on Cryptography Stack Exchange which you can read for an introduction to how the attack works.



          A second way in which this article is misleading is that this attack does not impact TLS 1.3 in itself. It impacts servers that support TLS 1.3 and older versions, if the attacker manages to downgrade the connection.



          “The most common RSA configuration used to encrypt TLS connections” is also misleading. It's technically true, in that it is the only TLS configuration that uses RSA for encryption, but in fact most TLS configurations that use RSA use it for signature, not for encryption.



          The attack works only against TLS_RSA cipher suites, i.e. against cipher suites that have RSA in their name but not DHE or ECDHE. It attacks RSA decryption. Cipher suites that use RSA signature, or that don't use RSA at all, are not affected.



          In order to perform the direct attack, the attacker has to convince the victims to use TLS ≤1.2 with an RSA-decryption cipher suite. It can often do that by hijacking the very beginning of the connection (it's a man-in-the-middle attack) and telling the client that it only supports TLS 1.2 (or some earlier version) and only RSA-decryption cipher suites. The client then sends a value encrypted with the server's public key, and the attacker must decrypt it to continue talking to the client. Normally decrypting the value requires the private key, but if the server is vulnerable to the attack, then the attacker is able to trick the server into decrypting that value by making many connections to the server with an RSA-decryption cipher suite, sending carefully-chosen ciphertexts and observing the precise timing of the server's response.



          Even if the client refuses to use RSA-decryption cipher suites, or indeed even if the client only supports TLS 1.3, it may still be vulnerable if the server uses the same RSA private key for decryption and for signature. To perform this variant of the attack, the attacker is once again a man-in-the-middle, and it uses an RSA-signature cipher suite to talk to the client. At some point the attacker needs to sign a value with the server's private key, and it does this as above by making many connections to the server with an RSA-decryption cipher suite.



          To protect against this attack, you can do any of the following:




          • Keep your server up to date. This is the best way to protect against every attack.

          • Disable RSA-decryption cipher suites on the server.

          • Disable RSA-decryption cipher suites on the client and not use the same RSA private key for decryption and signature on the server.






          share|improve this answer













          This article is poorly written. First, by this time, it's old news: the attack was made public over two months ago. Oddly there doesn't seem to have been a thread about this attack here before, but there was one on Cryptography Stack Exchange which you can read for an introduction to how the attack works.



          A second way in which this article is misleading is that this attack does not impact TLS 1.3 in itself. It impacts servers that support TLS 1.3 and older versions, if the attacker manages to downgrade the connection.



          “The most common RSA configuration used to encrypt TLS connections” is also misleading. It's technically true, in that it is the only TLS configuration that uses RSA for encryption, but in fact most TLS configurations that use RSA use it for signature, not for encryption.



          The attack works only against TLS_RSA cipher suites, i.e. against cipher suites that have RSA in their name but not DHE or ECDHE. It attacks RSA decryption. Cipher suites that use RSA signature, or that don't use RSA at all, are not affected.



          In order to perform the direct attack, the attacker has to convince the victims to use TLS ≤1.2 with an RSA-decryption cipher suite. It can often do that by hijacking the very beginning of the connection (it's a man-in-the-middle attack) and telling the client that it only supports TLS 1.2 (or some earlier version) and only RSA-decryption cipher suites. The client then sends a value encrypted with the server's public key, and the attacker must decrypt it to continue talking to the client. Normally decrypting the value requires the private key, but if the server is vulnerable to the attack, then the attacker is able to trick the server into decrypting that value by making many connections to the server with an RSA-decryption cipher suite, sending carefully-chosen ciphertexts and observing the precise timing of the server's response.



          Even if the client refuses to use RSA-decryption cipher suites, or indeed even if the client only supports TLS 1.3, it may still be vulnerable if the server uses the same RSA private key for decryption and for signature. To perform this variant of the attack, the attacker is once again a man-in-the-middle, and it uses an RSA-signature cipher suite to talk to the client. At some point the attacker needs to sign a value with the server's private key, and it does this as above by making many connections to the server with an RSA-decryption cipher suite.



          To protect against this attack, you can do any of the following:




          • Keep your server up to date. This is the best way to protect against every attack.

          • Disable RSA-decryption cipher suites on the server.

          • Disable RSA-decryption cipher suites on the client and not use the same RSA private key for decryption and signature on the server.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered 4 hours ago









          GillesGilles

          38.9k1192146




          38.9k1192146













          • Thank you very much for taking the time to post this! Very much appreciated!

            – Tyler
            3 hours ago











          • I find the name "RSA-decryption cipher suite" a bit misleading since these are usually not called this way. These are actually cipher suites that use the RSA key exchange. But yes, RSA key exchange makes use of RSA decryption, but only for getting the pre-master secret and not for decryption of application data.

            – Steffen Ullrich
            25 mins ago





















          • Thank you very much for taking the time to post this! Very much appreciated!

            – Tyler
            3 hours ago











          • I find the name "RSA-decryption cipher suite" a bit misleading since these are usually not called this way. These are actually cipher suites that use the RSA key exchange. But yes, RSA key exchange makes use of RSA decryption, but only for getting the pre-master secret and not for decryption of application data.

            – Steffen Ullrich
            25 mins ago



















          Thank you very much for taking the time to post this! Very much appreciated!

          – Tyler
          3 hours ago





          Thank you very much for taking the time to post this! Very much appreciated!

          – Tyler
          3 hours ago













          I find the name "RSA-decryption cipher suite" a bit misleading since these are usually not called this way. These are actually cipher suites that use the RSA key exchange. But yes, RSA key exchange makes use of RSA decryption, but only for getting the pre-master secret and not for decryption of application data.

          – Steffen Ullrich
          25 mins ago







          I find the name "RSA-decryption cipher suite" a bit misleading since these are usually not called this way. These are actually cipher suites that use the RSA key exchange. But yes, RSA key exchange makes use of RSA decryption, but only for getting the pre-master secret and not for decryption of application data.

          – Steffen Ullrich
          25 mins ago















          0














          Thank you for your answer, Gilles, apparently this has a name; (the first source never gave any name). Such appears to be the nature of everything crypto.



          https://robotattack.org/



          "ROBOT only affects TLS cipher modes that use RSA encryption. Most modern TLS connections use an Elliptic Curve Diffie Hellman key exchange and need RSA only for signatures. We believe RSA encryption modes are so risky that the only safe course of action is to disable them. Apart from being risky these modes also lack forward secrecy.



          By disabling RSA encryption we mean all ciphers that start with TLS_RSA. It does not include the ciphers that use RSA signatures and include DHE or ECDHE in their name. These ciphers are not affected by our attack.



          Based on some preliminary data we also believe the compatibility costs of disabling RSA encryption modes are relatively low. Cloudflare shared with us that around one percent of their connections use the RSA encryption modes. Disabling these modes on the HTTPS server operated by one of the authors caused no notable problems."






          share|improve this answer
























          • This does not look like an answer to (your own) question but instead as feedback to the answer by Gilles. But it was posted as answer. Please make yourself familiar on how this site works, i.e. that it is a strict Q+A site and not a discussion forum. Specifically the answers are not a discussion thread and they might be shown in different order for different users (like newest first, highest voted first etc). To give feedback to some user use the comment function instead.

            – Steffen Ullrich
            22 mins ago


















          0














          Thank you for your answer, Gilles, apparently this has a name; (the first source never gave any name). Such appears to be the nature of everything crypto.



          https://robotattack.org/



          "ROBOT only affects TLS cipher modes that use RSA encryption. Most modern TLS connections use an Elliptic Curve Diffie Hellman key exchange and need RSA only for signatures. We believe RSA encryption modes are so risky that the only safe course of action is to disable them. Apart from being risky these modes also lack forward secrecy.



          By disabling RSA encryption we mean all ciphers that start with TLS_RSA. It does not include the ciphers that use RSA signatures and include DHE or ECDHE in their name. These ciphers are not affected by our attack.



          Based on some preliminary data we also believe the compatibility costs of disabling RSA encryption modes are relatively low. Cloudflare shared with us that around one percent of their connections use the RSA encryption modes. Disabling these modes on the HTTPS server operated by one of the authors caused no notable problems."






          share|improve this answer
























          • This does not look like an answer to (your own) question but instead as feedback to the answer by Gilles. But it was posted as answer. Please make yourself familiar on how this site works, i.e. that it is a strict Q+A site and not a discussion forum. Specifically the answers are not a discussion thread and they might be shown in different order for different users (like newest first, highest voted first etc). To give feedback to some user use the comment function instead.

            – Steffen Ullrich
            22 mins ago
















          0












          0








          0







          Thank you for your answer, Gilles, apparently this has a name; (the first source never gave any name). Such appears to be the nature of everything crypto.



          https://robotattack.org/



          "ROBOT only affects TLS cipher modes that use RSA encryption. Most modern TLS connections use an Elliptic Curve Diffie Hellman key exchange and need RSA only for signatures. We believe RSA encryption modes are so risky that the only safe course of action is to disable them. Apart from being risky these modes also lack forward secrecy.



          By disabling RSA encryption we mean all ciphers that start with TLS_RSA. It does not include the ciphers that use RSA signatures and include DHE or ECDHE in their name. These ciphers are not affected by our attack.



          Based on some preliminary data we also believe the compatibility costs of disabling RSA encryption modes are relatively low. Cloudflare shared with us that around one percent of their connections use the RSA encryption modes. Disabling these modes on the HTTPS server operated by one of the authors caused no notable problems."






          share|improve this answer













          Thank you for your answer, Gilles, apparently this has a name; (the first source never gave any name). Such appears to be the nature of everything crypto.



          https://robotattack.org/



          "ROBOT only affects TLS cipher modes that use RSA encryption. Most modern TLS connections use an Elliptic Curve Diffie Hellman key exchange and need RSA only for signatures. We believe RSA encryption modes are so risky that the only safe course of action is to disable them. Apart from being risky these modes also lack forward secrecy.



          By disabling RSA encryption we mean all ciphers that start with TLS_RSA. It does not include the ciphers that use RSA signatures and include DHE or ECDHE in their name. These ciphers are not affected by our attack.



          Based on some preliminary data we also believe the compatibility costs of disabling RSA encryption modes are relatively low. Cloudflare shared with us that around one percent of their connections use the RSA encryption modes. Disabling these modes on the HTTPS server operated by one of the authors caused no notable problems."







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered 3 hours ago









          TylerTyler

          707




          707













          • This does not look like an answer to (your own) question but instead as feedback to the answer by Gilles. But it was posted as answer. Please make yourself familiar on how this site works, i.e. that it is a strict Q+A site and not a discussion forum. Specifically the answers are not a discussion thread and they might be shown in different order for different users (like newest first, highest voted first etc). To give feedback to some user use the comment function instead.

            – Steffen Ullrich
            22 mins ago





















          • This does not look like an answer to (your own) question but instead as feedback to the answer by Gilles. But it was posted as answer. Please make yourself familiar on how this site works, i.e. that it is a strict Q+A site and not a discussion forum. Specifically the answers are not a discussion thread and they might be shown in different order for different users (like newest first, highest voted first etc). To give feedback to some user use the comment function instead.

            – Steffen Ullrich
            22 mins ago



















          This does not look like an answer to (your own) question but instead as feedback to the answer by Gilles. But it was posted as answer. Please make yourself familiar on how this site works, i.e. that it is a strict Q+A site and not a discussion forum. Specifically the answers are not a discussion thread and they might be shown in different order for different users (like newest first, highest voted first etc). To give feedback to some user use the comment function instead.

          – Steffen Ullrich
          22 mins ago







          This does not look like an answer to (your own) question but instead as feedback to the answer by Gilles. But it was posted as answer. Please make yourself familiar on how this site works, i.e. that it is a strict Q+A site and not a discussion forum. Specifically the answers are not a discussion thread and they might be shown in different order for different users (like newest first, highest voted first etc). To give feedback to some user use the comment function instead.

          – Steffen Ullrich
          22 mins ago




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Information Security Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f203289%2fnew-tls-encryption-busting-attack-also-impacts-the-newer-tls-1-3-is-ecdhe-rsa-a%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          How did Captain America manage to do this?

          迪纳利

          南乌拉尔铁路局