Jenkins setup → Core: 2.516.2, Credentials:1419.v2337d1ceceef
Hello team!
We’ve been warned by auditing companies that AES CBC-256 is starting being considered weak. I wanted to have some visibility about potential changes to go to something stronger…
Best Regards
JM
Hi JM,
We’ve been warned by auditing companies that AES CBC-256 is starting being considered weak.
Did they tell you why? I would also ask for the reasons behind vague statements like this as encryption is complex and what is good for A can be bad for B and vice versa!
The “weakness” of AES/CBC compared to AES/GCM (which I guess they are pushing) is as far as I am aware the following:
Data Integrity: AES/GCM provides tamper evidence so if someone manipulates the data it is apparent.
Padding. which can suffer a padding oracle attack
So if we break these down, Credentials uses AES/CBC for data at REST.
Data integrity is useful when transferring data across untrusted system (e.g. think TLS encryption between a web server and client). In order to tamper with the credentials data you would need write access to the JENKINS_HOME directory. If you have write access to JENKINS_HOME you are already an admin it is game over as far as any security is concerned, the filesystem is considered trusted (the filesystem itself be encrypted for more guarantees).
As for padding attacks, you need to leak the data on the padding attack, but the encryption/decryption is performed solely inside Jenkins and is not under the control of the attacker. So there is no place for an attacker to attempt to perform this timing attack as they can not submit encrypted data to Jenkins for decryption.
Hello!
Let me come back with the exact reasoning.
Thanks for having taken the time to answer.
BR