)]}'
{
  "commit": "9280f153df0e4c651d658fb1f137dfc18136144e",
  "tree": "8664c3c729a19907a766900439816bea2915779d",
  "parents": [
    "e202e51cb0912f36dafbd2e67cf04d6ec82f3180"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Fri Mar 01 17:20:04 2024 -0500"
  },
  "committer": {
    "name": "Boringssl LUCI CQ",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Wed Mar 06 18:19:57 2024 +0000"
  },
  "message": "Check ECDSA curves in TLS 1.2 servers\n\nIn TLS 1.2 and below, the supported_curves list simultaneously contrains\nECDH and ECDSA. Since BoringSSL, previously, did not handle ECDSA\ncertificate selection in the library, we ignored the latter and left it\nto the callers. If configured with an ECDSA certificate that didn\u0027t\nmatch the peer\u0027s curve list, we proceeded anyway, and left it to the\nclient to reject the connection.\n\nThis contradicts RFC 8422, which says:\n\n   The server constructs an appropriate certificate chain and conveys it\n   to the client in the Certificate message.  If the client has used a\n   Supported Elliptic Curves Extension, the public key in the server\u0027s\n   certificate MUST respect the client\u0027s choice of elliptic curves.  A\n   server that cannot satisfy this requirement MUST NOT choose an ECC\n   cipher suite in its ServerHello message.)\n\nAs with the previous client certificate change, once we move certificate\nselection into the library, we\u0027ll need to evaluate this ourselves. A\nnatural implementation of it will, as a side effect, cause us to enforce\nthis match, even when only a single certificate is configured. This CL\nlands that behavior change ahead of time and, in case there are\ncompatibility impats, leaves a flag, SSL_set_check_ecdsa_curve, to\nrestore the old behavior. If the change goes through fine, we can retire\nthe flag after a few months.\n\nIf this does cause a problem, we can opt to turn it off for the default\ncertificate, or only enable it when multiple certificates are\nconfigured, but these all result in some slightly suboptimal behavior,\nso I think we should treat them as contingency plans.\n\nTo help debugging, I gave this a dedicated error, though doing so is a\nlittle tricky because of the PSK fallback. (See the\nCheckECDSACurve-PSK-TLS12 test.)\n\nUpdate-Note: A TLS 1.2 (or below) server, using an ECDSA certificate,\nconnecting to a client which doesn\u0027t advertise its ECDSA curve will now\nfail the connection slightly earlier, rather than sending the\ncertificate and waiting for the client to reject it. The connection\nshould fail either way, but now it will fail earlier with\nSSL_R_WRONG_CURVE. If the client was buggy and did not correctly\nadvertise its own capabilities, this may cause a connection to fail\ndespite previously succeeding. We have included a temporary API,\nSSL_set_check_ecdsa_curve, to disable this behavior in the event this\nhas any impact, but please contact the BoringSSL team if you need it,\nas it will interfere with improvements down the line.\n\nTLS 1.3 is not impacted by this change, neither are clients, or RSA\ncertificiates. Additionally, if your server was already looking at the\ncurve list before configuring an ECDSA certificate in TLS 1.2, this\nwill also have no impact.\n\nBug: 249\nChange-Id: I2f1d4e2627641319556847cbbbcdddf347bbc8a9\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66688\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\nReviewed-by: Bob Beck \u003cbbe@google.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "d0e5d6531c9de4a0787b94361a87aced348adc90",
      "old_mode": 33188,
      "old_path": "include/openssl/ssl.h",
      "new_id": "f8fd947192422bb282570b929a4e1cf8a1eee499",
      "new_mode": 33188,
      "new_path": "include/openssl/ssl.h"
    },
    {
      "type": "modify",
      "old_id": "661aeda1d080a036046ab5f9d947f4b0f478439d",
      "old_mode": 33188,
      "old_path": "ssl/handshake_server.cc",
      "new_id": "510062a7cdf544f69e5a542aebf262788f323c92",
      "new_mode": 33188,
      "new_path": "ssl/handshake_server.cc"
    },
    {
      "type": "modify",
      "old_id": "844c579f674d8300869459f8009118ab97fbc441",
      "old_mode": 33188,
      "old_path": "ssl/internal.h",
      "new_id": "8be743b8b5dd84b8e0568a098ff62002626d8c33",
      "new_mode": 33188,
      "new_path": "ssl/internal.h"
    },
    {
      "type": "modify",
      "old_id": "b0d296868943f8b58f9941609348d61f98af7d27",
      "old_mode": 33188,
      "old_path": "ssl/ssl_lib.cc",
      "new_id": "3f767a4c297620aa2df9432c04eb7355dc57a5c6",
      "new_mode": 33188,
      "new_path": "ssl/ssl_lib.cc"
    },
    {
      "type": "modify",
      "old_id": "bbb4d3671bd415e6077d3cf4623d792e4d5fd526",
      "old_mode": 33188,
      "old_path": "ssl/test/runner/runner.go",
      "new_id": "24e4ac72275431c0151a59fa60b83a35c9c8edad",
      "new_mode": 33188,
      "new_path": "ssl/test/runner/runner.go"
    },
    {
      "type": "modify",
      "old_id": "1883558d0c5f8f56a0ac0912332f5dee9bed2fda",
      "old_mode": 33188,
      "old_path": "ssl/test/test_config.cc",
      "new_id": "c0b435e7af899f82ff9ca406bf0695906f9126a9",
      "new_mode": 33188,
      "new_path": "ssl/test/test_config.cc"
    },
    {
      "type": "modify",
      "old_id": "8911a661bcc779b7490caf7c591e34e8b8c13077",
      "old_mode": 33188,
      "old_path": "ssl/test/test_config.h",
      "new_id": "26a11bca4f5676c09a5d6ec57989eed1e098a805",
      "new_mode": 33188,
      "new_path": "ssl/test/test_config.h"
    }
  ]
}