[ 
https://issues.apache.org/jira/browse/LOG4J2-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17202888#comment-17202888
 ] 

Matt Sicker commented on LOG4J2-2930:
-------------------------------------

Some remaining design considerations:

* The existing encryption in the flume appender doesn't include any metadata in 
the encrypted data. In the updated version, this will need to include 
additional metadata such as the IV used for the event, the encrypted session 
key (due to algorithms like RSA, I wouldn't want to attach this to every event 
as it can easily add up to 512 bytes each time), and some info about which 
ciphers and parameters are being used. It's possible that there are standard 
ways to encode this, though it might not be so important to do so unless we 
were integrating with something that uses it.
* With that in mind, besides the format for the metadata (along with including 
that metadata in the additional authenticated data during 
encryption/decryption), there's the question of where and when to include the 
encrypted session key.

> Add plugin for encrypting/decrypting log events
> -----------------------------------------------
>
>                 Key: LOG4J2-2930
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-2930
>             Project: Log4j 2
>          Issue Type: New Feature
>          Components: Appenders, Core, Receivers
>    Affects Versions: 2.13.3
>            Reporter: Matt Sicker
>            Priority: Major
>
> Some of the existing appenders write log events to sophisticated systems 
> which support encrypting said data at rest and in transit (e.g., storing 
> events in an encrypted SQL database using a TLS connection, writing data to 
> an encrypted filesystem or disk, etc.) However, not every system supported in 
> Log4j provides a feature or ability to encrypt and decrypt data natively. 
> There are a small collection of ad hoc cryptographic operations in Log4j 
> (e.g., {{SslConfiguration}}, {{KeyStoreConfiguration}}, 
> {{SecretKeyProvider}}, etc.) which should be refactored and extended to allow 
> for more flexibility in key management and message encryption/decryption. 
> This will allow appenders and receivers that wish to support encryption to do 
> so much more easily. This should also allow for more sophisticated use of 
> cryptography such as adding message digests or authentication tags to log 
> messages to help prevent tampering and add authenticity.
> Related resources:
> * 
> https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html
> * 
> https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html
> * 
> https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html#protection



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to