RFR: 8315487: Security Providers Filter [v17]

Tue Dec 17 21:43:48 UTC 2024

Let’s simplify the discussion.  Just one question, is the filter able to
filter out FIPS unapproved crypto algorithms and parameters form a provide?
If the answer is yes, I will support this proposal and you take any
possible action to make it.  If the answer is no, I will stop to discuss as
well and you need to workaround the words in JEP or revise the JEP from
scratch.

Yes or no?  Let me know.

Xuelei

On Tue, Dec 17, 2024 at 1:26 PM Xue-Lei Andrew Fan <xuelei at openjdk.org>
wrote:

> On Tue, 17 Dec 2024 17:57:02 GMT, Martin Balao <mbalao at openjdk.org> wrote:
>
> >> In addition to the goals, scope, motivation, specification and
> requirement notes in [JDK-8315487](
> https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe
> the most relevant decisions taken during the implementation of this
> enhancement. These notes are organized by feature, may encompass more than
> one file or code segment, and are aimed to provide a high-level view of
> this PR.
> >>
> >> ## ProvidersFilter
> >>
> >> ### Filter construction (parser)
> >>
> >> The providers filter is constructed from a string value, taken from
> either a system or a security property with name
> "jdk.security.providers.filter". This process occurs at
> sun.security.jca.ProvidersFilter class —simply referred as ProvidersFilter
> onward— static initialization. Thus, changes to the filter's overridable
> property are not effective afterwards and no assumptions should be made
> regarding when this class gets initialized.
> >>
> >> The filter's string value is processed with a custom parser of order
> 'n', being 'n' the number of characters. The parser, represented by the
> ProvidersFilter.Parser class, can be characterized as a Deterministic
> Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the
> starting point to get characters from the filter's string value and
> generate state transitions in the parser's internal state-machine. See
> ProvidersFilter.Parser::nextState for more details about the parser's
> states and both valid and invalid transitions. The ParsingState enum
> defines valid parser states and Transition the reasons to move between
> states. If a filter string cannot be parsed, a
> ProvidersFilter.ParserException exception is thrown, and turned into an
> unchecked IllegalArgumentException in the ProvidersFilter.Filter
> constructor.
> >>
> >> While we analyzed —and even tried, at early stages of the development—
> the use of regular expressions for filter parsing, we discarded the
> approach in order to get maximum performance, support a more advanced
> syntax and have flexibility for further extensions in the future.
> >>
> >> ### Filter (structure and behavior)
> >>
> >> A filter is represented by the ProvidersFilter.Filter class. It
> consists of an ordered list of rules, returned by the parser, that
> represents filter patterns from left to right (see the filter syntax for
> reference). At the end of this list, a match-all and deny rule is added for
> default behavior. When a service is evaluated against the filter, each
> filter rule is checked in the ProvidersFilter.Filter::apply method. The
> rule makes an all...
> >
> > Martin Balao has updated the pull request with a new target base due to
> a merge or a rebase. The incremental webrev excludes the unrelated changes
> brought in by the merge/rebase. The pull request contains one additional
> commit since the last revision:
> >
> >   Add a debug message to inform the Filter property value read.
> >
> >   See more in
> https://mail.openjdk.org/pipermail/security-dev/2024-October/041800.html
> >
> >   Co-authored-by: Martin Balao Alonso <mbalao at redhat.com>
> >   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>
> Then, please redefine the scope and purpose of this feature.   It is just a
> part of the solution.
>
> Xuelei
>
> On Tue, Dec 17, 2024 at 6:30 AM Martin Balao Alonso <
> ***@***.***> wrote:
>
> > A FIPS-certified cryptographic module needs to do more than blocking
> > algorithms or key strengths when configured in FIPS mode. E.g. it needs
> to
> > run self-integrity tests on startup, that you typically don't want if
> FIPS
> > mode is off. Thus, FIPS-certified security providers will probably have
> > their own configuration for FIPS, their own policy —which is under the
> > certification scope—, and will have their own mechanism to offer the
> right
> > algorithms and parameters. The Filter will be out of scope when they go
> > through the certification process. That is the current situation and we
> are
> > not proposing any change there.
> >
> > The goal of the Filter is to block cryptographic services from
> > non-FIPS-certified providers. This is a help for Java applications to
> avoid
> > mistakenly/inadvertently using non-FIPS cryptography. E.g. you plug-in an
> > OpenSSL provider configured in FIPS mode and SUN for X.509 certificates.
> > With the Filter, you can make sure that MessageDigest from SUN is not
> > available.
> >
> > —
> > Reply to this email directly, view it on GitHub
> > <https://github.com/openjdk/jdk/pull/15539#issuecomment-2548616098>, or
> > unsubscribe
> > <
> https://github.com/notifications/unsubscribe-auth/AQSB3EDMCXKLFLKWWNISA2T2GAYSBAVCNFSM6AAAAAA4HWWOTGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBYGYYTMMBZHA
> >
> > .
> > You are receiving this because you were mentioned.Message ID:
> > ***@***.***>
> >
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-2549664671
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241217/f34ddf86/attachment-0001.htm>