search

envoyproxy / envoy-openssl

Envoy OpenSSL extensions
Apache License 2.0
47 stars 45 forks source link

Roadmap #1

Open venilnoronha opened 5 years ago

venilnoronha commented 5 years ago

Here's a high-level roadmap for the project.

/cc @envoyproxy/openssl-dev

Feel free to add/edit.

rojkov commented 5 years ago

Added a reference to https://github.com/envoyproxy/envoy/pull/7377

rojkov commented 5 years ago

I'm marking the second task as done. Thanks @bdecoste !

urosgruber commented 3 years ago

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.

mattklein123 commented 3 years ago

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?

dmitri-d commented 3 years ago

There’s also maistra-envoy (https://github.com/maistra/envoy), which is a port of istio-envoy to OpenSSL, which is released as part of Service Mesh. We are currently working on a port of istio-envoy 1.8 (envoy release 1.16.1) to OpenSSL, the changes might be useful in your port too.

-d

On Jan 12, 2021, at 5:57 AM, Uros Gruber notifications@github.com wrote:

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.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

PiotrSikora commented 3 years ago

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.

urosgruber commented 3 years ago

@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

antJack commented 3 years ago

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 _envoylibrary.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_buildconfig.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.

UlasSAYGINIM commented 2 years ago

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.

PiotrSikora commented 2 years ago

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 (https://github.com/envoyproxy/envoy-openssl/issues/1#issuecomment-758889549), 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 (https://github.com/envoyproxy/envoy-openssl/issues/1#issuecomment-758859659), 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

mattklein123 commented 2 years ago

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.

twghu commented 2 years ago

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.

ipuustin commented 2 years ago

@mattklein123 Could you point your contact to this issue so we can discuss the possible approaches here? Thanks!

mattklein123 commented 2 years ago

@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.