)]}'
{
  "commit": "eae46df1e6c1df0556ee4106bcab75657eb8181e",
  "tree": "b7dda43aae5448010bb8930c9017837b96a24a10",
  "parents": [
    "3c31f33f61cdb22e48437c4347d17c6cebab1506"
  ],
  "author": {
    "name": "David Benjamin",
    "email": "davidben@google.com",
    "time": "Fri Aug 14 12:52:41 2026 -0400"
  },
  "committer": {
    "name": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "email": "boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com",
    "time": "Fri Aug 14 10:56:45 2026 -0700"
  },
  "message": "Remove the old F5 padding workaround\n\nMany, many, many eons ago, SSL 2.0 was born.\n\nMany, many eons ago, SSL 3.0 was born. SSL 3.0 was a completely\ndifferent record layer from SSL 3.0. Since then, all versions of TLS\nkept continuity with SSL 3.0 in the record layer and ClientHello.\n\nMany eons ago, F5 shipped a TLS load balancer that supported SSL 2.0 and\nSSL 3.0. As part of that, they had to detect SSL 2.0 and SSL 3.0.\n\nEons ago, ClientHellos started hanging when talking to F5 servers. It\nturned out that, once we made the TLS ClientHello exceed 256 bytes for\nALPN, F5 misinterpeted it as an incomplete SSL 2.0 CLIENT-HELLO and\nhung.\nhttps://mailarchive.ietf.org/arch/msg/tls/8wXwhM1d5WSmROHFSgrTyFmWN2o/\nhttps://www.imperialviolet.org/2013/10/07/f5update.html\n\nIt turned out bumping the size up to 512 bytes would dodge the bug, so\nthe padding extension was born:\nhttps://www.rfc-editor.org/info/rfc7685/\n\nIt has now been almost 10 years. In that time, ClientHellos have gotten\nlarger. With X25519MLKEM768 enabled by default, every ClientHello over\nwell over 1 KiB and the padding is a no-op. Also the F5s have hopefully\ngotten updated.\n\nRemove the padding, which requires some somewhat subtle bookkeeping. In\nparticular, we usually qualify changes with Chromium but as Chromium has\nlong enabled ML-KEM, we have gotten all the signal we ever will get\nabout F5.\n\nUpdate-Note: If there are still unupdated F5s out there, a TLS client\napplication may hang when connecting to them. This would only happen if\nyour application:\n\n1. Bypasses BoringSSL\u0027s default of enabling TLS 1.3, or\n2. Bypasses BoringSSL\u0027s default of enabling X25519MLKEM768\n\nImpacted applications should enable TLS 1.3 and X25519MLKEM768 for\nbetter compatibility and security. Applications using BoringSSLs\ndefaults are not impacted by this change.\n\nFixed: 532111493\nChange-Id: I78fd1d65d9fa7c25347fb56803acd6137f038eae\nReviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/101007\nAuto-Submit: David Benjamin \u003cdavidben@google.com\u003e\nReviewed-by: Lily Chen \u003cchlily@google.com\u003e\nCommit-Queue: David Benjamin \u003cdavidben@google.com\u003e\nPresubmit-BoringSSL-Verified: boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com \u003cboringssl-scoped@luci-project-accounts.iam.gserviceaccount.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "90238d9127fba416f61a3f072cd7a86bdf1db5c6",
      "old_mode": 33188,
      "old_path": "ssl/extensions.cc",
      "new_id": "954af185b81c1d15b333520f817b0c17988ed3c5",
      "new_mode": 33188,
      "new_path": "ssl/extensions.cc"
    },
    {
      "type": "modify",
      "old_id": "fc185ec33968295646fefaaaab1b0976b5798f6e",
      "old_mode": 33188,
      "old_path": "ssl/ssl_test.cc",
      "new_id": "242c738be17442b9ff868b22b82b886370cd7cfb",
      "new_mode": 33188,
      "new_path": "ssl/ssl_test.cc"
    },
    {
      "type": "modify",
      "old_id": "6c520c86376198c84e7430de0a25f44ba18c7935",
      "old_mode": 33188,
      "old_path": "ssl/test/runner/extension_tests.go",
      "new_id": "6022b19313fed2785c1120267cf4df1e45889aba",
      "new_mode": 33188,
      "new_path": "ssl/test/runner/extension_tests.go"
    }
  ]
}