I am trying to resolve this problem:
Using the following endpoint, obtain and decrypt the encrypted message. You may use any language and library of your choice to implement the solution.
POST https://challenge-b375.szechuen.workers.dev
Request
Body (Plain): Your X25519 public key (Base64)
Response
Body (JSON)
publicKey: Our ephemeral X25519 public key (Base64)
encryptedMsg: Message encrypted with AES-CBC using the X25519 shared key (Base64)
iv: IV for AES-CBC encryption (Base64)
Sample Request
$ curl https://challenge-b375.szechuen.workers.dev -d 'fjUfGYyHBYBRVMJp+P2aSHghq1K2s47ytzXLLhKWzQ4='
Sample Response
{"publicKey":"1ObUUf0ktnLKFGqbbuD63L6kQWS9YzUffucZzLJRJRE=","encryptedMsg":"22RhujlT7rGpgs1bZ4TshPYhHUvsjSVsuHOtBjC+rdEq1S4r+ozfdhMXU2tVdFtoSP2l7d1WkLZfioMSnNW20kt8s7+r9z72Ona7GWMg3q2C77jS6LOvh62FG1+uX5yea6YHdU7RceKqwiI00wyj7Q==","iv":"XWYiWHaw0m73nRKVvTPKXg=="}
I used openssl, but received "Bad magic number" in the output. Below is my openssl command where I've transformed the private key and the iv in binaries. encryptedMsg contains the message opbtained with
curl https://challenge-b375.szechuen.workers.dev -d 'fjUfGYyHBYBRVMJp+P2aSHghq1K2s47ytzXLLhKWzQ4='
openssl enc -base64 -aes-256-cbc -in encryptedMsg -d -k 666A55664759794842594252564D4A702B5032615348676871314B3273343779747A584C4C684B577A51343D -iv 65397530355659736452677571462B616C794E7965673D3D
bad magic number
I tried without transforming them in binaries, but I received errors. I also couldn't find a website that would decrypt it. Any help would be appreciated :)
Thanks
Related
I have a problem when I am making a request with Axios in node getting Error: ca md too weak.
I am sending .pfx file and password for the pfx certificate file.
I can easily access API using Postman and sending pfx certificate and password, but making a request with Axios in node js (v. 18.0) I get Error: ca md too weak.
I don't want to downgrade Node version and using: process.env.NODE_TLS_REJECT_UNAUTHORIZED = 0; also doesn't help.
Also to connect to the server I have to use VPN and this error pops up even if I haven't turned on VPN.
Is it possible to bypass this check, so I can send a request as I do in the Postman?
Here is a code example:
agent = new https.Agent({
pfx: fs.readFileSync((process.cwd() + "\\src\\sources\\KIISWSClient.pfx")),
passphrase: 'password',
rejectUnauthorized: false,
});
userKiisData = axios.post('https://ws-kiis.hlk.hr/AdeoMembersPublicService.svc/WSPublic/BasicData', {
Username: "myusername",
Role: "role"
}, {
auth: {
username: "user",
password: "mypassword"
},
httpsAgent: agent
}
return userKiisData
Here is the error:
Error: ca md too weak
at configSecureContext (node:internal/tls/secure-context:278:15)
at Object.createSecureContext (node:_tls_common:113:3)
at Object.connect (node:_tls_wrap:1622:48)
at Agent.createConnection (node:https:142:22)
at Agent.createSocket (node:_http_agent:343:26)
at Agent.addRequest (node:_http_agent:294:10)
at new ClientRequest (node:_http_client:311:16)
at Object.request (node:https:352:10)
TLDR: jump to end if you don't care about understanding
rejectUnauthorized directs nodejs to accept (some) invalid certs used by the server instead of aborting the connection, but this error is occurring on your own client cert/chain not that of the server. (That's why it can occur even without the VPN you need for an actual connection.) The "CA_MD_TOO_WEAK" check occurs in modern versions of OpenSSL (1.1.0 up) but can vary depending on how the OpenSSL was built, thus for nodejs it also depends whether your nodejs was built to use its own embedded OpenSSL (usual on Windows) or one already provided on the system where it is installed (usual on Linux).
You can look at the signature algorithms(s) used in your cert chain with openssl if you have (or get) it on this machine or you (may, can, and do) copy the pfx to a machine where ditto. First do
openssl pkcs12 -in yourpfxfile -nokeys >temp0
and look at temp0; it should contain one or more blocks each consisting of a subject= line, an issuer= line, a -----BEGIN CERTIFICATE----- line, several lines of base64, and an -----END CERTIFICATE----- line. (Likely there are also Bag Attributes: lines optionally followed by indented lines; ignore those.)
If there is only one block and it has the same value for subject and issuer, then your error should not have happened, because the cert is selfsigned and OpenSSL should not be checking signature strength on selfsigned cert. Otherwise, do
openssl x509 -in temp0 -noout -text -certopt no_pubkey,no_sigdump,no_extensions
and you should get a few lines of output that includes signatureAlgorithm: x where x is of the form {hash}withRSAEncryption ecdsa_with_{hash} dsa-with-{hash} or dsaWith{hash}. If {hash} is MD5, the signature on your certificate is weak and doesn't provide the security it claims -- although in your situation, if the server accepts it in spite of this weakness, it's probably not your problem.
If the first (leaf) cert is not selfsigned (subject not same as issuer) and its signature algorithm does not use MD5, either
the OpenSSL used by your nodejs is set to a higher than usual 'security level' -- this is not likely for a nodejs that has embedded OpenSSL but more plausible for a system-provided one, especially on security-focussed systems like RedHat 8; or
the problem is with a cert other than the first one (i.e. a CA cert), but this shouldn't occur if your cert(s) are from a properly-run CA because such a CA should never have a higher CA cert signed with a weaker key or signature algorithm than the leaf cert, except the selfsigned root whose signature doesn't matter, and isn't checked so it wouldn't cause your error. However, if you want, break each block other than the first into a separate file, and repeat the openssl x509 procedure above on each except if the last one has subject and issuer the same don't check it because it is the selfsigned root cert.
Anyway, workaround: add to your https-Agent options ciphers: "DEFAULT:#SECLEVEL=0". This should turn off several checks designed to prevent insecure SSL/TLS connections, including the one relevant here; as a result, if you use this code to process data of any importance, it may be at higher risk depending on what the server does.
We are using PGP encryption to encrypt files before transfer. We are using the npm package OpenPGP.js to encrypt the files using a public key from the recipient. I have exported the public key in armored format to use with openpgp.encrypt function.
Here is the code to encrypt the file:
const publicKey = await openpgp.readKey({ armoredKey: key.publicKey });
const encrypted = await openpgp.encrypt({
message: await openpgp.createMessage({ text: readStream }),
encryptionKeys: publicKey
});
However the function call produces this error:
Error: Error encrypting message: Could not find valid encryption key
packet in key ea8be7d9f2fd53a7: elgamal keys are considered too weak.
The output of gpg --list-keys gives the following information
pub dsa1024 2010-07-23 [SCA]
ABCDEFGHIJK
uid [ unknown] my recipient <my.recipient#email.com>
sub elg2048 2010-07-23 [E]
I'm able to encrypt a file using GnuPG, but OpenPGP does not seem to like the public key. Is this error message valid? Do I need to request another key from the client, or is there a way to bypass this error message?
*Edit: After some research I have found that DSA-1024/(ElGamal-anything) is not safe anymore, so I'll probably have to request new keys be made.
OpenPGP implementations have different security considerations, and OpenPGP.js seems decided to reject DSA/ElGamal by default via this PR: https://github.com/openpgpjs/openpgpjs/pull/1264/files#
However it is possible to override this behaviour via config, examples are available in tests.
I am trying to validate calls to my API from an IOS app. I have generated keys for backend like so:
openssl genrsa -aes256\
-passout pass:pass\
-out signature_private_key.pem 2048
openssl rsa \
-in signature_private_key.pem\
-passin pass:pass\
-out signature_public_key.pem\
-outform PEM\
-pubout
In the node backend I am validating the call like this:
static createSignatureString(bodyString, apiKey, timestamp) {
const bodyHash = crypto
.createHash("sha256")
.update(bodyString)
.digest("base64");
return `${bodyHash}:${apiKey}:${timestamp}`;
}
static createSignature(string, privateKey) {
const sign = crypto.createSign("RSA-SHA256");
sign.write(string);
sign.end();
return sign.sign(privateKey, "base64");
}
static verifySignature(xMessageSignatureString, signature, publicKey) {
const verify = crypto.createVerify("RSA-SHA256");
verify.update(xMessageSignatureString);
verify.end();
return verify.verify(publicKey, new Buffer(signature, "base64"));
}
The mobile app uses a .p12 file to generate a signature and send to the rest API. Given the above how would I generate a .p12 file using openssl that would send a valid signature?
To create a PKCS12 file you need the private key (which you have) and an (X.509) certificate containing the matching publickey, or if applicable a series of certificates starting with the matching one called a 'chain'. Either you can get this certificate/chain from a CA, or OpenSSL can create a self-signed certificate which uses no chain and which is acceptable to many applications but not all:
openssl req -new -x509 -key privatekeyfile -out certfile [-days N] [-$hash]
-days N specifies how long you want the cert to be valid; for dummy certs it is common to choose a large value like 3650 for about 10 years, or more, although you can as easily generate a replacement in the future if you need to. It's safest not to go beyond 2037 because some C programs, though fewer than in the past, are still affected by the Y2038 bug. You can specify the hash used in the self-signature; this doesn't really matter, but some people prefer to avoid the default (SHA1) and use e.g. -sha256 instead. You can specify the 'subject' name on the commandline if you wish with -subj; see the man page. There are also many extensions which can be placed in an X.509 certificate, but whether you want any of them and if so which ones and what values varies depending on the application(s) that will use it.
Once you have the cert and privatekey in files:
openssl pkcs12 -export -in certfile -inkey privatekeyfile -out p12file
On both of these commands you can specify passwords on the commandline, as you did in the commands you posted, if you prefer; see the man pages and/or usage messages. Remember that this practice makes your passwords temporarily visible to other processes, often including other users if on a shared system.
For clarity: on CA-issued certs the signature hash does matter and should not be SHA1 or weaker, but on root or self-signed certs it normally does not matter.
I'm trying to get client certificate verification working with ColdFusion10 http requests. Currently, all I'm getting back is a 403.7. I believe ColdFusion isn't picking up my client certificate. Below is the steps I've currently taken to install and get it set up.
What I've done:
Created a self-signed SSL certificate and installed it to my default website on IIS 7.5.
Installed the SSL cert into CF store.
Tested HTTPS request, everything works fine.
Followed this guide for CA and Client Certs. https://ondrej.wordpress.com/2010/01/24/iis-7-and-client-certificates/
Installed the CA cert to server and client (through MMC). Installed client cert (.pfx) on client.
Tested in local browser, everything is working as it should up to this point.
Created another client cert for CF10 (.cer, .pvk, .pfx).
Added the CA cert into CF store.
Tested, HTTPS rejected with 403.7.
Added CA cert, client .pfx and .cer through MMC under CF10.
Tested, rejected again with 403.7 still.
I've seen that there has been issues with CFHTTP and client certs before, but I haven't found an solution yet.
If anyone can help me with this, it would be great.
EDIT:
After doing what Miguel-F suggested, I skimmed through the log files and found that my CA was imported inside the ColdFusion trust store, but my client certificate wasn't there. I assume this is the reason for the 403.7.
However, I can't add my client certificate(.pfx) to the trust store using certman or keytool through cmd. I created the .pfx by merging my .cer and .pvk together, so I have both of those also.
How can I add my .pfx to the trust store so that Coldfusion picks it up and validates my https?
EDIT #2:
After following this to add my .pfx to the keystore, I can now see my client cert along with my CA being added as 'trusted cert' during the https request.
However, I'm still getting the 403.7 - Forbidden error.
Edit #3:
The handshake in ssl debug info after adding my .pfx (see edit #2) is:
'Is initial handshake: true'
'catalina-exec-3, WRITE: TLSv1 Handshake, length = 181' (Several of these in 1 request)
Edit #4 (More Debug Info):
The last section above where it returns 403 in the debug info looks like HTML content for the error page returned by the server. Just above that however is this:
catalina-exec-3, READ: TLSv1 Application Data, length = 5808
Padded plaintext after DECRYPTION: len = 5808
0000: 48 54 54 50 2F 31 2E 31 20 34 30 33 20 46 6F 72 HTTP/1.1 403 For (Example of the HTML error content)
Edit #5:
I can see my client cert being added as a trusted cert during the start of the request... It's just not using it.
adding as trusted cert:
Subject: CN=George CF10
Issuer: CN=MyPersonalCA
Algorithm: RSA; Serial number: 0x-431b7d9911f9856cb0adf94d50bb1479
Valid from Fri Apr 01 00:00:00 BST 2016 until Wed Apr 01 00:00:00 BST 2020
Edit #6:
After adding setClientCert(path to my .pfx) and setClientCertPassword(client cert password) to my https request, I'm seeing this error:
Error while trying to get the SSL client certificate:
java.security.UnrecoverableKeyException: Could not decrypt key: Could not decode key from BER. (Invalid encoding: expected tag not there.).
Check that the certificate path and password are correct and the file is in PKCS#12 format.
Too long for comment
Are you sure that you added the certificate to the correct JVM keystore? If you have upgraded Java on your ColdFusion server then it may not be in the default location. The ColdFusion administrator system information page will tell you the path in use under the "Java Home" label.
In order to turn on debugging information, add these lines to your ColdFusion server's jvm.config file located under this directory C:\ColdFusion10\cfusion\bin (by default) and restart the ColdFusion service:
-Djavax.net.ssl=debug
-Djavax.net.debug=all
This should add some more information to the coldfusion-out.log log file on your server. Post that information back here into your question for further analysis.
Adding the certificate to the Windows server using MMC is not needed and does not help your cfhttp calls from ColdFusion. It uses the Java keystore.
Response for EDIT 1 and 2
Follow the steps from this other answer on how to convert a .pfx file to the keystore.
Response for EDIT 3, 4 and 5
If you still have the ssl debug switch turned on you should see the handshake info in the log file. What does it show now that you have the certificate installed?
Have you tried using the clientCert and clientCertPassword attributes of the cfhttp tag? Note that it will require the full path to a PKCS12 format file that contains the client certificate for the request. See the docs here.
Response for EDIT 6
Take a look at this page - CFHTTP and client certificates regarding the error message you are getting: Could not decode key from BER. Excerpt from that page:
The client certificate appeared to be a normal client certificate with private key in PKCS#12 format, but from a different certificate chain then the server format. So I first had the client double-check that the chain was correctly installed on the server. Unfortunately it wasn’t that easy. I will spare you the details of what I tried, but in the end it turned out to be that the certificate was incorrectly encoded. These are the actual conversion steps I took to convert the certificate to a working state:
import the certificate in the Windows Certificate store through the MMC;
export the certificate with private key, whole chain and without strong encryption in PFX formet;
convert the PFX encoded certificate to PEM using OpenSSL:openssl pkcs12 -in raw.pfx -out intermediate.pem -nodes
re-order the certificates inside the PEM file to the following order: > - Identity certificate
Intermediate certificate
Root certificate
Private Key
convert the PEM encoded certificate to PKCS#12 using OpenSSL:openssl pkcs12 -export -out final.pkcs -in final.pem
It is probably possible to skip / merge a few of these steps (you probably just need to convert to PEM, reorder and convert back), but I really didn’t have time to explore that, I just know that this worked for me.
Solved by following this link.
I used the new .pkcs format file inside setClientCert of the HTTP request and it is now working.
import the certificate in the Windows Certificate store through the MMC;
export the certificate with private key, whole chain and without strong encryption in PFX formet;
convert the PFX encoded certificate to PEM using OpenSSL:
openssl pkcs12 -in raw.pfx -out intermediate.pem -nodes
re-order the certificates inside the PEM file to the following order:
Identity certificate
Intermediate certificate
Root certificate
Private Key
convert the PEM encoded certificate to PKCS#12 using OpenSSL: openssl pkcs12 -export -out final.pkcs -in final.pem
It is probably possible to skip / merge a few of these steps (you probably just need to convert to PEM, reorder and convert back), but I really didn’t have time to explore that, I just know that this worked for me.
I am using the Argon 3 web browser with Vuforia's image tracking. I've taken the license key of my Vuforia application and encrypted it with the GPG Keychain. I've included relevant snippets of my index.html and app.js files here.
Whenever I load up my application, I get the error:
Vuforia: could not decrypt vuforia license JSON
Running it in the debugger shows:
Unexpected token VSyntaxError: Unexpected token V
at Object.parse(native)
...
index.html
<script id="license" type="text/plain">-----BEGIN PGP MESSAGE-----
Comment: GPGTools - https://gpgtools.org
hQIMA3/IreB2WlL1AQ//WZ4evbtnP39ycrb5Z8fa1U0ugbjGOfVA1h0nhgye3IhF
UMRcDF4nJ/+LKYzcePI7orjwjfedTKfX3oVrqb8focLoQvBKwG6bgRhAIr9oTwtO
uXXOVeZFo9iCnEicwGvGtdgUVv/EQHl/VIstLg3+aEtV3Xpjnlx7r2VbUp9L7iEp
mhaTLVpAcgWyqyPYN3QoEbBEtjdRKnHAogb268ZKEWSVjtcDo9NQCI/Lfb+3ghZS
mBVxr3d4Jtb8mcpOYeUfMilD5BuzelhciJb0PPFVdj/JmcVpDsFNNX/FvFNIlm0c
qH64s+ByHGiCGcQeAJx/ZAF9cTjBYDk3HZLlPWHOD7rA1roHLujN/yf3UpLkBFFn
jEj/MMO3KSWJUAXVs+vNpThgqwgIDPeuV9nKH5QeQORpKp3zOVVsXGGYxbVY7sDl
3sbXTYghhE5XM21t4/A/iFwJxB1ndqbhfiA/kdQwsKAb17OdBVzldQ1Wh/JouTFB
m1ETnviMDKZYw7a9yiavvCjjxJHedmQNPWJVJBiOeHvGZLOpdV47TZwiXLs6dsqJ
NxB0352AOw4v66nk6RMUwclAhiz4ll0xQIPTWQpjIjOhf7COK1jFXUs+PDS21MVq
1nwjDDAjKsfj4dxPbzJUGuQwaNqI/Jg7BqhVxo/uZxtvw9c+ERcHdMY9EnK6aMLS
wSABq1kaId5VF5ccHO999AKWrB9IIhpahlFRi3asU62Cz4DZ6XqbiTDTFpmX1ZG0
6JynBv4+H/SH45TPgsBMs6IMgWPrGxTmpipte6W2X98lf5ogzWnSOGv5J7BDYtLz
0GruiAjcIOpneDx4x+i5gh/0GjBIM1ZlaHhW3Gl+zxRj8X2vhoGXFg/qB5YKk05T
womuhvDCGbO0fO1oSlZP+1kjqfsyN8k67LyWwjVvuoGfwrv3WS4dwVTB6YlCKM6l
LH1GcHmkdBVTFHQsltzbeIllcJ2QLSqWRIfPeB0eIAMh9G8P8397I9fWznBGGIz6
lXlH3AF50+cwruWTpv0Jnjyd+n3wGc14UFgaEgjWFCK04OOaZVUuRuJG900VT2qV
Nh8y9KsdTMGkVfU25BA8k04Vi6IKDnl2vbQWnYCs5wsFfj/e2/5B4Ixx7ekjgi5/
vylNv8t12ollHapJ5zSx7KzyV77N3Gam6PrORovx6evIEe+fXnPJoZkMrNRbKv/Z
uH5DMZQU3CW+Dy4hS4VEmRSM5hFa5SM7GrDAAtxsBoY2oX0AJYKs1RyhzokQCN9O
bV1qkcfW+6kKLq3HbNsMJ45ya2mcXZNaXa+JDeRE22U0csrJSsU4M5us9wZc6XiM
DuQ=
=qaTl
-----END PGP MESSAGE-----
</script>
app.js
// Tell Argon that we need Vuforia for image tracking
Argon.immersiveContext.setRequiredCapabilities('Vuforia');
var encryptedData = document.getElementById("license").text;
// initialize Vuforia with our license key
Argon.Vuforia.initialize({
encryptedLicenseData: encryptedData,
startCamera: true,
}).then(function(api)
{
// load, activate, and use our dataSet
api.loadDataSetFromURL('./auburn_map.xml').then(function (dataSet)
{
dataSet.activate();
setupStreetCar(dataSet.trackables.streetcar);
}).then(api.startObjectTracker)
.then(api.hintMaxSimultaneousImageTargets.bind(api, 2));
});
I am unsure of what to do from here. Any help would be greatly appreciated.
Edit:
I encrypted the JSON file using the GPG keychain. I created a new keypair with the email "secure#argonjs.io", went to my JSON file, highlighted the text, selected that I wanted to encrypt and did NOT sign or encrypt with password.
How did you encrypt this JSON file? You need to encrypt with the secure#argonjs.io public key, and do not sign it or encrypt with a password.