Roadmap
venilnoronha opened this issue · 14 comments
Here's a high-level roadmap for the project.
- Make boringssl-based TLS extensions fully unpluggable
- Move TLS extensions into envoy-openssl
- Convert the crypto library, etc. to an extension and implement one based on OpenSSL
- Implement OpenSSL patches for jwt-verify, quiche, etc.
- Implement a build and test pipeline which is triggered on commits into the main envoy project
- Pull latest Envoy before building
- Implement tests in the main envoy project to prevent spillage of SSL related code into classes which don't have proper SSL abstractions/extension mechanisms
/cc @envoyproxy/openssl-dev
Feel free to add/edit.
Added a reference to envoyproxy/envoy#7377
I'm thinking about porting this project to FreeBSD and I would like to know how stable this is and how in sync is this with Envoy that has BoringSSL as a dependency? The thing is FreeBSD does not have BoringSSL support and I would love to have envoy available in FreeBSD with OpenSSL support.
The thing is FreeBSD does not have BoringSSL support and I would love to have envoy available in FreeBSD with OpenSSL support.
cc @PiotrSikora @davidben I haven't checked but it would be really surprising to me if boringssl didn't compile on freebsd?
The thing is FreeBSD does not have BoringSSL support and I would love to have envoy available in FreeBSD with OpenSSL support.
cc @PiotrSikora @davidben I haven't checked but it would be really surprising to me if boringssl didn't compile on freebsd?
There is BoringSSL in FreeBSD ports, so it's unclear to me what's the real issue.
@PiotrSikora I'm not entierly sure why, but I believe there might be some conflicst with SSL available on porting tools. But maybe Alexey Dokuchaev have more infor about this https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247236
Any update on this thread?
Recently we need to upgrade to a newer version of Envoy(v1.18.3) and use OpenSSL for some specific cipher suites(ref to RFC8998).
But I realized that this repo cannot simply meet our needs, one of the main reasons is that BoringSSL is more embedded into Envoy nowadays, and an unpluggable TLS transport socket is far from enough.
For example, we can now see“ bssl::UniquePtr” in include/envoy/ssl/handshaker.h and much more dependencies to “//source/extensions/transport_sockets/tls” in source/common/quic, etc.
Therefore we may need some more modifications on Envoy to meet our needs. Perhaps we can extend the envoy library to replace all the above-mentioned dependencies with the OpenSSL-based version. For example:
in envoy_library.bzl:
load("@envoy_build_config//:extensions_build_config.bzl", “DEP_REMAPPING”)
dep envoy_cc_library(deps = []):
for dep range deps:
if dep in DEP_REMAPPING:
// replace with the new one
else
// use the original one
in envoy_build_config/extensions_build_config.bzl:
DEP_REMAPPING = {
"//include/envoy/ssl:handshaker_interface": "@envoy_openssl//include/envoy/ssl:handshaker_interface",
"//source/extensions/transport_sockets/tls:ssl_socket_lib": "@envoy_openssl//source/extensions/transport_sockets/tls:ssl_socket_lib",
}
Any suggestion or better way for this? We’d like to put some effort into this if there is an acceptable solution.
Hi People! is there any development on this side? because FreeBSD does not have envoy in any version! please consider supporting to port the envoy to FreeBSD port tree. A lot of people will use it.
Hi People! is there any development on this side? because FreeBSD does not have envoy in any version! please consider supporting to port the envoy to FreeBSD port tree. A lot of people will use it.
As mentioned earlier in this thread (#1 (comment)), there is a BoringSSL port in FreeBSD (although, it doesn't seem to be actively maintained), and I can guarantee you that using it is going to be much easier than trying to make Envoy work with OpenSSL.
As mentioned earlier in the thread (#1 (comment)), the people behind this effort (Red Hat) moved all their development into a fork at https://github.com/maistra/envoy, which is developed as part of their Istio distribution (Maistra), which means it's quite a bit behind Envoy HEAD, and it's not officially supported by Envoy team.
This effort seems to be completely abandoned, so it might be worth revisiting how this is done, or completely pulling the plug on this repo. cc @envoyproxy/senior-maintainers @envoyproxy/openssl-dev
This effort seems to be completely abandoned, so it might be worth revisiting how this is done, or completely pulling the plug on this repo. cc https://github.com/orgs/envoyproxy/teams/senior-maintainers https://github.com/orgs/envoyproxy/teams/openssl-dev
I would have said the same thing a week ago, but FWIW, I was recently contacted by Microsoft who might be interested in restarting this effort and maintaining it. I will circle back when I know more.
Introduction
Red Hat, IBM, and Intel have been investigating how to can achieve BoringSSL parity with OpenSSL.
While the effort has been "stalled" for a while, the work involved in an OpenSSL variant for each release is non-trivial, providing motivation to find a more expedient solution:
Current State
[WIP]
Rationale
We maintain our work on our OpenSSL-based transport socket as a modification to Envoy’s existing BoringSSL transport socket in maistra/envoy. The current process is to periodically (manually) merge the main branch of envoyproxy/envoy into the maistra/envoy, resolving conflicts and double checking everything on the go. The mechanics of this are currently under review.
It has been a while since the main branch has been brought up to date, and a first stab at that task taught us that this is not trivial. Furthermore, talks with external contributors and team members indicate that there is a shared understanding of there being ample opportunities for enhancing how we approach this.
Goals
This doc aims to align everyone involved on the best way to take the Envoy OpenSSL work forward. Furthermore the proposals in here aim to:
Minimize risks resulting from manual work currently associated to tracking upstream
Minimize the amount of manual work currently associated to tracking upstream
Minimize friction for cross company collaboration
Consolidate how we do things into docs/procedures
Proposals
Separate our transport socket extension
Today the OpenSSL-based Envoy proxy is materialized by forking the upstream Envoy repository and modifying the BoringSSL based transport socket and unit tests. This represents 99% of the changes we made to the fork. Instead of managing our extension as changes to an existing one, we could leverage Envoy’s extension model and maintain this work as a separate extension.
Advantages:
Instead of merge conflicts we will be managing build breakages as we update the Envoy dependency. Merge conflict resolution is risky business; this seems like a favorable tradeoff.
Instead of having to worry about merging in functional changes that we don’t want, we would need to switch to monitoring a set of upstream files for changes (the original boringssl transport socket implementation + tests) to see if we are interested in them.
We will have a distinct and separate commit history for the OpenSSL work.
Move the repository upstream
There are several advantages to moving the work into an upstream repository:
A vendor neutral repository reduces friction for external companies to contribute.
Enhanced discoverability/visibility; upstream is a much more popular place.
Leverage CNCF/envoyproxy CI resources.
Implement a pluggable crypto system
If we have our code as an extension and out of the way of the Envoy train, we can work on creating an abstraction between the openssl implementation and the ssl transport socket extension. If we can have an interface that works with both crypto implementations, we can go back upstream and propose a working alternative or replacement to the current ssl transport socket implementation which is hard-tied to BoringSSL.
Results of Meeting 15 November.
The current upstream repository envoy-openssl encapsulates the source/extensions/transportsockets/tls changes for OpenSSL based Envoy.
The group agreed that of all the options the use of this repository is the best option as maintaining forks of envoy and separate submodules etc represented a significant and unnecessary overhead.
The upstream repository has not been updated in 2 years and we should focus our efforts on bringing it up to date with the latest Envoy main branch together with the changes in the Maistra Envoy repository. Here we need only initially consider the commits to the source/extensions (and related tests) that are applicable to the extensions source as related to OpenSSL.
Once the upstream repository is up to date, we can utilise the github actions to perform nightly builds and reporting of failures (using bazel --disc-cache option will provide economic builds).
Action items to follow on responsibilities for checking changes, errors, security issues etc.
We probably need a new README.md to reflect the changes or scope of this sub-project in the upstream repository.
We have another repository bss-wrapper that we should merge into the upstream repository.
Meetings
FWIW here is the meeting document for those interested.
@mattklein123 Could you point your contact to this issue so we can discuss the possible approaches here? Thanks!
@mattklein123 Could you point your contact to this issue so we can discuss the possible approaches here? Thanks
I already did. Also free to email me and I can make an email connection.