Chrome sync folks need to do this. Add a function for it. There doesn't
seem to be a standard way to do it, so pick something arbitrary.
Bug: chromium:1010968
Change-Id: Ib55456e4af5849cd9da33f397e8f12deb6f02917
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38144
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
This makes it possible to fetch the min and max versions configured
directly on SSL objects (as opposed to SSL_CTX ones).
This is useful when configuring supported TLS versions on per-connection
basis.
Change-Id: Ibccc92c5f7668e9a7be5a01d6f84089608382407
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/38104
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Chromium's renegotiation handling currently relies on reads being the only
thing that can discover a renegotiation. However, for a number of reasons, we
would like to eagerly drive the read loop after a handshake:
- 0-RTT + HTTP/1.1 will otherwise not pick up ServerHellos until after we send
a request. In particular, if we preconnect a 0-RTT socket sufficiently in
advance, such that the ServerHello comes in by the time we use it, we should
send 1-RTT data rather than 0-RTT.
- In TLS 1.2 False Start, if HTTP/1.1 or preconnect, we will not pick up the
server Finished and NewSessionTicket until later. This way we pick it up
sooner.
- If the server does not implement
https://boringssl-review.googlesource.com/c/boringssl/+/34948, this plugs the
theoretical deadlock on the client end. The False Start and 0-RTT scenarios
above also have theoretical deadlocks and cannot be mitigated on the server.
- TLS 1.3 client certificate alerts interact badly with TCP reset. Eagerly
reading from the socket makes it behave slightly better, though it's still
not reliable unless the server defers closing the socket.
So we can SSL_peek without triggering a renegotiation, add an
ssl_renegotiate_explicit mode to defer processing the renegotiation.
Bug: chromium:950706, chromium:958638
Change-Id: I78242d93d651b7a32a5c4c24ea9032ef63a027cf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37944
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
1458b49a9e switched to using HMAC-SHA256 for FIPS integrity checks on
Android. However, the flag file was named after a full 64-byte hex
digest. The additional 32 bytes weren't uninitialised, but are still
superfluous. This change gets rid of them.
Change-Id: I192af9eb2b94833cdea3620a153d4fd05c7265b9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37864
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The assembly dispatch tests currently assume NDEBUG is consistently
defined between C/C++ and assembly. While this is usually the case for
UNIX, CMake does not pass NDEBUG to NASM. This is giving gRPC some
difficulties in updating BoringSSL, so switch it to an opt-in
-DBORINGSSL_DISPATCH_TEST flag instead.
Update-Note: If you were copying NDEBUG over to assembly files, that's
no longer required (though it's harmless to leave it in). If you want to
run ImplDispatchTest.*, build both C/C++ and assembly with
-DBORINGSSL_DISPATCH_TEST in your debug builds. (Don't enable it in
release builds. It causes assembly to scribble in some globals.)
Change-Id: I9ab3371dc0f0a40b27b44ef93835e007a6346900
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37764
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Electron builds Node.js with BoringSSL. They want to match OpenSSL as
much as possible and thus have a patch[1] that adds AES-256 CFB mode.
However, that patch makes libcrypto depend on libdecrepit, which can't
be done in general. This change lands the AES-256 CFB support in
libdecrepit without the libcrypto bit and, in order for BoringSSL to
remain consistent, without advertising support in
EVP_CIPHER_do_all_sorted. This will let Electron reduce the size of
their patch a bit.
[1] https://github.com/electron/electron/blob/master/patches/boringssl/expose_aes-cfb.patch
Change-Id: If628d22a595b354623439c587542e414e43e4045
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37264
Reviewed-by: Adam Langley <agl@google.com>
This adapts our existing API for QUIC, although I'm not entirely
convinced the shape of it fits as it does with TCP. Things that needed
to be changed:
- There is a slight ordering issue on the server with HRR and releasing
the 0-RTT keys to QUIC.
- Remove EndOfEarlyData.
- At the early return point for the server, QUIC needs to have installed
the client traffic secrets earlier.
- The maximum early data value is a constant in QUIC.
- QUIC never installs early secrets at the TLS level. (In particular,
this avoids nuisances with do_send_second_client_hello's null cipher
not updating the encryption level.)
- The read/write secrets for 0-RTT keys were mixed up.
As the QUIC tests are getting a bit unwieldy, I tidied them up a bit.
This CL does *not* handle the QUIC transport parameters or HTTP/3
server SETTINGS frame interactions with 0-RTT. That will be done in a
separate CL.
I suspect if we ever implement DTLS 1.3, we'll find ourselves wanting to
align some of the QUIC bits here with DTLS and perhaps refine the
handshake/transport abstractions a bit.
Bug: 221
Change-Id: I61f701d7241dbc99e5dbf57ae6c283e10b85b049
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37145
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
FIPS IG 9.11 allows for a shared library to skip running self tests if
they have already run successfully for a given module and environment.
This change has Android FIPS builds read and write a flag file in
/dev/boringssl to implement this. The flag file is named after the hash
of the module to ensure specificity.
Change-Id: I5c4e7b6244831746e61c5f78f703b0b4fb0ddd10
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37204
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Unexpected SSL_ERROR_* values usually mean the caller didn't handle an
error case for some opt-in feature, but it still would be handy to
stringify them when logging.
Change-Id: If1c44a180b5c124a51ba61410ba02bd637f3429a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37188
Reviewed-by: Adam Langley <agl@google.com>
There's no sense in having two of these (with similar but slightly
different numbers, no less!). Fold them together and remove the
redundant SSL_want constants. Almost everything uses SSL_get_error.
Update-Note: Most of the SSL_want constants have been removed, except
SSL_NOTHING, SSL_READING, and SSL_WRITING which are used by external
code.
Change-Id: I75727f7cf6333694767ce8129ee6815fd464c163
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37187
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We perform all our negotiation based on the first ClientHello (for
consistency with what |select_certificate_cb| observed), which is in the
transcript, so we can ignore most of the second one.
However, we ought to check the second PSK binder. That covers the client
key share, which we do consume. In particular, we'll want to check if it
we ever send half-RTT data on these connections (we do not currently do
this). It is also a tricky computation, so we enforce the peer handled
it correctly.
Tested that both Chrome and Firefox continue to interop with this check,
when configuring uncommon curve preferences that trigger HRR. (Normally
neither browser sees HRRs against BoringSSL servers.)
Update-Note: This does enforce some client behavior that we hadn't been
enforcing previously. However, it only figures into TLS 1.3 (not many
implementations yet), and only clients which hit HelloRetryRequest
(rare), so this should be low risk.
Change-Id: I42126585ec0685d009542094192e674cbd22520d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37124
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
OpenSSL has two notions of key type because it supports multiple OIDs
for the same algorithm: NID_rsa vs NID_rsaEncryption and five distinct
spelling of DSA. We do not support these, so the base ID is simply the
ID.
Bug: 280
Change-Id: I966530901405a29a0cc35a2bea67304dda336e8a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36844
Reviewed-by: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
cryptography.io expects X25519 support to be exposed via EVP_PKEY. Also we're
considering using EVP_PKEY to pass in keys for ESNI. This unfortunately
requires adding some odd EVP_PKEY_set1_tls_encodedpoint and
EVP_PKEY_get1_tls_encodedpoint APIs which cryptography.io uses for X25519
because the EVP_PKEY "raw" functions did not exist at the time.
To test, implement EVP_PKEY_derive support in evp_tests.txt.
Change-Id: Ie0666bb9aba13eecf203156dc047ac49ef6d0093
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36788
Reviewed-by: Adam Langley <agl@google.com>
This avoids early callback users writing their own SNI parser and gives us a
place to surface the server name from ESNI in the future.
Update-Note: This isn't a breaking change, but users of
SSL_CTX_set_select_certificate_cb can likely drop a bit of code after this CL.
Bug: 275
Change-Id: I9685ae5cca8e0483de76229d12dac45ff8e9ec32
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36784
Reviewed-by: Steven Valdez <svaldez@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
There are two naming conventions for TLS cipher suites, the standard
IETF names (SSL_CIPHER_standard_name) and the ad-hoc OpenSSL names
(SSL_CIPHER_get_name). When we added TLS 1.3, we had to come up with
OpenSSL-style names for the cipher suites.
OpenSSL-style names use hyphens rather than underscores (and omit
underscores in odd places), so the natural name for
TLS_AES_128_GCM_SHA256 would have been "AES128-GCM-SHA256". However,
that name is already taken by TLS_RSA_WITH_AES_128_GCM_SHA256 because
OpenSSL's naming convention treats the legacy RSA key exchange as
default. Instead, we used an "AEAD-" prefix to indicate the ciphers only
specified the AEAD.
Since then, OpenSSL has implemented TLS 1.3. Instead, they simply made
the OpenSSL-style name match the standard name starting TLS 1.3,
underscores and all. (This is why openssl s_client will return very
different-looking cipher names in TLS 1.2 and TLS 1.3.)
Align with OpenSSL and do the same.
Update-Note: SSL_CIPHER_get_name will return different values for TLS
1.3 ciphers than before. Note that we did not allow TLS 1.3 ciphers to
be configured at all, so no cipher suite configurations will need to
change, but code logging or asserting on the result of a TLS connection
may observe differences.
It is also recommended that consumers replace uses of
SSL_CIPHER_get_name with SSL_CIPHER_standard_name which gives a much
more consistent naming convention. (BoringSSL supports both standard and
OpenSSL names in the cipher suite configuration, so there's no need to
use OpenSSL names at all.)
Change-Id: I40b1de0689dd7b32af88602acc063934f2877999
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36764
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
When testing HRSS-SXY and SIKE, we also want a control group. However,
how are clients to indicate that they're part of the 1/3 of the
experiment population that's not advertising CECPQ? And how are servers
to indicate that they would have negotiated CECPQ2 / 2b if only the
client had asked?
This change adds a temporary signaling extension to solve these issues.
Change-Id: Ic087a09149ef10141568b734396981ae97950a9b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36725
Reviewed-by: David Benjamin <davidben@google.com>
The added code is a one-shot function. A handful of instructions could
be saved by having a context object for repeated use of the same key,
but perhaps it's not needed.
Selected the 2-4 variant to implement because it seems to be
overwhelmingly the most commonly used.
Change-Id: I1e4f699f7dd5a2d35e12245fa116bafbd3439979
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36664
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
KWP is Key Wrap with Padding, defined in RFC 5649 and SP 800-38F. Like
Key Wrap, it's a poor-man's AEAD and shouldn't be used. However, some
existing systems use it and we need to interoperate.
The interface of the added functions is a little unfortunate, but they
match the interfaces of the existing Key Wrap functions which, in turn,
match functions in OpenSSL. Hopefully this way, if OpenSSL ever add
support, we'll line up.
Change-Id: I3496c288f32230a891261586ca2e9c4ee8456c09
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36324
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This change adds a FIPS integrity check using shared libraries. Unlike
with the static case, a shared build can take advantage of the linker
resolving relocations and thus doesn't need delocation. It does mean
that both .text and .rodata sections need to be handled, however, so the
hashing format is slightly different. inject-hash.go is updated to be
able to rewrite shared libraries to inject the correct hash value.
Change-Id: I9a71910cd6df3a85e4efac896b0913e65b5f875b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36024
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Implements support for hybrid key exchange based on SIKEp503, a post
quantum, isogeny based KEM. This is a hybrid construction mixed with
X25519 key agreement. Code point is 0xFE32. Cloudflare's SIDH
implementation is used for testing. Key exchange can be used with TLS1.3
only.
Change-Id: I3a5f38d6f7d016274e5bcfb629249664e1d983eb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35264
Reviewed-by: Adam Langley <alangley@gmail.com>
This stores early data tickets regardless of whether early data is enabled in
the initial handshake, and provides an API to query whether early data would be
performed to allow for comparison between early data enabled and disabled
resumptions.
Change-Id: Id3ef62e36b5be48f6a39fcd7c67d332b7d495141
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35964
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
OpenSSL uses the private key to find the leaf certificate. cryptography.io's
tests rely on this.
Update-Note: PKCS12_parse's behavior changes slightly. Affected callers are
recommended to switch to PKCS12_get_key_and_certs, which has much more
predictable behavior and has no pressures from 3rd-party software to match
OpenSSL's quirks.
Change-Id: I4ee2befbd56a0882ee166f00e748f2fe58ac6a86
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/36125
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
For now just hard-code a tolerance of 1 minute.
SSL_get_early_data_reason and SSL_get_ticket_age_skew will allow us to
tune this.
Bug: 113
Change-Id: I85a530494d5405a3e11198d49bfa9cfd355f4f35
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35886
Reviewed-by: Adam Langley <agl@google.com>
This is to help servers diagnose 0-RTT rejects. (QUIC has a similar
feature, and this will help determine if we need to adjust the ticket
age skew.)
Bug: 113
Change-Id: Icc7e5df326b5fa82e744605021b1205298efba6a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35885
Reviewed-by: Adam Langley <agl@google.com>
cryptography.io expects this API for Ed25519. Replace the now redundant
EVP_PKEY_new_ed25519_* functions. Ours were more static-linker-friendly,
but we weren't taking advantage of it and EVP_PKEY needs an overhaul to
be static-linker-friendly anyway.
Update-Note: EVP_PKEY_new_ed25519_public and
EVP_PKEY_new_ed25519_private are removed in favor of
EVP_PKEY_new_raw_{public,private}_key. I do not believe anyone was using
those functions.
Change-Id: Ibd12b4e9e37cd8dd4dbc7ebc4346ba52655d523a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35806
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Including ssl.h is quite a chunk of code and #defines, so we've tried to
limit its spread internally in the interests of code hygine given that
we have a multi-billion-line repo.
However, header files that mention enums from ssl.h currently need to
include ssl.h. For example, your class may have static class member
functions intended to be callbacks, and they need to be class members
because they'll call other private methods.
C cannot predeclare enums, but C++ can if you explicitly type them.
Sadly C doesn't support explicit types. So option one is to move the
enums into base.h. That works, but the enums properly live in ssl.h and
reading the header file is a lot clearer if you don't have to jump
around to see all the pieces.
So option two (this change) is to explicitly type and predelcare the
enums in base.h for C++ only. The worry now is that C and C++ might
disagree about the type of the enums. However, this has already
happened: at least for |ssl_private_key_result_t|, g++ thinks that it's
an |int| (without any explicit type) and gcc thinks that it's an
|unsigned|. At least they're the same length, I guess?
So, to make sure that this doesn't slip any more, this change also adds
|ssl_test_c.c| which tests that C views the enums as having the same
size as an |int|, at least.
Change-Id: I8248583ec997021f8226d5a798609f6afc96dac4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35664
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The common name fallback does not interact well with name constraints.
Until we remove this fallback, we must resolve this conflict.
Blindly applying name constraints to the common name will reject
"decorative" common names that aren't intended to be hostnames (e.g.
[0]). We need to guess based on format whether the common name is a DNS
name. It is important this same check is applied to *both* name
constraints and name matching, which means the OpenSSL version (see
5bd5dcd49605ca2aa7931599894302a3ac4b0b04,
d02d80b2e80adfdde49f76cf7c7af4e013f45005, and
55a6250f1e7336e8a7d89fb609eb23398715ff6f) is unsuitable as a
compatibility data point.
In theory we could limit this to chains with name constraints, which are
uncommon, but X509_check_host sees only the leaf. We must apply it
uniformly. That means a strict check risks problems with malformed
non-WebPKI setups like [1].
For a first pass, mirror Go's behavior. Like Go, rather than run
SAN-less DNS-like common names through name constraints, we simply
reject all such certificates. Name constraints now exclude all leaf
certificates that can trigger the common name fallback. They are rare
enough that we can hopefully hold them to a higher standard.
Note this does not make misclassified decorative common names any worse,
compared to the checking the name constraint. Such names would not have
matched the constraint anyway.
Update-Note: This can may cause two kinds of errors:
1. Leaf certificates whose chain contains a name constraint and lack
SANs may be rejected with X509_V_ERR_NAME_CONSTRAINTS_WITHOUT_SANS.
2. Leaf certificates which use the common name fallback and verify
against an insufficiently DNS-looking hostname may fail with
X509_V_ERR_HOSTNAME_MISMATCH.
In both cases, the fix is to include the subjectAltName in the
certificate, rather than rely on the common name fallback. (Refining the
heuristic is also an option, but the two failure modes pull it in
opposite directions, so this is tricky.)
[0] https://github.com/golang/go/issues/24151
[1] https://github.com/GoogleCloudPlatform/cloudsql-proxy/issues/194
Change-Id: If25557de428768292a14ba3bdeeffbd74e3a3bf8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35665
Reviewed-by: Adam Langley <agl@google.com>
This flag is backwards. We want to check the common name less, not more. See if
anything was actually relying on this.
Update-Note: X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT is now ignored.
Change-Id: I8288d57540f8117059e58d72cc173aa4d3077fb6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35646
Reviewed-by: Adam Langley <agl@google.com>
cryptography.io uses this and it's also the correct behavior. Ideally it would
be default, but start with just adding the flag. See also
dd60efea955e41a6f0926f93ec1503c6f83c4e58 from upstream.
Change-Id: I9e13cdbfd44c904ba5bd69a5a66c68c4b7596867
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35645
Reviewed-by: Adam Langley <agl@google.com>
This will allow edge servers to pass judgement on the ClientHello before
completing the handoff process. This also means that edge servers will
now enforce ClientHello well-formedness — previously that check didn't
occur until the handshaker tried to parse the handoff submission.
Change-Id: I9804ac0224632b4b4381c1a81f434d188e0b9376
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35584
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
AES_set_*_key used to call directly into aes_nohw_set_*_key which
gracefully handles some NULL parameters and invalid bit sizes. However,
we now enable optimized assembly implementations, not all of which
perform these checks. (vpaes does not.)
This is fine for the internal assembly functions themselves. Such checks
are better written in C than assembly, and the calling C code usually
already knows the key size. (Indeed aes_ctr_set_key already assumes the
assembly functions are infallible.) AES_set_*_key are public APIs,
however. The NULL check is silly, but we should handle length-like
checks in public APIs.
Change-Id: I259ae6b9811ceaa9dc5bd7173d5754ca7079cff8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35564
Reviewed-by: Adam Langley <agl@google.com>
Child and root CBBs share a type, but are different kinds of things. C++
programmers sometimes mistakenly believe they should use ScopedCBB for
everything. This mostly works because we NULL cbb->child->base on flush,
making CBB_cleanup a no-op. This zeroing also skips the assert in
CBB_cleanup. (If we ran it unconditionally, CBB_zero + CBB_cleanup would
not work.)
However, if a CBB operation fails and a function returns early, the
child CBB is not cleared. ScopedCBB will then call CBB_cleanup which
trips the assert but, in release build, misbehaves.
Run the assert unconditionally and, when the assert fails, still behave
well. To make this work with CBB_zero, negate is_top_level to is_child,
so a flushed child CBB and a (presumably) root CBB in the zero state are
distinguishable.
Update-Note: Code that was using CBB wrong may trip an assert in debug builds.
Change-Id: Ifea7759e1d0331f2e727c59bbafa355d70fb9dba
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35524
Reviewed-by: Adam Langley <agl@google.com>
We usually name output parameters 'out'. (Someone made a C++ templating
change in Chromium which messed up const-ness, saw the compile error,
and thought it was in MD5_Final.) Also tag the parameters with the
sizes.
Sadly, there's a bit of goofiness around SHA224_Final/SHA256_Final and
SHA384_Final/SHA512_Final, but they're just documentation anyway.
(Though it does touch on the mess that is sha->md_len which would be
nice to clear through somehow.)
Change-Id: I1918b7eecfe13f13b217d01d4414ac2358802354
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35484
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
When building node with boringssl, `SSL_CTX_get_min_proto_version` and
`SSL_CTX_get_max_proto_version` are used. Openssl exposes those; this
change adds support for boringssl.
For this to work right in DTLS, we switch conf_{min,max}_version to store wire
versions, rather than our internal normalized versions.
Change-Id: I282ed224806c41f69e6f166ca97c6cc05ff51f17
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35404
Reviewed-by: Nitish Sakhawalkar <nitsakh@gmail.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
David Benjamin