Document the behaviour of non-standard separators in cipher strings. OpenSSL allows spaces, commas and semi-colons to be used as separators in cipher strings, in addition to the usual colons. This change documents that spaces cannot be used in equal-preference groups and forbids these alternative separators in strict mode. Change-Id: I3879e25aed54539c281511627e6a282e9463bdc3 Reviewed-on: https://boringssl-review.googlesource.com/18424 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
diff --git a/include/openssl/ssl.h b/include/openssl/ssl.h index 993046c..0196dd9 100644 --- a/include/openssl/ssl.h +++ b/include/openssl/ssl.h
@@ -1350,8 +1350,9 @@ * be used. * * Unknown rules are silently ignored by legacy APIs, and rejected by APIs with - * "strict" in the name, which should be preferred. Cipher lists can be long and - * it's easy to commit typos. + * "strict" in the name, which should be preferred. Cipher lists can be long + * and it's easy to commit typos. Strict functions will also reject the use of + * spaces, semi-colons and commas as alternative separators. * * The special |@STRENGTH| directive will sort all enabled ciphers by strength. * @@ -1369,7 +1370,7 @@ * [ECDHE-ECDSA-CHACHA20-POLY1305|ECDHE-ECDSA-AES128-GCM-SHA256] * * Once an equal-preference group is used, future directives must be - * opcode-less. + * opcode-less. Inside an equal-preference group, spaces are not allowed. * * TLS 1.3 ciphers do not participate in this mechanism and instead have a * built-in preference order. Functions to set cipher lists do not affect TLS