Skip to content

tls-rustls-aws-ls-sys-fips build option #1323

Open

Description

@xnox

Hi,

I see that there is tls-boring and tls-ring build flags available.

would you consider adding tls-aws-ls ? specifically to use rustls, with aws-ls-sys, with/without the fips feature flag of the latter one.

If such addition would be welcomed, let me know if you need help implementing it. The primary benefit of getting access to https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4759 CVMP cert under FIPS 140-3.

Activity

  1. howardjohn commented on Sep 20, 2024

    @howardjohn
    Member

    fwiw the boring crate is also has a cvmp 140-3 certification

  2. howardjohn commented on Sep 20, 2024

    @howardjohn
    Member

    Well actually the version currently is in the old one which is 140-2,but should be updated soon

  3. howardjohn commented on Sep 20, 2024

    @howardjohn
    Member

    Anyhow, from a technical standpoint it's harder to add providers than other projects since we need to do CSRs. This is the "rcgen" stuff. Might be simple but need to make sure we have a solution.

    from a project standpoint I think the main thing is we want to make sure any we are are actively maintained by someone so we don't end up with a bunch of providers causing issues.

  4. xnox commented on Sep 20, 2024

    @xnox
    Author

    Basically the aws-lc is now the default rustls provider (instead of ring), and more stuff is likely standertise on it.

    And the fips version of it the 2.0.0 lifecycle policy is much kinder, thus easier to deploy compliance with.

  5. ilrudie commented on Sep 23, 2024

    @ilrudie
    Contributor

    Interesting. I had not seen that rustls switched their default.

  6. xnox commented on Sep 23, 2024

    @xnox
    Author

    Interesting. I had not seen that rustls switched their default.

    I think that happened in rustls/rustls@7415b5f

  7. howardjohn commented on Sep 23, 2024

    @howardjohn
    Member

    @xnox do you have a specific desire to have the AWS module or to have a FIPS validated module? Id the former, would be curious to know why

    Currently the plan has been to offer boringssl as the FIPS validated module primarily, as is the same module used in Go and Envoy

  8. howardjohn commented on Sep 23, 2024

    @howardjohn
    Member

    If we do this one other thing I am reminded of - boringssl and aws-lc add some onerous build steps. With boring we are able to use a pre compiled build. It would be great to do this with aws as well if we adopt it.

    If it's the 3rd most recommended choice I suppose build ergonomics may not be as important, though.

  9. xnox commented on Sep 23, 2024

    @xnox
    Author

    @xnox do you have a specific desire to have the AWS module or to have a FIPS validated module? Id the former, would be curious to know why

    Currently the plan has been to offer boringssl as the FIPS validated module primarily, as is the same module used in Go and Envoy

    My goal is to minimize number of cryptographic modules, and to ensure that FIPS/non-FIPS use as close analogous implementations as possible. For rust, today it seems that the best choice is rustls with aws-lc (in either non-fips or fips feature flags).

    For go, most distributions do not use boringssl (because it allows to use many unapproved algorithms and google provides no support for such build of go and the policy is difficult to use). For go, most use OpenSSL via https://github.com/microsoft/go (or https://github.com/golang-fips/go). By most I mean: RHEL, Canonical/Ubuntu, Microsoft/Azure Linux, Chainguard Images / Wolfi OS. To achieve usable Go FIPS compliance.

    Envoy in FIPS mode for now only buildable using boringssl. There is attempt to provide openssl implementation but it is of unknown production status.

    Note at chainguard we do provide FIPS builds, with CVE patched dependencies of all of the above mentioned components already. But not yet ztunnel.

  10. xnox commented on Sep 23, 2024

    @xnox
    Author

    If we do this one other thing I am reminded of - boringssl and aws-lc add some onerous build steps. With boring we are able to use a pre compiled build. It would be great to do this with aws as well if we adopt it.

    If it's the 3rd most recommended choice I suppose build ergonomics may not be as important, though.

    I expect most distributions to provide a prebuilt aws-lc for usage in aws-lc fips crate. And the build instructions are actually fairly relaxed for asw-lc. At least they appear easier to meet than boringssl ones.

  11. xnox commented on Sep 23, 2024

    @xnox
    Author

    Some of the above points maybe very moot - in the context of ztunnel and how well coded it is. You appear to be very FIPS-friendly, intentionally picking a tiny subset of cryptography to use; and intentionally pick widely compatible, certified and popular ones.

  12. bleggett commented on Sep 24, 2024

    @bleggett
    Contributor

    works for me as long as multiarch build support is at-least-as-robust as boring, hopefully less painful.

  13. howardjohn commented on Sep 24, 2024

    @howardjohn
    Member

    @xnox thanks for the additional context. Overall I think this makes sense.

    Here is how I would go about it:

    • Add a new config feature, opt-in, to build with aws-lc. I doubt we need to bother with a fips/non-fips flag there, under the assumption non-fips builders will be fine with ring or whatever we choose to default to.
    • CI added for tests, but no OSS Istio release builds with it set (matching boring)
    • We may want to do some refactoring now as we go from 2 -> 3 options but probably nothing crazy

    One wrinkle around FIPS and ztunnel in general is wrt istio/istio#52926, btw.

    In terms of implementation I don't think it would be a priority from any of the current maintainers I am aware of, so if you are interested in this it would be great if you are able to contribute this directly. Happy to help with this/review the PR/etc

  14. xnox commented on Dec 24, 2024

    @xnox
    Author

    Also note #820 which was merged

    However note that rustls currently does not have a FIPS feature for the rustl-webpki depedency - see rustls/webpki#307

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions