Title:
Bug 85815:There seems to be a problem with the RSA BSafe CryptoJ Library included in ColdFusion enterprise and ColdFusion developer edition that prevents it from working with certain SSL Certificates
| View in TrackerStatus/Resolution/Reason: Closed/Fixed/
Reporter/Name(from Bugbase): Jason Dean / Jason Dean (Jason Dean)
Created: 01/13/2011
Versions: 9.0
Failure Type: Unspecified
Found In Build/Fixed In Build: 0000 / 277820
Priority/Frequency: Major / Unknown
Locale/System: English / Platforms All
Vote Count: 20
Problem:
There seems to be a problem with the RSA BSafe CryptoJ Library included in ColdFusion enterprise and ColdFusion developer edition that prevents it from working with certain SSL Certificates. Specifically it seems to be a problem with the Diffie-Hellman Key Agreement(KeyAgreement.DiffieHellman) (credit: Pete Freitag)This is reproducible with several URLs, I have provided samples below.The specific underlying problem seems to be "Cannot build a secret key of algorithm TlsPremasterSecret" (Credit: Todd Sharp)This can be worked around by disabling the CryptoJ lib with a JVM Arg: -Dcoldfusion.disablejsafe=true (Credit: Nathan Mische)Disabling CryptoJ works because the way JCA/JCE works is that it will simply use the next Crypto Provider available, which in this case is the Sun Provider, which works just fine. It can also be worked around by removing the KeyAgreement from the provider at runtime (Credit: Simon Free and Pete Freitag)<cfset objSecurity = createObject("java", "java.security.Security") /><cfset storeProvider = objSecurity.getProvider("JsafeJCE") /><cfset dhKeyAgreement = storeProvider.getProperty("KeyAgreement.DiffieHellman")><!--- dhKeyAgreement=com.rsa.jsafe.provider.JSA_DHKeyAgree ---><cfset storeProvider.remove("KeyAgreement.DiffieHellman")>Do your http call, but pack the key agreement if necessary.<cfset storeProvider.put("KeyAgreement.DiffieHellman", dhKeyAgreement)>THis work around removing the KeyAgreement which seems to be causing the problem. I am not sure what is going on in the underlying library that causes this to eliminate the problem. Perhaps it is simply using another means of key agreement.Both of these work arounds possibly compromise the FIPS-140 compliance of ColdFusion Enterprise.This issue extends back to at least ColdFusion 8 (possibly CF7).Since this affects CF's FIPS-140 compliance, I would consider this a pretty critical bug. It also makes it tough to use certain public facing APIs that do not require the CryptoJ Lib. Using the Sun provider (the second choice in the JCA/JCE with CF) works just fine.I have heard reports of this affecting ColdFusion Standard as well. But in my own and another's testing these issues do not seem to affect CF Standard (Credit: Ray Camden). THis makes sense, since CF Standard does not include the CryptoJ Lib.
Method:
<cfhttp url="https://app.zencoder.com/api/jobs"><cfdump var="#cfhttp#"><cfhttp url="https://api.basecamphq.com"><cfdump var="#cfhttp#">
Result:
I/O Exception Peer Not Authenticatd
----------------------------- Additional Watson Details -----------------------------
Watson Bug ID: 3043069
External Customer Info:
External Company:
External Customer Name: Jason Dean
External Customer Email: 4EF2503348075808992015A9
External Test Config: 01/13/2011
Attachments:
Comments: