aboutsummaryrefslogtreecommitdiff
path: root/fuzz/ssl_ctx_api.cc
AgeCommit message (Collapse)AuthorFilesLines
2023-05-31Align NIDs vs group IDs in TLS group APIsDavid Benjamin1-0/+7
Right now we use NIDs to configure the group list, but group IDs (the TLS codepoints) to return the negotiated group. The NIDs come from OpenSSL, while the group ID was original our API. OpenSSL has since added SSL_get_negotiated_group, but we don't implement it. To add Kyber to QUIC, we'll need to add an API for configuring groups to QUICHE. Carrying over our inconsistency into QUICHE's public API would be unfortunate, so let's use this as the time to align things. We could either align with OpenSSL and say NIDs are now the group representation at the public API, or we could add a parallel group ID API. (Or we could make a whole new SSL_NAMED_GROUP object to pattern after SSL_CIPHER, which isn't wrong, but is even more new APIs.) Aligning with OpenSSL would be fewer APIs, but NIDs aren't a great representation. The numbers are ad-hoc and even diverge a bit between OpenSSL and BoringSSL. The TLS codepoints are better to export out to callers. Also QUICHE has exported the negotiated group using the codepoints, so the natural solution would be to use codepoints on input too. Thus, this CL adds SSL_CTX_set1_group_ids and SSL_set1_group_ids. It also rearranges the API docs slightly to put the group ID ones first, and leaves a little note about the NID representation before introducing those. While I'm here, I've added SSL_get_negotiated_group. NGINX seems to use it when available, so we may as well fill in that unnecessary compatibility hole. Bug: chromium:1442377 Change-Id: I47ca8ae52c274133f28da9893aed7fc70f942bf8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60208 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2023-05-31Align on using the "group" over "curve" for ECDH in TLSDavid Benjamin1-6/+6
We're this awkward mix of "group" and "curve" right now. On the spec side, this is because they used to be "curves", but then RFC 7919 renamed to "group" in an attempt to generalize FFDH and ECDH. The negotiated FFDH stuff never really went anywhere (the way it used cipher suite values in TLS 1.2 made it unusable), but the name change stuck. In our implementation and API, we originally called it "curve". In preparation for TLS 1.3, we renamed the internals to "group" to match the spec in https://boringssl-review.googlesource.com/c/boringssl/+/7955, but the public API was still "curve". Then we exported a few more things in https://boringssl-review.googlesource.com/c/boringssl/+/8565, but I left it at "curve" to keep the public API self-consistent. Then we added OpenSSL's new "group" APIs in https://boringssl-review.googlesource.com/c/boringssl/+/54306, but didn't go as far to deprecate the old ones yet. Now I'd like to add new APIs to clear up the weird mix of TLS codepoints and NIDs that appear in our APIs. But our naming is a mess, so either choice of "group" or "curve" for the new API looks weird. In hindsight, we probably should have left it at "curve". Both terms are equally useless for the future post-quantum KEMs, but at least "curve" is more unique of a name than "group". But at this point, I think we're too far through the "group" rename to really backtrack: - Chromium says "group" in its internals - QUICHE says "group" in its internals and public API - Our internals say "group" - OpenSSL has switched to "group" and deprecated "curve", so new APIs will be based on "group" So align with all this and say "group". This CL handles set1_curves and set1_curves_list APIs, which already have "group" replacements from OpenSSL. A follow-up CL will handle our APIs. This is a soft deprecation because I don't think updating things is particularly worth the churn, but get the old names out of the way, so new code can have a simpler API to target. Also rewrite the documentation for that section accordingly. I don't think we need to talk about how it's always enabled now. That's a reference to some very, very old OpenSSL behavior where ECDH negotiation needed to be separately enabled. Change-Id: I7a356793d36419fc668364c912ca7b4f5c6c23a2 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60206 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: Bob Beck <bbe@google.com>
2021-06-11Make ECH server APIs take EVP_HPKE_KEY.David Benjamin1-4/+10
Previously we would extract the KEM ID from the ECHConfig and then parse the private key using the corresponding KEM type. This CL makes it take a pre-pared EVP_HPKE_KEY and checks it matches. This does require the caller pass the key type through externally, which is probably prudent? (On the other hand we are still inferring config from the rest of the ECHConfig... maybe we can add an API to extract the EVP_HPKE_KEM from a serialized ECHConfig if it becomes a problem. I could see runner or tool wanting that out of convenience.) The immediate motivation is to add APIs to programmatically construct ECHConfigs. I'm thinking we can pass a const EVP_HPKE_KEY * to specify the key, at which point it's weird for SSL_ECH_KEYS_add to look different. Bug: 275 Change-Id: I2d424323885103d3fe0a99a9012c160baa8653bd Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48002 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2021-06-10Rename SSL_ECH_SERVER_CONFIG_LIST to SSL_ECH_KEYS.David Benjamin1-8/+6
The old name was really long and a bit tedious to type out. Bug: 275 Change-Id: Ie24ef811f9288e619148a2bed36ca34b67af0a3a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48001 Reviewed-by: Adam Langley <agl@google.com>
2021-04-12Add ECH server config API to ssl_ctx_api fuzzerDan McArdle1-0/+19
Bug: 275 Change-Id: I4ccf7e8385d708326c71a855585583908e82bb2d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/46744 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
2019-09-27Bound the number of API calls in ssl_ctx_api.cc.David Benjamin1-1/+2
By spamming just two bytes, this fuzzer can bounce between SSL_CTX_use_certificate and SSL_CTX_get0_certificate, which continually runs d2i_X509 on some certificate. Doing that nearly 400,000 times is not particularly useful. Bound the number of API calls. Start with 10,000 and see if the fuzzers are still unhappy. Bug: oss-fuzz:17748 Change-Id: I074fa08475fffcb86c02e64dcb9c5c7c69bcda71 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37765 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>
2018-08-10Fix SSL_CTX_set1_sigalgs fuzzer and make them all more type-safe.David Benjamin1-43/+48
The size of an int is 4, not 2. To avoid worrying about this, add a GetVector counterpart to GetString that handles all this. Apply this uniformly to avoid all the pointer casts. This is less important for vector<uint8_t>, but even then we'll now notice a 1-byte OOB read since std::string is NUL-terminated. Also it's shorter. Change-Id: Ie96591cb8d8d52742f5fd30d70b6af0511109585 Reviewed-on: https://boringssl-review.googlesource.com/30864 Reviewed-by: Adam Langley <agl@google.com>
2018-08-10Fix SSL_CTX_set1_sigalgs_list fuzzer.David Benjamin1-1/+5
SSL_CTX_set1_sigalgs_list wants a NUL-terminated string, so we need to use GetString to give it one. Bug: oss-fuzz:9808 Change-Id: Id7f676aa514c36de9dea900763db3cbbf5c79a4c Reviewed-on: https://boringssl-review.googlesource.com/30804 Reviewed-by: Adam Langley <agl@google.com>
2018-08-09Support OpenSSL APIs SSL[_CTX]_set1_sigalgs[_list].Adam Langley1-0/+6
These functions can be used to configure the signature algorithms. One of them is a string mini-languaging parsing function, which we generally dislike because it defeats static analysis. However, some dependent projects (in this case TensorFlow) need it and we also dislike making people patch. Change-Id: I13f990c896a7f7332d78b1c351357d418ade8d11 Reviewed-on: https://boringssl-review.googlesource.com/30304 Reviewed-by: Steven Valdez <svaldez@google.com>
2018-07-05Add “bssl::” prefix to |UpRef| and |PushToStack| in fuzzer code.Adam Langley1-1/+1
Change-Id: Ie3ed310869f3068d5be8292448a27679fa91a7a7 Reviewed-on: https://boringssl-review.googlesource.com/29624 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2018-07-03Add bssl::UpRef.David Benjamin1-3/+1
bssl::UniquePtr and FOO_up_ref do not play well together. Add a helper to simplify this. This allows us to write things like: foo->cert = UpRef(bar->cert); instead of: if (bar->cert) { X509_up_ref(bar->cert.get()); } foo->cert.reset(bar->cert.get()); This also plays well with PushToStack. To append something to a stack while taking a reference, it's just: PushToStack(certs, UpRef(cert)) Change-Id: I99ae8de22b837588a2d8ffb58f86edc1d03ed46a Reviewed-on: https://boringssl-review.googlesource.com/29584 Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Adam Langley <agl@google.com>
2017-06-06Bound ssl_ctx_api more aggressively.David Benjamin1-1/+1
OpenSSL's d2i_X509 parser is amazingly slow. Only do about 10,000 of them, not 1,000,000. BUG=chromium:729419 Change-Id: I7034c3dde7d5c5681986af2ab5e516e54553d3c6 Reviewed-on: https://boringssl-review.googlesource.com/16905 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-06-05Bound expensive opcodes in ssl_ctx_api.David Benjamin1-223/+239
The fuzzers are timing out on inputs that spam SSL_CTX_add1_chain_cert and SSL_CTX_get0_chain_certs. In our current X509* caching implementation, this can be quadratic. As this is an API fuzzer, not an actual attack surface, this is not of much interest in itself, but bounding this will let the fuzzers fuzz faster. Change-Id: I3e27e938c413e5a0e8e6c7fad641f17c152dac39 Reviewed-on: https://boringssl-review.googlesource.com/16887 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-04-14Add SSL_CTX_set_verify_algorithm_prefs.David Benjamin1-2/+8
When writing tests and BoGo isn't available, it is useful to be able to configure the set of signature algorithms accepted on the verify side. Add an API for this. Change-Id: Ic873189da7f8853e412acd68614df9d9a872a0c8 Reviewed-on: https://boringssl-review.googlesource.com/15125 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2017-02-22Add new cipherlist-setting APIs that reject nonsense.Matthew Braithwaite1-3/+6
The new APIs are SSL_CTX_set_strict_cipher_list() and SSL_set_strict_cipher_list(). They have two motivations: First, typos in cipher lists can go undetected for a long time, and can have surprising consequences when silently ignored. Second, there is a tendency to use superstition in the construction of cipher lists, for example by "turning off" things that do not actually exist. This leads to the corrosive belief that DEFAULT and ALL ought not to be trusted. This belief is false. Change-Id: I42909b69186e0b4cf45457e5c0bc968f6bbf231a Reviewed-on: https://boringssl-review.googlesource.com/13925 Commit-Queue: Matt Braithwaite <mab@google.com> Reviewed-by: Matt Braithwaite <mab@google.com>
2016-12-16Remove version-specific cipher lists.David Benjamin1-10/+4
There are no longer any consumers of these APIs. These were useful back when the CBC vs. RC4 tradeoff varied by version and it was worth carefully tuning this cutoff. Nowadays RC4 is completely gone and there's no use in configuring these anymore. To avoid invalidating the existing ssl_ctx_api corpus and requiring it regenerated, I've left the entries in there. It's probably reasonable for new API fuzzers to reuse those slots. Change-Id: I02bf950e3828062341e4e45c8871a44597ae93d5 Reviewed-on: https://boringssl-review.googlesource.com/12880 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2016-10-26Fix SSL_CTX_set1_curves fuzzer.David Benjamin1-1/+1
SSL_CTX_set1_curves was being called with the size of the input data in bytes rather than in ints. BUG=chromium:659361 Change-Id: I90da1c6d60e92423c6b7d9efd744ae70ff589172 Reviewed-on: https://boringssl-review.googlesource.com/11840 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2016-10-18Include |SSL_CTX_set_signing_algorithm_prefs| in SSL_CTX fuzzer.Adam Langley1-0/+10
I missed this function, which was unfortunate. Change-Id: I8bcea1738a50aa3297d09a59a86437351ff5f84a Reviewed-on: https://boringssl-review.googlesource.com/11623 Commit-Queue: Adam Langley <alangley@gmail.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: David Benjamin <davidben@google.com>
2016-10-18Fix copy-paste error in SSL_CTX fuzzer.Adam Langley1-1/+1
Change-Id: I167d8ebfa7f2c08ba9f532df96ce5abd432c47c6 Reviewed-on: https://boringssl-review.googlesource.com/11622 Commit-Queue: Adam Langley <alangley@gmail.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: David Benjamin <davidben@google.com>
2016-10-13ERR_clear_error at the end of each fuzzer.David Benjamin1-0/+1
Data allocated in one fuzzer iteration and then freed in the next complicates the leak checker. Avoid this by dropping hidden global state at the end of each run. Change-Id: Ice79704f2754a6b1f40e288df9b97ddd5b3b97d5 Reviewed-on: https://boringssl-review.googlesource.com/11600 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
2016-10-12Fix fuzzer signatures.David Benjamin1-1/+1
They take a const pointer. See http://llvm.org/docs/LibFuzzer.html#building BUG=chromium:655016 Change-Id: Id6c7584c7a875e822b1fbff72163c888d02a9f44 Reviewed-on: https://boringssl-review.googlesource.com/11580 Reviewed-by: Steven Valdez <svaldez@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: Steven Valdez <svaldez@google.com> Commit-Queue: David Benjamin <davidben@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2016-10-07Adding mising <string> header.Mike Aizatsky1-0/+1
Fixing error: fuzz/ssl_ctx_api.cc:232:6: error: implicit instantiation of undefined template 'std::__1::basic_string.... BUG= Change-Id: I6d623dcca3e4edc52702d713fc948a0242bd4db8 Reviewed-on: https://boringssl-review.googlesource.com/11540 Reviewed-by: Adam Langley <agl@google.com>
2016-10-04Add a fuzzer for the SSL_CTX API.Adam Langley1-0/+473
This is not a complete fuzzer, even for SSL_CTX, but it's a start. Written in memory of c-ares[1]. [1] https://twitter.com/hanno/status/781506296906444800 Change-Id: I64b02c60f35b9057201df2cc325ebb7a84a0229d Reviewed-on: https://boringssl-review.googlesource.com/11423 Reviewed-by: Adam Langley <alangley@gmail.com> Commit-Queue: Adam Langley <alangley@gmail.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
generated by cgit v1.1 at 2024-07-17 02:56:12 +0000