I'm leaving libc++abi unupdated for now, because it depends on a newer
libc++ than Chromium has managed to update to just yet. (It looks like
Chromium is, for now, manually passing -D_LIBCPP_CONSTINIT=constinit.)
Probably easier to pick that up when the dust settles.
(When that happens, libc++abi will need to be built as C++20, but that's
fine because this is only used on bots.)
Change-Id: I2b7ae62b618b0e09863b4b38548be1b937fbe0d0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52646
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I'm collecting these changes, made by `go fmt` into their own change so
that they don't add noise to a meaningful change in the future.
Change-Id: I0ca931816fdba60ecde43e3eaffd0339d1773e73
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52429
Reviewed-by: Bob Beck <bbe@google.com>
The module supports these operations, they should probably be tested
with ACVP.
Change-Id: I09a52281f0c6877862139b73a876c995aa9af92a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52428
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
PSS verification with RSA 1024 is still acceptable. This change adds it
to our regcap. SHA-512 is omitted because that doesn't fit in 1024 bits
with PSS encoding. (Unless you shrink the salt, but we don't want to
deal with odd PSS configurations like that.)
Change-Id: I05d4778d45c25c87e2e50cd095380ecd4f12c75c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52427
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
3DES is no longer acceptable for FIPS validation.
Change-Id: Id4f80f6201220eff28cb3597540a3b796bfcf54f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52426
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
I broke the delocate tests with 27ffcc6e19 because that change
switched the integrity check hash function in the tested configuration
to SHA-256, but didn't update the expectation files.
Change-Id: I05f61eda795c833847981c5b21287fd0d2b33064
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52405
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Now that we've dropped MSVC 2015, I believe we can rely on C++14 (which
is now seven years old). This switches the build to require C++14. I've
gone ahead and switched code in both public headers and within the
library, but if the public headers are a problem, we can revert those
separately.
C++14 doesn't get us quite as much as C++17, but see if we can get to
C++14 first. Still, std::enable_if_t and the less restricted constexpr
are nice wins.
Update-Note: C++14 is now required to build BoringSSL. If the build
breaks, make sure your compiler is C++14-capable and is not passing
-std=c++11. If this is causing problems for your project, let us know.
Change-Id: If03a88e3f8a11980180781f95b806e7f3c3cb6c3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52246
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This creates an install directory under the top level source directory.
The install contains a CMake config file that produces variables and
targets compatible with FindOpenSSL, or the directory can be scanned by
FindOpenSSL via -DOPEN_SSL_ROOT. This allows using BoringSSL with
third-party dependencies that find an SSL implementation via CMake.
Change-Id: Iffeac64b9cced027d549486c98a6cd9721415454
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52205
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The ARMv8 assembly code in this commit is mostly taken from OpenSSL's `ecp_nistz256-armv8.pl` at 19e277dd19/crypto/ec/asm/ecp_nistz256-armv8.pl (see Note 1), adapting it to the implementation in p256-x86_64.c.
Most of the assembly functions found in `crypto/fipsmodule/ec/asm/p256-x86_64-asm.pl` required to support that code have their analogous functions in the imported OpenSSL ARMv8 Perl assembly implementation with the exception of the functions:
- ecp_nistz256_select_w5
- ecp_nistz256_select_w7
An implementation for these functions was added.
Summary of modifications to the imported code:
* Renamed to `p256-armv8-asm.pl`
* Modified the location of `arm-xlate.pl` and `arm_arch.h`
* Replaced the `scatter-gather subroutines` with `select subroutines`. The `select subroutines` are implemented for ARMv8 similarly to their x86_64 counterparts, `ecp_nistz256_select_w5` and `ecp_nistz256_select_w7`.
* `ecp_nistz256_add` is removed because it was conflicting during the static build with the function of the same name in p256-nistz.c. The latter calls another assembly function, `ecp_nistz256_point_add`.
* `__ecp_nistz256_add` renamed to `__ecp_nistz256_add_to` to avoid the conflict with the function `ecp_nistz256_add` during the static build.
* l. 924 `add sp,sp,#256` the calculation of the constant, 32*(12-4), is not left for the assembler to perform.
Other modifications:
* `beeu_mod_inverse_vartime()` was implemented for AArch64 in `p256_beeu-armv8-asm.pl` similarly to its implementation in `p256_beeu-x86_64-asm.pl`.
* The files containing `p256-x86_64` in their name were renamed to, `p256-nistz` since the functions and tests defined in them are hereby running on ARMv8 as well, if enabled.
* Updated `delocate.go` and `delocate.peg` to handle the offset calculation in the assembly instructions.
* Regenerated `delocate.peg.go`.
Notes:
1- The last commit in the history of the file is in master only, the previous commits are in OpenSSL 3.0.1
2- This change focuses on AArch64 (64-bit architecture of ARMv8). It does not support ARMv4 or ARMv7.
Testing the performance on Armv8 platform using -DCMAKE_BUILD_TYPE=Release:
Before:
```
Did 2596 ECDH P-256 operations in 1093956us (2373.0 ops/sec)
Did 6996 ECDSA P-256 signing operations in 1044630us (6697.1 ops/sec)
Did 2970 ECDSA P-256 verify operations in 1084848us (2737.7 ops/sec)
```
After:
```
Did 6699 ECDH P-256 operations in 1091684us (6136.4 ops/sec)
Did 20000 ECDSA P-256 signing operations in 1012944us (19744.4 ops/sec)
Did 7051 ECDSA P-256 verify operations in 1060000us (6651.9 ops/sec)
```
Change-Id: I9fdef12db365967a9264b5b32c07967b55ea48bd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51805
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
There are paperwork reasons why it's useful to use the same hash
function in all cases. Thus unify on SHA-256 because contexts where
SHA-512 is faster, are faster overall and thus less sensitive.
Change-Id: I7a782a3adba4ace3257313a24dc8bc213b9d64ec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52165
Reviewed-by: David Benjamin <davidben@google.com>
VS 2017 was released in March 2017, five years ago now. This means VS
2015 is now past our support window.
This will make the unmarked and "vs2017" configs in CI/CQ do the same
thing. I'll follow up with a separate CL in infra/config to switch the
test VS 2019 instead.
Update-Note: BoringSSL may no longer build with VS 2015. Consumers
should upgrade to the latest Visual Studio release. VS 2017 or later is
required.
Change-Id: I477759deb95a27efe132de76d9ed103826110df0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52085
Reviewed-by: Bob Beck <bbe@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We need a function that returns a version that links to a certificate.
Previously we have used the git hash as the version of our modules but
the source cannot contain its own hash. Thus this change defines a new
format for FIPS module versions which will be filled in once we're ready
to define a version.
Change-Id: Ie4641945119106bc47e8da94ed8a45a86abb6f92
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51986
Reviewed-by: David Benjamin <davidben@google.com>
VS2015 has finally dropped off our support window. As part of dropping
it from the bots, I'm thinking of using the current vs2017 builders to
test vs2019. In preparation for that, add a vs2019 hash to
vs_toolchain.py.
Change-Id: I4c3dde2825f57c39a8da0e155e96d08550d39893
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52005
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Also don't linkify pipe words in the table of contents. Those are
already inside a link.
Change-Id: Ib984e914bcfe7a8e0216a0553b92100fd034bf36
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51605
Reviewed-by: Adam Langley <agl@google.com>
Clang 13 will put a “-1” inside a DWARF expression that's the difference
between two labels. We just need to pass it onto the output.
Change-Id: Ib58d245157a44ae9f1839c2af123bfe01791abf1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51445
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
All FIPS testing is done with ACVP now. We can delete all the CAVP
stuff.
Change-Id: I459873474e40b0371f9cf760090a130ef9a90a8c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51330
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
FIPS validation requires showing that the continuous and start-up tests
are effective by breaking them. Traditionally BoringSSL used #defines
that tweaked the expected values. However, 140-3 now requires that the
inputs be changed, not the expected outputs.
Also, the number of tests is going to increase. Since slower platforms
already took too long to compile BoringSSL n times (once for each test
to break) we want something faster too.
Therefore all the known-answer tests (KATs) are changed such that a Go
program can find and replace the input value in order to break them.
Thus we only need to recompile once to disable the integrity test.
The runtime tests still need a #define to break, but that #define is now
put in a header file so that only the module need be recompiled, not
everything as in the previous system.
Change-Id: Ib621198e6ad02253e29af0ccd978e3c3830ad54c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51329
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
AS10.20 requires that the self-test for the integrity algorithm pass
before the integrity check itself. IG 10.3.A requires an HMAC self-test
now. Therefore run these tests before the integrity check.
Since we also need the ability to run all self-tests, both SHA
self-tests and the HMAC test are run again when running self-tests.
I'm assuming that they're so fast that it doesn't matter.
Change-Id: I6b23b6fd3cb6107edd7420bc8680780719bd41d2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51328
Reviewed-by: David Benjamin <davidben@google.com>
ACVP authorisation tokens expire and, once expired, need to be renewed
by sending a new TOTP code. We almost never hit this but some FIPS
modules are slow enough that they can't compute the response within the
token lifetime.
But the ACVP code was putting an Authorization header on the renewal
message because it put that header on every message. But doing so breaks
the renewal because the server rejects the request because the token has
expired before noticing that it's a renewal request.
Also, put a 10 second buffer on deciding if a token has expired to
account for the transmission delay.
Change-Id: I50643a223cdb313d07dd7b2c559ad160cbe608ff
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51385
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Now that the naming for Apple platforms is aligned, we can select the
variable uniformly.
Change-Id: Id547d1a4ba0585d5f9e4ea0b5d8b255b2ab2ec38
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51345
Reviewed-by: Adam Langley <agl@google.com>
The current names are confusing because (ios, aarch64) is also used on
macOS. The various Apple platforms all use the same ABI, and aarch64 is
no longer limited to iOS. (For that matter, the iOS simulator on x86
Macs is x86 iOS.) Just call it 'apple'.
Update-Note: References to 'mac' or 'ios' source lists in downstream
builds should be renamed to 'apple'.
Change-Id: Id1a0627f8ce3241f34ffa6bb245ee5783adc7c15
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51307
Reviewed-by: Adam Langley <agl@google.com>
https://boringssl-review.googlesource.com/c/boringssl/+/51265 broke
Linux and macOS platforms on architectures where we don't build
assembly. OPENSSL_NO_ASM needs to match the assembly selector.
While I'm here, remove the OPENSSL_C11_ATOMIC comment. We autodetect
atomics these days, so the flag is only useful if you want to force it.
Change-Id: I1f20f7577b5ca7e208dc90fb46a93b20da864ec5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51305
Reviewed-by: Piotr Sikora <piotrsikora@google.com>
Reviewed-by: Adam Langley <agl@google.com>
These symbols were not marked OPENSSL_EXPORT, so they weren't really
usable externally anyway. They're also very sensitive to various build
configuration toggles, which don't always get reflected into projects
that include our headers. Move them to crypto/internal.h.
Change-Id: I79a1fcf0b24e398d75a9cc6473bae28ec85cb835
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50846
Reviewed-by: Adam Langley <agl@google.com>
This imports the changes to sha512-armv8.pl from
upstream's af0fcf7b4668218b24d9250b95e0b96939ccb4d1.
Tweaks needed:
- Add an explicit .text because we put .LK$BITS in .rodata for XOM
- .LK$bits and code are in separate sections, so use adrp/add instead of
plain adr
- Where glibc needs feature flags to *enable* pthread_rwlock, Apple
interprets _XOPEN_SOURCE as a request to *disable* Apple extensions.
Tighten the condition on the _XOPEN_SOURCE check.
Added support for macOS and Linux, tested manually on an ARM Mac and a
VM, respectively. Fuchsia and Windows do not currently have APIs to
expose this bit, so I've left in TODOs. Benchmarks from an Apple M1 Max:
Before:
Did 4647000 SHA-512 (16 bytes) operations in 1000103us (74.3 MB/sec)
Did 1614000 SHA-512 (256 bytes) operations in 1000379us (413.0 MB/sec)
Did 439000 SHA-512 (1350 bytes) operations in 1001694us (591.6 MB/sec)
Did 76000 SHA-512 (8192 bytes) operations in 1011821us (615.3 MB/sec)
Did 39000 SHA-512 (16384 bytes) operations in 1024311us (623.8 MB/sec)
After:
Did 10369000 SHA-512 (16 bytes) operations in 1000088us (165.9 MB/sec) [+123.1%]
Did 3650000 SHA-512 (256 bytes) operations in 1000079us (934.3 MB/sec) [+126.2%]
Did 1029000 SHA-512 (1350 bytes) operations in 1000521us (1388.4 MB/sec) [+134.7%]
Did 175000 SHA-512 (8192 bytes) operations in 1001874us (1430.9 MB/sec) [+132.5%]
Did 89000 SHA-512 (16384 bytes) operations in 1010314us (1443.3 MB/sec) [+131.4%]
(This doesn't seem to change the overall SHA-256 vs SHA-512 performance
question on ARM, when hashing perf matters. SHA-256 on the same chip
gets up to 2454.6 MB/s.)
In terms of build coverage, for now, we'll have build coverage
everywhere and test coverage on Chromium, which runs this code on macOS
CI. We should request a macOS ARM64 bot for our standalone CI. Longer
term, we need a QEMU-based builder to test various features. QEMU seems
to have pretty good coverage of all this, which will at least give us
Linux.
I haven't added an OPENSSL_STATIC_ARMCAP_SHA512 for now. Instead, we
just look at the standard __ARM_FEATURE_SHA512 define. Strangely, the
corresponding -march tag is not sha512. Neither GCC and nor Clang have
-march=armv8-a+sha512. Instead, -march=armv8-a+sha3 implies both
__ARM_FEATURE_SHA3 and __ARM_FEATURE_SHA512! Yet everything else seems
to describe the SHA512 extension as separate from SHA3.
https://developer.arm.com/architectures/system-architectures/software-standards/acle
Update-Note: Consumers with a different build setup may need to
limit -D_XOPEN_SOURCE=700 to Linux or non-Apple platforms. Otherwise,
<sys/types.h> won't define some typedef needed by <sys/sysctl.h>. If you
see a build error about u_char, etc., being undefined in some system
header, that is probably the cause.
Change-Id: Ia213d3796b84c71b7966bb68e0aec92e5d7d26f0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50807
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Testing the Python 3 recipe migration.
Change-Id: I428f08eaf426cf0bbd4b53f9f6932df7d15ad2ee
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50326
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We haven't done this in a while. This also tests more codepaths in
in the previous Python 3 update.
libc++ required a few more build tweaks. Also the CMake update was
necessary to update the NDK. Older CMake cannot detect CMAKE_LINKER
in the newer NDK.
Change-Id: I59ab1c6b074b805dd4b8a6ab596c4cf469d5bfa9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50167
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
In doing so, I think this fixes a bug on Windows where extract.py was
digesting the archive in text mode. (Doesn't particularly matter, though
by using the correct digest, we will end up re-extracting the files
once.)
Change-Id: Ia7effe5f9c228c1a702cba8e6380975b59261808
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50166
Reviewed-by: Adam Langley <agl@google.com>
One down, two more to go! As part of this, I've added it to doc.config,
revised the note at the top, and moved the sample i2d/d2i functions
here.
Bug: 426
Change-Id: I7bb9d56bf9ba58c921cfcf9626bf3647c6e5c7df
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50107
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Trusty's TLOGE macro nowadays expects TLOG_TAG to be defined
as the log tag to use.
Change-Id: I18121287ba51698d354323027d5382c8406f0b99
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49685
Commit-Queue: Pete Bentley <prb@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CS3 is ciphertext-stealing variant three from SP 800-38A.
Change-Id: I992dc22778c91efad361f25ff65ae5966fc447c6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49505
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CMake's language is rather fragile and unsound. For the most part, it is
a shell script with more parentheses. That is, it simply expands command
arguments into a list of strings and then evaluates it, complete with
shell-style differences between "${FOO}" and ${FOO}.
The if() command is special and internally also expands variables. That
is why things like if(FOO STREQUAL "BAR") work. CMake interprets "FOO"
as a variable if it can find a variable, or a string otherwise. In
addition to getting very confused on typos, it means that
if("${FOO}" STREQUAL "BAR") will double-expand, and it will do strange
things if BAR is a variable.
CMP0054 patches this (which we set by minimum version) so that if() only
expands if the token was unquoted. This fixes
if("${FOO}" STREQUAL "BAR"). However, if(${FOO} STREQUAL "BAR")
continues to double-expand FOO.
We had a mix of all three of FOO, ${FOO}, and "${FOO}". It's not clear
which is the canonical spelling at this point, but CMake own files
(mostly) use FOO, as do most of our lines, so I've standardized on that.
It's a little unsatisfying if we typo a variable, but I suppose ${FOO}
also silently ignores unset variables.
Bug: 423
Change-Id: Ib6baa27f4065eed159e8fb28820b71a0c99e0db0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48705
Reviewed-by: Adam Langley <agl@google.com>
Some JSON files have a header, but without a URL. Thus consider a block
that doesn't contain an algorithm to also be a header.
Change-Id: Ic35a827843e9d0169ba8398df69c46a5baeffb44
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48605
Reviewed-by: David Benjamin <davidben@google.com>
This is a reland of 160a8891ae with go.mod
and go.sum fixed. This updates golang.org/x/crypto, adds the latest
golang.org/x/net as a direct dependency (it was previously an indirect
dependency via x/crypto), and cleans up stale entries from go.sum with
go mod tidy.
Original change's description:
> Add util/fetch_ech_config_list.go
>
> I wrote this tool to make it easier to test the ECH client against
> real-world servers with the bssl client tool. I found that manually
> extracting an ECHConfigList from a raw HTTPS record is unnecessarily
> painful.
>
> The tool queries DNS over UDP for HTTPS records. If it finds any HTTPS
> records in the response, it attempts to extract an ECHConfigList from
> the "ech" SvcParam. It can write each extracted ECHConfigList to a file
> in a given directory. Once the ECH client implementation lands, the bssl
> client tool should have a new flag that that takes the path to an
> ECHConfigList file.
>
> I am using golang.org/x/net/dns/dnsmessage to parse the DNS response. I
> recently added the |UnknownResource| type to this library to enable
> callers (like us) to extract the bytes of otherwise-unsupported records
> (like HTTPS). I updated the dependency with `go get -u golang.org/x/net`.
>
> Although the bssl client tool knows how to resolve the address of its
> "-connect" parameter, it is difficult to query HTTPS records in a
> platform-agnostic way. If we decide the bssl client should directly
> query HTTPS rather than leaning on fetch_ech_config_list.go, we should
> look into libresolv. Specifically, the |res_query| function enables the
> caller to query arbitrary record types. This may open its own can of
> cross-platform worms; macOS and Linux typically ship with different
> implementations and it is not available on Windows. For more info, see
> `man 3 resolver`.
>
> Bug: 275
> Change-Id: I705591658921f60a958164a18b68ffb697c2ea4b
> Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44104
> Reviewed-by: David Benjamin <davidben@google.com>
Bug: 275
Change-Id: I9571e96c7a2ad7e239d86a353929a4e556d71287
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48106
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This reverts commit 160a8891ae.
Reason for revert: This broke go.sum on CI for some reason. Will fix
and reland.
Original change's description:
> Add util/fetch_ech_config_list.go
>
> I wrote this tool to make it easier to test the ECH client against
> real-world servers with the bssl client tool. I found that manually
> extracting an ECHConfigList from a raw HTTPS record is unnecessarily
> painful.
>
> The tool queries DNS over UDP for HTTPS records. If it finds any HTTPS
> records in the response, it attempts to extract an ECHConfigList from
> the "ech" SvcParam. It can write each extracted ECHConfigList to a file
> in a given directory. Once the ECH client implementation lands, the bssl
> client tool should have a new flag that that takes the path to an
> ECHConfigList file.
>
> I am using golang.org/x/net/dns/dnsmessage to parse the DNS response. I
> recently added the |UnknownResource| type to this library to enable
> callers (like us) to extract the bytes of otherwise-unsupported records
> (like HTTPS). I updated the dependency with `go get -u golang.org/x/net`.
>
> Although the bssl client tool knows how to resolve the address of its
> "-connect" parameter, it is difficult to query HTTPS records in a
> platform-agnostic way. If we decide the bssl client should directly
> query HTTPS rather than leaning on fetch_ech_config_list.go, we should
> look into libresolv. Specifically, the |res_query| function enables the
> caller to query arbitrary record types. This may open its own can of
> cross-platform worms; macOS and Linux typically ship with different
> implementations and it is not available on Windows. For more info, see
> `man 3 resolver`.
>
> Bug: 275
> Change-Id: I705591658921f60a958164a18b68ffb697c2ea4b
> Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44104
> Reviewed-by: David Benjamin <davidben@google.com>
TBR=davidben@google.com,dmcardle@google.com
Change-Id: Iec36265dfa3b7c59eb811ed708219bfebb07a710
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 275
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48105
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I wrote this tool to make it easier to test the ECH client against
real-world servers with the bssl client tool. I found that manually
extracting an ECHConfigList from a raw HTTPS record is unnecessarily
painful.
The tool queries DNS over UDP for HTTPS records. If it finds any HTTPS
records in the response, it attempts to extract an ECHConfigList from
the "ech" SvcParam. It can write each extracted ECHConfigList to a file
in a given directory. Once the ECH client implementation lands, the bssl
client tool should have a new flag that that takes the path to an
ECHConfigList file.
I am using golang.org/x/net/dns/dnsmessage to parse the DNS response. I
recently added the |UnknownResource| type to this library to enable
callers (like us) to extract the bytes of otherwise-unsupported records
(like HTTPS). I updated the dependency with `go get -u golang.org/x/net`.
Although the bssl client tool knows how to resolve the address of its
"-connect" parameter, it is difficult to query HTTPS records in a
platform-agnostic way. If we decide the bssl client should directly
query HTTPS rather than leaning on fetch_ech_config_list.go, we should
look into libresolv. Specifically, the |res_query| function enables the
caller to query arbitrary record types. This may open its own can of
cross-platform worms; macOS and Linux typically ship with different
implementations and it is not available on Windows. For more info, see
`man 3 resolver`.
Bug: 275
Change-Id: I705591658921f60a958164a18b68ffb697c2ea4b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44104
Reviewed-by: David Benjamin <davidben@google.com>
NIST breaks these URLs so often it's unclear if it's worth including
them. If they do it again it might be a signal to remove them all.
However, until then, this change updates many of them. Some were deleted
because the format of the anchors has been switched and all the section
numbers remove, and I don't think it's worth trying to unpick all that.
Change-Id: I31457c225e68ee44d383a5a148fdcc80a3430864
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47464
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
In cases where the RPC from acvptool to modulewrapper is expensive,
these iterated tests take excessive amounts of time. By moving the
inner loop into the module wrapper the number of round-trips is reduced
by 1000×.
Change-Id: Ic047db071239492e416a08cab60d6a7e2905e8dc
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47364
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
David Benjamin
Adam Langley
Adam Langley
Daniel Thornburgh
Nevine Ebeid
Bob Beck
Piotr Sikora
Pete Bentley
Dan McArdle